EQ8 with Kstars / Ekos & INdI

[Stuart1971]

I have an ongoing issue, in that my six year old EQ8 mount will not work with EQMOD on INdI, now it used to work fine last year, but with that same version I was using then right up to the latest version it just will not connect.

It does not seem to see or respond to any serial commands, now what is really odd, is that it works perfectly fine on INdI with a Bluetooth EQMOD adapter and with the handset, and also even more weird is that is works perfectly fine on windows with the three EQMOD cables that I own…but nothing on INdI with any of the cables.

I have tried many many things as help on the INdI forum suggested, but still not good, I tired ditching the RPI for an Intel NUC with Ubuntu, still the same, so everything on my set up has been changed bar the mount, but as it works fine on windows, could the mount really be the issue…???? Any ideas from and INdI users…👍🏼

Edited September 17, 2021 by Stuart1971

[malc-c]

If the mount works fine on windows then it can't be anything physically wrong with the mount.  If the motorboard was faulty it wouldn't respond to commands under any platform or connection method, and would give a "no response" message when the handset is used.  The fact that it also works fine with a BT module, and with the handset also confirms that the issue isn't IMO hardware related.  Also as it fails on Indi with the same known working EQDIR cables, but works with the BT adapter, to me suggest its the way Indi handles the control of the COM ports, especially as you're tried the same platform on different hardware and get the same result. 

I can't help with suggestions as I use windows as the platform in the observatory PC.   The fact that it works via BT on the Indi platform may be the fix for now... at least it gives you a working set up.

[Stuart1971]

23 minutes ago, malc-c said:

If the mount works fine on windows then it can't be anything physically wrong with the mount.  If the motorboard was faulty it wouldn't respond to commands under any platform or connection method, and would give a "no response" message when the handset is used.  The fact that it also works fine with a BT module, and with the handset also confirms that the issue isn't IMO hardware related.  Also as it fails on Indi with the same known working EQDIR cables, but works with the BT adapter, to me suggest its the way Indi handles the control of the COM ports, especially as you're tried the same platform on different hardware and get the same result. 

I can't help with suggestions as I use windows as the platform in the observatory PC.   The fact that it works via BT on the Indi platform may be the fix for now... at least it gives you a working set up.

Thanks very much.

This is what I thought, but not being of electrical mind, I needed some reassurance, it does work fine in NINA with all three of the cables, and I was considering a new board for the mount, but at £160, it was an expensive risk, which may not have made any difference…

So when INdI tries to connect to the mount it sends a serial command to the mount and expects a reply, and this is not happening…is this correct, so I assume windows works in a similar way, so it’s not possible that it’s even a misaligned pin in the handset port on the mount could be the issue, as would be the same on all platforms…

So the main thing is the mount is fine… 

[Stuart1971]

The really odd thing is that the INdI developer, says I am the only person he knows of to have this issue, yet there are many people using the Skywatcher mounts with EQMOD and INdI…

He tried a piece of software on my RPI that tested the serial port, and there was a “no response” from the mount, so he says it’s not INdI related…..🤔🤔

yet similar software on windows gets a responds just fine…

[StevieDvd]

That reduces the areas it could be if all working on Windows.

What eqmod cable (what serial chip) are you using?  It needs a driver on the Linux side as well as the mount does, if the OS can't establish a working port for the mount connection then any serial test would likely fail.

On the AsiaAir Pro there were issues with the USB ports on some of the new mounts, as the RPi kernel driver was old - updating the kernel solved that.  As the Asiar is a locked system it involved an update from ZWO or a backdoor into the AAP to update the kernel. It's possible the eqmod cable you are using has the same serial chip as the non-working mounts.

See this github thread

 

[alacant]

3 hours ago, Stuart1971 said:

it works perfectly fine on INdI with a Bluetooth EQMOD adapter

<guess>

All your three eqdir cables have the same serial converter which Ubuntu doesn't like?

We have a dead posh brand-name cable which works with NINA but not with INDI, whilst these cheepo ones work fine with all our sw eqs. under any os.

</guess>

But really, I'd lose the cable anyway if you have BT working.

Cheers

** could you post a link to the indi forum discussion?

Edited September 17, 2021 by alacant

[malc-c]

This is my logic:

• Under windows and the ASCOM platform communications with the mount via EQMOD and any planetarium software etc work and the mount reports no time out errors. - Ergo there is noting physically wrong with the motor board on the mount.
• Under windows three EQDIR cables have been proven to work, again EQMOD doesn't time out or suggest any communication issues - Again suggesting that the hardware is fine
• Under Linux communication is established using the BT adapter - the mount control functions as expected - (you see where this is going) thus the hardware is fine.
• The supplied handset connects and controls the mount as expected - (do I need to repeat that the hardware is fine  )
• If under a flavour of Linux NINA established connection using all three EQDIR cables and the BT module then again this proves that communications are fine as is the mount

If under Indi communications fail using the same hardware then the issue clearly is that platform.  My guess is that as mentioned above, the chipset used in those EQDIR cables isn't supported, or any "driver" that Linux platform uses is not compatible or corrupts the data strings.  The fact that it works via BT would suggest that the BT chipset is supported and the driver handles the communications just fine.  As to why others have never reported the same issue is the $64000 question, but no two installations will be the same.  I don't know enough about Linux to know if it's the build, or flavour of the underlying kernel. 

The bottom line is that you have alternatives that work.   Maybe switching to one of those alternatives is the way forward rather than loosing sleep trying to get to the bottom of this, especially as the indi developer can't offer a solution. 

[malc-c]

Forgot to add:

• When either the handset or EQMOD is first connected the handset or EQMOD sends :e1 and :e2  to the mount.  This is basically "Send me your firmware version so I know what mount you are"
• The mount will respond with  a string of digits.  This is the firmware version which then confirms communications have been established 
• The handset / EQMOD then sends further commands to establish the gear ratios, microstepping etc so it can then do the math when processing gotos etc.

You could download any serial communication terminal app and manually send :e1 etc, or you could download and install the SW firmware updater application that does exactly the same to confirm communications.  But it wouldn't prove anything as you've already stated the mount works perfectly under windows and when using the BT option... 

[Stuart1971]

16 minutes ago, malc-c said:

Forgot to add:

• When either the handset or EQMOD is first connected the handset or EQMOD sends :e1 and :e2  to the mount.  This is basically "Send me your firmware version so I know what mount you are"
• The mount will respond with  a string of digits.  This is the firmware version which then confirms communications have been established 
• The handset / EQMOD then sends further commands to establish the gear ratios, microstepping etc so it can then do the math when processing gotos etc.

You could download any serial communication terminal app and manually send :e1 etc, or you could download and install the SW firmware updater application that does exactly the same to confirm communications.  But it wouldn't prove anything as you've already stated the mount works perfectly under windows and when using the BT option... 

yes done this, works and reports in windows…but not on RPI with latest kernel and latest INdI, there is no response there at all

[Stuart1971]

47 minutes ago, alacant said:

<guess>

All your three eqdir cables have the same serial converter which Ubuntu doesn't like?

We have a dead posh brand-name cable which works with NINA but not with INDI, whilst these cheepo ones work fine with all our sw eqs. under any os.

</guess>

But really, I'd lose the cable anyway if you have BT working.

Cheers

** could you post a link to the indi forum discussion?

I have two cheapo ones, and a Lynx one from FLO, same with all…

[Stuart1971]

2 hours ago, StevieDvd said:

That reduces the areas it could be if all working on Windows.

What eqmod cable (what serial chip) are you using?  It needs a driver on the Linux side as well as the mount does, if the OS can't establish a working port for the mount connection then any serial test would likely fail.

On the AsiaAir Pro there were issues with the USB ports on some of the new mounts, as the RPi kernel driver was old - updating the kernel solved that.  As the Asiar is a locked system it involved an update from ZWO or a backdoor into the AAP to update the kernel. It's possible the eqmod cable you are using has the same serial chip as the non-working mounts.

See this github thread

 

Yes, that is with PL chipsets, all mine are FTDI….👍🏼

[alacant]

4 minutes ago, Stuart1971 said:

two cheapo ones, and a Lynx one

Is ftdi loaded? e.g. on one of our 20.04s:

lsmod | grep  ftdi_sio
ftdi_sio               61440  0
usbserial              53248  1 ftdi_sio

 

[Stuart1971]

1 hour ago, alacant said:

<guess>

All your three eqdir cables have the same serial converter which Ubuntu doesn't like?

We have a dead posh brand-name cable which works with NINA but not with INDI, whilst these cheepo ones work fine with all our sw eqs. under any os.

</guess>

But really, I'd lose the cable anyway if you have BT working.

Cheers

** could you post a link to the indi forum discussion?

It sounds like you have experience with BT adapters, is there any downside to using over the cable, like any lag or delays with signal..??

I have tried but not actually used one in anger….

[malc-c]

1 hour ago, Stuart1971 said:

yes done this, works and reports in windows…but not on RPI with latest kernel and latest INdI, there is no response there at all

Switch to windows then   - But then the windows version of Kstars doesn't (for some crazy reason) support ASCOM... I've been asking for years for them to do so....

1 hour ago, Stuart1971 said:

Yes, that is with PL chipsets, all mine are FTDI….👍🏼

That's surprising - I was betting that it would have been the other way around - PL 2303 drivers are not natively supported under windows... FTDI are and (which probably explains why it works so well under windows.

[Stuart1971]

28 minutes ago, malc-c said:

Switch to windows then   - But then the windows version of Kstars doesn't (for some crazy reason) support ASCOM... I've been asking for years for them to do so....

That's surprising - I was betting that it would have been the other way around - PL 2303 drivers are not natively supported under windows... FTDI are and (which probably explains why it works so well under windows.

I cant move to windows, as INdI still needs to run on the RPI…🤔

[Stuart1971]

2 hours ago, alacant said:

Is ftdi loaded? e.g. on one of our 20.04s:

lsmod | grep  ftdi_sio
ftdi_sio               61440  0
usbserial              53248  1 ftdi_sio

 

Yes 

[alacant]

2 hours ago, Stuart1971 said:

Yes

OK.

Try the traditional route:

Disconnect everything on usb. Pull the plugs.

before

ls /dev/ttyUSB0
ls: cannot access '/dev/ttyUSB0': No such file or directory

Unload the ftdi module and tail the log as you plug in the cable.

Use the old method of communicating.

e.g.:
Sep 17 19:58:22 g50 kernel: [  588.552277] usb 2-2: FTDI USB Serial Device converter now at
tached to ttyUSB0

and after:

ls /dev/ttyUSB0
/dev/ttyUSB0

Enter the port in the INDI panel:

Disable autoconnect in your EKOS profile and connect only the mount.

Anything?

 

Edited September 17, 2021 by alacant

[Stuart1971]

1 hour ago, alacant said:

OK.

Unload it and tail the log as you plug in the cable.

Hmmm, tail the log….?. You are talking to a Linux dummy here….😂

[alacant]

11 minutes ago, Stuart1971 said:

tail the log

tail -f /var/log/syslog

**I've edited that post with more detail

HTH

 

 

 

Edited September 17, 2021 by alacant

[malc-c]

27 minutes ago, Stuart1971 said:

Hmmm, tail the log….?. You are talking to a Linux dummy here….😂

 

You and me both mate... Now you know why I suggested windows 😟

I hope you manage to resolve this

[Stuart1971]

31 minutes ago, alacant said:

tail -f /var/log/syslog

**I've edited that post with more detail

HTH

 

 

 

I’m not sure you are quite understanding, it shows in Linux, and comes up with the correct port name in INdI, but will not connect, just shows, TTY read failed…

If I disconnect it disappears and if I re connect it shows up, so it’s recognised no problem, but Indi will not connect to it…so what you suggest will show it as working, but then when I click connect in INdI it will not, also INDI now does not show ttyUBB* ports, but actually shows them by name and ID, so the port names are much longer….

Edited September 17, 2021 by Stuart1971

[alacant]

4 minutes ago, Stuart1971 said:

just shows, TTY read failed…

I'm trying to find out why. I've only the snippets of information posted here. 

No logs, no link to the indi discussion... So all I can do is guess.

As you have a working system, maybe just use that:)

[Stuart1971]

32 minutes ago, alacant said:

I'm trying to find out why. I've only the snippets of information posted here. 

No logs, no link to the indi discussion... So all I can do is guess.

As you have a working system, maybe just use that:)

Here you go….👍🏼
https://indilib.org/forum/stellarmate/9918-eqmod-will-not-connect-with-cable-at-all.html

[alacant]

1 hour ago, Stuart1971 said:

...you go

Mmm. So you haven't tried removing the kernel module...

 

 

Edited September 17, 2021 by alacant

[Stuart1971]

59 minutes ago, alacant said:

Mmm. So you haven't tried removing the kernel module...

 

 

Don’t think so….all I know is I have the very latest kernel as Jasem updated it today while he was having another go to try and fix….but got nowhere…

He has  given up now..☹️