Does the shutter firmware crash after some time? about firmware HOT 3 OPEN

I got a little more familiar with the rs232 based commands - I noticed it seems sensitive to using teraterm or termite - I suspect something wrt \r\n, echo alone also doesn't work (wsl). I'm also not entirely sure what rts/dts settings need to be used or any other comm settings; I couldn't glean it from the ascom server either. Windows for linux (wsl), I used printf to format the commands and this did work when redirecting to the right comm object.

It was also kind of interesting, every time I instructed reboots to the rotator, I would need to reboot in order to get ubuntu or the server to talk to the nexdome again.

Anyway, '@zzs\r\n' didn't work.

XB->WaitAT

XB->WaitAT

XB->Config

XB->Detect

XB->WaitAT

XB->Config

XB->Detect

XB->WaitAT

XB->Config

XB->Detect

and continuous XB->WaitAT's after.

from firmware.

Hi there, Yeh, there is something going on with it, as mine does the same occasionally. I used to get a lot of disconnects, but for some reason calmed down after I changed the battery charging arrangement, so don't know if the issue problems were related to power.

It still appears to lockup for some reason, and needs a shutter power cycle to recover.

I would really like to get 100% reliability in the shutter comms;

1. I would like to do remote imaging when I am overseas..... can't have a failure when thousands of miles away, be near impossible to explain to the misses how to resolve it.
2. The rain sensor ability to function is dependant on this - I have often thought that the rain sensor should have been put on the rotation element directly to remove this dependency.

I have been trawling through the source code, trying to think up options that would maybe solve the original problem of dead comms, one idea I was thinking of was to perform a power cycle of the shutter if the serial comms were lost by driving an output high, then make a small external circuit to do a power disconnect and timed reset.

Oh, and I use ClearTerminal for doing the serial comms directly when there is issues with the position and need to drive things manually etc.

from firmware.

My observation is that the XBees can get into an unrecoverable state which requires a hard reset to recover them. The firmware issues a factory reset command during the Config phase of the state machine, but this does not seem to be enough to fully reset the XBee. The firmware is not able to perform a hard reset because the XBee reset pin was not connected to anything in the hardware. Therefore the only option is to power-cycle the controller and XBee. If you are sufficiently motivated, you could try strapping the XBee reset pin through to an Arduino digital output pin, and using that to pull reset low during the config phase of the XBee state machine. Obviously this requires modification of both the hardware and firmware so it is not for everyone.

from firmware.