Hello everyone! I have an INDI server running on a RasPi 4 that I built up myself (ie, not an astroberry image). It's been working well with the following devices:
Nikon D5600
ASI120MM Mini
EQMod mount
GPSD (UBlox 7 dongle)

I just received a new ASI533MC Pro, so I changed the CCD config in Ekos to the new camera, fired everything up, and the camera is working great. Unfortunately, the GPS no longer works. The device is shown in lsusb, I see it connect in dmesg with no errors, but I get no real messages in gpsmon. If I unplug the camera, the GPS gets a fix in less than 30 seconds, as before. If I have a GPS fix with the camera unplugged, and then plug the camera in, I lose the GPS fix.

Things I have tried:
Updated all drivers
Verified no virtualgps service running
Extension cable for the gps dongle in case noise was preventing reception
GPS dongle on USB2 port with ASI533 on USB3 port
GPS dongle and ASI533 on USB3 ports
GPS dongle on USB2 port with ASI533 on powered USB3 hub
GPS dongle and ASI533 on powered USB3 hub
Burned a fresh astroberry sd card, configured, and recreated the problem exactly as above.

So...I'm a bit stumped. It's almost like an old IRQ error but that shouldn't happen with USB. Any ideas?

GPS attached, with fix, no cam

pi@astropi:~ $ lsusb
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1546:01a7 U-Blox AG [u-blox 7]
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 003: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

After cams attached:

pi@astropi:~ $ lsusb
Bus 002 Device 003: ID 03c3:533f
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1546:01a7 U-Blox AG [u-blox 7]
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 007: ID 03c3:120c
Bus 001 Device 006: ID 04b4:6572 Cypress Semiconductor Corp.
Bus 001 Device 003: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg section when cams are plugged in and GPS is working:
[ 170.159501] usb 1-1.2: new high-speed USB device number 5 using xhci_hcd
[ 170.291063] usb 1-1.2: New USB device found, idVendor=04b4, idProduct=6572, bcdDevice=32.99
[ 170.291083] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 170.291099] usb 1-1.2: Product: USB2.0 Hub
[ 170.293107] hub 1-1.2:1.0: USB hub found
[ 170.293481] hub 1-1.2:1.0: 4 ports detected
[ 170.629455] usb 1-1.2.3: new high-speed USB device number 6 using xhci_hcd
[ 170.760413] usb 1-1.2.3: New USB device found, idVendor=03c3, idProduct=120c, bcdDevice= 0.00
[ 170.760432] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 170.760448] usb 1-1.2.3: Product: ASI120MM Mini
[ 170.760464] usb 1-1.2.3: Manufacturer: ZWO
[ 170.969618] usb 2-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 171.000764] usb 2-2: New USB device found, idVendor=03c3, idProduct=533f, bcdDevice= 0.00
[ 171.000779] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 171.000791] usb 2-2: Product: ASI533MC Pro
[ 171.000803] usb 2-2: Manufacturer: ZWO


Thanks,
Casey

Can’t you uses the serial port mapper in INdI webmanager to assign permanent ports to the devices, this will solve the issue, or maybe this tool is only available to Paid up Stellarmate users, I am not sure now....Hmmmmm

Hi cofford,

I am 99% certain it is an issue with USB3.0 connections causing em interference with the GPS Signal.
you can test this by operating the UBlox 7 Module on a completely seperate device (for example a windows laptop), but in very close proximity to the rest of the setup.
As soon as you turn your setup on (including the USB3 connection to the astrocamera), you will lose GPS Signal. It has nothing to do with drivers or software problems. It is sadly just electromagnetic interference.

I ended up ditching the Ublox 7 gps dongle, and streaming the GPS Data from my phones GPS instead

It’s not that, I use the same GPS in my rpi, and have no issues....

If you are using a dongle with no attached GPS antenna, then you are relying on the signal received by an teensy tiny little patch antenna built onto the chip inside the Ublox. These patch antennas are marginal under all circumstances, but when other devices start adding to the local noise, the snr can get so low that a lock isn't possible, and it sounds like that's you. If the Ublox has a connector for one, try a GPS antenna. Or separate the Ublox from the rest of the gear with an appropriate usb cable.

I experienced similar issues between a Ublox 7 GPS and the electronics of my installation (ODroid computer, Pegasus Astro PPBA...) lately as I had cut the GPS cable short, not to have a long cable dangling. The GPS would not get a signal, likely because of nearby interferences from the electronics. Putting the GPS at the end of a USB extension and away from the electronics made the GPS work correctly again. Lesson learned, do not cut your GPS cable short!

Cool - how do you do that?

Hi AirBourn,

In short: with the android app "Share GPS" and the INDI GPS NEMA driver.

With the app, you can share a NEMA stream via Network.

The INDI NEMA driver needs to know the IP address of the phone. I use the small TP-Link travel router (30€) on the telescope to manage the network and give fixed IPs to all devices.

In the app, I set up a connection with the following settings:
Data Type: NEMA
Connection Method: TCP/IP
Port: 50000
TCP/IP Server: act as server and listen for incoming connections

I first connect my phone to the network and start the app. I then start a gps application on the phone and make sure I have a position fix. Then I connect the indi driver. It usually gets the position immediately and also syncs the exact time for KSTARS.

For some reason, this method stops working after the intitial connection. The indi driver can't get a connection to update the position or time again without restarting everything. I don't know if this is a problem with the driver or the app. But I only need the position and time sync once at the beginning of a session anyway.

The NMEA output stream does not provide accurate time. It provides only "current second" which is usually off at least half a second, and sometimes more with Cell system delays etc. Repeatedly looking at the stream and resetting time to it will introduce a lot of erratic error into the timebase of your rig. In order to get accurate time from a GPS, you must use the PPS signal coming from the GPS sats. This requires significant effort on a Linux box, and a compatible GPS (Most U-Blox based dongles do not provide PPS.)

Given that a GEM mount is just a big clock, time matters.

Every device on your rig should be set to the exact same time. If that time is wrong, it creates an offset that your software can mostly deal with through alignment (which mainly corrects time error). But if the time changes more or less constantly, as it would using an NMEA source with continuous updating, your guiding will blow goats. If the GPSNMEA driver did update with every tz string from the GPS, it would be a constant large error source. So INDI using it once, is the correct method for NMEA-only sources.

I never could get the UBlox 7 dongle working, so I did the same thing and used the GPS in my iPhone with the GPS2IP app. Works great.

I have the DIYmalls VK-162 G-Mouse USB GPS Dongle and it works great by itself when the antenna is far away from the Stellarmate, but not at all when the puck is near the StellarMate. Anyone tried a shield or similar to help? I'm trying to avoid placing the antenna lower on the mount away from the kit to minimize any cabling hanging off the gear.

I haven't had much luck with the internal patch antennas on either dongles or hats. Pi's are noisy and unshielded, and hard to get a signal right next to them. They'll get a lock outdoors sometimes, but its erratic.