BT NMEA, why is GGA and RMC needed?
I try to reduce amount of tranfered BT data because even BT does consume 30% of my battery runtime which is way less then internal GPS, but still alot.
I did try to enable RMC only and then I did try GGA only. But I don't get coordinates. I did need to setup GGA and RMC together to get locus to work with my BT device.
Why do we need GGA and RMC for BT GPS?
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47 $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6ARMC
- Track Angle
- Speed
- Date
GGA
- altitude
- quality
- sat count
I guess we can't disable GGA because there are to many locus features relying on the availability of fix quality values.
But I guess we can make RMC optional because speed and angle could be calculated and date could be used from android.
I did already change the NMEA BT sentence speed to 5 times refreshrate (5000ms) to check how much power is consumed by active BT data streams without loosing more frequent 1000ms fix values in my 4mb GPS logger flash.
I will tell you the result tomorrow to give you an idea how much power saving could be expected by an lightweight NMEA sequence.
The same question
Good day Falco,
currently, both GGA and RMC sentences are necessary to make BT GPS connection work in Locus.
As you wrote, RMC parameters may be partially computed from the received location in GGA sentence. I just think that speed, bearing values are partially preprocessed directly in BT device. At least, internal GPS works this way and angle & speed values change faster than when computed from an incoming location (where is always one second delay without any Kalman filter).
When you will have some real values about battery consumption & number of send messages, let me know. Most crucial is to remove GSV messages which contain quite useless satellite stats and are send usually 3 or more times per second (depends on connected satellites). GSA & RMC, once per second, will have most probably really small effect (at least I hope).
Jiří M. aka Menion
Good day Falco,
currently, both GGA and RMC sentences are necessary to make BT GPS connection work in Locus.
As you wrote, RMC parameters may be partially computed from the received location in GGA sentence. I just think that speed, bearing values are partially preprocessed directly in BT device. At least, internal GPS works this way and angle & speed values change faster than when computed from an incoming location (where is always one second delay without any Kalman filter).
When you will have some real values about battery consumption & number of send messages, let me know. Most crucial is to remove GSV messages which contain quite useless satellite stats and are send usually 3 or more times per second (depends on connected satellites). GSA & RMC, once per second, will have most probably really small effect (at least I hope).
Jiří M. aka Menion
I did just thought about my test setup.
Old Setup: 4 sequences each 1hz = 4 lines/s
Test setup: 2 sequences each 1/5hz = 0.4 lines/s
I guess in real world I would need at least 1 position every 3 seconds which translate into
2 sequences each 1/3hz = 0.67 lines/s and could maybe be improved to 0.33 lines/s
If the test result of 0.4 doesn't blow us away, it would make sense to add more complextiy to reduce Bluetooth data amount from 0.67 lines/s to 0.33 lines/s
Do we acutally use RMC track angle and speed? Or does it got calculated anyway?
I did just thought about my test setup.
Old Setup: 4 sequences each 1hz = 4 lines/s
Test setup: 2 sequences each 1/5hz = 0.4 lines/s
I guess in real world I would need at least 1 position every 3 seconds which translate into
2 sequences each 1/3hz = 0.67 lines/s and could maybe be improved to 0.33 lines/s
If the test result of 0.4 doesn't blow us away, it would make sense to add more complextiy to reduce Bluetooth data amount from 0.67 lines/s to 0.33 lines/s
Do we acutally use RMC track angle and speed? Or does it got calculated anyway?
Good day Falco,
currently, both GGA and RMC sentences are necessary to make BT GPS connection work in Locus.
As you wrote, RMC parameters may be partially computed from the received location in GGA sentence. I just think that speed, bearing values are partially preprocessed directly in BT device. At least, internal GPS works this way and angle & speed values change faster than when computed from an incoming location (where is always one second delay without any Kalman filter).
When you will have some real values about battery consumption & number of send messages, let me know. Most crucial is to remove GSV messages which contain quite useless satellite stats and are send usually 3 or more times per second (depends on connected satellites). GSA & RMC, once per second, will have most probably really small effect (at least I hope).
Jiří M. aka Menion
Good day Falco,
currently, both GGA and RMC sentences are necessary to make BT GPS connection work in Locus.
As you wrote, RMC parameters may be partially computed from the received location in GGA sentence. I just think that speed, bearing values are partially preprocessed directly in BT device. At least, internal GPS works this way and angle & speed values change faster than when computed from an incoming location (where is always one second delay without any Kalman filter).
When you will have some real values about battery consumption & number of send messages, let me know. Most crucial is to remove GSV messages which contain quite useless satellite stats and are send usually 3 or more times per second (depends on connected satellites). GSA & RMC, once per second, will have most probably really small effect (at least I hope).
Jiří M. aka Menion
No, doesn't make sense to reduce amount of sequenzes even more. I got something between 5 and 10% improvement which it does still consume 2/3 to 5/6 of the much more frequent BT sentences (GPS BT off will improve runtime by 30%). Power saving is not even close to 10 times less sentences.
Ok, this result does match to tests like this: https://www.semanticscholar.org/paper/The-power-consumption-of-Bluetooth-scatternets-Negri-Beutel/439c2ebfc86517198850439319f29a8bd0dda1c0
the baseline of the connection does already use 600 of my 2500mAh in 10 hours.
No, doesn't make sense to reduce amount of sequenzes even more. I got something between 5 and 10% improvement which it does still consume 2/3 to 5/6 of the much more frequent BT sentences (GPS BT off will improve runtime by 30%). Power saving is not even close to 10 times less sentences.
Ok, this result does match to tests like this: https://www.semanticscholar.org/paper/The-power-consumption-of-Bluetooth-scatternets-Negri-Beutel/439c2ebfc86517198850439319f29a8bd0dda1c0
the baseline of the connection does already use 600 of my 2500mAh in 10 hours.
Good day Falco,
is there any result from these tests? From your latest post, it seems that reducing a single NMEA message (send once per second), does not bring useful benefit, is it correct? Thanks
Good day Falco,
is there any result from these tests? From your latest post, it seems that reducing a single NMEA message (send once per second), does not bring useful benefit, is it correct? Thanks
Yes, no benefit. I guess the data amount is already to low to get any messureable power consumtion changes compared to baseline BT consumtion.
I did repeat the test and messured with my 560mA GPS logger, runtime didn't change more then 10% messurement error, which means it's anything below 4mA/h which is basically nothing.
Yes, no benefit. I guess the data amount is already to low to get any messureable power consumtion changes compared to baseline BT consumtion.
I did repeat the test and messured with my 560mA GPS logger, runtime didn't change more then 10% messurement error, which means it's anything below 4mA/h which is basically nothing.
Oki, understand, thanks.
Oki, understand, thanks.
Replies have been locked on this page!