I think it is better if the INDI driver for TeenAstro and OnStep share the same code base (i.e. they are one .cpp/.h file).
The reasoning behind this is that TeenAstro is merely a subset of OnStep. So it will only be missing some features. The code can check the executable name and set a flag, and if it is TeenAstro then just skip the features that TeenAstro lacks. Everything else remains the same.
That way, bug fixes are quicker, and maintenance is generally easier.
Developing a driver is no rocket science and it is easy to maintain. For Ascom I have release Cycle that are aligned with the firmware update and I have to do the same with INDI.
What do I need to compile all that stuff? is it possible to crosscompile INDI with visual Studio?
@Charles: Following this. I like the simple scope of this teensy only version of onstep. Try to keep that KISS attitude as you guys go forward.
I was reminded recently that keeping units separate has the benefit of making troubleshooting easier and processor redundancy, as in the case of using a standalone focuser or filter wheel, allows you to continue to operate the others if any one unit goes down. This just seemed like a good place to share that bit of wisdom.
@Kbhaley: Good idea! Maybe you can give them a short example of how the linking works?
I mean, if they still need it?
@Herrhausen I'd continue to use the version that's working for you. I think the idea here is to make the project more approachable for people just starting out.
Blueshawk wrote: Good idea! Maybe you can give them a short example of how the linking works?
I mean, if they still need it?
There is an example of how INDI checks the name of the executable (which is actually a symbolic link), in
In the above case, the code instantiates a new driver depending on the name. But I am suggesting that the codebase for OnStep and TeenAstro be a single code base, with the parts that the latter does not support being conditional in the code. This is much better in the long run.
There is always the temptation to write new code, but what people often forget is the technical debt carried forward with maintenance (bug fixes, new features, ...etc.).
I am testing communications through EKOS and a TeenAstro mount controller. TeenAstro does not have a serial port, it communicates through TCP instead.
I used the LX200 Basic driver, because I was not able to configure OnStep for TCP (it seems to connect through serial only).
The communication starts fine, I can read the initial coordinates of the mount,
[2019-10-04T22:37:17.134 CEST INFO ][ org.kde.kstars.indi] - LX200 Basic : "[INFO] Connecting to 192.168.0.12@9999 ... "
[2019-10-04T22:37:17.434 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[DEBUG] Connection successful, attempting handshake... "
[2019-10-04T22:37:17.442 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[SCOPE] CMD <:GR#> "
[2019-10-04T22:37:17.446 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[SCOPE] RES <09:53:28> "
[2019-10-04T22:37:17.446 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[SCOPE] VAL [9.89111] "
[2019-10-04T22:37:17.447 CEST INFO ][ org.kde.kstars.indi] - LX200 Basic : "[INFO] LX200 Basic is online. "
but immediately after, the log shows communication errors
But I don't understand how we can make Ekos work: eithee we keep the connection open all the time, like a serial port, or for every command issued (and this can be one per second or more when polling the mount), the driver needs to open the connection, issue the command, then close the connection (not nice). What do you think?