Driver is not showing up in the Driver selection dropdown

[wuyuanyi135]

indiserver 1.9.1 indi-thirdparty 6b5bd37 system: Linux raspberrypi 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l GNU/Linux When selecting driver, this driver is not showing up. I can confirm all other telescope drivers (e.g., Telescope simulator) works fine.

[kneo]

Hello @wuyuanyi135, First, please provide the software you are using, I only tested astroberry indi server in combination with kstars or stellarium!

Second, remote indi clients never showed the remote device names, only devices locally available, I suspect this is also the case with what ever software you are using.

However the Cursor in the "Driver" combo box seems to allow you to enter a custom name. So simply enter "BRESSER Messier EXOS-2 EQ GoTo" as you would when using kstars (see: Application Setup: kstars) Make sure the server is setup in accordance to the provided manual.

Regards,

[wuyuanyi135]

@kneo Thanks for your response! Sorry that my information was not specific. The screenshot is from PHD2. It is a combo box and it does not allow text input. I noticed that your Application Setup note is using text input BRESSER Messier EXOS-2 EQ GoTo but PHD2 does not support this. I wonder whether the driver could notify the client so it get registered in the list?

[wuyuanyi135]

I just played around the built-in driver and the driver discovery should be automatic. I will take a look and see why this driver is not being discovered.

[kneo]

Unfortunately I have to tell you that PHD2 aka "software auto guiding" is not supported with this mount/this driver. The controller simply does not allow it, unless a major software update is provided by the manufacturer. Which might a reason why its not showing up. You can only use ST-4 guiding unfortunately, which should be a completely different setup! I don't know if PHD even supports something like this. However, I can not assist you with that, because I don't have any auto guiding hardware.

[wuyuanyi135]

@kneo Thanks! Actually you are quite right. The autoguiding performance on this mount is not optimal. I was able to use the official driver to play with the auto-guide. Although this mount may not be autoguide worthy, I think the INDI client failed to detect this driver is a different problem. I will try some debug and see if I could figure out why. Thanks for your information!

[kneo]

Drivers have to report their capabilities to the driver framework. Because the serial protocol simply does not support this. Just slewing, slow slewing is supported, thus I do not report a "can autoguide" flag to the framework. The driver not showing up there, might not be a bug, but intentional.

[wuyuanyi135]

@kneo Oh I see. This explains the behavior. Thank you! Seems the windows ASCOM driver supports the slow slew. Was it not implemented or the reference project did not reverse this part of command?

[wuyuanyi135]

I think ST4 is a viable workaround. Thank you for creating this amazing driver!

[kneo]

When I started examining the capabilities of the serial protocol for the driver I used the ASCOM test tool which only revealed two implements for directional motion:

1. take the current pointing coordinates and add a tiny amount (which always annoyingly beeps),
2. add the slew according to the user settings on the hand controller.

I deemed both possibilities unsuitable for software auto guiding, because all the mount did was slewing off course. This behavior was also observed by ASCOM users, and by examining the reverse engineered source code of spitzbube(see readme.md), you will see, the auto guiding pulses and slewing are two different pairs of shoes. Thus I removed the whole software auto guiding implementation again, because a malfunctioning tool is worst than a limited tool.

There is hearsay, that Bresser is working on a firmware update, but unless its released and does support proper software auto guiding I'd rather not claim the driver supports it.

I'm sorry.

[wuyuanyi135]

@kneo I totally understand this decision given the limited capability of the mount. I am also looking at the de-assembly of the ASCOM driver. I have a question: when ASCOM send pulse command (command byte 1, 2, 4, or 8), is it handled by this code?

https://github.com/Spitzbube/EXOS-2_GoTo_HandController/blob/cc0b41dfcc6f78cf218073f9ca3d245d1e5431b0/applications/v2.3/ascom.c#L246

[kneo]

you have also this code fragment:

uart.c

It contains the ISRs for the serial channels. I really don't understand everything of it, I just used it to recover some messages I could not sniff. It labels these commands as guiding commands, however I sniffed these as "motion commands" because in the ASCOM test panel gismo these were not associated with auto guiding in any way. These pulses via ST-4 should received via UART1, where ever this happens. Spitzbube said there was a mainloop around somewhere, I could not find it this instant.

[wuyuanyi135]

Many thanks to your explanation. I see the pulse guide section now.

[kneo]

I found it. here it is:

main.c Line 3237 etc...

the computation is here: main.c Line 4559 etc...

[Spitzbube]

Hi both, interesting discussion. Do you require any further help in understanding the EXOS2 handcontroller firmware? @wuyuanyi135: Did you disassemble the ASCOM driver? It would be interesting even for me to have a look at their sources.

[wuyuanyi135]

Hi! @Spitzbube Yes, the ASCOM driver located at C:\Program Files (x86)\Common Files\ASCOM\Telescope\ASCOM.BRESSER.Telescope.dll (installed by https://cdn.shopify.com/s/files/1/0390/6029/files/BRESSER_GOTO_SYSTEM_2018-06-05.zip) can be easily de-assembled with an IL viewer. I used JetBrains Rider to do that. The code is not mangled so it's quite easy to see the serial commands.

[kneo]

From what I see now, ST-4 and Handcontroller pulses are basically the same, if only one of both is used. Thus reintegrating the auto guiding is feasible. With your disassembly method I should be able to see how its supposed to work, when reintegrating. However I suspect there will be no improvement, over the ASCOM implementation. I see what I can do next time I have access to my mount.

you can checkout this 7f08b0f279e00cc5aeda9c11ca97ed3d328954bc commit to try out the experimental auto guiding implementation.

[wuyuanyi135]

@kneo Thanks for taking care of this. In the mean time I will test how this mount performs with ST4 guiding. Let me know if you need any help or test!

[kneo]

Just FYI: I found this repository containing an Open Source version of an ASCOM driver in C#, It seems my autoguiding implementation was completely incorrect, if this thing is right: Open Source C# ASCOM Bresser repository.

[wuyuanyi135]

@kneo I quickly peeked the code. It looks like the disassembled official EXOS2GT ASCOM driver. I don't know if the developer just reused some code from the official codebase.

[Spitzbube]

Very interesting!

[wuyuanyi135]

@kneo I had somewhat better experience with the ST4 autoguide on this mount. For some reason, the ASCOM interface is very aggressive (I could hear the motor engage promptly). The ST4 guiding is quite smooth. I am not sure if the hand controller handles the two guiding input differently.

[Spitzbube]

According to the reversed code there seems to be a factor of 2 (for RA) and 4 (for DEC) to the values coming from the ASCOM interface:

    if (bTrackingMode == MENU_TRACKING_MODE_TRACKING/*2*/)
    {
        //6fb34
        ReceiveMountAutoguideValues();

        g_iAscomGuideValueRa = g_iUart0GuideValueRa;
        g_iAscomGuideValueDec = g_iUart0GuideValueDec;

        Data_40004128.dAutoguideRa += (2 * g_iAscomGuideValueRa + iMountAutoguideRa) *
            dGuidingSpeed * 0.00153;

        Data_40004128.dAutoguideDec += (4 * g_iAscomGuideValueDec + iMountAutoguideDec) *
            dGuidingSpeed * 0.00153;

        g_iUart0GuideValueRa = 0;
        g_iUart0GuideValueDec = 0;
    }

[kneo]

The problem is you can not change it: uart.c Line 168

It also is used here: file_1f30.c Line 2202

Its set to a constant when a "move" command is sent. So the Parameters of these commands are superfluous after all, and this C# driver above may not be intended with V2.3 Firmware.

So a patched firmware remains essential. I think I will reintegrate the auto guiding with the next overhaul of the driver. I think I'll start this week end. If we can patch the firmware this feature should work like the ST-4 auto guiding. I can mention these facts to the user in the documentation for awareness.

@Spitzbube did you manage to test your firmware on real hardware (=the mount)?

[Spitzbube]

yes I can apply any change and run this patched fw on my EXOS2 + hand controller. So if you would like to have anything changed, please tell me. I can even send you the new hex file for you to flash.

[kneo]

Neat! I'd like to come back to that offer, currently I'm still not able to flash this thing anyway. This ancient flash tool tells me "can not communicate with test board!", no matter what I set it up in accordance to the manual. Using a serial monitor to send "?" on reset does not work either. I suspect that the provided flash adapter thingy is faulty, or something. If I use the serial port for ASCOM communication with the mount everything works. I think I first fix the driver and then later come back to the firmware flashing issue. I'll have to rig something up for better diagnostics.

A pin out schematics for the connector(s) would be nice though.

[Spitzbube]

Please see here the pins on the RJ9 cable connector (the actual wire colors may not be correct):

1 = GND 2 = ISP (connect to GND to start the flash loader) 3 = PC Rx 4 = PC Tx

[kneo]

Thank you for your help @Spitzbube! I think I'm on to something, after several hours of continuity testing, I made a little schematic to illustrate the issue I found: Correct me if I'm wrong: the flash adapter connects ISP to GND. However in normal operation ISP is also connected to VCC (5V). Using the flash adapter then shorts the MaxLinear (U4) IC and renders it useless, thus serial connection does not work. I always thought you need somewhat of a GND and VCC for an IC to work. The fix would be cut a trace, solder in a botch wire in order to get it working, ah yes toss the flash adapter since its useless.

[wuyuanyi135]

I purchased the official ISP cable from ES and it does force the handbox entering the ISP mode during boot up. I believe the ISP pin is internally hard wired. So for normal operation the cable must be connected to the handbox after the initialization.

[kneo]

I have everything official from Bresser and yes I made a yet incomplete schematic of the whole board in the documentation folder: The ISP pin is wired to the processor directly but also to VCC. No problem in normal operation but it results in a short between VCC and GND when using the flash adapter. I measure continuity when the adapter is connected between these two pins. I consider shorts generally a bad thing so I think I concluded I need to modify the board in order to get it to work. Maybe this is just my revision, or a bad charge, I don't know just that it beeps between pin 15 and 16 on the shown IC when the adapter is connected.

[kneo]

@wuyuanyi135 I created a branch for development, the autoguding support is reintegrated within this branch only, See: dev_Ver0.900 With these modifications your can select the Exos2 GoTo in the PHD2 dialogs, but you'll still have the same "shooting star" problem. I tried to simulator guide with the mount and it always drifted away, so the coefficients in the firmware increase the magnitude of the guide pulses. You can try it out if you like, but unless these values are reduced to 1, I fear the guiding via software will never work properly.

If are in the fortunate position, where you can flash a firmware without modifying your handbox, you could try that.

[wuyuanyi135]

@kneo Thanks! I will give it a try next clear night. I guess this guiding rate is hardcoded as discussed above, not controlled by the guiding speed as in the handbox setting menu?

[kneo]

you can set the value there, but it will always be 2 and 4 times the value of the normal guiding amount, that is without a firmware patch.

[XXh2enningXX]

In my case the driver was also not showing up.

I found (with the help of a Linux-pro-friend) that the "indi_bresserexos2.xml" file was not stored in the "/usr/share/indi" folder.

Copying the file into the right folder fixed the problem. Possible, that the issue was a problem with my Astroberry distribution.

btw. thanks for the effort and work on this driver!

[kneo]

Its was an error in the build system, see Issue #7.