Closing in on version 2.0

So I did more digging and change the ATString for both the rotation controller and the shutter controller.

I gave them each their own address, forced some parameters and removed the RO0 command... and low and behold I see all the commands sent by the rotation controller hello :

<<< Command:H Value:

Rotator says hello!

Sending hello

Sent hello back

Asking for rain status

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:V Value:

V2.0.0.0

>>> Sending V2.0.0.0

<<< Command:Y Value:

Y0

>>> Sending Y0

<<< Command:T Value:

Get Steps 885000

>>> Sending T885000

<<< Command:R Value:

R5000

>>> Sending R5000

<<< Command:E Value:

Acceleration is 7000

>>> Sending E7000

<<< Command:P Value:

P0

>>> Sending P0

<<< Command:K Value:

K637,1220

>>> Sending K637,1220

<<< Command:B Value:

Close on low voltage 0

>>> Sending B0

<<< Command:F Value:0

It's not raining

Asking for rain status

<<< Command:F Value:0

It's in my pull request but here they are :

Rotation :

ATCE1,ID7734,CH0C,MY0,DH0,DLFFFF,AP0,SM0,WR,CN

So we force the PAN Id and the channel, as well as the rotation controller id to 0 (MY0) and the destination to the broadcast address. We also set the rotation controller as the coordinator

Shutter :

ATCE0,ID7734,CH0C,MY1,DH0,DLFFFF,AP0,SM0,WR,CN

Same thing but with a CE0 to set tit as an end device, MY1 to set the address to 1.

I need to run more test as this was done with 2 extra Arduino on my desk to see if that also works fine on the one on my test rig.

I might have found another issue .. RO0 was added the the ATString. This forces the XBee to send data as it arrives from the arduino.. this can create issue as it doesn't allow the XBee to use its internal packetizer and as the radio is half duplex it probably creates some of the issues we see. I'm going to remove it in my version and see if it helps. The default is set to 3 in the XBee, we could change it to the lowest command we send or increase it a bit so that it relies on the internal XBee buffers and timeouts.

I found more info on XBee modules ... they are not full duplex. They are half duplex only for the series 1, so you can't send and receive at the same time. The module itself has an internal buffer and it should allow for a simulated full duplex but from that I see when we send a bunch of commands and the XBee on the shutter starts responding the data stream collide and get mangled.

So the XB handling code need to be redone to deal with this.

May be XBee was not such a great idea after all.

so here is what I see when sniffing using a 3rd XBee :

H#

H#

M#M#M#V4T#R##

M4#

ME#P#K#B4#

#

V2.0.0.0#

F#F0#

So there is obviously some collision.

I also see what Pat is seeing when the Hello codes sends a bunch of commands to the shutter and a lot are missed.

We see this :

<<< Command:H Value:

Rotator says hello!

Sending hello

Sent hello back

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:V Value:

V2.0.0.0

>>> Sending V2.0.0.0

<<< Command:Y Value:

Y0

>>> Sending Y0

<<< Command:T Value:

Get Steps 885000

>>> Sending T885000

<<< Command:R Value:

R1000

>>> Sending R1000

and here is what is actually sent (command letter -> code ):

M Wireless.print(String(STATE_SHUTTER_GET) + "#");

M Wireless.print(String(STATE_SHUTTER_GET) + "#");

M Wireless.print(String(STATE_SHUTTER_GET) + "#");

V Wireless.print(String(VERSION_SHUTTER_GET) + "#");

Y Wireless.print(String(REVERSED_SHUTTER_CMD) + "#");

T Wireless.print(String(STEPSPER_SHUTTER_CMD) + "#");

R Wireless.print(String(SPEED_SHUTTER_CMD) + "#");

E Wireless.print(String(ACCELERATION_SHUTTER_CMD) + "#");

P Wireless.print(String(POSITION_SHUTTER_GET) + "#");

K Wireless.print(String(VOLTS_SHUTTER_CMD) + "#");

B Wireless.print(String(VOLTSCLOSE_SHUTTER_CMD) + "#");

So we're missing one M and anything after R as far as I can see.

Also when we do this we don't wait for the response, hopping to get them as they come in during the next ProcessWireless call. I wonder if there is either a buffer issue (buffer overflow) or a bug somewhere that squash the command response (or sent).

I'm going to plug an extra XBee module on my laptop to sniff the traffic and hopefully see what's going on.

So I made a few fix for the 2.0 firmware (I have a pending pull request).

The changes are mostly around command response to make sure the firmware behave the same way as 0.5.x and that all command send a response.

I also found out the the 2 XBee were configured exactly the same way ... but one should be set as the coordinator so I also fixed this (ATCE1 in the init string).

Now regarding the issue of losing commands ... or seeing weird thing on the XBee I have a clue.

When the rotator arduino send command if at the same time the shutter arduino send a command to get the rain status, it reads the command being sent by the rotator as the response, or in some case a command get the response of the rain check command sent to the shutter arduino.

I tested this with 2 serial terminal and issued a H# on the rotator arduino, the shutter arduino sees the H, replies with an H and the rotator then send a few commands to get the different values from the shutter.

<<< Command:H Value:

Rotator says hello!

Sending hello

Sent hello back

<<< Command:H Value:

Rotator says hello!

Sending hello

Sent hello back

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:V Value:

V2.0.0.0

>>> Sending V2.0.0.0

<<< Command:Y Value:

Y0

>>> Sending Y0

<<< Command:T Value:

Get Steps 885000

>>> Sending T885000

<<< Command:R Value:

R1000

>>> Sending R1000

Asking for rain status

<<< Command:E Value:F0

Set acceleration to F0

Signature is 2000

Wrote sig of 2000

Acceleration is 0

>>> Sending E0

Unfortunately, in the above, when it sends the E command to get the stepper acceleration for the shutter, the result of the "Asking for rain status" command get appended to the E command and this overwrite the actual value for the stepper acceleration.

So there is some collision in a buffer somewhere.

Hi André.

No news from Pat either. I too hope he's fine.

Rodolphe

Awesome thank you Rodolphe. Any news from Pat about his v2 ? Hope all is well... Clear skies!

I just posted the new X2 plugin for Pat's firmware. It was test with version 0.5.2.3 and should also work with version 2.x as the command are not changing (if we see some issue with firmware 2.x I will of course fix them :) ).

https://rti-zone.org/macosx_x2dome_plugins.php#nexdome

Regards,

Rodolphe

My X2 plugin is being tested on version 0.5.2.3 which once I fix a few issue should directly work with Pat 2.0 version when he's done with it.

Regards,

Rodolphe

Hi Pat & Rodolphe :) How is the new v2 release comming along? :)

You guys are Awesome! Can't wait to install the new v2 this weekend :)

Cool. I'll have time this weekend to finish and test the plugin on my test rig. If all works well I'll release it as version 2.0 with explanation on what firmware works with what version.

Rodolphe

Finally figured out the problem and, of course, it was a dumb mistake. I've been looking at the wrong part of the program for days! Turns out my conditions that must be met before sending hello were wrong so hello was being sent prematurely so the radio wasn't quite ready.

Now to clean up all the junk code from messing with this and a release should be out today.

I'm still fighting with the XBee initialization code. Want it to configure once after uploading the firmware then just use the saved configuration afterwards to avoid the problems with two initializing at once. Not sure where the problem is but for some reason it won't transmit a "hello" after setting the XBee parameters though it works fine when started using the saved config.

I'm 99% done with the X2 plugin for TheSkyX Pro. Just need to test with latest firmware from Pat.

Rodolphe.

Excellent work Pat :)

OK I'm officially dumb!

Was having more configuring problems with the shutter this morning where after startup the shutter would send a hello to the rotator but the rotator got nothing, meaning nothing was actually sent.

After farting around for a couple hours I accidentally fixed it and this time I know what it was! Turns out that declaring and instantiating an object doesn't actually mean it's initialized even though it seems like it. I have to call a function in that object before everything actually works. So sending the hello would initialize the object but miss out on actually talking to the radio. I moved the .Run() call to the top of the main loop which initializes the object and now everything works.

Of course if you don't know anything about programming this won't mean anything to you. Anyone else working with the code will understand what I'm talking about.

Awesome!

I've decided that the radio setup as it is now is too much of a PITA. I had made it configurable with the intention of using different sleep settings but the radio sleep modes are just too complicated, requiring a LOT of coding to support for which there really isn't room in the Leonardo's flash memory (at least not on the rotator).

So instead of always configuring the radio at startup I'm going to add a flag to the saved settings. If the flag is not set it will do the radio configuration and, if successful, set the flag when complete. From then on the radio will not configure at startup but rather just stick with the stored settings which means a much faster startup without the possibility of being disrupted by the other controller trying to talk to it.

This will mean only the controller being programmed should be powered up when updating so the other can't interfere. Once both are done the controllers won't be able to mess up the radio configuration at startup.

Of course that also means no release this weekend but it won't take too long.