Products > Test Equipment
TM4313 GPSDO: strange behavior after a night of poor reception
<< < (3/7) > >>
tverbeure:

--- Quote from: shapirus on April 09, 2024, 08:34:43 pm ---All I could find was "30MHz TCXO". It does take a good bit of time to warm up before finally stabilizing, but after that it doesn't seem to deviate from the GPSDO much, and so far it seem to be consistent across power cycles.

--- End quote ---

Ok. When you're talking about the GPSDO being off by 0.4Hz during lock, it will be the TCXO that's off instead.
shapirus:

--- Quote from: tverbeure on April 09, 2024, 08:49:07 pm ---Ok. When you're talking about the GPSDO being off by 0.4Hz during lock, it will be the TCXO that's off instead.

--- End quote ---
I believe I never said that one or the other was off (except for when the GPSDO loses signal and stops tracking). I always referred to it as a difference between the TinySA and GPSDO. Of course I'm assuming that it's the latter that is more accurate of the two, as long as it's tracking and the logs look sane.

Now, here's something very funny:


--- Code: ---Ph =        -7, D =  551672, GL = 0, LOS = 3, ST =       480, AF =  37, RT = 124297
Ph =         5, D =  551709, GL = 0, LOS = 3, ST =       481, AF =  37, RT = 124298
Ph =         6, D =  551730, GL = 0, LOS = 3, ST =       482, AF =  37, RT = 124299
Ph =         5, D =  551750, GL = 0, LOS = 3, ST =       483, AF =  37, RT = 124300
Ph =  10000005, D =  551734, GL = 0, LOS = 3, ST =       484, AF =  37, RT = 124301
Ph =  10000006, D =  551692, GL = 0, LOS = 3, ST =       485, AF =  37, RT = 124302
Ph =  10000002, D =  551692, GL = 0, LOS = 3, ST =       486, AF =  37, RT = 124303
Ph =   9999998, D =  551700, GL = 0, LOS = 3, ST =       487, AF =  37, RT = 124304
Ph =   9999997, D =  551700, GL = 0, LOS = 3, ST =       488, AF =  37, RT = 124305
Ph =   9999990, D =  551700, GL = 0, LOS = 3, ST =       489, AF =  37, RT = 124306

--- End code ---

I'm not sure about the frequency, as I've already turned off the TinySA, but hey, this change in the Ph parameter. And neither GL nor LOS changed here. I wonder if it's really GNSS jamming that puts it into this state.

Several minutes later, the D parameter also becomes screwed up:


--- Code: ---Ph =   9989475, D = 2117078271, GL = 0, LOS = 3, ST =      1860, AF =  37, RT = 125677
Ph =   9989440, D = 2119228159, GL = 0, LOS = 3, ST =      1861, AF =  37, RT = 125678
Ph =   9989295, D = 2128710399, GL = 0, LOS = 3, ST =      1862, AF =  37, RT = 125679
Ph =   9989153, D = 2138178175, GL = 0, LOS = 3, ST =      1863, AF =  37, RT = 125680
Ph =   9989015, D = -2147336449, GL = 0, LOS = 3, ST =      1864, AF =  37, RT = 125681
Ph =   9988879, D = -2137898241, GL = 0, LOS = 3, ST =      1865, AF =  37, RT = 125682
Ph =   9988746, D = -2128475393, GL = 0, LOS = 3, ST =      1866, AF =  37, RT = 125683
Ph =   9988619, D = -2119067393, GL = 0, LOS = 3, ST =      1867, AF =  37, RT = 125684
Ph =   9988482, D = -2109673985, GL = 0, LOS = 3, ST =      1868, AF =  37, RT = 125685
Ph =   9988335, D = -2100295425, GL = 0, LOS = 3, ST =      1869, AF =  37, RT = 125686

--- End code ---

...and the "track" LED is still flashing!

It'll be interesting to see if it can recover from this, but so far it seems that the firmware is not able handle some conditions. It looks like the GPS signal is in reality lost, but the firmware fails to recognize it.

Would also be interesting to see the messages produced by the GPS module when it's in this state, but, alas, we can't hot-switch it. Or can we? I don't feel like trying it :)
tverbeure:
Having to deal with GPS jamming may be something the designers never thought about, especially for something as cheap as this. I mean how do you even start to cover all the ways jamming can work.
shapirus:

--- Quote from: tverbeure on April 09, 2024, 09:02:44 pm ---Having to deal with GPS jamming may be something the designers never thought about, especially for something as cheap as this. I mean how do you even start to cover all the ways jamming can work.

--- End quote ---
Well, if I had to write software handling it, I'd do it in the most straightforward way: no data? treat as lost signal; bogus data, an abrupt change of coordinates and/or timestamps received from the GPS module? discard data and treat as no signal.
That's not even about handling jamming situations, but just a regular input conditioning procedure that is a very common thing to do.

Besides, whatever is causing it, it has to be able to recover once good data starts coming back. If it starts. And this "if" makes me think that it may be not the firmware that locks up, but the GPS module itself, which requires a reset of the antenna to recover. I think it's quite likely. I'll switch the UART path to the GPS module next evening and see what it will report.
tverbeure:

--- Quote from: shapirus on April 09, 2024, 09:14:33 pm ---And this "if" makes me think that it may be not the firmware that locks up, but the GPS module itself, which requires a reset of the antenna to recover. I think it's quite likely. I'll switch the UART path to the GPS module next evening and see what it will report.

--- End quote ---
That's a good point. I don't remember if the unfiltered 1PPS signal that comes from the module is easily available, but it could be useful putting that up on a scope.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod