AstroEQ doesn't work with EQMOD 2.xx #24
Comments
|
Which version of EQMOD? I've not ever seen EQMOD send the :O command, and have never had the problem you describe. Could you provide more details. |
|
EQASCOM_V200k I haven't original synscan, so I know only information published on web. I change in both, firmware and java software progmode command to ")" and now. Everything is working. |
|
Interesting. Seems there have been some changes to EQMOD since AstroEQ was first developed, and new commands added by Skywatcher. I'm looking in to the issue. |
TCWORLD
changed the title
Since EQMOD V2.00, the :Oxx is issued as part of run time. This caused AstroEQ to spuriously enter programming mode causing connection issues. To combat the problem, programming mode entry now requires 20 successive :O1x commands with no other commands in between. It is highly unlikely EQMOD will ever issue this many :O1x commands without other commands interleaved. EQMOD always appears to send :O1x commands together with a companion :O2x command. This is enough to prevent entry as only an :O1x command is considered.
The purpose of EQMOD using the :Oxx command has become clearer. This is used to control up to two GPIO pins, for example to trigger a camera shutter. The :O1x command in AstroEQ is used to enter programming mode, so in order to tell EQMOD not to use the SNAP1 interface, AstroEQ now reports an error packet when :O1x is issued in run-mode. The configuration utility knows to expect this error packet. On the 20th time of writing :O1x, AstroEQ enters programming mode and sends a success packet. This should provide a secure way of fixing issue #24. AstroEQ V4.6 and newer, as well as Mega variants, have a spare GPIO pin not used for standalone mode. To still allow a feature rich experience in AstroEQ, the :O2x command is now used to control this GPIO pin. By adding a simple transistor or optocoupler, the GPIO1 pin can now be used as SNAP2 in EQMOD.
Compile Release Version of Firmware V8.12 and Configuration Utility V3.9.0. This Fixes Issue #24.
|
I've pushed a new version of the config utility and firmware. I believe this should solve the issue - seems to on my end. |
|
Hi Tom
I have held back fro sending you my AstroEQ controller to you for the moment for you to test, I tried to use your new configuration and firmware but found that the configuration template does not reveal itself , I have all the uptodate software to allow this to work but no joy does anyone else have this issue?
Regards
James Wood
…Sent from my iPhone
On 23 Jun 2018, at 15:04, Tom Carpenter ***@***.***> wrote:
I've pushed a new version of the config utility and firmware.
I believe this should solve the issue - seems to on my end.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I believe this is now resolved. If it's not, feel free to reopen. |
|
Hi Tom
I have packaged my controller and will send off today by Royal Mail , I have included a note of drive setup etc, just hope you can resolve the time out in EQMod test after configuration.
Thank you again.
Jim Wood.
…Sent from my iPhone
On 30 Jun 2018, at 13:00, Tom Carpenter ***@***.***> wrote:
I believe this is now resolved. If it's not, feel free to reopen.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
EQMOD send to device on initialisation commands ":O10" fillowed by ":O11". Because you use "O" as progmode select command, AstroEQ is switched to programmin mode and stop responding to normal commands. EQMOD then hangs-up.
Solution is to move "progmode" command to other letter as "O".
The text was updated successfully, but these errors were encountered: