I resolved the issue. I just deleted everything and did a clean build. Not sure what the issue was.
Anyway, position data now updates properly and both relative and absolute motions work.
That was my idea as well. Once I get it to build I can test it out however, despite building libindi and installing I still cant build indi-avalon.
I will do that. However at the moment I cant get it to build. I have tried building it solo and building all 3rd party drivers and it fails due to:
In file included from /home/canis/Code/indi/3rdparty/indi-avalon/lx200stargofocuser.h:25:0, from /home/canis/Code/indi/3rdparty/indi-avalon/lx200stargofocuser.cpp:22: /home/canis/Code/indi/3rdparty/indi-avalon/lx200stargo.h:27:34: fatal error: mount/lx200telescope.h: No such file or directory
I think I have a fix but I am having problems compiling now so once I get that resolved and test the fix out I will generate a PR for the indi library.
I think I know what is going on.
The mount has a periodic function to query status like RA/DEC and what not. The focuser also has one as well but it isn't being called. The reason you can extend the focuser and not retract is because position commands to positive values are allowed, all extension motions produce positive values when referenced to 0. However retraction motions require a negative position (compared to the current position) which means you cant retract because the current position is always 0. The problem will be resolved once the focuser's query function is called periodically.
I will see what I can do to fix this. I know the design has changed a bit since I last looked at the code. The main difficulty will be in preventing the focuser from trying to query status while the mount is doing the same thing. The simplist thing might be to call the focuser's periodic update function at the end of the mount's periodic update function.
I wrote the initial version of the focuser interface. Currently I don't have much free time but I will see what I can do.
I have a couple of questions:
- What is the firmware version you are using for StarGO?
- Are you commanding the motor to move through the interface or are you physically moving it?
- If you are commanding the motor to move through the interface is it actually moving? (I think it moves out but wont move in)
I suspect I know what is happening but I will get back to you.
Wolfgang, How do you feel about grabbing the focuser code I wrote and adding it to your driver? I have decided to halt development of the Telescope/Focuser driver combo I was working on so we can focus on a single Avalon driver. If that sounds good to you I'll start trying to break your driver
I have the ability to set the tracking rates and slewing rates. I haven't figured out how to query what the currently selected tracking rate and slewing rate is. One status command you might be interested in is :X34# it will return something like m00# where the first 0 is for RA, second 0 is for DEC. The higher the number, the faster that axis is moving. m10# indicates RA tracking only while m54# would indicate a fast slew on RA, and slightly slower slew on DEC.
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.
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.
Take a look at the code and tell me what I think.
I have apparently been duplicating work Wolfgang has been doing. When 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: github.com/CanisUrsa/indi grab branch canisursa/avalon_work The readme in 3rdparty/indi-avalon should provide you with any information you need.
Here is the google document. The sync homing commands are a bit more involved and require calculating the LST (Local Sidereal Time) and uploading that to the StarGO. I am currently updating the spreadsheet with more detail on the syncing steps as my understanding increases.