Two uBlox GPS & Compass combo-modules for Pixhawk compared

Both of these are advertised as being "GPS combo-modules" with uBlox NEO-M8N GPS and a HMC5883L compass. They are both pinned with Molex PicoBlade for easy PixHawk use. The content of this post started as a rant/complaint, but I've decided to present it as a Comparison, so I can offer a suggested alternative. Ok, so first the bad ...

Beitian GPS & Compass combo-module (white):

Looks pretty on the outside right? Well, looks can be deceiving.

For starters, it only works intermittently. Initial testing revealed it gets more erratic as it warms-up. Inside, we first find a conventional uBlox chipset missing. However, if you look through the hole, you see a chip with uBlox printed on it ... so who knows if it's all real. Not sure if that is a battery or super-capacitor, but it's spot-welded in. Also interesting that the magnetometer is apparently under the metal shield ? (the other side is just the ceramic GPS antenna).

Then I noticed that instead of using the available (dependable and industry-standard) Molex PicoBlade connector, they have instead decided to hard-wire solder the tiny cable wires directly to the module's PCB. Seems this miss-step allowed the real problem (below) to even manifest itself in the first place. It might not have been so bad if the assembly technician knew how to solder.

Yes, the real surprise inside is the soldering (zoom in or "open in new tab/window"). The wires are frayed and barely attached. Not only that, but all the connections are poor, dull, and obvious "cold solder" connections that aren't always making good contact. Everyone knows what happens if your GPS or compass becomes disconnected or glitched in flight ... right, the aircraft flies-away or crashes. I think this poor soldering is why the module works intermittently, worse as it warms-up, clearly un-reliably, and completely unfit for its purpose.

Finally, there is no obvious indication or arrow pointing forward. Neither on the module's outer case or inner PCB. The compass chip is not visible either.

EDIT 11-2017
I needed a GPS (and external compass) for a new PixRacer quad I'm putting together. So, instead of wasting $20 on this, I decided to try to fix it (it's a challenge right ? :) and good micro-soldering practice). I think the main problem was the poor solder job.

The cable itself has a nice molded strain-relief.  I was temped to just splice-in a Pico-Blade 6-pinner, but that's more hacky-work and the designer went the other way for some reason. Instead, I removed the wires, cleaned the holes, and carefully re-stripped and tinned the thin wires. I think the wires should go through the holes, and then solder (like a normal hole-thru part).

Here is what it looks like now. It looks "rough" but it's functionally solid. Seems to work fine so far. Wow, GPS on uBlox 8-series is so much better than 6-series (even in poor conditions). And yes, the compass/magnetometer works fine (even under the metal shield). The "S" points to the front, and the "B" is to the back of quad.

GR-BD uBlox GPS & Compass combo-module (black):

 

I had this NEO-M8N unit, out on porch getting "warmed-up" for a recent test flight. I was getting SATS:15 & HDOP:0.8 . So, good performance and as expected ... much better than my uBlox 6-series units in same environment.

  

This GR-BD GPS module is much better built. Inside you find a more standard looking uBlox chipset. They also use a properly crimped cable connector to match the one provided on the PCB. This provides a much better connection to vital sensors like these (compared to the white Beitian unit) . In hours of testing, I have never seen this GR-BD module fail. While the proper direction is already clearly marked, the compass chip is also visible. I like the visible blue status led also. I'm in the USA, so not sure about performance when using alternate GLONASS (GNSS).

In summary, I guess the real advantage of this black GR-BD one, over the white Beitian one ... is that it actually worked without first being opened and repaired :)

Pixhawk v2.4.8 bench-testing & barometer accuracy with drift

I finally got around to firing-up the new PixHawk v2.4.8 on the workbench. It came with ArduCopter v3.2.1. I had to flash to v3.3.3 to cure some external Compass detection issues. I then had to flash to AC_v3.4rc2 to fix "compass variance" errors. It's now working except for this altitude drifting issue. 

So, it turns-out that ESCs and motors do not have to be installed for Pixhawk to Arm and run a simulated “test-flight”. I was able to now better compare the new Pixhawk-v248 altitude behavior against my other FCs.  

Test conditions:

- FC and sensors are powered-up and “warmed-up” for 5 minutes before Arming

- Only the FC is connected. No GPS for now.
- Using on-board compass only. Calibrated and not throwing “Compass Variance” errors
- FCs are completely calibrated (gyros, etc.)
- FCs are sitting on the actual flat level ground outside
- During mock “test flights”, FC were occasionally picked-up to 2 meters, held for Tower chic's announcement (about 30 secs), and then set back down.

Initial Observations (for all tested FCs unless noted):

- Daylight, temperature, and weather not large factors (example pic below from a night run)

- All FCs drift a bit after cold power-up. This appears to be normal. I allow 5 minutes to warm-up.
- On Arming, altitude is reset to 0.0 meters. After a cold-boot, works nice to reset barometer after power-up but before take-off.
- Neither the APM_252 nor PixRacer ever exhibited a deviation any different or worse than about 1.0 meters in any test.

The below chart shows results from actual sim-flights in my backyard. While it only shows a few, I would say I have run about 10 tests so far. Multiple tests of same FC showed similar results (so no big problem they aren't all logged).

 

Altitude of ground (as determined by FC)	APM_252	PixRacer	Pix248_F01	Pix248_F02
Power-up	0.0	0.0	0.0	0.0
After 5 minutes warm-up	0.3	0.1	-3.0	-3.0
After Arming (resets altitude once)	0.0	0.0	0.0	0.0
During simulated flight. 1 minute	0.1	0.0	-0.1	0.2
During simulated flight. 2 minutes	0.2	0.0	-3.0	-1.0
During simulated flight. 10 minutes	0.7	0.1	-7.0	1.0
During simulated flight. 30 minutes	1.0	0.8	-10.0	-2.0
After landing	1.0	0.8	-10.0	-2.0
Max in-flight barometer units deviation	1.0	0.8	10.0	2.0

Like the popular PixHawk 2.4.6 before it ... the PixHawk 2.4.8 and PixRacer all still use the same Measurement Specialties MS5611 barometer sensor. Even my old APM_252 FCs uses the same. When looking at Flight-Example-01, I don't see how the PixHawk_v248 can be determined good and trusted on a $1000 aircraft if it can't even determine it's own altitude closer than this. I had hoped to use this aircraft for precise auto-missions. From this example simulated-flight (F01), you can see it clearly performs worse than the others.

Sometimes this PixHawk_v248 drifts into positive altitudes instead of negative. Originally, I had thought that Arming (and it's reset) was required to net a good result. However, (at least in this case) I'm seeing that is not the case, and a drifting barometer will continue to drift, no matter how many times you reset or Arm-Reset it. I'm thinking it must be a bad barometer on the board. Hopefully just a rare random bad unit.

Update 08-29-2016
I have continued to run tests (up to about 15 iterations now) and example test-flight scenarios with similar results. They have been run on both 90f hot-days and cool 70f nights. Weather is active (like always) but is generally mild (no storms).

Most results are similar. However, it seems I ran enough tests (about 6 now) on PixHawk_248 to get a rare result. I have updated the above chart with that flight (in column PixHawk v248 - Example Flight #02). It shows that this exact PixHawk_v248 (that has been performing so poorly) finally showed a result more in-line with similarly equipped FCs (it finally performed properly once). It seems to say that this MS5611 barometer sensor can work under ideal conditions or maybe just randomly. However, since it's not reliably correct or dependable, I will likely never fly this particular FC on a nice aircraft as originally intended.

You can also start to see how some pilots might not notice a 1-2 meter barometer drift during a flight. Conceivably, you could take off at 0.0 meters. During the flight, the barometer might drift around 2.0 meters. But if it happens to drift back near true altitude (around the time you land), the pilot might not even notice.

I'm thinking the Measurement Specialties MS5611 barometer sensor is a fairly delicate and sensitive sensor. It might be that some work better than others. Maybe I just got a "boarder-line sensor" that tends to drift too much over a short period of time. Hard to say how many FCs that might end-up affecting over the years. I just visually confirmed that my PixHawk v2.4.8 from BG does have the proper sensor soldered onto the PCB.

MEAS - 561101BA03

Grey foam is there and lightly pressing against sensor. In my case, it appears to be a bad $3 barometer sensor .

Update 09-28-2016

I contacted vendor. They sent me a new one after seeing these test results. This new one works properly. I holds a 1-meter or better accuracy while on flight-line or during mock flights.