Tested Latest 2.0 Build

Here are the DIP switch settings.

Steve

Glad you got it working!! The "factory" setting should have been switch 2 & 6 ON - all others OFF which is 8 micro steps and 2.8 Amps. Switches 1-3 are the micro step and pulse per rev settings; and switches 4-6 control the current.

Tom,

That sounds like it may be an ASCOM issue? I say that because using Rodolphe's X2 driver, my dome completes a full rotation in just under 2 minutes. However, a complete calibration-rotation will normally take up to 2x longer because the firmware divides the rotation speed setting by 2 during calibration (and finding home) for better accuracy.

As Rodolphe points out, changing the rotation speed to a value greater than 5000 will have no effect on the normal rotation speed. However, a rotation speed value of greater than 5000 WILL increase both the "find home" speed as well as the calibration speed all the way up to a value of 10000, at which point dividing by 2 gives you the maximum rotation speed of 5000. My rotation home-sensing switch is quite close to the magnet and can easily tolerate the full rotation speed during calibration and finding home, so I leave the dome rotation value set to 10000 - which means the dome calibrates and finds home at full-speed.

To Rodolphe's point about doubling the rotation speed by lowering the micro-stepping value. I actually tried that setting and it did seem to work OK, although it moved so quickly that the mount became the limiting factor in a slew so I ended up leaving the stepper set to its original value of 8. However, I also changed the micro-step value in the shutter stepper and am very happy with the speed at which the shutter opens and closes (under a minute!).

Steve

Thanks for the update. Does this make the dome accelerate faster or does it make the rotation faster also? Mine is VERY slow with 2.11E. I'll give it a try!

I just fixed a small bug on the rotator firmware. It was not properly forward the command to change the acceleration on the shutter. I pushed the new code to github and tagged it as 2.11.2

I did manage to get the new firmware and ASCOM drivers running last night and was able to use the observatory with no problems. At first I couldn't get the shutter opened, and then finally saw that the voltage was down below 12V on the battery - that explained it! I set a lower threshold and it opened fine. I tried to turn it off once open to save on the battery, but then noticed that the rotator ran with a much stronger "stutter' without the shutter in the loop. Plugged it back in and it smoothed out. I'll put the battery on charge before trying again (I run my observatory on an extension cord when using it).

I'll probably be going back and forth between this and the old 1.1 in my attempts to get the Kstars/Ekos running on my Raspberry Pi. Another one of the "Rons" who I've been conversing with on the FB group has his running and it's been doing pretty well.

Thanks again for the work on this, it's running well!

Tom

So looks like with the latest ASCOM code with the shutter enabled by default, it might be causing issue for people without the shutter : https://www.nexdome.com/forum/observatory-automation/rotator-slave-takes-minutes

So I guess we need to figure out why when it was disabled by default and the user enables it , the settings doesn't stick (even though the ASCOM profile get saved with it enabled).

Worst case we need to build 2 version of the ASCOM installer, one with shutter enabled by default and one with shutter disabled by default.

So you tested with a serial terminal and said it replies to 'v' .. but it should only reply to 'v#'

You can also check if it sees the shutter arduino. Send "H#", It should reply with H#. Then after hat send a 'V#' (this is capital V in this case as opposed to lower case v) and it should reply with 'V2.11#'

Here is what it looks like for me in CoolTerm on my test system :

v#v2.11#H#H#V#V2.11#

Once we know that the firmwares are working we can try to figure out with the ASCOM part is not working.

If the shutter doesn't reply we can also force a XBee configuration with the 'x#' command on the rotator and you will need to do that via USB for the shutter

OK thanks. I'll try putting that one back in and hope I can rotate and open. I think I am also following too many forums and pages sometimes, so I know you are a different Ron. Ha!

I've had zero luck with 1.1 and the INDI platform getting the sync to work and controlling the shutter.

I went back to my windows machine and installed the 2.1 drivers on both the motors as well as the newest ASCOM drivers. It says it connects, but nothing happens. I don't see the version numbers ont either the shutter or rotator when going into the setup window either. I did install the 2.11 version. I first had the 2.11E on there, and went to 2.11, hoping that would work. Nothing.

Any ideas what I can check? It does show up fine on the COM port and connects, but nothing else.

The 90 second home timer is working fine, since the dome tries to rotate back to home, so that is working.

I was really hoping to get something going with INDI and Stellarmate, but went back to Windows for a sanity check now nothing works.

Any ideas?

I'll give that a try. I didn't realize that there could be some residual "stuff" left over. I figured the new code upload would totally replace the old.

I'm thinking I have the same setup that Ron is running, but he got his opening, syncing, and rotating at a decent speed.

After a lot of testing we finally have a release version of the new firmware and ASCOM code.

Thanks to Ron Crouch testing on the ASCOM side I made a full release.

The firmware need to be upgrade on both Arduino.

This will reset ALL the settings to default on the Arduino so you'll have to recalibrate, reset your voltage cut-off and speed and acceleration.

The shutter watchdog is set by default to 90 seconds after losing communication with the rotation Arduino. The ASCOM setup dialog doesn't have a way to change the settings but if you need to it can be done in a serial terminal (including the Arduino IDE serial console) using the I command followed by the value in milli seconds and a #. So I300000# would set the watchdog to 5 minutes (300 seconds).

The ASCOM driver has been tested by Ron over the last 2 weeks.

I've also tested this firmware with the X2 plugin for TSX and have not seen any issue with my test system.

The firmware are at the usual place : https://github.com/nexdome/Automation

And the latest ASCOM driver : https://github.com/nexdome/Automation/blob/master/ASCOM_Driver_Releases/NexDome%20Setup_211E.exe

For people who are having issue with the watchdog .. you probably have been using multiple versions of the firmware (0.5.2.3, 2.000, 2.11 ... ) and have some corrupted value in the EEPROM.

I committed a new version that has a new signature for the EEPROM and will ignore all the previous values.

Using this version means you have to reconfigure the whole thing (calibrate to get the number of ticks per rotation, set the speed and acceleration to what you had before, reset the voltage cut-off, ...) as it resets everything to default settings.

This version is in the develop branch and is being tested. If all goes well it will be pushed to master with the new ASCOM driver install.

Rodolphe

INDI is much better than ascom. What happened to the original nexdome INDI author? He still have a nexdome? I suspect after Tim Long gets the offical releases done we'll just one a indi update. HOWEVER I hear rumor there are people currently using the indi driver. I'm trying to figure out what firmware they're using. WATCHDOG - ya know - mine was fine - for about a hour. I was playing/texting Kstars and indi setup and the shutter closed for seemingly no reason. And I've not gotten it to work since. EVen later I went to manually open the shutter. If I let go of the button it would close. As it opened all the way it stopped and it started to close. I had to pull the power cord out of the battery to keep it open. You think this is that watchdog code? Whats the chances of the old INDI driver being compatible with the 2.1 firmware?

This is great news. Spring is just around the corner (although you would never know it here) and there are a lot of people waiting for an ASCOM solution!

LOTS to read up there (sorry I skipped to the chase). My shutter doesn't connect very often at boot up. I was thinking of swapping to a new xbee card (if I knew what to order and where). Is there some other fix in all this work mentioned above?

My problem is - I might have to boot power off and on shutter and or rotator 20 times to get them to connect. Once they do, if I can LEAVE THE ROTATOR POWERED the two will stay connected (weeks to prove it). but we've lost power recently in wind and I can't get the shutter to connect again. Any way to force it via some code or what do you think about me swapping it. (when I have no clue what that entails).

LOTS to read up there (sorry I skipped to the chase). My shutter doesn't connect very often at boot up. I was thinking of swapping to a new xbee card (if I knew what to order and where). Is there some other fix in all this work mentioned above?

My problem is - I might have to boot power off and on shutter and or rotator 20 times to get them to connect. Once they do, if I can LEAVE THE ROTATOR POWERED the two will stay connected (weeks to prove it). but we've lost power recently in wind and I can't get the shutter to connect again. Any way to force it via some code or what do you think about me swapping it. (when I have no clue what that entails).

I found another bug in the shutter firmware which I fixed. It's only on the develop branch for now as I wan to release both the firmware and the ASCOM code at the same time. So I'll wait for Ron to be back for this.

The issue regarding the shutter is that the state was only updated when opening or closing. So if your app queries the initial state it was getting a state of ERROR (or unknown) even if the dome pas properly close or fully open. This can me an issue if for some reason the Arduino is power cycled as it would think it's closed when it might not me. Now the state is properly updated and set to it's proper initial state by checking the open and close sensor/switch state when the arduino starts.

Let me ask this to make sure I'm still up to date. The last release 2.1.1 is for TSX users? So regular windows users running dome/scope/camera/etc. devices using Starry Night, Sky Safari, SGP, etc should not use this driver for dome control and we should continue using NexDome Dome ASCOM driver 5.2.3?

Thanks,

Steven

I posted the latest ASCOM driver compiled by Ron after the changes I made.

It's in the develop branch (as opposed to the master branch) :

https://github.com/nexdome/Automation/tree/develop/ASCOM_Driver_Releases

If this works better we can keep digging in there and try to fix the stutter.

And then do a 2.11 release.

So these are sent every seconds :

	SendSerial(POSITION_ROTATOR_CMD);
	SendSerial(HOMED_ROTATOR_STATUS);
	SendSerial(SEEKSTATE_GET);
	SendSerial(SLEW_ROTATOR_STATUS);

	if (canSetShutter == true) {
		SendSerial(POSITION_SHUTTER_GET);
		SendSerial(STATE_SHUTTER_GET);
	}

in OnStatusUpdateTimer.

this seem overkill. If there was no slew of find home requested, HOMED_ROTATOR_STATUS doesn't need to be pulled, SLEW_ROTATOR_STATUS and SLEW_ROTATOR_STATUS don't need to be pulled all the time either.

Unless you're closing or opening, POSITION_SHUTTER_GET and STATE_SHUTTER_GET don't need to be pulled.

I think we need to add some state variable that track what we're doing (homing, slewing, calibrating, or doing nothing) and only call what's needed.

I just tried with terminal on mine and got a very smooth rotation when doing a g# command. I started ASCOM and it stuttered again. Also, when ASCOM is running and I use the toggle switch, I get the stutter also. Turn off ASCOM, toggle is smooth again.

Just some more results to consider if I'm not too late to add something.

Tom

Progress!!

Well Steve's idea to explore ASCOM is a winner here! Sending commands in CoolTerm results in rotator which could not be smoother! So the stutter is the way ASCOM interacts with the firmware.

CoolTerm is fun!!

Thanks Rodolphe.

@Ron Crouch

I just emailed you my modified version of Driver.cs

If you could test it and see if it helps with the stutter that would be great.

We could do a new release of the ASCOM driver (2.11 :) ).

I still have to test all this again for real in the observatory. Just waiting for a clear night, and some reasonable temperatures, a day where I can sweep the snow out of the inside (darn gaps!), and hook it all up and reconfigure all the USB, Serial ports, new guider camera...etc.

Wow good instincts guys! If anything shakes out for testing just point me at the files. Thanks so much.

Kind of unrelated. I've been working on a fresh re-install of Windows 7 and all the other astro software that goes with it. I was having problems with my old install where the computer would lock up on boot (the "glare" behind the Windows logo would stop moving and hang). It would often take a couple reboots and a "repair" to get it running again. Extremely annoying. I thought I had that fixed, then the new install did that yesterday. I think I must have installed something that isn't happy, but looking through the event log, I'm not figuring it out yet.

When I installed some updates, I then found that some software was removed, one of the plate solvers was missing and a few other things.

I'll be so happy when I can get this all running on Linux, just a lot of work to do before that will happen.

Oh, when testing the rotator on the new install, it still has the "stutter". When I grab the motor shaft, it feels like when it stutters, it moves backwards a very tiny bit, then resumes turning forward.

That's interesting. But maybe a side-effect of the shutter attempting to remain closed after it doesn't hear from the rotator?

Hello Team, I observed a small bug with 2.1. I am not sure of all cases which might cause as follows: This morning after a good night of imaging I decided to leave shutter open and then disconnect/shutdown the PC to test the shutter close. I have my firmware set to do that after 300 sec rather than the default 90sec. Right on schedule the shutter closed! Excellent!! Now with PC and rotator power off I observed that the rocker switches on the shutter move shutter towards closed no matter which way I push!! Power of PC and rotator power and open shutter is normal.

Other than that and the slightly hitchy rotation motion all has been flawless without ever touching anything. I normally turn off rotator and shutdown PC during the day and it's all turned back on by script about an hour before sunset. Communication issues truly seem gone.

It's interesting that people get different results with the exact same firmware.

So the only difference is going to be the parameter (acceleration and speed).

As we saw in Steve's experiments related to speed and acceleration, and verified by calculating the max speed using the TB6600 spec sheet, the max practical speed is 5000.

If you also set the acceleration to 5000 you do not get the ramp up and down when you move.

I have mine set to 4000 on my test system as I don't care about the ramping on something as small as my rig. On a bigger dome you might want to give the motor enough torque to initiate the rotation and slow it down to a stop when reaching the target angle. So setting the acceleration to the same thing as the speed prevents this.

I would recommend testing with a speed of 5000 (steps per second) and may be an acceleration of 2500 (step per second per second). This should give a smoother start/stop on movement.

As for the "tick" and "thump" this might be related to the fact that motor stepping is not done under an interrupt but "as often as possible in the code"... Tim is rewriting the firmware to address this but as he's changing the command set (from what he said) this doesn't help us.

I might do some test with Arduino timer and try to put the stepping in a timer interrupt based on the speed.

Rodolphe

Both of my motors rotate smoothly. However, they do emit a "tick" (definitely not a thump) from the gearbox approximately once every couple of seconds but it does not affect the rotation velocity.

I am using non-default rotation and acceleration values and have just assumed that every couple-hundred calculations the stepper controller either gets a number that "doesn't compute" or the Arduino is so busy it misses a step-command.

I also got tired of waiting for the shutter to open so I changed the micro step setting on the shutter TB6600 to 4 micro steps and 800 pulses/rev which opens the shutter in less than a minute :-).

The values I gave above for the steps per rotation is the default value from the firmware .. in case the eeprom data were set to bad values from previous firmware(s).

If other people run into non smooth movement the next step would be to use interrupt to step the motor (I might run some tests). I would also need to add an interrupt for the homing if the stepping is in another interrupt to make sure we do stop on homing.

And I thought I was done ... "little did he know ..."

So let me know if the "pulsating" is an issue everyone sees .. which would me I need to fix this (I don't see it on my test rig).

Rodolphe

Slaving is perfect provided the offsets in the client are correct. Firmware is fine!!

Hi Ron,

Glad to hear you are having success with the new firmware & driver!

The calibration data are stored in EEPROM and survive firmware updates. If the stored value is too far off of the expected value, calibration will fail. I think Rodolphe suggested entering 440800 in the steps/rev field on the assumption that the stored value in Tom's EEPROM might have been corrupted by the old firmware.

Steve

Is one of these the new ASCOM driver vs. the old one? I was using the one called

PDM NexDome driver" before. Now I also see a "NexDome Driver" in the list. Seems clear tonight, so maybe I'll go out and try to home it on the magnets, set to 5000/5000 and 440800 then try the calibrate and see what happens.

Installed the new drivers and firmware. Is it normal for the motor to pulsate when it rotates? It runs for about 1.5 seconds, stops for a moment, then runs again. --Repeat.

Ron files updated, release done :

https://github.com/nexdome/Automation/releases

The zip file (Automation-v2.1.zip) also has the installer in ASCOM_Driver_Releases and the firmware in Firmwares.

I have driven the new matching ASCOM driver for the 2.1 firmware pretty hard now. I'd have to say that based on my experience now I'd not hesitate to fire up the observatory in any weather from anyplace. It is robust just left on or shutting down rotator between sessions. No need to doa shutter switch dance any longer. Rodolphe did great stuff!! It's not perfect because software can never be so but more than serviceable and far more robust than 0.5.3.2. I did modify my ACP automation scripts in a rational way. Now I can do things with weather alerts like turn off tracking, start moving dome to home so the charger tabs line up and CloseShutter() while that happens. No strange scripting to get around FindHome failing.

If folks want the driver we should find a way. I could put up a link but that depends on need.

Ron

Sorry - TSX is TheSkyX observatory control software. TSX supports the X2 plugin standard and the author of the new v2.1 firmware has also developed the NexDome X2 plugin for it.

Oh....well I guess I'll just hold off on that then. I'm not even sure what TSX is.

Tom

Hey Tom,

Now for the bad news... Unfortunately, v2.1 firmware only works with TSX and is not compatible with the old ASCOM driver. Frankly, that's the rub - seems like the "new guy" Babak hired could have at least started there.

Steve

Hey guys,

Steve directed me over here from another question I posted. Happy to see the 2.1 seems to be the latest. I see the new .ino files are out and I'll give it a try. Just one question though, do I need new ASCOM driver installed? I did skim over the messages, but didn't find a link to it. If there is a new driver, can you direct me to the URL?

I got a new ASI120 guider a couple weeks ago, but was cursed with clouds (or no clouds - but some very negative F temps thanks to the polar vortex!). We have some promising weather and "teen" temps coming up so I may be ready to resume work on my observatory.

Tom

I'd say Tim is very experienced with all of this having written code for professional observatories and such. In the end all will be well plus for me personally I've learned so many things by following Rodolphe here. Rodolphe did wonders and those lessons learned will be reborn forever! One of the totally missing links in current driver is multi-threading. ASCOM is wired for this but in our world connect two clients and it's certain death for the driver.

I did find a very nice ASCOM how to intro:

https://www.youtube.com/watch?v=XVlrDyIBd5I

Anyway I've come to the conclusion that in my world here I'm more likely to lose the shutter from ASCOM crapping out than the firmware itself. Say I open shutter.. status says "open" but it's one of those days when clicking "close shutter" does nothing at all. The fix is:

1.) disconnect the client I'm using if it does not allow access to setup.

2.) Connect with POTH. Go to setup -> setup. Uncheck can set shutter.

3.) Disconnect POTH.

4.) Reconnect POTH setup->setup. Check can set shutter.

5.) disconnect/reconnect. Shutter will be back and will close.

Note the firmware is not touched or restarted. ASCOM is fragile for sure.

Fortunately things work most of the time... 0.5.3.2 with two or three tiny touches.. Fortunately I do have a rain sensor in the mix... I bought one but will not use it til things are sorted out.. My cloudwatcher is good enough and if fast-moving nasty storms are forecast it's just a night to unplug everything for now.

Ron

Got it. Now if I can just remember...

Your 2.1 firmware and X2 plugin are still running smoothly. I haven't needed to cycle the power to either the shutter or the rotator since the last update; and they have stayed connected through several days of brutally cold weather (-17C)! So far the weak-link in my electronics has been the battery charger: it's an upgrade from the stock Black & Decker that came with the dome; but it stopped working twice when the temps dropped below -15C and I had to unplug it to get it come back to life.

I still think "Tim" could have saved everyone a lot of time and headaches if he had started by updating the existing ASCOM driver to work with v2.1 firmware. He could still write a new firmware and driver, but at least the NexDome customers could be up and running in the meantime. Oh well...

Steve

Good catch Rodolphe!

Just to be clear, this only needs to be done if/when replacing one or more of the XBee radios?

Steve

After spending more time reviewing the code I had to make another change and add a special command.

The current code will only configure any XBee once. Why ? Because it saves the fact that it configured the XBee in the config in the EEPROM.

So if you change the XBee for any reason the new one will never be set with the required parameters.

I added a 'x' command. So on the Rotation Arduino you can send a 'x#' via the Arduino IDE serial console and it'll configure the XBee of the rotation Arduino, it will try to send a 'x#' command to the shutter XBee... just in case that one is also new and on the same PAN ID.

Once the XBee is configured there is a 10 second pause to give time to the radio to come back online on the new PAN ID.

For the shutter Arduino, you would need to do the same thing by attaching it to a computer and flash the new firmware then send a 'x#' from the Arduino IDE serial console. It will then configure (or reconfigure) the XBee on the shutter Arduino.

I discovered this while doing a special version for a friend that only cares about the rotation Arduino but want to talk to it via XBee from his computer.. and the Arduino wasn't configuring the Xbee ... head scratch for a few minutes :)

This might not be important to anyone as it looks like a new firmware is being developed (I haven't had time to resync with Tim on that so I have no idea where that's at) but I wanted to leave things is a 100% usable and stable state in case this is of use to anyone.

Rodolphe

I finally got time this weekend to implement what we discuss above.

I even tested the watchdog timer by turning off my rotation Arduino and it close the shutter once the timer hit (90 seconds).

Now the shutter only responds to commands and doesn't send anything on its own.

I also added the command to set the watchdog (I# to read it Ixxxxx# to set it. Value is in ms and the min is 60000 and max is 300000, aka 60 seconds and 5 minutes).

While doing this I finally discover what the XBee communication issue was and fixed it.. Since then, not a single message lost !!

Even the hello that was missing the first 2 messages now works perfectly.

I updated my X2 plugin to allow you to set the watchdog timer value.

Latest 2.1 firmware has all the changes (rotator and shutter) : https://github.com/nexdome/Automation

I think that's the last of the firmware changes I'll do based on my test.

Also... NexDome is now working with an ASCOM developer .. who apparently want to rewrite the firmware, which is fine , before fixing the ASCOM driver. What I see as an issue is that he wants to change all the commands .. so I'll have to fix my X2 Plugin whenever this happens. In the mean time this firmware is what we have to work with and is now stable.

Rodolphe

Seems like a good plan Rodolphe. Happy to help test when you are ready!

Ok so Ron's 3 rain-check cycle is a good idea and can be the lower bound, we add Steve configurable range with a max of 5 minutes (300 seconds, 10 rain-check cycles).

Doing this could also help people running into issues when it gets really cold.

My take on this is that the Arduino CPU or the stepper controller are not failing per say (the AVR can run as low as -40C and the stepper controller is rated to -10C), but the 16MHz oscillator (and other crystals) on the boards deviate from the original 16MHz as the temperature falls. They are usually rated for 0C, -10C, -20C, -40C and -55C. But I don't know what is on the Arduino Leonardo. As everything is derived from this oscillator, the serial speed and usb speed are no longer correct and the computer can't talk to the rotator and the rotator can't talk to the shutter. So this can be bad too but if you're at -10C it will not rain or snow but you still want to close if anything fails.

I'll start working on some changes to make the shutter Arduino only respond to command and not send anything on its own. Then I'll add the watchdog timer and test it to make it close if it loses communication with the rotator.

I'm not sure how long it'll take me as this is a bigger changes than all the one we've done so far.

Since this is a watchdog for lost communications I'd say something like 3 cycles of the normal 30 sec rain-check. Comment the line well with notes for low and high valid readings in case it needs adjustment.

@Rodolphe

Automation is the heart of an observatory, so I am very much in favor of anything that will improve the functionality and reliability of the NexDome automation system! As you point out, hoping that a half-duplex device will behave correctly when the firmware treats it like a full-duplex device is a recipe for disaster.

The question of timer duration is an interesting one and I think the answer depends upon 1) how often the shutter will look for the rotator; and 2) the list of things that could cause a loss of communication between the rotator and shutter and/or failure of the rotator outright.

If one assumes the “communication issues” that everyone experiences are caused by the firmware rather than RF interference disrupting the radios, then I think it is reasonable to assume the actual RF communication between the XBee radios is reasonably reliable. In which case, any loss of communication between the rotator and shutter is more likely to be caused by a catastrophic (unrecoverable) error in the rotator rather than a temporary glitch in radio transmission. That said, the watchdog timer could be on the short-end of your scale, i.e., 30 seconds or less.

On the other hand, you don’t want the shutter closing for no good reason, so it’s probably a good idea to leave at least a little room for unforeseen circumstances that could briefly (but not permanently) disrupt communication between the rotator and shutter – although I can’t imagine what those would be – which would suggest a little longer watchdog timer, say 1 to 3 minutes.

Since I suspect most people leave the shutter stepper controller at its default setting of 8 micro-steps & 1600 pulse/rev, it will typically take about 2 minutes for the shutter to close. And, since the watchdog timer is responding to a system-error rather than a weather event, it seems like a setting that will support closing the dome within 5 to 7 minutes of a rotator malfunction would be reasonable.

All of that said, I would think a 3 to 5-minute watchdog timer would be a good starting point. If communication is disrupted for that period, I can’t imagine it’s going to recover; and 5 to 7 minutes is certainly a short-enough period to close the dome before weather conditions could change.

One additional thought: you could also allow the user to set the timer within a reasonable range, e.g., 1 – 10 minutes. This would allow for some customization but still protect the firmware from bad values. It would also allow folks like me, who have set their shutter stepper controller to 4 micro-steps & 800 pulses/rev, to set the timer to 4-minutes and still get the dome closed in a 5-minute period :-).

So after even more reading on how the XBee radio is working I'd like to make changes to the firmware to make it even more robust.

The XBee are half duplex devices and are in receive mode by default.

When you send data, you can't receive any data as the antenna port is no longer connected to the receiver :

Right now both the rotator and shutter firmware send data as needed without any regards for the above.

This leads to data loss once in a while when the shutter decide to query the rotator for the rain status.

This is the source of most of the issue I still see with the XBee communication.

The change I propose is that the Rotator is the main device and the shutter is a listening device.

The shutter doesn't send data on its own and only respond to commands from the rotator.

This way the communication is always initiated by the rotator which sends a command and wait for a response before sending the next one, thus ensuring that it is listening for the answer from the shutter before trying to send more data. This would solve the issue for the data loss I see.

Of course this also means the shutter need to have a watchdog timer and should assume the worst if it doesn't get any data from the rotator over a long-ish period. If the communication breaks it should close the shutter to avoid any damage to the hardware as it can no longer asses the state of the rotator and the rain sensor.

So before doing anything I'd like to discuss this here to see what people think.

We also need for agree on the watchdog timer length (30 seconds, 1 minutes, 5 minutes ... less , more ... ). I want to set this as non configurable as I don't want user making a mistake and setting this to a vlaue that would render the shutter inoperable (can't do anything with it because the value is too small, or doesn't close on rain/communication loss because the user set a value that is too big).

This change would really improve the robustness of the system as I really don't like the fact that we're potentially losing commands (or response).

Thanks Rodolphe!

So today I did more cleanup in all the places where millis() was used and replaced them with a stopwatch class. This simplifies the code and makes it more readable. I've tested this and it works well for me.

I also did more cleanup in the code.

Let me know if you find some issues.

I'm making a few more changes.

Ron pointed out that the millis() function on the Arduino was used and will roll over and this could create issue (after 49.71 days). So I'm fixing this as this has been solved already by countless people and just require a small change.

I jus fixed the Rotator code and will soon fix the Shutter code for this.

Just did a small commit to set both firmware version to 2.1 , no other changes.

I did more reading on the XBee and I'm about 99% sure that the few issues I still see are due to the fact that the XBee is not a full duplex device as it uses 1 frequency to send and receive.

This is directly from Digi (maker of the XBee) : "The XBee products are Half duplex products. They are not able to send while receiving RF data. "

So the fixes I put in place and sending a few extra commands for the hello is probably the best we can do without doing a full rewrite of the firmware communications.

So unless we find more bugs, I think this firmware has reach its release state and should be rename version 2.1

I want to thank you all for all the testing and support.

I'll probably update the firmware version tonight or tomorrow and do the final commit.

I won't tag it yet as the ASCOM driver still need to be fixed.

Rodolphe

Great! The weather here has cleared so I will be able to test it over the next couple of nights.

Other good news is that your last commit is working well!

I made a new change as apparently on Hello we still miss the 2 first commands somehow.

This fixes a few issues I saw with the ASCOM driver.

New firmware code is there : https://github.com/nexdome/Automation

@Rodolphe

So I figured out why you aren't getting half-speed when finding home on your test rig. As I mentioned earlier, when I compared the times for my dome slewing to a point via a goto versus returning to home from that point, I found them to be about the same. The only difference between your settings and mine was that I had the rotation speed set to 8000 in my firmware.

I had a bit of time to waste this afternoon so I decided to experiment with different rotation speeds. Here is what I found when comparing a GOTO AZ 270 to a "Find Home" from AZ 270 (using a stopwatch this time):

As you can see, the GOTO (normal slew) rotation speed tops out at a setting of 5000 in the firmware. However, the "Find Home" speed continues to increase with increasing rotation-speed settings until it finally tops out at the same maximum rotation speed as a normal GOTO slew. So it looks like the stepper controller can't go any faster than an equivalent setting of 5000 in the firmware.

Who knew...

That's great news Rodolphe!

I'll probably change the final version to 2.0.1.0 or something more like 2.1 (we don't need 4 digits !!! ).

Also Baback created an official NexDome github account with an Automation repo in it and move all the latest code over there.

I need to probably rename a few things and update the Readme.md to add the new info in there, but this will be the new official location of the firmware and ASCOM code.

https://github.com/nexdome/Automation

I plan on creating a develop branch in addition to the master branch so that master always point to a working version (once we release 2.1) and develop point to what I'm testing and is not ready for prime time.

Rodolphe

For what it's worth, despite Pat's excellent efforts, v2.0.0.0 never really "worked."

Before your started working on it, I had so many communication issues with the shutter that it was completely unreliable for dome automation (which is the whole point of automation software)!

Now, thanks to your efforts, we at least have firmware that works! So, thanks again for getting us to this point!!! Maybe it's time to change the version number to 2.0.1.0?

Well, in that case, it must just be my imagination! I am rarely in the dome when it is actually busy slewing - I generally only go in to upload the shutter firmware and then go back in the house to test it :-). I just happened to test the latest firmware from inside the dome this last time because I was making some equipment changes. So, the previous "sound" I recall from the motor is from several versions ago and based on solely my (often unreliable) memory.

The good news is that everything is working! I will continue to put the firmware through it's paces starting in a couple of days when the weather improves. I just swapped OTAs and am hoping to collect a bunch of data in Jan/Feb.

Thanks Rodolphe!!

I went all the way back to when I introduced the half speed and it behaves the same way.

It's not really half speed as we've seen so the behavior has been the same from version

b5897dc8eeb7a3dd3055442f70b8be968d79a3ef

I removed these extra stepper.run() and it didn't change anything.

The "new" code only does extra things when talking to the XBee which doesn't happen often when just slewing. It only happens when when send a hello to the shutter, when the shutter ask for the rain sensor status , when you send open/close commands and when in the settings dialog and we're retrieving the values from the shutter controller.

So there should not be any effect on the rotation speed on a slew.

The default speed is 5000 with an acceleration of 8000.

That being said the fact that it's not turning at 1/2 the speed on find home is troublesome.

I the latests version I added code to read the response from the command from the XBee as soon as we send one and also call the stepper.run() in there.

May be that's causing issues and/or unexpected effect.

I can try removing these calls though and see how it goes.

That's interesting. I timed my dome yesterday for a slew from Az 165deg to Az 270deg and then for a "find home" from Az 270 back to Az 165; and they both took 28sec.

Has the maximum slew speed changed at all? The reason I ask is that with the last version of firmware my rotation motor was very smooth and quiet during a normal slew; however, it had a periodical (about 2x per second) "clicking" (like the motor wasn't quite happy with the stepping rate) noise from the gearbox during the slower, "find-home" slew. Now, the clicking noise is occurring during both normal and find-home slews and the rotation definitely seems slower during normal slews than it was previously. I haven't changed the rotation speed so I'm not sure why the motor would sound different with the latest version. When the weather clears I may reload the previous version to make sure it's not just my imagination.

As for a colder-temp stepper controller, that would be nice, but the weakest link in my system is not the (-10C rated) TB6600 stepper because many of the electronic devices in my dome are only rated to operate down to 0C. Frankly, I am surprised everything works down to -15C! So far, the first thing to fail when it gets too cold is my filter wheel.

I check the code and homing and calibrating are supposed to be done at half speed.

I'll do some test on my side.

Edit :

I did a test, even though I call the stepper.setMaxSpeed with _maxSpeed/2 it's not quite going at half the speed. I did a goto 90 on mu test rig.. 8 second, find home from that position ... 12 second

So not quite half, more like 2/3rd. Not sure why the AccelStepper lib does this. I know it doesn't use a timer so it's not as precise as it could and it also depends on the number of time you call the run() function for the stepper object.

So I didn't break anything.

The more I look at the AccelStepper lib the more I thing a proper stepper library that uses interrupt timer to driver the stepper steps and state would do a way better job. But at this point we seem to have a fairly stable version, not issues with XBee as far as we know and all my changes seems to work and help make the whole thing more stable.

Indeed find home and calibrate should be at half speed.

I need to make sure I didn't "break" that.

For the dome command in progress, all of this is under TheSkyX Pro control, not the plugin.

AS for low temperature I've been doing some research on stepper controller that could work to -20C

I found one but it can only deliver 2A which is not enough as the motor is rated at 2.8A. I'll keep looking but for controller like these with low temperature to cost is getting high (the 2A one is $90 and works from -20C to 50C).

@Rodolphe

Good news, your latest firmware commit and v2.04 of the X2 plugin seem to be working as expected!

One thing I did notice was that, based on the sound from the stepper motor, I thought the dome seemed to be slewing a bit slower than with the previous firmware. So I timed both a normal slew and a find-home slew and noticed they are now the same speed. Not sure if that was intentional as I remember you mentioning that you slowed the find-home speed a bit so the dome didn't overshoot the home sensor.

Another thing I managed to do totally by accident was to hit the telescope slew button just as the dome was making a small tracking adjustment. This triggered a "dome command in progress" error which immediately stopped the dome from slewing to the target with the scope. However, once the scope was on target and tracking, the dome began slewing (as it should) to the new location, but while the dome was slewing, the progress display kept switching between 1)ready, 2) process aborted and 3) slewing to target. Fortunately, everything seemed to self-correct once the dome reached the target and began tracking with the scope. Also, subsequent slews worked normally.

So, that's the latest. I will be shut down for a couple of days due to snow tonight and tomorrow, and then a couple of -20C nights. The coldest I've tested my electronics to is -15C so I think I will leave everything closed up until we get back to that range.

That's Awesome Rodolphe! I will try to test your latest changes tomorrow. We have a snow storm coming but it looks like it won't start until tomorrow afternoon so I should be able to at least get it installed and try a few slews. I let you know how it goes.

Merry Christmas!

I found one more bug in the shutter firmware while working on the ASCOM driver. It's now fixed.

I just pushed a new code changes that should help preventing buffer overrun when the shutter sends a hello to the rotator and the rotator was then sending a lot of commands without reading the response immediately which was apparently creating some buffer overrun.

Now when we get a hello from the shutter, the code calls a function that sends the commands and wait for the response before sending the next one. It also calls the stepper.run(); function yo make sure we still move while processing the commands if it happens during a slew.

I've tested this on my rig and it works but nothing beats a real world test.

If this works without error I think this will be my last change for the 2.0.0.0 firmware and we can focus on the ASCOM problems.

Rodolphe

Unfortunately, CCDAP just waits for the slew to timeout. After it times out, CCDAP does another plate-solve and it always shows that a slew actually completed and the mount has been tracking the last 5 minutes. Here is an example from the log file:

06:00:00 Solved RA: 05 36 18.3, Dec: +34 08 23, PA: 89.9 (2.1s)

06:00:00 Plate Solve Time: 11.7 sec.

06:00:00 Pointing error (arcmin): RA -0.2; Dec 0.1

06:05:03 Correcting slew failed. TheSkyXAdaptor.RASCOMTele.1 says Receive time-out. Error = 209.

06:05:03 Plate solving...

06:05:03 Telescope RA: 05 37 32.5, Dec: +34 09 02

06:05:13 D:\UserData\Pictures\CCDWARE\SyncImages\Sync_20181121_060503.fit

06:05:15 Stars: 37, FWHM: 9.0 arc-sec.

06:05:15 Solved RA: 05 36 18.1, Dec: +34 08 27, PA: 89.9 (2.1s)

06:05:15 Plate Solve Time: 12.1 sec.

06:05:15 Pointing error (arcmin): RA -0.1; Dec 0.0

06:05:15 Try 1 slew error: 6.2 arc-sec

Anyway, the firmware seems to be working well and I also agree the small-moves problem seems to be fixed and the above slew errors probably have something to do with TSX & CCDAP not working well together.

Bottom line is it looks like great progress!

@Rodolphe

Great timing, I just about to give you a quick update on your last firmware commit. The great news is that, after using it continuously for the past week, I am happy to report that is has been completely stable and seems to be working perfectly. The dome has been connected to TSX continuously, and I have run imaging sessions every night but one without any issues with the shutter.

The only weirdness has been an occasional non-fatal, “correcting slew failed” error from CCDAP. As you may recall, I originally surmised these errors were caused by the firmware struggling to accommodate very small moves arising from the closed-loop slews CCDAP uses to acquire and maintain targets. However, just for fun, I performed over 50 closed-loop slews using TSX directly as well as another 50 random manual slews of less than 10 arc-sec and could not reproduce the error in TSX. I also swapped OTAs the other night and performed a 75-target T-Point pointing-model run without any slew errors.

Because I haven’t had any slew-errors using TSX directly, I suspect some sort of issue with the scripting interface between CCDAP and TSX. I contacted the author of CCDAP and, unfortunately, his response was “use the ASCOM driver instead of the X2 plugin.” I pointed out that the only reason I was using CCDAP was due to its tight integration with TSX and the ability to use a single control program; and, if I had to use ASCOM, I would probably switch to something else like SGP or even try PRISM. Unfortunately, he didn’t seem particularly concerned...

At any rate, the slew errors in CCDAP are not fatal, and the system recovers when the slew times-out in 5 min. Also, they don’t occur every night and, when they do occur, I am only seeing one or two in a session.

Hope that helps!

So, no failure report so I guess this is a good sign :)

I'm going to make a few more changes this weekend.

Currently when the rotator Arduino get a Hello from the shutter it sends commands to get all the data, all at once, without reading the response and expect they'll be waiting in the serial fifo or the XBee fifo for the next check. I think this is causing some of the communication issue I was seeing and I've made a change to make this more synchronous (send command, read response, send next command, read response ...) instead of the way it's done right know to avoid fifo buffer overruns.

I'll test this on my local rig and if it works I'll push the new code sometimes this weekend.

So I can confirm that the XBeeConfig code is just to configure the XBee for testing and what not and does pretty much what we do in the code to configure the XBee .. so not used.

In my W10 world.. for build :

https://github.com/pmeloy/NexDome/tree/69017e505f485f9a4d5784b2bd99ff23cedaa9ae

Shutter compiles fine but Rotator fails to compile.

Looks like a path thing but Rotator PDMRotator folder is sitting right in the Arduino folder. When I compile I always put the folders directly there and avoid nesting. I can put my current 532 PDMRotator folder there instead and things are normal. Since the new PDMShutter.ino compiles fine it might be something in the Accelstepper.h. Which library version should I be linked to?

I am using the same Arduino program I've been using since the beginning. I'll enable verbose messages.. Here is the short story.

Errors follow.

##

Arduino: 1.8.8 (Windows Store 1.8.19.0) (Windows 10), Board: "Arduino Leonardo"

C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.19.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\WString.cpp: In member function '__base_ctor .constprop':

C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.19.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\WString.cpp:98:1: internal compiler error: Segmentation fault

}

^

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

lto-wrapper.exe: fatal error: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.19.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc returned 1 exit status

compilation terminated.

c:/program files/windowsapps/arduinollc.arduinoide_1.8.19.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

Multiple libraries were found for "AccelStepper.h"

Used: C:\Users\roncr\Documents\Arduino\libraries\AccelStepper

Not used: C:\Users\roncr\Documents\Arduino\libraries\src

exit status 1

Error compiling for board Arduino Leonardo.

This report would have more information with

"Show verbose output during compilation"

option enabled in File -> Preferences.

##

Hello Again.. One other question.. What if anything do I do with the XBeeConfig files?

ron

Good morning all! Rodolphe.. Should I try this last commit (where if blah == false changed to if !blah).. with that Nov 24 ASCOM driver version or are you pretty sure of some stoppers?

Best,

Ron

If this thing is ready where can we find it? I think I answered my own question: https://github.com/pmeloy/NexDome/tree/69017e505f485f9a4d5784b2bd99ff23cedaa9ae is this correct?

Thanks for all of the hard work!

Steven

Good.

So we need to let this version "bake" a little bit and see how it fares in normal usage.

@Ron Crouch , now I guess it's back to ASCOM to get things working for you.

Rodolphe is the "master mechanic," I'm just kicking the tires... :-)

This is getting really exciting! Go guys!!

Ron

...83978 = AOK. Congratulations Rodolphe, as far as I can tell, you didn't break anything!! Awesome work!

...aa9ae checks out AOK. I saw you just finished the shutter code so I will test that as well - unfortunately, I have to actually go outside to do it...

all == false remove from the shutter code

13616242e2f6bcaf8ba80dfe79db5b941f883978

So with this last one we have all the cleanup changes I wanted to do.

As these are in separate commit it'll be easy to isolate what broke if something breaks :)

all == true gone from shutter code

88595449ebdff77424085ee6c88c3892cc1bdbe0

I've been following the ASCOM help group. Since I don't really know what language you guys are talking I thought this might be useful information. Knowing you guys you probably already know about these groups but at least I can tell myself I've contributed.

Here are the links:

https://ascomtalk.groups.io/g/Help

https://ascomtalk.groups.io/g/Developer

Steven

all == false are gone from the rotator code

69017e505f485f9a4d5784b2bd99ff23cedaa9ae

all == true from the rotator code are gone

47038cc4247c3e8fedda1ca0f485e2c1789b6aee

so next change will be more important.

There are a lot of

if(variable == true)

in the code... that I'm going to replace with

if(variable)

as it's the same and get better optimized by the compiler.

Then I'll do all the

if(variable == false)

and replace them with

if(!variable)

same reason.

I uploaded and tested ...8fc2: the good news is that you haven't broken anything yet!

shutter code also done, commit id 163b366b3c5ff22f84ec0cbe8f70e03a09f58fc2

Next I'll start some stack usage optimization.

New commit. I removed all unused variable in the rotator code.

Will do the same with the shutter next.

commit id is 71beebb93156c21f063aaba30b8c33b2feabfa32

@Rodolphe

Between the two of us, we can probably break just about anything! At any rate, the good news is the shutter firmware is uploaded and working fine!

Another giant leap for mankind - well, at least a small step for NexDome users.

As always, thanks a million for your continued efforts to get this firmware to the point we can forget about it :-) !!

Figured it out - too many folder layers - go figure...

Still won't compile on my side - any suggestions?