What is your motor micro-stepping set at? The plugin is hardcoded to 32 steps which is what the waveshare comes pre-configured with.
I would set your controller to a single step, and build the plugin again with the step size set to 1 as well, and try that.

Read More...

You should set "Delay per step" in a value between 50 and 200, or whatever works for you.

If you don't set this the motor will try and run as fast as physically possible, which results in it doing a whole lot of nothing because the torque is super low. I use around 150 or so, the docs say 200.

It might be good to default this value to 200 instead of 0 in the plugin.

Read More...

Thanks. I had the wrong PDF saved… I am running the latest firmware for both hand controller and mount, which is what it came with.

Read More...

I logged debug info for the iOptronV3 driver and this is the error. I am not sure how to debug multiple INDI drivers at the same time, as I am not sure what happens first, the ASI CCD failing to expose, or the CEM40 not returning to the command. I will debug the ASI driver next.

T22:02:59.795 PDT DEBG ][ org.kde.kstars.indi] - Image received. Mode: "Guide" Size: 1237440
[2022-09-07T22:03:01.151 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[SCOPE] RES <+2073037511691336011> "
[2022-09-07T22:03:01.181 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:GLS#> "
[2022-09-07T22:03:01.182 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] RES <-4432800050135700210931> "
[2022-09-07T22:03:01.182 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[SCOPE] CMD <:GEP#> "
[2022-09-07T22:03:01.182 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[SCOPE] RES <+2073037511691342011> "
[2022-09-07T22:03:01.182 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:ZE00080#> "
[2022-09-07T22:03:01.852 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:GLS#> "
[2022-09-07T22:03:01.876 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] RES <-4432800050135700210931> "
[2022-09-07T22:03:01.877 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[SCOPE] CMD <:GEP#> "
[2022-09-07T22:03:04.831 PDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI120MM Mini : "[ERROR] Exposure failed after 3 attempts. "
[2022-09-07T22:03:04.831 PDT INFO ][ org.kde.kstars.ekos.guide] - "Exposure failed. Restarting exposure..."
[2022-09-07T22:03:06.879 PDT INFO ][ org.kde.kstars.indi] - iOptronV3 : "[ERROR] Read Command Error: Timeout error "
[2022-09-07T22:03:07.479 PDT DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Error"
[2022-09-07T22:03:07.882 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:GLS#> "
[2022-09-07T22:03:08.446 PDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI120MM Mini : "[ERROR] Exposure failed after 3 attempts. "
[2022-09-07T22:03:08.446 PDT INFO ][ org.kde.kstars.ekos.guide] - "Exposure failed. Restarting exposure..."
[2022-09-07T22:03:11.459 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] RES <> "
[2022-09-07T22:03:11.466 PDT INFO ][ org.kde.kstars.indi] - iOptronV3 : "[ERROR] bool IOPv3::Driver::getStatus(IOPv3::IOPInfo*): Expected 23 bytes but received 0. "
[2022-09-07T22:03:11.467 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[SCOPE] CMD <:GEP#> "
[2022-09-07T22:03:11.482 PDT INFO ][ org.kde.kstars.indi] - iOptronV3 : "[ERROR] Write Command Error: Write Error: Input/output error "
[2022-09-07T22:03:12.067 PDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI120MM Mini : "[ERROR] Exposure failed after 3 attempts. "
[2022-09-07T22:03:12.067 PDT INFO ][ org.kde.kstars.ekos.guide] - "Exposure failed. Restarting exposure..."
[2022-09-07T22:03:12.457 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:GLS#> "
[2022-09-07T22:03:12.459 PDT INFO ][ org.kde.kstars.indi] - iOptronV3 : "[ERROR] Write Command Error: Write Error: Input/output error "
[2022-09-07T22:03:12.459 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[SCOPE] CMD <:GEP#> "
[2022-09-07T22:03:12.461 PDT INFO ][ org.kde.kstars.indi] - iOptronV3 : "[ERROR] Write Command Error: Write Error: Input/output error "
[2022-09-07T22:03:13.458 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:GLS#> "
[2022-09-07T22:03:13.460 PDT INFO ][ org.kde.kstars.indi] - iOptronV3 : "[ERROR] Write Command Error: Write Error: Input/output error "

The only part that is weird is this : [2022-09-07T22:03:01.182 PDT DEBG ][ org.kde.kstars.indi] - iOptronV3 : "[DEBUG] CMD <:ZE00080#> "

The driver has this as a guide command, but I can't find it in the RS-232 command set, that instead appears to be expecting motion commands to be prefixed with :M

Read More...

Simply sending a disconnect and then reconnect didn't work, even after resetting the USB subsystem and being able to see all the USB devices with lsusb.

Unfortunately I was debugging INDI and when I attempted to restart the server Kstars crashed, so I wasn't able to see if restarting the indi server while Ekos is active is a valid workflow.

I will try again when not debugging.

Read More...

I disconnected the iPolar and still had issues.

Has anyone else had issues with random dissconnects? A disconnect would be fine but this not only takes out the CEM40 but the entire USB subsystem. I have a script which allows me to reset it without rebooting the Pi, but it does require me to restart my EKOS session, which means I lose my guide calibration and previous focus FWHM. I would like to find a way to reconnect without needed to shut down EKOS/INDI.

Read More...

This is working great for me, but I am wondering how everyone is evaluating your backlash? Is there some way to do it easily? My though was to take images and measure how many steps before the FWHM changes in the guide module, but I am not sure if there is a more reliable way.

Read More...

Someone else posted that the USB port on the CEM40 can be a bit loose, and this can manifest in a disconnect during the meridian flip.

I would suggest using tape or double sided hook and loop to pull the USB plug to one side to create sideways tension on the USB cable in the port, preventing it from slipping backwards. It doesn't need to fall out to not connect properly.

I am having a similar disconnect although mine doesn't happen with excessive mount movement, and it isn't a simple disconnect, it takes down the entire Pi USB subsystem. Still trying to figure that one out.

Read More...

For me I get an error that the CCD can't start a new capture because it is already capturing. I am using a ASI120mm mini to do the alignment, and so in most cases it captures in 1 second and solves in 1 or so seconds, meaning that a refresh rate of 8 seconds should be more than enough to capture and solve the images, but it simply errors completely.

I know the CCD and solve can happen properly because the 3 images needed to figure out the polar alignment error work just fine and solve quickly. Something in how this looping process is done is not working. I suspect it is timer based. Really, the time input should be the time between complete exposure + solves, and used just to prevent rapid updates or to let users time their adjustments.

Read More...

I think this a dead iPolar.

I plugged my mount into my Windows PC and while the PC can see iPolar the iPolar app just gets into a loop where it says it is connected and initializing, but then fails. I suspect the iPolar is defective, and the random failures I sometimes have are the result of the iPolar sending an unfriendly USB response that causes the subsystem to crash.

I am going to try and get the iPolar replaced.

Read More...

I have the same issue, where the plate solve takes longer then the refresh time and just fails.

Ideally refresh would just be a time interval between the plate solves. This way you can slow down the refresh to not be constantly plate solving and have time to make the adjustments, but also not cause any issues with plate solving if for some reason it does take longer than the refresh rate.

Read More...

radon199 replied to the topic 'Polar Assistant interface problem' in the forum. 3 weeks ago

Sometimes my polar misalignment is so far off I can do it in one session, so in addition to the above, being able to restart the polar alignment by having the mount slew back to the original source position would be great.

Right now if you hit the Start button it attempts to move another 30 degrees, which in most mounts would cause an impact with a tripod leg. Having it return to its start position would ensure that the mount can do a second alignment safely.

So, I would suggest that the start button once started is renamed to "Restart", and perform the above. I think that would help with readability, and also make it useful.

Read More...

Hey,

I got a CEM40 and overall the mount works fine on linux but there are some issues. While I am able to run a session, and I was even able to run a full night with limited issues, I have had the whole USB subsystem crash on my, and have found to be able to do is consistently.

I am using the 2021 version of the CEM40 with a single USB cable which connects to a USB2.0 HUB, the CEM40 itself, and the iPolar. It only works when connected to my powered USB hub, connecting to the USB3.0 or 2.0 ports directly does not work.
I am able to work for a while but then sometimes the USB subsystem will crash, and all USB devices disconnect. I have run it with just the HUB + the CEM40 and have it crash, and I ran the HUB for 6 months with zero issues before getting the CEM.

When the subsystem crashes all devices except the root hubs will no longer be visible with lsusb, and dmesg reports the following :

[ 6035.747938] usb 1-1.2: new high-speed USB device number 3 using xhci_hcd
[ 6035.882081] usb 1-1.2: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice=92.26
[ 6035.882098] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6035.882111] usb 1-1.2: Product: USB2.0 Hub
[ 6035.882125] usb 1-1.2: Manufacturer: GenesysLogic
[ 6035.988356] usb 2-2.1: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[ 6036.021349] usb 2-2.1: New USB device found, idVendor=05e3, idProduct=0616, bcdDevice=92.26
[ 6036.021364] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6036.021375] usb 2-2.1: Product: USB3.0 Hub
[ 6036.021386] usb 2-2.1: Manufacturer: GenesysLogic
[ 6036.207930] usb 1-1.2.1: new high-speed USB device number 4 using xhci_hcd
[ 6036.341031] usb 1-1.2.1: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice=92.26
[ 6036.341055] usb 1-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6036.341073] usb 1-1.2.1: Product: USB2.0 Hub
[ 6036.341090] usb 1-1.2.1: Manufacturer: GenesysLogic
[ 6036.677955] usb 1-1.2.1.1: new high-speed USB device number 5 using xhci_hcd
[ 6036.808640] usb 1-1.2.1.1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.00
[ 6036.808662] usb 1-1.2.1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 6036.808679] usb 1-1.2.1.1: Product: USB 2.0 Hub [MTT]
[ 6037.237932] usb 1-1.2.1.1.3: new high-speed USB device number 6 using xhci_hcd
[ 6037.506719] usb 1-1.2.1.1.3: New USB device found, idVendor=1233, idProduct=1455, bcdDevice= 1.00
[ 6037.506729] usb 1-1.2.1.1.3: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 6037.506736] usb 1-1.2.1.1.3: Product: iOptron iPolar
[ 6037.506743] usb 1-1.2.1.1.3: Manufacturer: iOptron iPolar
[ 6037.564768] input: iOptron iPolar: iOptron iPolar as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1.1/1-1.2.1.1.3/1-1.2.1.1.3:1.0/input/input3
[ 6037.767969] usb 1-1.2.1.1.4: new full-speed USB device number 7 using xhci_hcd
[ 6038.015998] usb 1-1.2.1.1.4: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[ 6038.016016] usb 1-1.2.1.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6038.016029] usb 1-1.2.1.1.4: Product: FT230X Basic UART
[ 6038.016043] usb 1-1.2.1.1.4: Manufacturer: FTDI
[ 6038.016055] usb 1-1.2.1.1.4: SerialNumber: D3091EXI
[ 6038.026066] usb 1-1.2.1.1.4: Detected FT-X
[ 6038.031436] usb 1-1.2.1.1.4: FTDI USB Serial Device converter now attached to ttyUSB0
[ 6201.049896] usb 1-1.2: USB disconnect, device number 3
[ 6201.049921] usb 1-1.2.1: USB disconnect, device number 4
[ 6201.049942] usb 1-1.2.1.1: USB disconnect, device number 5
[ 6201.049962] usb 1-1.2.1.1.3: USB disconnect, device number 6
[ 6201.157294] usb 1-1.2.1.1.4: USB disconnect, device number 7
[ 6201.460561] usb 1-1.2: new high-speed USB device number 8 using xhci_hcd
[ 6201.560765] usb 1-1.2: device descriptor read/64, error -71
[ 6201.780821] usb 1-1.2: device descriptor read/64, error -71
[ 6202.000620] usb 1-1.2: new high-speed USB device number 9 using xhci_hcd
[ 6202.100845] usb 1-1.2: device descriptor read/64, error -71
[ 6202.320842] usb 1-1.2: device descriptor read/64, error -71
[ 6202.441260] usb 1-1-port2: attempt power cycle

USB disconnect, device number 3 is the start of the error.

I can run the following commands twice to get the devices to re-connect :
sudo sh -c "echo 1 > /sys/bus/pci/devices/0000:00:00.0/remove"
sudo sh -c "echo 1 > /sys/bus/pci/rescan"

I can also get it to crash 100% of the time when trying to use the iPolar driver, or even when trying to stream from the iPolar in vlc using the video4linux drivers, so I wonder if it is a compatibility issue.

I have ordered a usb multimeter to test if this is an issue with the HUB shutting the iPolar down for drawing too much power, but wanted to ask if anyone else has had this issue?

Read More...