CONTACT US

BE FIRST TO KNOW

Questions? Comments or like to contact us? Use this form to message us.

Email: sales@nexdome.com

Tel:    +1.604.421.2835

Sign up for our newsletter to get informed about NexDome news or new products.

Jun 28, 2018

Closing in on version 2.0

22 comments

Why the jump from 0.5.x.x to 2.0.0.0? I was just reminded that the original firmware is in the 1.x.x.x range and using a version number in that range will probably be confusing for new adopters. The downloads page will make it clear that my software is not compatible with the original firmware but the version number should make "skimmers" look twice and hopefully not get hit with a gotcha.

 

There is a new native driver being worked on for TheSkyX which will support my firmware so it'll be a version 2 as well. That way if someone wants to stick with the original firmware they can still use matching version 1s. While those using my firmware use matching V2s. Someone else is developing that driver so I can't give a timeline or really any details about it.

Jul 7, 2018

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.

Jul 7, 2018

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

Jul 8, 2018

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.

 

Jul 8, 2018

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.

 

Jul 8, 2018

Excellent work Pat :)

Jul 11, 2018Edited: Jul 11, 2018

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

Rodolphe.

Jul 11, 2018

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.

 

Jul 12, 2018

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.

Jul 12, 2018

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

Jul 12, 2018

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

Jul 24, 2018

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

Jul 24, 2018

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

 

Jul 29, 2018

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

Aug 1, 2018

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

Aug 1, 2018Edited: Aug 5, 2018

Hi André.

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

 

Rodolphe

Oct 8, 2018

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.

 

 

Oct 8, 2018

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.

 

Oct 8, 2018Edited: Oct 8, 2018

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.

 

 

Oct 9, 2018

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.

New Posts
  • This is the process i go through to get to the speed settings for the shutter, so a few questions: First I open ascom dome control panel I click connect. Of course it doesnt let you change values unless its disconnected, so i disconnect and reopen the nexdome ascom server monitoring window, hit setup: Seems no matter what values i put below, here 600/1500 etc, the speed of the shutter is the same. I had tried lowering these at first to see if it would help with the motor sticking. Is this the right procedure to lower the values and test? Also, i know there is a much longer thread here about updating the firmware on the shutter/rotator, but, what does the update firmware button here do? At one point i clicked it when only the rotator was connected, it claimed it updated? How do i know if i even need to update either? Both came brand new recently? Thanks in advance
  • I've completed the motor install (although i may be missing parts on the motor related to this, the set key that holds the pin in place was missing, found an m4 for now that seems to hold it but the pin doesnt go in fully, see this thread for more details) https://www.nexdome.com/forum/observatory-automation/shutter-motor-missing-key-set-screw-locking-pin-wont-go-in-fully-track-shredding First issue (or maybe not), when i push the motor and it moves up, i think when the panel that has the band through it goes under the first panel, half way up, it sticks for a half second, flexes and pops and keeps going. After this at times on the way up, even during the first half, sometimes the motor stalls briefly. The biggest issue is after its up fully and you bring it down, the first 16" or so going back it stalls and moans repeatedly, however, interestingly i can work it forward by doing an on off real quick multiple times, OR by pressing upward on the motor. Here is a video clip of the stalling (most of it near the end): https://www.youtube.com/watch?v=nCtvALmB6zU At this point i took all the wheels off the rear, added washers, so now they have quite a bit of flex available. The retention bracket is installed, but i had my son work the motor while i pulled back on the bracket and wheel on one side only, no change. When you pull the panels in the rear when its up there, apart, you can see grinding marks on each panel on the sides. So at this point i'm left with removing the retention brackets on both sides as a final test, and to be able to get the panels apart to add antifriction tape someone recommended. It appears the front panels will need to come off (not the rear solid non moving one), then apply tape as here: Here is an external view of the situation: https://www.youtube.com/watch?v=rNHI3KzOkbw This is the antifriction tape i've ordered (1" x 15 feet, two rolls,TapeCase 423-5 UHMW) : https://www.amazon.com/gp/product/B00823JF0S/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 I dont know what else to try, other than what i have planned at this point. Pretty frustrated. Incidentally, i have the inside dome rotation working pretty solidly, so this is the only sticking point, pun intended. Thanks in advance.
  • Im breaking my shutter issues into multi parts here, in this one, i seem to be missing the set screw on the part by the gear as in this image: The part circled was naturally coming out. I'd like to get the official part to fix this, however in the meantime i've added what seems to mostly fit but not flush, m4 set screw and the locking pin goes in a tad further: Any suggestions here? From someone else, it appears that pin should slide all the way inside (i dont know if this could be related to the motor stalling/sticking issue i have (sep thread))