Open tkerby opened 5 years ago
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. :-) I've flashed the patched image successfuly into my 878, but on the 1st glance I didn't recognize any improvement.
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. However, from the protocol description I can't find any NMEA command which would inject these values into the GPS module for a location initialization.
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? I mean how do you get the crc 2bye after : $PCAS04,1 Tnx
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. Hence you can simply modify the parameters of the cmd strings with a suitable hex editor, the FW will calculate the required chksum for its own when sending the cmds to the GPS module.
D868UV fw 2.33
Ver 1.00.2018-09-26.Ver 1.11.Ver 1.00...$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*.$PCAS04,3*.,091926.000,3113.3166,N,12121.2682,E,0.51,09,0.9,36.9,M,7.9,M,,0000*56.,961639.00,A,2458.21111,N,11838.31444,E,0.18,,091217,,,A,V*,,*
D868UV fw 2.34
Ver 1.00.27-01-2019.Ver 1.20.Ver 1.00...$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,,0000*56.,961639.00,A,2458.21111,N,11838.31444,E,0.18,,091217,,,A,V*,,*
D878UV fw 1.10
Ver 1.00.21-12-2018.Ver 1.1d.Ver 1.00...$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,,0000*56.,961639.00,A,2458.21111,N,11838.31444,E,0.18,,091217,,,A,V*,,*
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 https://www.google.ca/maps/place/31%C2%B007'59.4%22N+121%C2%B012'45.7%22E/@31.1331707,121.2039273,15z/data=!4m5!3m4!1s0x0:0x0!8m2!3d31.133166!4d121.212682
2458.21111,N,11838.31444,E https://www.google.ca/maps/place/24%C2%B034'55.6%22N+118%C2%B022'59.3%22E/@24.5821173,118.3481253,13z/data=!4m5!3m4!1s0x0:0x0!8m2!3d24.5821111!4d118.3831444
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! Even though I am lacking programming (...) skills, I managed to change the part about the BDS satellites by a HexEditor to test whether the GPS lock will now actually do it's thing. But when I want to load the modified FW by actually loading the corresponding .spi file into the 878's software, I get an "file format error" for the .cdd FWfile. Do I have to change something else to get a modified FW working again? Like... a checksum...thing in the .spi? Or something different what is "obvious" for ppl knowing how to deal with..firmware-files or hex-stuff?
I have to admit, that's something not included in my skillset 😆 Thanks in advance
73 de DK6KR
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):
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,118
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,118
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:
select BDS:
$PCAS04,21b
select BDS + GPS:
$PCAS04,31a
Again, the '*' separating the command from the checksum is missing. Tested with D878, FW 1.21 and 1.20
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:
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,118
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,118
It's really just the PCAS04 hat is broken...
Yes, confirmed! As a countercheck I've just logged the initialization sequence on my (upgraded) 878 V1.21, looks similar to Thomas' log above:
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,31a
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,31a
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. Time to file an bug report to Anytone.
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...
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. :-( (Init sequence after power on:)
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,31a
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,31a
$PCAS02,1000*2e
$PCAS03,1,0,0,0,1,0,0,0*02
$PCAS04,31a
GPS module instead expects $PCAS04,3*1A
For transmission of data over the air, these radios send an NMEA RMC sentence in UTF-16. Example from 878 below.
'~'~$GPRMC,044931.000,A,4726.1740,N,12019.6275,W,0.05,0.00,120321,,,A*67
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?