So that would mean an issue with either the cable or the PI USB port, but both of those have been ruled out, the cable is fine on windows, and the cable on INdI, has been used in the Pegasus hub and not direct in the RPI and the problem is still there.. so…or have I got that all wrong….maybe,, 

oh, and I have measured the voltage when connected to the rpi on the RX and TX lines of the cable and they are correct approx 4.9v on both…as this is a 5v TTL cable as the EQ8 mount is both 3.3v and 5v tolerant….

If you think the electrical part is OK (I am referring to current draw when communication starts, because the Pi is different from your laptop), then all that is left is the way the serial port is configured, with a parameter that ASCOM sets but not indi.

By the way, Jasem proposed to send a character through the serial port to get the firmware version from the mount. Please test this under Windows so we have a reference for comparison. You will probably need to install the optional hyperterm for this.

-Eric

Not sure what you mean about Jasem….he tested on my set up with cutecom…and did not get a reply back on the serial port, is that what you refer to, ?? he never mentioned about needing the firmware of the mount…? Is that important, I’m sure I can find that from the handset….
But like I say this cable worked perfectly six months ago with exactly the same set up…

I don't need the firmware version, I need a test that confirms communication is happening on the cable with strictly minimal parameters.

-Eric

Ah, ok….
I am just totally bemused by what has changed in the last six months to stop this working on both the RPI direct and through the Pegasus UPB, which is where I used to have it plugged in….and nothing changed on my set up…at all…

That, is a question we cannot really answer from our point of view. As there is no magic in this, no change between setups necessarily means we are not able to see the change. You proved that the cable was OK, and that the difference is the Pi, be it for the mount or the power box. So let's focus on this, withour urgency.

-Eric

Hi Eric,
back from holiday now, and downloaded Hyperterm free trial on windows, but have no idea at all how to use it or what to do…but there is no serial communication at all on cutecom in INdI…
but the cable shows fine in lsusb, and when connected in dmseg….

also tried yet another EQMOD cable and still the same, my next step is to ditch the RPI and try a mini PC running Ubuntu…but don’t think that will make any difference
I am at the end of my tether with this….
It’s not the cable, it’s not the mount, it’s probably not the RPI, and it happens on every version of INdI I have tried, plugged directly  into the RPI, and plugged into the Pegasus UPB, and also without the UPB in the equation….I am stumped…and have an unusable system..

 

Hmmmm, why do both the Pegasus UPB and the EQMOD serial port names end in the same “port0” is this correct…?

Does this look correct from DMESG

  [    3.259396] usb 1-1.2.5: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[    3.259418] usb 1-1.2.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.259437] usb 1-1.2.5: Product: FT232R USB UART
[    3.259454] usb 1-1.2.5: Manufacturer: FTDI
[    3.259471] usb 1-1.2.5: SerialNumber: AM00M7QG
[    3.373155] usb 1-1.2.7: new full-speed USB device number 6 using xhci_hcd
[    3.391850] random: systemd: uninitialized urandom read (16 bytes read)
[    3.404655] random: systemd: uninitialized urandom read (16 bytes read)
[    3.405318] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    3.405961] random: systemd: uninitialized urandom read (16 bytes read)
[    3.406471] systemd[1]: Listening on Journal Audit Socket.
[    3.407312] systemd[1]: Listening on Journal Socket.
[    3.415193] systemd[1]: Mounting Kernel Debug File System...
[    3.416878] systemd[1]: Created slice User and Session Slice.
[    3.523578] usb 1-1.2.7: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[    3.523601] usb 1-1.2.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.523619] usb 1-1.2.7: Product: UPBv2 revB
[    3.523637] usb 1-1.2.7: Manufacturer: Pegasus Astro
[    3.523654] usb 1-1.2.7: SerialNumber: UPB24YVD54
[    3.563020] i2c /dev entries driver
[    4.087242] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    4.185754] systemd-journald[116]: Received request to flush runtime journal from PID 1
[    4.870007] usbcore: registered new interface driver usbserial_generic
[    4.870084] usbserial: USB Serial support registered for generic
[    4.888403] usbcore: registered new interface driver ftdi_sio
[    4.888481] usbserial: USB Serial support registered for FTDI USB Serial Device
[    4.888814] ftdi_sio 1-1.2.5:1.0: FTDI USB Serial Device converter detected
[    4.888979] usb 1-1.2.5: Detected FT232RL
[    4.892628] usb 1-1.2.5: FTDI USB Serial Device converter now attached to ttyUSB0
[    4.892923] ftdi_sio 1-1.2.7:1.0: FTDI USB Serial Device converter detected
[    4.893177] usb 1-1.2.7: Detected FT-X
[    4.898719] usb 1-1.2.7: FTDI USB Serial Device converter now attached to ttyUSB1
[    4.969002] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.

@Eric
this is from “serial port monitor” for windows, tried all three EQMOD cables and all work on three different COM ports, COM 4,5 and 6, all worked perfectly with N.I.N.A  and ASCOM EQMOD driver, connected fine and unmarked, then slewed the mount around, parked and switched off….with all three cables….
This is just a snippet of the test, it’s a few pages long, hope it helps

  

Since the cable and mount work fine on Windows, and you've tried older StellarMate images that used to work, and you've tried Astroberry, and none of them work on the Pi, I'm thinking the problem is the Pi (or its power supply).

Just curious, have you tried to verify that USB in general is working properly on the Pi? Try plugging in a USB flash drive, and copy files to/from the USB drive.

@Kevin
yes other items plugged into the PI work fine, also when the cable is plugged into the Pegasus UPB which is powered, it still does not work, but obviously the Pegasus UPB is connected to the PI….so would this rule out a power issue with the PI….as the power is coming from the hub when plugged into that, and just signal from the PI…?
And this was how it used to run fine, connected to the hub….