We are using the Tiny RTK system with a PixHawk autopilot. Basestation is ublox C94-M8P. On one of our drones, when connecting the battery, the Tiny RTK blue light would go on, but yellow light does not flash (even after waiting +5 minutes with clear skies). Power cycle does not help. However, when using the USB cable, Tiny RTK works. What is even stranger, is that the following sequence of events seem to work:
Connect USB to Tiny RTK (drone powered off)
Wait a couple of seconds, green light on Tiny RTK flashes
Disconnect USB
Power-up drone
Tiny RTK works
This happens only on one of our drones with Tiny RTK, Tiny RTK powers up fine on the other drone.
Another issue we’ve been seeing, is that the rover status changes / toggles between DGPS and RTK float, it does not seem to acquire and hold RTK float status. QGC also reports “GPS signal noisy”. This is also with the Tiny RTK system giving us the strange start-up behavior.
We are running version 3.01 HPG 1.2. Will try the newer one as well. From tests we’ve done today, communication between pixhawk and Tiny RTK is fine on the UART side. The system reported again GPS fix lost, will look at the logs to see if space vehicles were lost or not.
Just checked the logged data. When QGC reports GPS Fixed Loss, the Fix reported by the M8P dropped down for 2 seconds. Our GPS antenna is installed outside of the vehicle. Any ideas? Are you aware of potential noise that can interfere with the GPS reception?
Transition from DGNSS/FLOAT to Nothing. Remained NO FIX for 2 seconds, then came back up again i.e. transition from NO FIX to DGNSS/FLOAT. Thinking of getting a spectrum analyzer to see if I can find potential interference antenna side.
Could you connect your Tiny RTK to U-Center by USB and have a look at the SNR of all satellites and post it here? You can see it on main screen.
You can also have a look at View -> Messages View -> UBX -> MON -> HW -> Noise level and jamming.
On what frequencies are you transmitting on your drone? Also, are you using a ground plane under the antenna? It can potentially help against interference
We logged it during the flight. Noise level was around 106 the entire time, even when losing GPS fix. Will still look into the jamming part, I think it’s also logged by default.
A ground plane is a good practice, if you can make some measurements with one and see if you can spot any differences. I don’t know exactly the noise/jamming magnitude orders so I’ll also make some measurements.
Not yet. We first want to investigate the strange power-up behavior. We want to power the TinyRTK directly from the 5V BEC (and not the PixHawk) to see if that fixes the strange power-up behavior. It could be that the strange power-up behavior is somehow causing the strange signal behavior i.e. when not powering up correctly, the ublox is in a strange state which makes it lose RTK. It’s a long shot, but we do have this weird power-up problem, so we might as well focus on that first (just easier because it happens in the lab).
We are using this: http://www.holybro.com/product/15 . Output power is set to 10mW. We are using PixHawk 1, HW rev 2.4.5 (latest I think). The strange thing we want to focus on first is:
Power up drone from battery, receiving communication from ublox but no satellites visible (even after waiting 20 minutes outside with clear skies)
Power down drone i.e. disconnect battery
Connect USB to Tiny RTK (drone powered off)
Wait a couple of seconds, green light on Tiny RTK flashes
Satellite reception is also verified on U-Center
Disconnect USB
Power-up drone using battery
Tiny RTK works, green light is flashing, satellite information is received (fix, number of SVs etc)
The above-mentioned behavior occurs after having the drone powered off for a couple of hours.
Update: We found the apparent “power up problem”. Turns out it was not power related at all, but EMI. The telemetry radio was not shielded, when placing the telemetry radio close to the TinyRTK PCB (about 5cm or less), the ublox simply does not get lock. However, when using a shielded radio, the ublox acquires lock in the normal expected time. I’m hoping that this is related to our GPS fix loss issue as well.