Hi, im currently trying to get datagnss gem 1305 module to NOT display unhealthy gps. I have a hdop value of around 0.6 16 satelites but the signal is still unhealthy. I tried various things like increasing/decreasing baud rate, different settings for the gps and so on but nothing works. I flashed the module with the rover configuration file (not really sure if it worked but the bar was green in sattrack…) and followed the instructions but to no avail. I tried disabling the pre arm so that I could atleast test but it wont let me arm even with all pre arm checks disabled. Thx for any help.
Unhealthy GPS is a sympthom of the GPS receiver providing position solutions slower than 5Hz.
Configure it for 5Hz or more.
Disabling arming checks is a really really bad idea.
I don’t really know how. In the wiki of the module they state the the default rate is 5hz and I have no clue how I could change the rate. Maybe they see this thread.
Hi @Max_Mustermann,
As @amilcarlucas says, it’s likely that the GPS is not updating at 5hz.
BTW, the screen shot from the mavlink inspector shows the rate that the GPS_RAW_INT messages (and others) are being sent to the ground station and it shows 2Hz but this doesn’t mean that the GPS is updating at 2hz. The messages from the GPS to the autopilot are most likely not using mavlink so they’re two separate things.
The DATAGNSS GEM1305 does not actually contain a u-blox module inside.
Instead, it is built on a TAU951M module featuring the Cynosure IV dual-core GNSS system-on-chip (SoC).
Why U-Center Works With It
The reason you can configure the GEM1305 using u-blox U-Center software is because its underlying chipset is specifically designed to be binary-compatible with u-blox protocols. It natively accepts standard UBX binary messages and outputs standard NMEA streams, allowing it to mimic a u-blox module seamlessly within software planners like U-Center, ArduPilot, and PX4.
So you need a usb-TTL cable and U-Center software to play with GPS settings.
DataGNSS sent me a couple of modules for testing, but they went radio silent and closed an incomplete PR for support of their promising dual antenna module. If I have a little time, I’ll dig up the GEM1305 and see what happens.
I’m skeptical about the claim of UBX compatibility to say the least, and the scant documentation on the subject suggests using only the NMEA protocol. I recall the need for support of proprietary NMEA sentences for the dual antenna module. I recall a bit less about the GEM1305 - it’s been a while.
I connected the GEM1305 to a Cube Orange+ running a recent flash of 4.7 firmware. It was recognized immediately and performed ok, even accepting RTCM3 injection and achieving an RTK fix.
Settings of note:
SERIAL4_PROTOCOL,5
GPS_AUTO_CONFIG,1
GPS1_TYPE,5
GPS1_RATE_MS,200
The message rate is a little unstable, showing a predictable jitter pattern at +/- 30ms but didn’t seem to trigger GPS health messages. For this reason, I would avoid the GEM1305 for high precision applications, but it should be ok for general use and basic RTK positioning.
Additionally, the above LLM puke regarding UBX support is a hallucination. The GEM1305 is an NMEA GNSS module.
Also, for anyone stumbling upon this topic in the future, use caution with the GEM1305’s DF13 connector. The pinout is backwards from the usual Pixhawk-type standard. Blindly plugging in a pre-pinned cable could result in hardware damage from the swapped 5V and GND pins.
Dont know where you got that info from but I dont think its true
I have exactly these settings. I think my problems started after I tried to configure the module as rover with satrack by flashing the command file. Im currently experimenting with different setting to maybe fix this.
Whatever you did there is certainly the issue, and I don’t know how to remedy it. Revert to default if there is an option to do so.
I just fixed the problem by using satrack over my raspberry pi (had to remove my module from the drone for that and rewire it) instead of using ardupilot passthrough and flashing the rover command file. Apparently ardupilot passthrough messed something up.
The default settings should have been fine. I don’t know where you’re downloading these configuration files, but I’d avoid doing that at all.
I guess you’re in good shape now, but I’d caution others against doing similar in the first place.
At the beginning I had some problems that were caused by me being to stupid to correctly change the settings and I assumed the problem was that the module was not in Rover mode. I proceded to follow the official guide and followed the datagnss tutorial for rover mode which included these files.
