New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we improve the GPS lock time? #61
Comments
Switching off BDS appears to give me a lock within a few seconds outdoors now. Doesn’t improve indoor sensitivity though! |
$PCAS04 can be easily patched in the current V1.10 FW's .cdd file at addr 0x000863dF, change it from 0x33 to 0x31 and flash FW to the target as usual. There is obviously no CRC or similar which could prevent us from flashing a patched image. :-) Right after the PCAS04 string there seem to be templates of each a GGA and a RMC string whose values point to the mentioned place in Shanghai, China. As far as I understand the CASIC protocol specification, the only cmd which could affect the GPS fix time is PCAS10 which specifies the reset method of the GPS module (hot, warm, cold factory reset). But a quick search through the .cdd file didn't show any string consisting of this cmd. |
Tkerby could you share the mod? |
There is no static CRC16 appended to the cfg strings, instead there is just a '*' 0x2A as a marker for the dynamically calculated checksum to follow after. |
D868UV fw 2.33 D868UV fw 2.34 D878UV fw 1.10 |
Hmmm, no changes for me. GPS lock in my flashed 878 is very bad. |
@tkerby Did you have any luck changing the default location (China) and did it help lock time any...? |
I'm looking at this too, and I see the coordinates, but there are more than one set. there seem to be a few sets. One is Shanghai, the other is just off the coast in the south china sea. These could be geo-located Satellites that it is set to look for. 3113.3166,N,12121.2682,E 2458.21111,N,11838.31444,E Perhaps, finding geolocated satellites in your area and using those coordinates is a better idea then setting your own location? Just an idea |
Thank you for your suggestions! I was wondering since I bought my 878 one month ago why there is no GPS lock at all! I have to admit, that's something not included in my skillset 😆 73 de |
Interesting. I purchased an 878 last week and it was having a hard time to get a GPS lock. It was taking about one hour, no less! After patching the command so that it will only use GPS satellites it does lock in about 1 minute at the same spot where I was checking. Who knows, maybe spotty BDS service depending on your area can be more or less detrimental? I am at IN83. |
tapped into the communication between the GPS module and the Main CPU to observe the messages exchanged between the main CPU and the GPS module. I came across something that I believe may be an error in the devices firmware. When the AnyTone does initialize the GPS module, it sends the following sequence (MCU -> GPS module):
The $PCAS04 command in this case should select "GPS only". However, this is an invalid NMEA sequence (the '*' character separating the checksum from the command is missing - the checksum value itself (0x18) seems to be correct). Switching the GPS mode from GPS to BDS or GPS+BDS via the Menu results in similarly invalid NMEA sequences:
Again, the '*' separating the command from the checksum is missing. Are there any official channels to report Firmware issues to AnyTone? PS: I'm also having issues with GPS lock. The GPS does not see any satellites and never had an initial lock. Note (2021-02-06): NMEA sequences were not properly shown ('*' was interpreted as formatting character) |
Given your communication trace is correct, as the Asterisk "*" is present in the firmware flash image for each cmd, the resulting sequence may be constructed in a wrong way by the FW: The asterisk is replaced by the CRC rather than the CRC append AFTER the asterisk. |
I've seen that the '' is present in the FW image. And I'm confident that my traces are correct, as other commands to and from the GPS module are properly formatted ('' as separator between command and checksum). E.g. the power on sequence (MCU -> GPS module) looks like:
It's really just the PCAS04 hat is broken... |
Yes, confirmed!
Checksum calculation of $PCAS4 is definitely broken, which may cause the GPS module to ignore all the $PCAS4 cmds. Means selection of GPS, Beidou or both doesn't have any effect. |
I am wondering if the latest 1.22 firmware fixes the checksum calculation. Changelog doesn't seem to mention it, but hope's still there... |
Nope, issue still persists in V1.22. :-(
GPS module instead expects |
For transmission of data over the air, these radios send an NMEA RMC sentence in UTF-16. Example from 878 below.
|
This FW hexeditor fix to remove the Chinese Satelites brought my gps fix time from 17m to 1.5m: http://members.optuszoo.com.au/jason.reilly1/868mods.htm?fbclid=IwAR3We8hIt20lFBOhBdOoGneDnTRfB2PTQAMff1Tsupw06QlFLPlOnOnBRLE#FasterGPS |
Background:
The GPS in the 868/878 is the ATGM331-5N-31 with datasheet here: http://www.icofchina.com/d/file/xiazai/2018-01-08/af977f1adb801ec170c0fe04c34fafab.pdf
Looking at decoding the GPS Startup test data on the 878, it seems that it might be the RMC minimum format shown here: https://www.gpsinformation.org/dale/nmea.htm#RMC However, most parsers seem to fail as I think some data is off the side of the screen
Taking a look at the firmware version 1.10 in a hex editor and searching for the $GP string that precedes GS sentences (as I was wondering about how they were parsed), I found the following block of data which appears to be in amongst other strings
$PMTK�PMTK�$GPTXT�$GNRMC�$GPRMC�$GPGGA�$GPGSV�,0�,1,25,180000,60000�,1,3000,12000,18000,72000�,0,1,0,1,0,5,0,0,0,0,0,0,0,0,0,0,0,0��$PCAS02,1000�$PCAS03,1,0,0,0,1,0,0,0�$PCAS03,0,0,0,1,0,0,0,0�$PCAS04,3�,091926.000,3113.3166,N,12121.2682,E,0.51,09,0.9,36.9,M,7.9,M,,000056�,961639.00,A,2458.21111,N,11838.31444,E,0.18,,091217,,,A,V*,,*
The locations seem to be in China - right here: https://www.google.com/maps/place/31%C2%B013'19.0%22N+121%C2%B021'16.1%22E/@31.2236261,121.35367,18z/data=!4m5!3m4!1s0x0:0x0!8m2!3d31.221943!4d121.35447
My first thought is whether the radio is providing a warm start, making it think we are in China. Can we edit the location to local coordinates in the UK to speed up the first fix?
I also wondered about the $PCAS commands as these look like private setup data. Finding the protocol manual here: http://www.icofchina.com/d/file/xiazai/2017-05-02/ea0cdd3d81eeebcc657b5dbca80925ee.pdf I have pulled together a rough translation available at
https://docs.google.com/document/d/e/2PACX-1vQaEH6gbVeQds5AOQ7c2dJoNef1o6vCL4SeDRDB9YNtRzI1MKUYzDqS9clEdwL_RdI9TpjErreM-wiM/pub
This suggests that
I'm presuming the two $PCAS03 messages are used at different times in the firmware.
I'm wondering if
Any thoughts?
The text was updated successfully, but these errors were encountered: