GPS2 on Cube Orange+ Mini Mapping Possibly Incorrect

PX4 Autopilot Flight Controllers 💻
1

G’day,
I am using Cube Orange+ with mini carrier board. I have 2xMatek M10p GPS units connected to GPS port 1 and 2, a RFD900x on Telem1 and a Raspberry Pi 0W-2 connected via Telem 2, running Mavlink-Router and raspiap. All the hardware are alive and connected correctly, and can be configured to function depending on the SW configs. In particular, I feel the GPS2 mapping may have a bug. With one config, I can get GPS 1 and GPS 2 and the RFD900 working, or I can get GPS 1, RFD900 and raspi working, but I cannot seem to achieve all 4 devices functioning simultaneously.

The GPS #2 is only functional when I have it set against Telem2 in QGroundControl (GPS_2_CONFIG=Telem2/102), and it will not function if set to GPS2/202 in QGC. GPS #2 is clearly plugged into the GPS2 port of the mini carrier board, and the raspi is connected to Telem2 port. All devices are powered successfully.

I have tried all permutations of setting serial settings, telem on/off, as well as 1.14 and 1.15 beta (current main). MAV_1_CONFIG set to Telem 2/102 works just fine for my raspi, but that means the GPS 2 is not being listened to. Neither GPS2 nor raspi works if I try to overload the Telem 2 port by assigning both the GPS and Raspi to it. I suspect there is a bug in the board mapping.

I had a look in the board/cubepilot/cubeorangeplus and did not see anything awry.

Cheers,
Joni

1 Like
2

Hi, thanks for the report! I will look into this today.

So, a second GPS connected in the GPS port does not work, right? How are you testing/checking this?

3

Oh, I missed one detail: mini carrier board. I don’t have that one but I would assume it doesn’t matter, and I should see the same on the normal carrier board.

4

This works for me with these params:

  • GPS_1_CONFIG: 201
  • GPS_1_GNSS: 0
  • GPS_1_PROTOCOL: 1
  • SER_GPS1_BAUD: 0
  • GPS_2_CONFIG: 202
  • GPS_2_GNSS: 0
  • GPS_2_PROTOCOL: 1
  • SER_GPS2_BAUD: 0

Could it be that you had the baudrate params wrong?

gps status
INFO  [gps] Main GPS
INFO  [gps] protocol: UBX
INFO  [gps] status: OK, port: /dev/ttyS2, baudrate: 115200
INFO  [gps] sat info: disabled
INFO  [gps] rate reading:                  823 B/s
INFO  [gps] rate position:                5.00 Hz
INFO  [gps] rate velocity:                5.00 Hz
INFO  [gps] rate publication:             5.00 Hz
INFO  [gps] rate RTCM injection:          0.00 Hz
 sensor_gps
    timestamp: 88332897 (0.092653 seconds ago)
    ...

INFO  [gps]
INFO  [gps] Secondary GPS
INFO  [gps] protocol: UBX
INFO  [gps] status: OK, port: /dev/ttyS5, baudrate: 115200
INFO  [gps] sat info: disabled
INFO  [gps] rate reading:                  634 B/s
INFO  [gps] rate position:               14.85 Hz
INFO  [gps] rate velocity:               14.85 Hz
INFO  [gps] rate publication:             0.01 Hz
INFO  [gps] rate RTCM injection:          0.00 Hz
 sensor_gps
    timestamp: 88353673 (0.102408 seconds ago)
    ...
1 Like
5

G’day Julian,
Thank you for the reply! ‘gps status’ was giving me very intermittent results on GPS 2, whereas 1 was solid. Most of my testing prior to today was done outdoors with a battery, but today I was troubleshooting differently.

Testing today was with the drone plugged into a solid 13.5 VDC power supply. The GPS2 section of ‘gps status’ seemed to hang a lot of the time, and the PPS was blinking intermittently. It achieved lock sporadically but just as often the console hung and did not go back to ‘nsh>’ without an enter keystroke.

Plugging USB directly into the cube cleaned up the intermittent GPS2 behaviour. I believe I fooled myself into thinking the ports were mapped wrong by inconsistent testing largely done in the hot sun in a field.

I determined the intermittent fault was due to insufficient power getting to the second GPS causing intermittent functionality. During testing I managed to push it over its limit, and the RFD900 and raspi are no longer consistently powered. Going down to just RFD did not help. I think I smoked or damaged a vreg.

Thanks again,
Joni

6

That’s currently a bug, see: [Bug] Recent DMA change ed4814f6239097dde5eecf2b4fbd58661db84dda stm32h7/serial: Do not wait on TXDMA semaphore breaks a lot of things. · Issue #22399 · PX4/PX4-Autopilot · GitHub

Hm, tricky. I wonder if you can see that mesasuring v5 on the connectors to check when and where it’s dropping. Or is it completely broken at this point?