| 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 |