Today I got to the bottom of why my LC29HEA was recognized with normal 3D fix, but apparently no NTRP data reached the GPS. It had nothing to do with inside or outside, but simply with the slide switch at the top of the picture:
You can apparently switch the NTRIP data source (upper slider) and the GPS output (lower slider in the picture) separately between USB and serial interface at the PINs. I had the upper slider set to USB, the lower one to the serial interface. To prevent this from happening to anyone else, move both sliders down (or up if you want to connect to the GPS via USB).
It is good to know it may be possible to use a different UART for each of NTRIP ‘IN’ and GPS ‘OUT’. I wish they labeled the switches as you have figured out. I just ‘assumed’ what you have taken the time to confirm.
I have hesitated using the header pin uart since I wasn’t 100% sure if the Vin pin is 5v tolerant.
I could not find documentation about those 2 board buttons on the MOZIHAO EVB’s.
Their markings leave much to be desired. Rolfs interpretations seems most logical to me.
I use USB converters all the time. I am writing my own software to communicate with them so this potential to maybe send the Ntrip in on a 2nd serial port, using maybe STRSVR, would simplify my life when I get to writing my code.
In my tests, I connected the serial port of the Mateksys H743 slim directly to the PINs of the LC29H. The supply voltage is therefore 5 volts, TX of the H743 should be 3.3 volts.
(To change the settings with QGNSS.exe, I naturally connected the GPS to the laptop via USB and moved both sliders towards the “USB” label on the board).
Looks like a great story of hacking and collaboration to achieved something working !
Would somebody like to make a small blog post to share the story and current result ? I think that would be really interesting story and motivational for the rest of the community!
Sorry, but I don’t see hacking anywhere, but I do see collaboration in the sense of efficient communication.
Just my 2 cents: I think that’s a bit early, because as far as I’ve been following things here, this GPS has probably been tested on the workbench several times, but has only actually been flown briefly once so far ( by @Yuri_Rage , sorry if I’ve missed someone or something). I would wait and see what movingbaseline, for example, and other flights comes up with.
I made several flights with the Quectel GPS, both as a second GPS as well as the sole GPS onboard. All were promising.
But I agree with this assessment, particularly with respect to moving baseline performance as a key element to a good write up.
I would happily submit a second funding request for hardware to complete that testing, but I think @geofrancis may beat me to it, and I hope he does! I won’t have time to dive in again for at least 2 weeks.
I am instantly getting RTK Fixed but it is not as stable as ublox. Even with simple hover mission it is constantly moving around with 1m accuracy. GGA.Delta is also not steady around 200, not sure if that could be an issue.
Can you provide a log or screenshots of the inconsistencies?
I will say, expecting perfection is a bit of a pipe dream here. I’m surprised we can get it working at all. I do wonder if the instability noted by several so far will make this useless as a moving baseline module.
This looks like typical if not good performance from this module, and it looks pretty good to me. There are no big step changes in position, and EKF innovations are largely well within the 1m variance you claim to have observed. It’s hard to make a claim that this is a “bad” example. I do see the sawtoothing of GPA Delta that indicates a bit of variance in message timing, but I’m not certain this is actually problematic (I observe the same in my own logs). Message rate stability certainly satisfies the “GPS Health” logic within the AP drivers, though I’m aware that this is not a perfect indicator.
Might be nice to see a log from the same vehicle and flight mode using the GPS module you perceive to be better.
You should update to the latest 4.5 stable release, as well.
No, there’s not a compass onboard. Yes, a QMC5883L-based standalone will work fine. But you tend to get what you pay for, so, much like the GPS module in this topic, don’t expect perfection from that cheap board (I’ve used it - it works ok).
What would be more reliable or accurate compass modules than the QMC5883L? I have some of these in Matek or Foxeer M10 GPS modules and am actually quite happy with them. Apart from interference from battery cables, which could be eliminated by repositioning.
I received my LC29HEA module yesterday and wanted to start testing it. I therefore still need an external compass module. Moving baseline is out of the question for me, as my autonomous buoy for RC sailing only has a diameter of 350 mm.
I almost forgot. Many thanks to everyone in this thread who has dealt with the LC29HEA module and encouraged me to get into the RTK topic. You have done a great job.
