For GPS with compass I had to add support for a newer M100 module.
I also switched to Automotive since I am above 500m.
It is crazy how good AI supportes/generates code, see:
Nice updates!
But I feel like I need to point out to all modifying or generating code please keep something in mind:
The maximum TOA (time on air) for the frequency we are using is 10% both in EU law as well as US law
That means at 10Hz update rate, you may only send for 10ms every 100ms
I see parts in the code with for example implicitHeader(14) which will definitely be over the 10ms TOA. However they seem to be spread to 500ms intervals so it should be fine.
Please keep within legal limits, both for yourself as well as the community!
1 Like
The tx blocks at pairing on the first startup.
Is it possible to change the tx config (e.g. radio EU, etc.) in this state ?
I could not manage it…
In my original version, when the Tx is booting, before anything it checks if it is charging
In that state, so with charging animation, config can be changed always
1 Like
Maybe a Pocket in the housing for an Airtag or better a Pixel Tag.
… Asking for a friend 
1 Like
@monter_man I was not able to get M100 Pro to work (no NMEA, etc. ) but for the M100-5883 it was strait forward. See my pull request…
I think from the GPS/compass quality both are simular.
I am currently finishing my tests and will go in the water in the next days.
For the compass I was not sure about its orientation on the tow boogie.
I did not find an option where its orientation could be defined.
Is the compass orientation on the tow boogie not required to configured?
Thanks!
I do not think so, no orientation needed.
Just the ?compasscal and ?magtest check my guide.
I updated it yesterday.
P.S. Will check the pull request, and address there.
It’s done. New firmware .bin is out for RX.
BREmote V2.5-Evo — RX now auto-detects your compass
New RX build: BREmote-RX-SW34-dual-compass.bin
Until now the RX only drove the QMC5883L at 0x0D — the magnetometer in a BN-880.
Fit an HGLRC M100-5883 and the RX saw no compass at all, because that module
carries a QMC5883P at 0x2C.
It now detects which part is fitted at boot and drives it correctly:
0x0D QMC5883L — BN-880, HGLRC M100 Pro
0x2C QMC5883P — HGLRC M100-5883
0x1E HMC5883L — very old BN-880 stock, reported but not supported
?i2c names whichever it finds.
Not just a second address — the two chips put their data at different registers
(0x00 vs 0x01). Reading a P with the L’s driver shifts every axis one byte: no
error, just a smooth and completely wrong heading.
Your settings are safe. Still SW_VERSION 34, so moving between dual-compass and
gps-verified doesn’t touch your config — no re-pairing, no re-calibration.
If you CHANGE module, re-run ?compasscal. Stored offsets are raw counts and
don’t survive a part swap. The firmware reminds you at boot.
Honest status: I have not tested the QMC5883P on hardware — I don’t own that
module. Written from the QST datasheet, cross-checked against iNav and
Betaflight, compiles clean. The QMC5883L path is unchanged, so BN-880 builds are
unaffected either way. @heiguga will test and report.!
Grab it from the RX firmware folder. Click the .bin, then “Download raw file” —
not Save Page As, which gives you an HTML file with a .bin name. Flash at
0x10000.
1 Like
This can not be right.
You either need to define a clear orientation “offline” or (better) make it definable in software.
Otherwise the way the GPS module is mounted will define how the boogie reacts.
IMO the best way forward is to just get rid of the compass completely.
Its just unneeded complication and another failure point.
What actual real world problem does it solve in the system?
A)
tested BREmote-RX-SW34-dual-compass.bin , works fine:
...
QMC5883P compass detected at 0x2C. Init OK (8 G, 50 Hz, continuous).
If you have just changed GPS/compass module, run ?compasscal before trusting FM/RTM heading.
GPS [M10]: Connecting at 115200...
GPS [M10]: Config complete (115200, 10Hz, GPS+Galileo+BDS+GLONASS)
GPS: heard the module at 115200 baud
GPS config [legacy CFG (u-blox 6/7/8)]: dynModel=Sea OK | GSV OK | GLL OK | VTG OK
E (2209) task_wdt: esp_task_wdt_init(517): TWDT already initialized
WDT: initialized
...
B)
but it is dynModel=Sea, so not perfect for me living at 550m.
In the pull request I added sea model automotive. I think it should be the default to support all users in the first place…
I would love to live on the sea but just not realistic in the narrow future :-).
Maybe you check this too
C)
I bought a new HGLRC M100 Pro from HGLRC M100 PRO GPS – HGLRC Company
It was not able to get NMEA out of it even directly connected with my serial console…
Therefore I switched to the HGLRC M100-5883.
D)
I will go on the water in the next days but still not sure about physical orientation of the compass.
What is the default requirement?
Can I hardcode something for testing?
Thanks for getting me ready for testing! 