-
Notifications
You must be signed in to change notification settings - Fork 563
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
Hamming code correction method (Glonass) #667
base: next
Are you sure you want to change the base?
Conversation
It is just math, which is reflected in google tests. I take a valid string and generate all possible errors in this string. First all possible single bit errors, then all possible two bit errors. Can you tell me, please, any reference to this consensus? Because I am not sure I understand the reasoning... If I get a message, which has all sums valid, it does not mean anything, because these correction codes are just probability based and I can change 3 bits in a valid message, keeping all the check sums valid. So I guess there should be some research which says "OK, the strategy without recovering errors gives correct results in X % of cases which is larger than Y % for a strategy with error correction", or vice versa. Right? Straightforward estimate seems to be in favor of correction in case of low error rate: If probability of error in a single bit is
Probability of a message with a single error is
And the rest is
For small enough |
In real world, if you get a message, that requires error correction, chances, that next message will be uncorrectable, are very high. And chances, that you'll have correct navigation message decoded when you receive all required strings are very low. |
Almost full recording was made in a "bad environment". The skyview was blocked by trees and buildings most of time. Only ~5 minutes of clean skyview (not continous). And, while driving through a city, there were some places with strong interference. |
As far as I understand the parity bit is needed for correction only. Nothing more. If there is no intent to correct the message, the parity is not needed. If I have invalid parity, there are two options: single bit error error in parity or two or more bit error somewhere else. If the probability of single error is higher, I win by correcting the parity. Right? |
I am sorry, I did not understand the results. Was it better with correction in your experiments or without correction? |
I have not seen any significant improvement with correction enabled. |
I had several runs with debug message enabled, but I have not implemented error counters. OK. I'll add counters (error-free strings, 1-bit errors and uncorrectable) and re-test. |
Some statistics:
It looks, like percentage is incorrect... It is calculated against successful decodes instead of total words processed. |
I have not tested for that specific case .
|
I think, I have obtained more or less correct stats:
It may be more interesting to test, how many ephemeris, decoded with ECC are dropped by the validator later. |
3 more runs:
|
More, than 50% of ephemeris with 1-bit errors corrected are passing validation. Not as bad as I thought.
Tests are here: https://github.com/vladisslav2011/gnss-sdr/tree/glonass_ephemeris_validation_test commit 3cbfc6b. |
I have not tested Glonass in assisted mode, but I don't think, that published ephemeris are much different from broadcast ephemeris. For RTK it is always better to setup a base station in a place with known coordinates not far from the place, where actual measurements are to be done. You'll get corrected pseudoranges and phase measurements either in real-time or as a RINEX file to do post-processing. |
APPS is different thing. It is GPS-only. And, as I can see, they are offering post-processing only.
No. Read the code of this method: https://github.com/gnss-sdr/gnss-sdr/blob/main/src/core/system_parameters/glonass_gnav_navigation_message.cc#L234 especially this line https://github.com/gnss-sdr/gnss-sdr/blob/main/src/core/system_parameters/glonass_gnav_navigation_message.cc#L363 and it's outer blocks. |
f03aedd
to
7044338
Compare
- Added google tests for this method
7044338
to
7333f0c
Compare
This would be hard to test as this is a very rare case. One error per 4..5 runs.
Noise/garbage may pass the validation only when
No. It should receive time from each satellite before trying to solve for the PVT. Glonass satellites transmit time information once per 30 seconds (L1OF, L2OF signals). GPS satellites transmit time information once per 6 seconds. |
The original data is not noise as it has correct preamble. This means, that there are more, than 2 bits flipped.
Knowledge of absolute time does not help because delay from antenna to tracking/acquisition block is unknown and unstable. |
I have added Hamming code correction method for Glonass signal and google tests for this method. I have also replaced the call to
CRC_test
by the call to this new method, so that errors in messages are automatically corrected if possible.The code works as described in Glonass ICD 5.1, with only a single difference: the document says that if
then the error is not recoverable. My experiments show that this case just means that all information bits are valid and there is a single error in
C_Sigma
. Therefore settingC_Sigma
to0
completely corrects the string.Please, let me know if I am wrong, i.e. you can create a case
by introducing 2 errors in a valid message.