Radarcape status message changed, Unrecognized GPS fault

[marcus-aa]

The latest Radacape firmwares cause an error with beast-splitter.

:1a 34 1b 66 40 00 00 04 00 35 01 ff 02 f4 23 4a 80 00 01 10 00 00 00
:1a 34 1b 66 7b 9a c9 f0 00 35 00 ff fd f4 23 4a 70 00 00 f0 00 00 00
:1a 34 1b 66 c0 00 00 0c 00 35 01 ff 04 f4 23 4a 80 00 01 80 00 00 00
:1a 34 1b 66 fb 9a c9 ff 00 35 00 ff 00 f4 23 4a 80 00 01 d0 00 00 00
:1a 34 1b 67 40 00 00 03 00 35 01 ff 02 f4 23 4a 80 00 02 20 00 00 00
^C


 "pps_offset" : 0,
    "message"    : "Unrecognized GPS fault"
    "pps_offset" : 1,
    "message"    : "Unrecognized GPS fault"
    "pps_offset" : 0,
    "message"    : "Unrecognized GPS fault"
    "pps_offset" : 1,
    "message"    : "Unrecognized GPS fault"
    "pps_offset" : 1,
    "message"    : "Unrecognized GPS fault"

https://wiki.jetvision.de/wiki/Radarcape:Version_History#Version_240411.1000.02_(withdrawn)

Timestamp and Time Information Redesign of the FPGA GNSS/Timestamp synchronisation: A few units were observed having a drift of the timestamp correction factor even with a valid GNSS 1PPS pulse.
Consequently this data became invalid for MLAT.

GNSS timestamp synchronisation was improved by a factor 4 and now operates in a 4ns resolution.
There is some more diagnostic data about GNSS timestamp behaviour in the GNSS status page

In order to eventually use data from units with a non present GNSS reception, sensors transmit a time quality in their timestamp information, indicating wether it is GNSS based, NTP synchronized or free running.

[marcus-aa]

The GPS status message is different, in the example above "ff" so all bits are high.

That means Bit 5 is interpreted as "TS not from GPS",
Bit 6 is also set high, not sure how it is used but it is not the problem.

The high bit 5 leads status_writer.cc here

beast-splitter/status_writer.cc

Line 128 in 85be92e

// FPGA is not using GPS time, work out why.

And then it runs out of options since no other bits indicates any problems.

I have requested an updated specification on how bit 5 should be interpreted.

https://groups.io/g/ModeSBeast/topic/new_format_of_radarcape/111491036

[mutability]

Do you know if, in your example data, the radarcape is correctly synced to GPS time or not?

If the meaning of bit 5 has changed, that's a backwards-incompatible change that will break stuff.

[marcus-aa]

Yes it is (they are) synced. I have 3 at different locations, all do the same with new firmware (2024 and 2025 releases)

I also did some more testing and have up- and downgraded my own test receiver several times, GPS fully working, and the change is reproduceable.

I have added more detailed data from that testing here
https://groups.io/g/ModeSBeast/message/4521

It seems the 3 bits 5,6,7 are now always 1, regardless of the actual status. Bit 7 daysec also does not change when this setting is toggled.

I also noted that if the antenna is unplugged, only bits 0 and 1 will change, in both the new and old release. That causes beast-splitter (connected to old fw) to continue to report "within 45 ns" and "GPS synched" which seems unlikely, but it is what is reported. the pps value also keeps in that range. Not sure how long the rc can keep the synch with no GPS at all.

[dl4mea]

Hi, lets discuss it here...

Don't look at the bits, its the complete byte I cannot explain how that ends up in the status. I haven't seen this ever in the status message.

• How often or under which conditions do you see 0xff?
• Which binary port do you connect to?

[marcus-aa]

Hi,

Sure;

* How often or under which conditions do you see 0xff?

Always, as soon as the GPS has stabilized. On 3 different Radarcapes. As soon as they have been upgraded to any 2024 version or later. Millions of messages by now... Never seen anything else under normal operation.

Main status now shows also the GPS Status;

Product Name	Radarcape
Software Type	AAC
Software Version	250215.1500.02
FPGA Version	meaADSB_ep3_154_TsAccu4_2Bit
FPGA Settings	BIN ALL CRC TSgps RTS FEC ACoff
FPGA GPS Status	AntOk Track GoodSat TimeUTC Sync PpsOk TsipUbxOk TrueUTC

And this status AntOk Track GoodSat TimeUTC Sync PpsOk TsipUbxOk TrueUTC provides an "FF" if OK is a high bit !

Sometime the GPS goes to unstable, and we get an "EF" also confirmed by the GPS Status Operational log;

2025-03-11 01:03:22(T) Status 35 BIN ALL CRC TSgps RTS FEC ACoff  31 EF AntOk Track GoodSat TimeUTC noSync PpsOk TsipUbxOk TrueUTC
2025-03-11 01:03:22(t) Time status changed to GPS(unstable)
2025-03-11 01:03:23(t) GPS stable
2025-03-11 01:03:23(T) Time status changed to GPS

Now, this line "AntOk Track GoodSat TimeUTC Sync PpsOk TsipUbxOk TrueUTC"

has 2 problems in my opinion;

1. The bit 7 "Daysec" never changes, regardless of what I use in the settings.

2. Bit 4 and 5 now have a different meaning. Are they swapped?

Whith "GPS Unstable", bit 4 toggles from 1 to 0, and messages goes to "noSync" This used to be the pps range?

But now ppsOK is listed as bit 5, and is always high. This used to be the "Timestamp from FPGA (not GPS) " and is the reason beast-splitter signals error, because a high bit here was NOT OK, it was bad....

* Which binary port do you connect to?

Normally 10002, but 10003 and 10006 has exactly the same message, so it doesn't matter.

root@R-TEST:~# nc localhost 10006 | hexdump -e '16/1 "%02x " " "'  | awk '$0' RS="1a 3" | awk '{print ":1a 3"$0}' | awk '{$1=$1}1' OFS=" " | grep "1a 34"
:1a 34 09 49 fb 9a c9 f2 00 35 00 ff fd f4 23 09 a0 00 01 a0 00 00 00
:1a 34 09 4a 3b 9a c9 dc 00 35 ff ff f8 f4 23 09 70 00 00 90 00 00 00
:1a 34 09 4a 7b 9a c9 e6 00 35 ff ff fa f4 23 09 9f ff ff e0 00 00 00
:1a 34 09 4a bb 9a c9 ea 00 35 00 ff fb f4 23 09 6f ff ff a0 00 00 00
:1a 34 09 4a fb 9a c9 ff 00 35 00 ff 00 f4 23 09 7f ff ff 80 00 00 00
^C

root@R-TEST:~# nc localhost 10003 | hexdump -e '16/1 "%02x " " "'  | awk '$0' RS="1a 3" | awk '{print ":1a 3"$0}' | awk '{$1=$1}1' OFS=" " | grep "1a 34"
:1a 34 09 50 fb 9a c9 eb 00 35 00 ff fb f4 23 09 90 00 03 10 00 00 00
:1a 34 09 51 3b 9a c9 f8 00 35 00 ff ff f4 23 09 90 00 02 b0 00 00 00
:1a 34 09 51 80 00 00 11 00 35 01 ff 05 f4 23 09 b0 00 03 00 00 00 00
:1a 34 09 51 c0 00 00 10 00 35 01 ff 05 f4 23 09 c0 00 03 70 00 00 00
:1a 34 09 52 00 00 00 0f 00 35 01 ff 04 f4 23 09 c0 00 03 d0 00 00 00
:1a 34 09 52 3b 9a c9 eb 00 35 00 ff fb f4 23 09 c0 00 03 60 00 00 00
^C

root@R-TEST:~# nc localhost 10002 | hexdump -e '16/1 "%02x " " "'  | awk '$0' RS="1a 3" | awk '{print ":1a 3"$0}' | awk '{$1=$1}1' OFS=" " | grep "1a 34"
:1a 34 09 57 fb 9a c9 ff 00 35 00 ff 00 f4 23 09 6f ff ff 90 00 00 00
:1a 34 09 58 40 00 00 02 00 35 00 ff 01 f4 23 09 4f ff ff 90 00 00 00
:1a 34 09 58 80 00 00 07 00 35 01 ff 02 f4 23 09 5f ff ff b0 00 00 00
:1a 34 09 58 bb 9a c9 f8 00 35 00 ff ff f4 23 09 40 00 00 00 00 00 00
:1a 34 09 58 fb 9a c9 fd 00 35 00 ff 00 f4 23 09 30 00 00 f0 00 00 00

It also makes no difference if we access the ports locally or from another system.
This one was the first that we noticed, around August 2024 I think, it had just been upgraded with 240412 then.

root@P-ENNO9:~# nc 192.168.68.69 10002 | hexdump -e '16/1 "%02x " " "'  | awk '$0' RS="1a 3" | awk '{print ":1a 3"$0}' | awk '{$1=$1}1' OFS=" " | grep "1a 34"
:1a 34 09 b9 80 00 00 0b 00 35 01 ff 03 f4 23 2e c0 00 01 10 00 00 00
:1a 34 09 b9 bb 9a c9 fd 00 35 00 ff 00 f4 23 2e c0 00 01 60 00 00 00
:1a 34 09 ba 00 00 00 03 00 35 00 ff 01 f4 23 2e c0 00 01 70 00 00 00
:1a 34 09 ba 3b 9a c9 fd 00 35 00 ff 00 f4 23 2e c0 00 01 50 00 00 00
:1a 34 09 ba 7b 9a c9 f6 00 35 00 ff fe f4 23 2e c0 00 00 f0 00 00 00

I can give you remote access to the web interface of the R-TEST box if you want to have a look.

/M

[marcus-aa]

Operational Log

2025-03-11 01:20:57(t) Time status changed to GPS(unstable)
2025-03-11 01:20:58(t) GPS stable
2025-03-11 01:20:58(T) Time status changed to GPS
2025-03-11 02:15:53(T) Status 35 BIN ALL CRC TSgps RTS FEC ACoff -26 EF AntOk Track GoodSat TimeUTC noSync PpsOk TsipUbxOk TrueUTC
2025-03-11 02:15:53(t) Time status changed to GPS(unstable)
2025-03-11 02:15:54(t) GPS stable
2025-03-11 02:15:54(T) Time status changed to GPS
2025-03-11 02:43:07(T) Status 35 BIN ALL CRC TSgps RTS FEC ACoff -26 EF AntOk Track GoodSat TimeUTC noSync PpsOk TsipUbxOk TrueUTC
2025-03-11 02:43:07(t) Time status changed to GPS(unstable)
2025-03-11 02:43:08(t) GPS stable
2025-03-11 02:43:08(T) Time status changed to GPS
2025-03-11 02:45:21(T) Status 35 BIN ALL CRC TSgps RTS FEC ACoff -28 EF AntOk Track GoodSat TimeUTC noSync PpsOk TsipUbxOk TrueUTC
2025-03-11 02:45:21(t) Time status changed to GPS(unstable)
2025-03-11 02:45:22(t) GPS stable
2025-03-11 02:45:22(T) Time status changed to GPS

[marcus-aa]

Any progress?

[dl4mea]

No, sorry, busy with some other, more urgent tasks.

[dl4mea]

I'm picking up that problem - and I am wondering if anywhere in official pages there is a documentation for the status bits.
Yes, you're reading right, I don't know if within 15 years I have somewhere documented FPGA status bits or is it just 2nd level you wrote in the bottom of your message March 11th ?

[marcus-aa]

Sorry for the late reply, I did not notice that it was a question for me.

If we go back to my original post on March 6 here: https://groups.io/g/ModeSBeast/message/4519

I can only find a specification of the status bits dating from Version 170521.1100.02
https://wiki.jetvision.de/wiki/Radarcape:Version_History#Version_170521.1100.02

And here there is no mention of bit 4, 5 or 6, they are all listed as unused. But 4 & 5 are used for sync performance since some time back.

What is the "new" purpose of bit 5 & 6 ?

So the problem is in the undocumented bits, the interpretation of them I have taken from the beast-splitter code. But Beast-splitter has (seemingly) correctly decoded them for years, until the 250215 fw.

Also the documented bit 7 does not work any more, as described in the same message.

So I collected this in my own table to troubleshoot this problem and that looks like this:

As a side note, another user reported weird behaviour on the NTPd service, but not on his non-EVO unit using 2022 firmware.
https://groups.io/g/ModeSBeast/message/4531
This looks related to me.

For information, I have only tested with classic units, no EVO. Maybe you are looking only at the EVO unit and the behave differently?

BR /Marcus

[marcus-aa]

Upgraded to Version 251112.2000.02 but there seems to be no improvement.