Hello ! nice start !

here is my fork of indi :

github.com/dragonlost/indi

i have copy OnStep driver and remove PEC and Focuser part. I write new line in other file : CMaleLists.txt, drivers.xml, lx200driver.h, lx200generic.cpp

Following Kbahey's suggestion, it would be nice to put a symbolic link to the onstep functions that are identical and common to teenastro so as not to duplicate code.

It should remove all the part alignment to N star that is not supported by teenastro.
At first, no need to coded the part that allows you to change the mount settings on the fly.

Charles, will you be able to list the differences between teenastro and onstep so that everyone can clearly identify what he will need to do ?

Will the Teenastro driver support the onboard focuser?

The focuser will not be supported by this driver because in teenastro the focuser is on another card (another teensy and usb). But nothing prevents to develop another driver for the focuser.

Many thanks for the clarification. Am I correct in assuming it currently doesn't make sense to build my own Teenastro if I want to continue on an "INDI only" basis?

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.

actually this seems like a good solution. On the other hand, the coding in C and C ++ exceeds me. I only code in python. I am coding an interface to program the teensy with pyqt.

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?
Thanks.
Charles

@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.

just my 2c. :-*

There is an example of how INDI checks the name of the executable (which is actually a symbolic link), in this code .

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

[2019-10-04T22:37:19.474 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[SCOPE] CMD <:GR#> "
[2019-10-04T22:37:19.498 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "Error reading RA/DEC. "
[2019-10-04T22:37:21.484 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[SCOPE] CMD <:GR#> "
[2019-10-04T22:37:21.491 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "Error reading RA/DEC. "
[2019-10-04T22:37:23.486 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[SCOPE] CMD <:GR#> "
[2019-10-04T22:37:23.488 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "Error reading RA/DEC. "
[2019-10-04T22:37:25.488 CEST DEBG ][ org.kde.kstars.indi] - LX200 Basic : "[SCOPE] CMD <:GR#> "

I started investigating, and found out this is due to tty_write() returning an error: first TTY_WRITE_ERROR then TTY_OVERFLOW.

Before continuing, I would like to ask if anyone recognizes this, and ask for suggestions on how to fix it. Thank you!

** updated **
I found out the problem was in the board which would close the connection after 2 seconds.

TeenAstro is based on OnStep. What I am going to say applies to OnStep, and probably to TeenAstro as well.

OnStep does not keep the TCP connection open for subsequent communications. As a result, each command has to establish communication as if it is a new connection.

I wrote a Python API for OnStep , and I had to connect on every call, when using TCP.

Thanks Khalid, this explains it.

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?