GPS will not communicate CubeOrange

Hi all,

I’ve got a cube orange that I’ve setup and got communicating with QGroundControl.

I wired a MTK GPS to the proper serial RX and TX (verified with Oscope). The GPS unit has an Led on it that blinks when it gets lock, but despite this blinking I never get GPS lock in QGroundControl.

I’ve enable MTK in the parameters and recycled power, still not working. I enable GPS logging and recycles power, still no logs.

I connected the GPS directly to a serial terminal on the computer and I’ve verified it indeed is working.

I looked at the code in src/drivers/GPS/devices/scr/mtk.cpp and mtk.h and the code commands and parsing matches the GPS device data sheets…

I’m at a complete loss.

I’m using Visual Studio on a Linux Debian computer.

My GPS unit is a GlobalTop Titan X1 Chip.

Update: Using the console in QGroundControl to check on the GPS I get:

nsh> gps status
INFO  [gps] Main GPS
INFO  [gps] protocol: MTK
INFO  [gps] status: NOT OK, port: /dev/ttyS2, baudrate: 9600
INFO  [gps] sat info: disabled
INFO  [gps] rate reading:              0 B/s

Isn’t GPS1 supposed to be ttyS0???

1 Like

So I’m just going to post what I’m learning since no one seems to answer anyone’s questions on this forum…and PX4 people wonder why ArduPilot is more popular…

Answering my last question “Isn’t GPS1 supposed to be on ttyS0?” NO

The best way to figure out how Nuttx knows which port is which is to read the default.cmake file in the directory for you board in my case PX4-Autopilot/boards/cubepilot/cubeorange.

For the Orange Cube ttyS0 is TEL1. GPS1 is ttyS2 so from gps status in the console reporting back port ttyS2 is good.

Why I’m not getting any data is still an unknow. The GPS unit works, it’s at the correct baud and the protocol is MTK.

My next step is to drop PX4_INFO()s in the MTK and GPS files to track down where the data is being blocked…

Stay tuned for more…



I’ve dug into the code and even though I’m still not getting lock I am getting data. In order to tell that I’m getting data I had to do the following, in MAVLink Console:
gps stop
gps start -d /dev/ttyS2
gps status

If I didn’t specify ttyS2 then the instantiate function would default to ttyS3 which for an OrangeCube is PX4IO and would hang the system. I did go into that function and change the default to:
const char *device_name = “/dev/ttyS2”;
So now I can simply call gps start and then gps status to get the following:

nsh> gps status
INFO  [gps] Main GPS
INFO  [gps] protocol: ASHTECH
INFO  [gps] status: NOT OK, port: /dev/ttyS2, baudrate: 0
INFO  [gps] sat info: disabled
INFO  [gps] rate reading:              0 B/s
INFO  [gps] rate position:           0.00 Hz
INFO  [gps] rate velocity:           0.00 Hz
INFO  [gps] rate publication:          0.00 Hz
INFO  [gps] rate RTCM injection:      0.00 Hz
    timestamp: 254874983  (1.185214 seconds ago)
    time_utc_usec: 0
    lat: 415273036
    lon: -713763710
    alt: 15956
    alt_ellipsoid: 0
    s_variance_m_s: 0.0000
    c_variance_rad: 0.1000
    eph: 0.0000
    epv: 0.0000
    hdop: 0.0000
    vdop: 0.0000
    noise_per_ms: 0
    jamming_indicator: 0
    vel_m_s: 0.0000
    vel_n_m_s: 0.0000
    vel_e_m_s: 0.0000
    vel_d_m_s: 0.0000
    cog_rad: 0.0000
    timestamp_time_relative: -254874983
    heading: nan
    heading_offset: 0.0000
    fix_type: 3
    jamming_state: 0
    vel_ned_valid: True
    satellites_used: 0

What you’ll notice is that the status is still showing NOT OK, but I am getting the correct Lat/Lon.

Next step is to but some PX4_INFO into the MTK read functions to see why it’s showing rate read zero.

1 Like

So it seems that the PX4 code is NOT set up correctly based on brand.

The only brand that will actually parse NEMA messages is Ashtech. In the ashtech.cpp the code actually parses the GGA and GSV messages outputted by a GPS unit. NONE of the other gps files decode NEMA messages… Why? (Looking at you Thomas Gubler and Julian Oes)

So to actually get my GPS unit to be read you have have to tell it it’s a Ashtech gps…which it’s not. The problem with that is not you can’t update the GPS to output different messages or rates or baud because it doesn’t doesn’t use the MTK message structure…

How has this code stayed like this for this long? Does everyone just use the generic GPS units that PX4 recommends?

1 Like

You might have better luck on the PX4 Slack. I don’t think devs are on this forum as much as they are there.

1 Like

i just noticed that there is no 6th option ( NMEA generic) on the GPS2_PROTOCOL . When I enter 6th option —> GPS2_Protocol , the cmd GPS STATUS simply shows FEMTOMES protocol… Any ideas where is the generic NMEA is ?

Herelink Radio Telemtery ( Android version)
QGC platform
Px4 stack v1.12.3 with NuttX, v8.2.0 Os
Flight controller- CUBE Orange Pixhawk