Radarcape:Firmware Versions

FPGA Firmware

Firmware update on the Radarcape is absolutely simple: Just mount the Radarcape as a drive into your Windows, then replace the existing meaADSB.rbf file with the one downloaded from this web page. You may save the existing one, but the history also exists here for download (including the version name in the file name). The GPS timestamp

The GPS timestamp is completely handled in the FPGA (hardware) and does not require any interactions on the Linux side. This is essential to meet the required accuracy. The local clock in the FPGA (64MHz or 96MHz) is stretched or compressed to meet 1e9 counts in between two pulses by a linear algorithm, in order to avoid bigger jumps in the timestamp. Rollover from 999999999 to 0 occurs synchronously to the 1PPS leading edge. In parallel, the Second-of-Day information is read from the TSIP serial data stream and also aligned to the 1PPS pulse. Both parts are then mapped into the 48bits that are available for the timestamp and transmitted with each Mode-S or Mode-A/C message.

The legacy 48bit and 12MHz based timestamp however is not synchronized to 12MHz at all, so it still works as it has been since ever.

Linux and FPGA firmware package ppsjump-021 (23. Aug. 2013)

Corrections

• For enhanced stability, this version is based on Linux 3.8.
• The GPS tool is now included into the radarcape deamon. It also provides a GPS status through the web server, accessing gps.html on the integrated webserver
• The TCP ports for data streaming connect on each try, not each second.

Installation

For this version, it is essential that you update your SD card completly from scratch. Download the naked Linux 3.8 image (73MB) and make a SD card as described in Radarcape Linux Install/Configure. Please mind the two screenshots there in order to see how about the update procedure works like. (As some users hat problems unpacking the XZ, there is a Linux 3.8 image ZIP Version (130MB) on the server, too)

When inserted and rebooted, either login through the serial port (Mini-USB on the back side) or via SSH/network (then your destination temporarily is “beaglebone”). Enter these commands, and don't forget to enter your known Radarcape ID when beeing asked from the skript:

cd
rm install38.sh
wget http://www.modesbeast.com/resources/install38.sh
sh ./install38.sh
reboot -f

FPGA Firmware meaADSB_ep3_143_ppsjump-020

Corrections

The GPS timestamp locked on multiplies of 32768 in situations when the 1PPS signal was disturbed by external matters.

superseeded by ppsjump-021

FPGA Firmware meaADSB_ep3_141_gpsmlat-3

Corrections

1) SecondOfDay (the upper 18 bits of the timestamp in GPS mode) and Nanoseconds (the lower 30 bits) are now synchronized. Note that in order to overcome above problem with negative timestamps, the GPS read: absolute timestamp of Mode-S and Mode-A/C frames is taken at the end of the frame, at least until further notice. This does not make any difference for multilateration, as long as this feature is unique provided by the Radarcape.

Firmware meaADSB_ep3_141_gpsmlat-3

md5sum meaadsb_ep3_141_gpsmlat-3.rbf
86d6cdb069868e4f57d47dfc3441593c  meaadsb_ep3_141_gpsmlat-3.rbf
md5sum meaadsb_ep3_141_gpsmlat-3.zip
5bcae05ea429b4ef943b303314e22b82  meaadsb_ep3_141_gpsmlat-3.zip

FPGA Firmware meaADSB_ep3_141_gpsmlat-2

Firmware meaADSB_ep3_141_gpsmlat-2 has a working GPS timestamp function. Therefore, DIP#5 switch selects either the standard 12MHz timestamp (when off) or the GPS timestamp (when on).

md5sum meaADSB_ep3_141_gpsmlat-2.rbf
dc7a6278a668b1bdb81fd67e7a1891a6  meaADSB_ep3_141_gpsmlat-2.rbf
md5sum meaADSB_ep3_141_gpsmlat-2.zip
ba54740894406cb38e8dd95d0fc3e3e8  meaADSB_ep3_141_gpsmlat-2.zip

Radarcape DIP Switch	DIP#1	DIP#2	DIP#3	DIP#4	DIP#5	DIP#6	DIP#7	DIP#8
equivalent Beast DIP with resp. to PP setting	DIP#3	DIP#4	DIP#5	DIP#6	DIP#7	DIP#8	DIP#9	DIP#10
when ON	Binary format	only DF-11 and DF-17	enable MLAT in AVR format	CRC check disabled	GPS based timestamp	RTS hardware handshake	1 Bit FEC disabled	Mode-A/C decoding enabled
when open	AVR format	all usable DF	no MLAT in AVR format	CRC check enabled	standard 12MHz timestamp	hardware hand- shake disabled	1 Bit FEC enabled	Mode-A/C decoding disabled
Command Character	c/C	d/D	e/E	f/F	g/G	h/H	i/I	j/J
		not used in binary format

An upper case character is equal to a DIP that is in ON position, a lower case character equal to DIP in open position

The green LED next to the SMA connector is used as GPS indicator:

1. Short on, long off: Just 1PPS is present, but no time of day information
2. On and off time equal: 1PPS present, Time of day present, but there is a synchronisation offset
3. Long on, short off: 1PPS present, Time of day present, Internal time is synchronized to GPS

It is not a problem if the clock sometimes falls back from (3) to (2), because the sensitivity of synchronisation check is +/-1 tick.

The center red LED flashes as an indication of operating about twice per second. It should flash very fast in case that hardware handshake is active.

The GPS based timestamp still uses the standard 48 bits as known from the 12MHz timestamp, but in different way:

• the lower 30 bits are the time since the last 1PPS pulse, in 1ns steps, currently 15ns resolution
• the upper 18 bits are the Seconds-Of-Day, starting with zero at midnight UTC

Known Issues (meaADSB_ep3_141_gpsmlat-2)

1. Within the GPS timestamp, the Second-Of-Day part advances in the mid of the 0-999999999ns phase ⇒ next version
2. Sometimes the Second-Of-Day part does not increment at the rollover of the nanosecond part ⇒ next version
3. The absolute value of the GPS timestamp of 14 bytes long Mode-S frames is offset, however since all units do have that error, it is not a big problem for multilateration ⇒ wait for release
4. Negative delta time offsets between consequent frames ⇒ not an issue (see below)

Negative delta time between consequent frames

If you look at the block diagram of the Mode-S Beast, recognize that there are several frame decoders working in parallel, plus the Mode-A/C decoder, which is not yet mentioned in the picture. They all work independently, their output - a ready frame - is written into a FIFO in order to buffer it for RS232 transmission.

It now may happen that during the reception of a Mode-S frame, an overlapping Mode-AC frame becomes decoded in parallel and is written into the FIFO, prior to the end of the Mode-S frame. Since the timestamps are taken at the start of frame, in that situation, the Mode-AC frame with a later timestamp is written to the FIFO before the Mode-S frame finishes. Consequentally on the output, the later timestamp of the Mode-S frame appears ahead of the Mode-S frame's.

It is easy to understand with the Mode-AC as a cause, but the same happens if one of the noise decoders or the overlapping Mode-S frame decoder outputs a frame while the other is still working.

Sorting that in the FPGA would cost too many ressources, so users of the timestamps anyway need a matching algorithm among different units, so that algorithm should be aware about this situation.

If you think about swapping them around, note that it may not happen with two frames bu several, e.g. in the situation that two Mode-A/C frames do overlap a 14 byte Mode-S frame.