I build it and test il yesterday night in my garage.
I do a synchronisation with th button in the indi panel, then I do some gotos.
The area pointed was always good.
Next step, I try it on the sky.
Very goog job !!!!!
I have apparently been duplicating work Wolfgang has been doing. When I finished the Focuser and tried to get a telescope up and running I ran into issues with the serial port. I fixed that by making an Avalon driver that handles both Telescope and Focuser (AUX1). Instead of using the lx200basic as a starting point I rolled my own. My intent is to take this knowledge and write an updated bluetooth application.
- Set Site Location
- Set Park Location
- Sync Home
- Goto Home
- Set Movement Speed (Guiding/Centering/Finding/Slewing)
- Move mount (N/S/E/W)
- Abort Motion
- Goto RA/DEC
- Sync to RA/DEC
- Abort Telescope Motion
- Turn tracking On/Off
- Change tracking rate Lunar/Solar/SIdereal (the commands are implemented but I think they only activate when you try to slew to the moon or sun, I am trying to get clarification from Jasem)
- Get Firmware Info (Manufacturer/Firmware Version/Firmware Date)
- Change Focuser Speed (Not recommended, Avalon's implementation seems a bit strange, suggest leaving it at "2")
- Move Focuser by Time (Not recommended, still a bit wonky)
- Move Focuser by Absolute Position
- Move Focuser by Relative Motion
- Sync Focuser to Position
- Abort Focuser Motion
If you are interested in trying it out see:
grab branch canisursa/avalon_work The readme in 3rdparty/indi-avalon should provide you with any information you need.
There are a couple of problems that remain, sometimes a parsing error occurs during a park. The park / goto home commands produce a number of responses over time and it is hard to predict when I will receive them. The result is a race condition in which I send the command to query RA/DEC and as a response get one of the park command responses. It doesn't impact performance but does mean the RA/DEC won't update until the next poll cycle. I am not quite certain how to handle this or if it is worthwhile to handle it.
Another issue I have encountered is trying to make sure I update the various INDI::Telescope states (properties and otherwise). I think I have handled most cases but I am pretty certain some issues with the IDLE/OK/BUSY/ALERT indicators remain.
I had two main reasons for not utilizing LX200Generic as a base class. The first was to increase my understanding of INDI. The second is that Avalon has certain functionality (mainly AUX1/AUX2 control) that can't be accessed during things like slew and parking. I am pretty certain it could be made to work but I didn't want to cobble something together. I think it ended up making a more cohesive driver. I find utilizing inheritance too much can make code more difficult to understand. There are a couple of things I am not happy about design wise, the main one being the mixing of the telescope and focuser functionality. I may try to pull those two things apart but I haven't spent enough time thinking about how to handle that.
After speaking with Jasem I found out what I was missing for controlling the tracking rates so that should be fixed later tonight.
Next features implemented: parking, unparking, tracking rates, slewing speeds.
@CanisUrsa: I think I found a way how to keep the tracking rates and slewing speeds in sync between the INDI driver and StarGO. Setting it from outside - e.g. with the Windows StarGO client - leads to updates in the INDI client.
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | Moravian G2-8300 + ASI 1600mm pro + ASI 294mc pro | KStars/INDI on Raspberry Pi 4 with Raspbian 10