Can anyone convert an INDI driver to ASCOM?

[dazzystar]

Hi All,

I'm a complete idiot when it comes to coding and have next to no knowledge on the subject so please excuse the question if it is a ridiculous one to ask but I'm trying to build the BullsEye DIY focuser project that Kari Brown has developed but there is only an INDI driver available and I want to use NINA on a mini PC. Can anyone convert the driver?

Cheers

Daz

[rsarwar]

it is possible. you need to have a python server running that will accept ASCOM commands and execute the corresponding indi commands through indi server.

indilib already supports python. so all you have to do is open a virtual serial com and listen to serial commands from ASCOM.

i did something similar for indiEqmod. feel free to use it as a reference. i was written in cpp and talks to the low level drivers of my DIY mount, but the concept is the same

https://github.com/rsarwar87/CmodA7-SkyTracker/blob/device-qmtech-a7-35t/koheron-server/libclient/ascom_server.cpp

Edited December 26, 2021 by rsarwar

[dazzystar]

Thanks very much for the reply (again!) but 90% of what you said went right over my head. Hope it helps other people though.

[wimvb]

Converting an INDI driver into ASCOM isn't an easy task, as INDI and ASCOM are completely different. In this case it is probably easier to convert the Bullseye firmware to accept another focuser protocol. If you eg rewrite the Bullseye Arduino code to use the MoonLite protocol (MoonLite commands), you could then use the MoonLite ASCOM driver to control the focuser. The MoonLite command set is available on the internet, and not too difficult to implement. Maybe someone already has done that.

[TerryMcK]

On 26/12/2021 at 11:29, dazzystar said:

Hi All,

I'm a complete idiot when it comes to coding and have next to no knowledge on the subject so please excuse the question if it is a ridiculous one to ask but I'm trying to build the BullsEye DIY focuser project that Kari Brown has developed but there is only an INDI driver available and I want to use NINA on a mini PC. Can anyone convert the driver?

Cheers

Daz

Have you asked Kari who is a member of this forum? He may be able to help.

[dazzystar]

Yes. I've asked Kari and he can't help unfortunately.

[BCN_Sean]

Looking at the hardware side of it, it may be quicker and easier to modify the firmware for the focuser itself to recognise as and accept commands as if it was a MoonLite clone than looking around to try and translate the drivers from one platform to another.

[dazzystar]

Thanks for the reply.

[rsarwar]

20 hours ago, BCN_Sean said:

Looking at the hardware side of it, it may be quicker and easier to modify the firmware for the focuser itself to recognise as and accept commands as if it was a MoonLite clone than looking around to try and translate the drivers from one platform to another.

I don't think that is true. Either way one needs to be able to map out the as om protocol. Question is where would you rather do it, in python which is easy to do for most with zero chance of breaking the firmware or in low level c code with possibility of breaking the device.. 

Edited January 1, 2022 by rsarwar

[malc-c]

I would assume porting an INDI driver to the ASCOM platform is quite complicated.  I raised this in a previous discussion regarding K Stars, which I think is one of the best planetarium application out there, siting between the glossy Stellarium app, and the now somewhat dated looking GUI of CdC.  But when it was ported to run on Windows there is no ASCOM support natively built in for telescope control.  I can only presume that the reasoning was it was too complicated to do so.  There may be workarounds to get windows K stars talking to EQMOD etc but often it seems like a lot of faffing around and I've never managed to get it to work reliably.   I don't know enough about Linux to make the jump in order to run the same work flow and applications I'm used to, so I have no choice but to continue with CdC.

Where hardware is concerned  it would be nice if manufactures released drivers for all three platforms, windows, linux and mac OS... but  I guess they feel the latter two are in a minority so don't see the point in investing the time and effort to write / port drivers to these platforms.

 

[rsarwar]

8 hours ago, malc-c said:

I would assume porting an INDI driver to the ASCOM platform is quite complicated.  I raised this in a previous discussion regarding K Stars, which I think is one of the best planetarium application out there, siting between the glossy Stellarium app, and the now somewhat dated looking GUI of CdC.  But when it was ported to run on Windows there is no ASCOM support natively built in for telescope control.  I can only presume that the reasoning was it was too complicated to do so.  There may be workarounds to get windows K stars talking to EQMOD etc but often it seems like a lot of faffing around and I've never managed to get it to work reliably.   I don't know enough about Linux to make the jump in order to run the same work flow and applications I'm used to, so I have no choice but to continue with CdC.

Where hardware is concerned  it would be nice if manufactures released drivers for all three platforms, windows, linux and mac OS... but  I guess they feel the latter two are in a minority so don't see the point in investing the time and effort to write / port drivers to these platforms.

 

they way i do is have kstar runing on ubuntu/windows (i use ubuntu but i tested it on on windows as well, no difference and dont need the indiserver on windows which is what is not ported on windows yet) and run indiserver and phd2 on a rpi4. then get the kstar to connect to the indiserver /phd2remotely. indiserver has its own version of eqmod which works reliably for me. 

RE: porting indi to ascom using python, it is possible. just wrap the indi calls with corresponding ASCOM and let the server run on rpi4. the open a virtual com port using serial to wifi driver and it should work fine. you ccannot do it for complex drivers, like for example eqmod, but for a focuser, it should be fairly straightforward

https://indilib.org/develop/indi-python-bindings.html

Edited January 2, 2022 by rsarwar

[wimvb]

5 hours ago, rsarwar said:

RE: porting indi to ascom using python, it is possible. just wrap the indi calls with corresponding ASCOM and let the server run on rpi4. the open a virtual com port using serial to wifi driver and it should work fine. you ccannot do it for complex drivers, like for example eqmod, but for a focuser, it should be fairly straightforward

Would that mean that you connect the focuser to an RPi4, and all else to a Windows machine? Then run everything on ASCOM except the focuser? (Remember, the OP wants to run NINA which is Windows). It seems a lot less hassle and cheaper to get a ZWO eaf and forget the Bullseye.

I wrote arduino firmware for my own diy focusmotor, using the MoonLite protocol, and used that with the MoonLite INDI driver. I would assume that the ASCOM MoonLite driver must use the same protocol, and that it is easier to rewrite the Bullseye firmware to follow the MoonLite protocol. Not all MoonLite commands need to be implemented.

[dazzystar]

I'm going to be building Robert Brown's DIYFocuserPro2 instead as this has ASCOM drivers, etc. I'll report back if I'm successful! 

[malc-c]

14 hours ago, rsarwar said:

they way i do is have kstar runing on ubuntu/windows (i use ubuntu but i tested it on on windows as well, no difference and dont need the indiserver on windows which is what is not ported on windows yet) and run indiserver and phd2 on a rpi4. then get the kstar to connect to the indiserver /phd2remotely. indiserver has its own version of eqmod which works reliably for me. 

Thanks for the advice, but this really clarifies the point I was making.  You have to have a computer of some sorts running linux to run the INDI Servre for the work around to function.  The fact you can download a version of Kstars written for windows and install it on a windows computer, but can't use its full potential to control a mount using ASCOM is so frustrating, especially for those not familiar with linux.  I'm sure if it was reversed, and the application was windows only, but got ported to Linux but without INDI support there would be the same concerns.  This for me suggests that making an application ASCOM compliant is far more complicated that we think ?

[rsarwar]

2 hours ago, malc-c said:

Thanks for the advice, but this really clarifies the point I was making.  You have to have a computer of some sorts running linux to run the INDI Servre for the work around to function.  The fact you can download a version of Kstars written for windows and install it on a windows computer, but can't use its full potential to control a mount using ASCOM is so frustrating, especially for those not familiar with linux.  I'm sure if it was reversed, and the application was windows only, but got ported to Linux but without INDI support there would be the same concerns.  This for me suggests that making an application ASCOM compliant is far more complicated that we think ?

Indiserver is written for distributed control systems. So that is by design. 

Why do you think indi cannot handle ascom compplient devices? it can talk to ascom devices. i have written by own mount controller and i refused to uses ASCI so i had to re write part of indi-devcies to make it work with mine, because all it did was talk to ascom devices. also it is not true that ascom can give more control.
Ascom is just a uart/serial device with a control charactor followed by some hex digits written an ascii. personally i dont like working with softwares that requres me to parse string. but hey, its what proposed and  made in 1990s using 1980s teck due to limitation on hardware and computational power. but things are a bit different now in 2022

I feel like this os becoming a Linux vs Windows debate. But Everone  has their thing, but Windows is not the most stable platform to run a control platform with psudo real-time requirements.  it works better on Linux 

Edited January 3, 2022 by rsarwar

[rsarwar]

also, if i am not mistaken, all ascom devices come with some form of driver from the manufacturer that sits between the planeterium and the device it self. so it really is inconsequential if one labels a device as ASCOM, as it requires a middleware to work.

essentially, indiserver provides the same functionality as this middle ware, but can also do a lot more than just allow kstar to comminicate with device located in a remote part of your observatory and you dont need to have usb cables running all over the place. just something like a pi zero W to run indiserver over wifi and have it comepletely detached.

Edited January 3, 2022 by rsarwar

[malc-c]

Not a an ASCOM vs INDI debate at all.  Just the way I see it you install a windows application on a windows machine that runs a standard platform (ASCOM)  so you would expect that windows application to support the platform designed for that operating system.  Not have to purchase another computer such as a pi to run linux to run the platform and then remote into it from the windows PC .

EQMOD as originally written is an ASCOM telescope driver.  So is selectable from other applications that need to control the mount, which is why the driver is listed in any other ASCOM compliant application.  Being an open source project others have ported it to other OS's and platforms.  Granted it's been a long time since I installed a flavour of linux so maybe things are more user friendly.  Back then adding a USB device required command line code which for someone totally new to the OS isn't ideal.  Windows, whilst in your opinion may not be the ideal OS on which to run software  for astronomical needs, and I respect that opinion, is more user friendly and plug and play.

I may play about later and see if installing a VM ware machine running linux will work - probably run into networking issues , but hey ho ... could be fun trying

[rsarwar]

2 hours ago, malc-c said:

Not a an ASCOM vs INDI debate at all.  Just the way I see it you install a windows application on a windows machine that runs a standard platform (ASCOM)  so you would expect that windows application to support the platform designed for that operating system.  Not have to purchase another computer such as a pi to run linux to run the platform and then remote into it from the windows PC .

EQMOD as originally written is an ASCOM telescope driver.  So is selectable from other applications that need to control the mount, which is why the driver is listed in any other ASCOM compliant application.  Being an open source project others have ported it to other OS's and platforms.  Granted it's been a long time since I installed a flavour of linux so maybe things are more user friendly.  Back then adding a USB device required command line code which for someone totally new to the OS isn't ideal.  Windows, whilst in your opinion may not be the ideal OS on which to run software  for astronomical needs, and I respect that opinion, is more user friendly and plug and play.

I may play about later and see if installing a VM ware machine running linux will work - probably run into networking issues , but hey ho ... could be fun trying

good luck with the linux. i would recommend getting a rpi3/4 for testing or install ubuntu as dual boot. i am not sure if all USB devices will work properly over VM. maybe it will. linux  distros has come a long way in the last 5 years, let alone compared to 15 years ago or more.

to me it makes little sense to dedicate a laptop/pc in the observator when it can be done with rpi remotely. and if you are set up in the backyard without a fixed observatory. it even less sense to me. wifi and ethernet is everywhere in our home, why not take advantage of IoT compliant devices . they have more power and stable compared to a what they were even 3 years ago.

 

Edited January 3, 2022 by rsarwar