×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

GEM45 -> Ekos / Astroberry Fails Read/Write error

  • Posts: 18
  • Thank you received: 3
Hi there,

I'm at a loss and now wondering if this is a potential GEM45 issue... after trawling the net.

- Astroberry - Pi4
- GEM45 (latest v.) bought late 2021.

I have plugged in the GEM45 to a usb hub as advised, tried powered and not powered.  Either the device won't register immediately and I need to restart Pi or services or the mount. Finally after registering it will work for a random period of time and then issue a 'Write Command Error: Write Error: Input/Output Error' - see attached the screenshot.

I then restart and may work again. After awhile it will do it again. I'm losing my freaking mind. Now after digging into the Pi's logs I can see at the exact same time the following:
<strong>Ignore the times on this log but its the same at each time associated with the syslog. </strong><code>
[2022-01-04T20:05:53.804 GMT DEBG ][           org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:GLS#> "
[2022-01-04T20:05:53.805 GMT INFO ][           org.kde.kstars.indi] - iOptronV3 :  "[ERROR] Write Command Error: Write Error: Input/output error "
</code>
Syslog
<code>Jan  4 18:21:02 astroberry kernel: [  366.821341] usb 1-1.2.2.4: new full-speed USB device number 11 using xhci_hcd
Jan  4 18:21:03 astroberry kernel: [  367.241615] usb 1-1.2.2.4: device descriptor read/64, error -71
Jan  4 18:21:03 astroberry kernel: [  367.608969] usb 1-1.2.2.4: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
Jan  4 18:21:03 astroberry kernel: [  367.608989] usb 1-1.2.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan  4 18:21:03 astroberry kernel: [  367.609005] usb 1-1.2.2.4: Product: FT230X Basic UART
Jan  4 18:21:03 astroberry kernel: [  367.609020] usb 1-1.2.2.4: Manufacturer: FTDI
Jan  4 18:21:03 astroberry kernel: [  367.609034] usb 1-1.2.2.4: SerialNumber: D3091ILC
Jan  4 18:21:03 astroberry vhusbdarm[723]: Found Full speed device [0403:6015] "FTDI, FT230X Basic UART" at address 11224
Jan  4 18:21:03 astroberry mtp-probe: checking bus 1, device 11: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:0$
Jan  4 18:21:03 astroberry mtp-probe: bus: 1, device: 11 was not an MTP device
Jan  4 18:21:03 astroberry systemd-udevd[1688]: Process '/bin/sh -c 'test -f /sys/module/usbcore/parameters/usbfs_memory_mb && test $(ca$
Jan  4 18:21:05 astroberry kernel: [  369.811872] usb 1-1.2.3.2: reset high-speed USB device number 7 using xhci_hcd
Jan  4 18:21:06 astroberry vhusbdarm[723]: Unmanaging device 11224 [0403:6015]
Jan  4 18:21:06 astroberry kernel: [  370.264308] usb 1-1.2.2.4: USB disconnect, device number 11</code>
According to sites, it is meaning the device is faulty?  Does anyone have any thoughts on this?

Steve
The following user(s) said Thank You: MH
Last edit: 2 years 2 months ago by Steve. Reason: formatting
2 years 2 months ago #79069

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 3
Reading more on this, the MTP issue could be showing a few different things... either GEM45 faulty or my Pi rules are messed up?
2 years 2 months ago #79070

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 2
Not alone here - I think I'm running into the exact problem with my GEM45 and Astroberry on a Pi4.

Attempting an `apt update && apt upgrade` currently but then will delve deeper into the logs and see what the heck is going on.

There was this thread from a very long time ago that indicated maybe it was due to re-used drivers for the 40, but it seems like that PR would have been reviewed and merged ages ago.
2 years 2 months ago #79210

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 2
I haven't used a powered hub yet, but I had my old GEM28 mount lying around, so after many hours of smashing my head against the wall I figured I'd do some wacky stuff to see how it behaved between the two.

This is the `dmesg -Tw` output from the Pi, literally all I'm doing here is pulling the USB cable from the powered-on GEM45, plugging into the powered GEM28 hand controller (where it accepts USB in), then back:
[Sat Jan  8 18:27:48 2022] usb 1-1.4: new full-speed USB device number 7 using xhci_hcd
[Sat Jan  8 18:27:48 2022] usb 1-1.4: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[Sat Jan  8 18:27:48 2022] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat Jan  8 18:27:48 2022] usb 1-1.4: Product: FT230X Basic UART
[Sat Jan  8 18:27:48 2022] usb 1-1.4: Manufacturer: FTDI
[Sat Jan  8 18:27:48 2022] usb 1-1.4: SerialNumber: D30AC5U7
[Sat Jan  8 18:27:48 2022] usbcore: registered new interface driver usbserial_generic
[Sat Jan  8 18:27:48 2022] usbserial: USB Serial support registered for generic
[Sat Jan  8 18:27:49 2022] usbcore: registered new interface driver ftdi_sio
[Sat Jan  8 18:27:49 2022] usbserial: USB Serial support registered for FTDI USB Serial Device
[Sat Jan  8 18:27:49 2022] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
[Sat Jan  8 18:27:49 2022] usb 1-1.4: Detected FT-X
[Sat Jan  8 18:27:49 2022] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
[Sat Jan  8 18:34:53 2022] usb 1-1.4: USB disconnect, device number 7
[Sat Jan  8 18:34:53 2022] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[Sat Jan  8 18:34:53 2022] ftdi_sio 1-1.4:1.0: device disconnected
[Sat Jan  8 18:35:09 2022] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[Sat Jan  8 18:35:10 2022] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[Sat Jan  8 18:35:10 2022] usb 1-1-port4: attempt power cycle
[Sat Jan  8 18:35:11 2022] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[Sat Jan  8 18:35:12 2022] usb 1-1-port4: Cannot enable. Maybe the USB cable is bad?
[Sat Jan  8 18:35:12 2022] usb 1-1-port4: unable to enumerate USB device

Note that the Pi has a good ol' time picking up the GEM28 and detecting the serial converter, then assigning it to `/dev/ttyUSB0` which is where INDI looks, while the GEM45 just craps out - looking at output from `ls /dev/tty*` you can see that the `/dev/ttyUSB0` is created with the GEM28, and then gone as soon as it's disconnected, does not come back with the GEM45 (nothing new gets created in `/dev/`, in fact)

Whatever is causing it, it's beyond frustrating; I don't even think it's an INDI issue or even a USB issue; I suspect that the local drivers on the GEM28 are able to create that USB serial converter via FTDI, while the GEM45 is just being a hot pile of garbage and is unable to do so.

I'm giving up for now for my sanity, but this sucks.
Last edit: 1 year 11 months ago by MH. Reason: GEM45 had problems, not GEM28 =(
2 years 2 months ago #79221

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 2
I figured it out finally - I don't know *why* this is the case, but someone mentioned over here a very strange thing: "Failing that connect the mount to the USB2 on your camera and then connect the camera to the RPi4 (so use the hub in your camera). From what I have read there have been some issues with the mounts USB (as you said maybe not really Universal!)"

And I thought to myself "there is no way this would work, but why not" and lo and behold.... you can see below where my `dmesg -Tw` output was failing horribly trying to connect to the RPi directly, then suddenly when I changed to the ASI294MC hub.

Hopefully that helps you and others anyway - I spent way too many hours today on this and was about ready to pull my hair out.
The following user(s) said Thank You: Steve
Last edit: 2 years 2 months ago by MH. Reason: Quote formatting is terrible, just using quotation marks
2 years 2 months ago #79224
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 3
Hey, I wanted to provide an update as it looks like I've solved the issue (Thanks to Alex at FLO).

So it seems maybe the Astroberry and my Pi had some weird udev rules for MTP errors. The rules clashed or I believe it considered the mount as something else than the FTDI.

I was having errors randomly, if it was 5mins, 10mins or hour or two. I was LOSING my mind and thinking it was the mount... 

SO.. I followed these instructions:
Try creating a new udev rule to match the FTDI adaptor ID, these instructions could help here. Delete the rule if it does not help:
superuser.com/questions/1206664/disable-...t-as-a-usb-mass-stor

1. Identified the USB id
2. Created a defined MTP udev rule to skip and go to the end
3. Boom! Worked.

I have had two nights of no input/output errors at all.
The mount is connected through a non powered USB hub to the USB3 port By the way too.
The following user(s) said Thank You: MH
2 years 2 months ago #79288

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 3
Oh I also had to do the rules for the FTDI and the iPolar so remember to grab both IDs.
The following user(s) said Thank You: MH
2 years 2 months ago #79289

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 2
Awesome, thank you for the research and I'm glad it ended up working!

I will try to give this a go sometime soon; I'd still like to get this all working without a hub, but at least if it *has* to use the ZWO camera hub to function, cable management is just one power line up to the power distribution system mounted on the scope...

Will try to update regardless, in case by some magic or luck I'm able to get the GEM45 to behave without extra hardware intermediaries.
Last edit: 2 years 2 months ago by MH.
2 years 2 months ago #79310

Please Log in or Create an account to join the conversation.

  • Posts: 62
  • Thank you received: 1
Maybe this helps someone; I had the exact same issue with my CEM40 and spent many hours trying to figure out why the write error suddenly appeared.
It turned out it was the USB cable that came with the mount that was bad. Since I replaced the USB cable I've never had an I/O error.
I have seen posts in the FB iOptron group where people have had the same issue/solution.

Cheers, Åke
2 years 2 months ago #79366

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 2
Welp, I'm farther back than I was before, with no reason as to why.

All of a sudden tonight I'm getting a huge number of mount I/O errors and timeout errors, it won't slew correctly, can't even set initial calibration to guide now.

Nothing I've done differently, in fact I even shelled out for a powered hub which seemed to solve the problem, also got a fancy USB cable just for the absurdity of the GEM45 mount. Even had a few nights with superb guiding, images, etc.

Now it's every ~5s I get an I/O error and timeout errors; nothing has changed, I'm even using the same USB ports...

Honestly, I don't even have the heart to keep fooling with it at this point; I'm going to try to reach out to iOptron but they've not returned any emails, otherwise I may try to initiate a return and get a NUC or something. Not enough painkillers in the world to deal with this headache at this point, seemingly purely based on the whims of fate.
2 years 2 months ago #79964

Please Log in or Create an account to join the conversation.

  • Posts: 18
  • Thank you received: 2
Alright, I've returned after much frustration to at least provide a bit of an update for folks that may be having the same problem; things I tried and how they ended up (and current progress)
  • Different USB configurations (the cheapest option)
    • Still using various USB type A cables that I had laying around; had not bought any new ones yet
      • Used mount-included cable, as well as other cables I had (4 total)
    • Going USB from mount directly to the Pi4 did not work, no matter the USB port nor the udev rules
    • Using the hub on the camera worked okay, but ultimately I still had some errors and it was still inconsistent; not really acceptable from a trust perspective
    • Tried udev rules for all of the above attempts; didn't make any difference unfortunately
  • Bought a new, higher quality USB cable
    • This didn't work; still having connection issues directly to Pi4 on all ports as well, same with ZWO CCD camera USB hub
  • Bought a powered USB hub and even a fancy dovetail-compatible bracket for it
    • Figured this would solve my woes, but this ended up leading to my previous post and immense frustration
    • This was going from mount (with new USB cable) -> powered hub -> Pi4 USB3 port
    • Updated udev rules to account for the new hub; didn't matter and was wildly inconsistent; usually manifested in random "read/write" errors on the logs, which would sometimes manifest as full-on timeout errors which would completely ruin any guiding / tracking and happened randomly
  • What ended up getting it working? A stupid unpowered USB hub that is actually currently connected to a USB 2.0 port on the Pi
    • No udev rules for the hub, only udev rules for the mount still in place; not sure if this matters or not at this point and will test to see how it behaves with no udev rules
    • USB setup here is mount (new USB cable) -> unpowered hub -> Pi4 USB2 port
    • I suspect this would also work on a USB3 port on the Pi4 but haven't tested this yet
    • Absolutely zero problems with read/write errors or timeout errors last night
    • HOWEVER as full disclosure, I ran into a lot of guiding calibration issues last night as well halfway through the session
      • I'm not sure if this is related though, so I would caution anyone away from thinking that the hub solved one problem but introduced another (I don't have enough info yet to be sure)
  • Something I am going to try is getting a USB to RJ12 adapter to go directly from the Pi4 to the HBX input on the mount and see if that also has good stability
    • Not super confident about this, but might as well try different things at this point to save other folks with these problems a lot of time and $$$
Last edit: 2 years 1 month ago by MH. Reason: Yet more formatting, I give up on making the bullet spacing look nice
2 years 1 month ago #80135

Please Log in or Create an account to join the conversation.

Moderators: Radek Kaczorek
Time to create page: 0.725 seconds