Closing in on version 2.0

Suffering from lack-O-concentrationitis the last while. I'd sit down to program but not be able to get my mind to focus on the task. So not much done over the last couple of weeks.

Looks like I've snapped out of it since I've gotten more done in a couple of hours this morning than i have over the last couple of weeks. Hopefully I can keep this up and get the feature complete release 2.0 done this weekend.

The additional programming is already done so no more features to add. What I'm doing now is going over every line to cut unnecessary and abandoned code in an effort to reduce the firmware sizes (need room in the rotator) and eliminate some of the messaging bugs (short or empty messages). Already found the source of most of the short messages - old command responses that aren't actually used - and it's looking like that annoyance has been eradicated.

Now I'm trying to figure out why the driver is receiving the shutter voltage string with a motor status tacked onto the end (which results in an invalid value being logged).

After this it'll just be bug fixes and perhaps some cleaning up for code readability and efficiency.

Super Cool Pat! Looking forward to install your new v2.0 release :)

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.

Awesome!

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.

Excellent work Pat :)

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

Rodolphe.

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.

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.

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

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

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

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

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

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

Hi André.

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

Rodolphe

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.

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 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 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.