TM4313 GPSDO: strange behavior after a night of poor reception

[tggzzz]

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.

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 only a crude version of what GPS (etc) jamming does. The more sophisticated version moves the apparent position, so that ordnance lands near the target, not on the target.

I've heard reports of someone in the UK whose GPS receiver told them they were flying directly over a military airfield - but they could see the runway a couple of miles away over the top of their wing.

If your problem is time-dependent, then maybe jamming only occurs when an attack is imminent.

[shapirus]

I cannot reproduce this lock-up when the jumpers are set to receive messages from the GPS module!

All right, so I caught it in the middle of something.

The output frequency is all over the place. There's no nice seeking back and forth (yet), as I've shown before, but it clearly cannot synchronize.

At the same time, the NMEA messages look totally fine. Well, at least the coordinates are correct.

I have scrolled the minicom buffer backwards for ~1.5h and noticed that the output changed: from four "$GPGSV" lines starting with "$GPGSV,4," followed by a number from 1 to 4, to three lines starting with "$GPGSV,3," followed by a number from 1 to 3. I cannot correlate this with the time when it lost proper tracking, but 1.5 hour ago would seem likely.

On scrolling further backwards, I see that this number flapped between 3 and 4, and even earlier between 5 and 6. I guess that's the number of satellites it can receive data from?

Will check what it says in the morning and what the output frequency will be.

p.s. while I was scrolling the screen buffer and writing this post, the output frequency stabilized and is now exactly where it's expected to be. Go figure.
So yes, I'm still unable to see it going into a permanent bad state when the UART->USB jumpers are set for the GPS module. It does lose proper tracking from time to time, but it seems to be able to recover, unlike when the jumpers were set for the MCU.

[shapirus]

If your problem is time-dependent, then maybe jamming only occurs when an attack is imminent.

Found no correlation with that.

[MIS42N]

The $GPGSV messages decode as $GPGSV,<number of $GPGSV messages being sent>,<sequence number>,<total satellites in view>, etc.

So look at the field after the sequence number to see how many satellites are in view. It should be the same in every group of $GPGSV messages (but may be different a second later). If you are getting between 3 and 4 lines, that's between 9 and 16 satellites in view and that should be plenty.

Capture the NMEA messages and analyze them with a program such as GPSview or u-center to find out signal to noise. Four or more satellites above 30dBs should give reasonable tracking.

I spent a few years on and off trying various discipline algorithms for my GPSDO design. I finally came up with one that reliably recovers from almost anything, simply by the program rebooting the processor if signal is lost for more than a minute. It then reverts to a past good control voltage until signal is acquired again. This has the disadvantage that the past control voltage can be out by a margin due to ageing of the crystal in the meantime. However, since the indicator LED will not revert to normal until the processor decides it is tracking properly again, the user knows.

So my guess is the erratic behaviour and failure to recover is down to the programming. As long as the unit gives fair indication that it is misbehaving, that's probably tolerable. You get what you pay for.

[nctnico]

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.

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 only a crude version of what GPS (etc) jamming does. The more sophisticated version moves the apparent position, so that ordnance lands near the target, not on the target.

I've heard reports of someone in the UK whose GPS receiver told them they were flying directly over a military airfield - but they could see the runway a couple of miles away over the top of their wing.

If your problem is time-dependent, then maybe jamming only occurs when an attack is imminent.

You have to take into account that the map might be wrong on purpose. Theoretically you can spoof gps but it will also cause problems with car navigation systems when done permanently.

[tggzzz]

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.

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 only a crude version of what GPS (etc) jamming does. The more sophisticated version moves the apparent position, so that ordnance lands near the target, not on the target.

I've heard reports of someone in the UK whose GPS receiver told them they were flying directly over a military airfield - but they could see the runway a couple of miles away over the top of their wing.

If your problem is time-dependent, then maybe jamming only occurs when an attack is imminent.

You have to take into account that the map might be wrong on purpose. Theoretically you can spoof gps but it will also cause problems with car navigation systems when done permanently.

Unlikely in the specific case, due to the adjacent main road and town in Wiltshire.

The curious issue is that there is "forbidden" airspace above that airfield. If someone was relying on GPS and penetrated that airspace, I'm not sure what would happen. I expect the attitude would be "you should look out the cockpit, because all instruments lie".

Around that time there were many NOTAMs to the effect of "don't trust GPS near Aberstywth" (nowhere near Wiltshire!). Clearly jamming trials were in progress.