View source for Mode-S Beast:Firmware Updates

==Firmware Revision Indication==

There is a heartbeat signal on the LEDs: Up to the 5 left most LEDs flash once each second for a short moment if there is no antenna connected.
These are used to indicate the FW version. Until now these codes have got used:

{| class="wikitable"
|Firmware Version
|[[File:Led-green.png|LED Green]]
|[[File:Led-red.png|LED Red]]
|[[File:Led-red.png|LED Red]]
|[[File:Led-green.png|LED Green]]
|[[File:Led-blue.png|LED Blue]]
|[[File:Led-yellow.png|LED Yellow]]
|[[File:Led-green.png|LED Green]]
|-
|until FW V1.21
|flashing
|flashing
|flashing
|flashing
|flashing
|off
|on
|-
|FW V1.30, FW V1.31
|flashing
|flashing
|flashing
|flashing
|off
|off
|on
|-
|FW V1.32
|flashing
|flashing
|flashing
|off
|off
|off
|on
|-
|FW V1.40
|flashing
|flashing
|off
|flashing
|off
|off
|on
|}

'''Note:''' LED colors of 2CH version are different.


==Copyright Notice==

'''This firmware is free of charges and given as is. No warrenty for any kind of functionaly.'''

'''This software must not be copied or distributed to any other media that is available for public, such as public storages, webpages, CDs or any other media which is not just for your own, private use. It also must not be stored to any other hardware than a Mode-S Beast produced by me and my partners.'''


==Firmware Revisions==

===Revision 1.0 - 13.05.2011===

1st production release supporting Mode-A/C and 1bit error correction.


===Revision 1.1 - 16.05.2011===

Correct DF-11 error checking in case that interrogator SI>47.

''Who needs this update?''<br>All users who live in an area which has radar stations with interrogators SI=48...63. You can check on this [https://docs.google.com/spreadsheet/ccc?key=0Ag3xzzd2vNVedDE0S3FOWDdETEhoYW1qWXZxeHB6aEE&hl=en_GB#gid=0 Google spreadsheet] or simply ask me if I recommend this update.


===Revision 1.15 - 02.06.2011===

Mode-S priority over Mode-AC.

''Who needs this update?''<br>All users who experience significant drop of Mode-S frame rate when enabling Mode-AC decoding, which happens at about above 750 Mode-S frames per second.


===Revision 1.21 - 10.06.2011===

Baudrate 1MBit replaced by 3MBit - the FPGA now is able to transmit all incoming data to the FT232 without a bottleneck. With this version I saw 1300 Mode-S frames and 4500 Mode-AC frames per second in Planeplotter speed meter.

''Who needs this update?''<br>All users who still experience a drop of Mode-S frame rate when enabling Mode-AC decoding


===Revision 1.30 - 20.09.2011===

This firmware is another milestone in the capabilities of the Mode-S beast.

* '''NEW!''' Overlapping frames decoder
* '''NEW!''' Binary protocol towards the PC
* '''NEW!''' Signal strength output

The Mode-S Beast is now able to decode even overlapping frames. In this case not just one, but both frames are output towards the application. The two beta testers and I have seen additional 20% Mode-S frames, in one case even 39% more frames have been seen. The blue LED is used to indicate FIFO overflow and it flashes whenever the received data cannot be output towards the application, which means you need to switch on a filter, most likely first the DF0/4/5 filter, and if that alone does not help, the DF11/17 only filter.

My maximum frame rate 1804 Mode-S frames per second with two receive channels (screenshot taken too late, but two eyewhitnesses)

{|
|[[File:Fpga-shot32-1756frames.gif|link=File:Fpga-shot32-1756frames-big.gif|Received off-air message rate ]]
|''(click on the speedmeter picture to see whole screen)''<br><br>Note that the USB serial bus is again the bottleneck and the implementation gives Mode-S priority over Mode-AC.<br><br>Also remember that prediction is now totally off in my Planeplotter screenshots.
|-
|[[File:Fpga-shot32-1934frames.gif|link=File:Fpga-shot32-1934frames-big.gif|Received off-air message rate ]]
|<ins>Update 26.08.2011:</ins><br>''(whole Planplotter screen if you click on the picture)''<br>Friday evening is the traffic maximum: 1934 Mode-S frames and 6180 Mode-AC frames. MLAT was on! Compared to the capture on the left, it seems that Mode-AC is now less because of Mode-S priority.
|}

My maximum distance on the yagi is 300nm:

[[File:Pp-shot80-300nm.gif|link=File:Pp-shot80-300nm-big.gif|Planeplotter screenshot 80-300 NM]]	

Look at the left side of the picture: There you see the range rings for 200nm (solid) and 225nm (dashed). The 300nm distance of NVR277 is shown in the bottom line. The picture was taken with prediction off, so notice that there was a sequence of frames received from this plane and another one before. Surely there was some good propagation, but at least those between 200nm and 225nm are regular.

The <ins>binary protocol</ins> the Mode-S Beasts makes a more efficient usage of the serial interface. It allows transmission of twice as much information on the same baudrate.

The binary format is a simple escaped format, like

TBD

Since especially Xport-Ethernet users gain from this feature, and additionally since Bev implemented the TCP Mode-S Beast support in Planeplotter right in time, the "AV" UDP support was dropped in the expectation that the binary mode is used with preference over Ethernet. As an example, Bev while testing was easily able to connect to my Mode-S Beast from Portugal. More on the [[Mode-S Beast:Lantronix Xport Assembly|Xport page]]. More about the different output formats on the [[Mode-S Beast:Data Output Formats|output formats page]].

Signal level information is output on the interface for each Mode-S and Mode-AC frame now. This can be used for example to identify the most close flying aircraft. The range is from 0 to about 210. The upper limit is a floating value and depends on the noise level that the antenna sees. Users are recommended to use a long term filter on the maximum when they like to scale the value down or upwards. Due to compatibility reasons, the signal level is available only in the binary output protocol.


===Revision 1.31 - 07.10.2011===

I was not satisified with the way that the signal level was measured in 1.30: Signal level is the difference between noise and the pulse height, and the alogrithm that detects "noise" did not satisfy my expectations. Finally I decided to take "noise" as the average level in the last 4 time slots of the preamble, while "signal" is the amplitude of the last pulse. This provides a quite reproducible display.
There are no improvements neither changes in the signal detection.

''Who needs this update?''<br>All users who want to enjoy new features. Strongly recommended for all users of the Xport ethernet interface.

''A word about all the effort to cope with the serial interface bottleneck''' - or why the hell do other receivers not suffer from this? Simply said: Their frame rate (maybe performance) is not as high as that of the Mode-S Beast. And they mostly do not decode Mode-AC with timestamp, which is while on the input just 12 Bits on the output nearly multipes times 5.

'''Downloads:''' [http://www.modesbeast.com/resources/meaADSB-v131-1ch-SNRimp-blaster.zip 1 CH Firmware V1.31], [http://www.modesbeast.com/resources/meaADSB-v131-2ch-SNRimp-blaster.zip 2 CH Firmware V1.31]


===Revision 1.32a - 03.01.2012 and 10.01.2012===

FW V1.32 adds following new features and corrections:

* RS232 control of the DIP switches: All functions of the DIP switches but not the baudrate setting can be controlled over the serial interface now. There is no longer a need to open the box.
* See page [[Mode-S Beast:Data Input Formats|data input formats]] for more information.
* Noise reception: The squelch level of FW V1.31 was a little bit too low for some locations, so this became increased and no longer showing frames even without antenna. (This surpression still needs still improvement.)
* Progressive detection: Mainly strong signals that are visible through local reflections for another time hooked up the receiver. With a progressive algorithm this is effect is eliminated with outstanding performance.
* With FEC on, about 1ppm of DF-11 frames was incorrectly handled.

'''Free downloads:'''

{| class="wikitable"
|for USB blaster (POF file):
|[http://www.modesbeast.com/resources/meaADSB-v132a-1ch-bincorr-blaster.zip 1 CH Firmware V1.32a]
|[http://www.modesbeast.com/resources/meaADSB-v132a-2ch-bincorr-blaster.zip 2 CH Firmware V1.32a]
|-
|for embedded update (RBF file):
|[http://www.modesbeast.com/resources/meaADSB-v132a-1ch-bincorr-usbupdate.zip 1 CH Firmware V1.32a]
|[http://www.modesbeast.com/resources/meaADSB-v132a-2ch-bincorr-usbupdate.zip 2 CH Firmware V1.32a]
|}

Remember that those which got their HW V1.0 Beast (sold around May 2011) updated to USB update or those who have HW V1.1 (sold after September 2011) can enjoy [[Mode-S Beast:Update over USB|updating over USB]].


===<span style="color:red">FW 1.32a Correction Release</span>===

Unfortunately there was an error in the binary data output of original FW V1.32, so there is a correction release V1.32a.

'''<span style="color:red">Important note:</span>'''

The serial input requires two significant updates:

# The RxD signal must be routed correctly from the device that you're using. See the [[Mode-S Beast:Solder Jumper Settings|solder jumpers]]
# The configuration of the FTDI USB device when selected as interface to the PC must be updated. Users of the [[Mode-S Beast:Update over USB|USB update]] automatically get this done.

Owners of [[Mode-S Beast:Mode-S Beast Hardware History|hardware version V1.1]] who update using blaster please download the USBUpdater and execute the batch file zuruecksetzen.bat.<br>Owners of [[Mode-S Beast:Mode-S Beast Hardware History|hardware version V1.0]] please also download the USBUpdater and execute the batch file hw-v10-serial-init.bat

Your COM port number may change after this procedure.

(Please also those who have got the USB updater in advance, download it again)<br>Testing of the serial configuration feature can easiest be done by switching off and on Mode-A/C decoding with the letters "j" and "J" in the config string and observing it with Planeplotter's speed meter.


===Revision 1.40 - 07.03.2012===

This version introduces a totally new design of the frame synchronisation, which now uses all available information from the preamble without any compromises. It was tested over several weeks by some beta testers with great success, who all saw a further <ins>increase of frame rate by about 10%</ins> and also <ins>some increase in range</ins>. When testing by myself, I now can see up to '''1500 Mode-S frames per second''' in the evening hours with only the omni antenna and I am getting a stable 225nm range displayed. The sensitivity increase not at least allows me seeing the ground traffic at Munich airport, which did not appear in the versions before and whatfor I needed the yagi antenna. Also, I found a way how to better filter false non-CRC checkable frames, which are drastically reduced and keep load away from the interface and post processing SW. My number is that around 75% of the frames now are good frames.

While testing, I found a nice performance value: When the channel is not heavily loaded, below about 60 aircraft beeing tracked, the number of frames per second is 10 times the number of aircraft. Or, in other words, each aircraft transmits 10 frames per second. This may be different in other parts of the world, as for example we've learned just recently that in some areas DF-20 and DF-21 are not in use.

<ins>FW V1.40 adds following new features and corrections:</ins>

* New design of the frame synchronisation: Leads to a better detection of  frames while having local reflections, and also a better detection of weak and noisy frames. Not at least the timestamp by this has an accuracy of 1 sample clock or 62ns.
* Removal of double output DF-17 frames while having forward error correction (FEC) enabled.
* FEC of .DF-11 frames is working again.
* Improved signal level measurement: Signal level now is measured using all 128 ADC samples that are part of the preamble. It is the normalized level difference between all samples that should be zero and those which should be one. The value range has not changed, just the accuracy is better.
* Drastic decrease of corrupt frames that cannot be checked by a CRC.

'''Who needs this update?'''<br>This FW update is recommended to all users.

'''Free downloads:'''

{| class="wikitable"
|[[Mode-S Beast:Update with Blaster|for USB-Blaster]] (POF file):
|[http://www.modesbeast.com/resources/meaADSB-v140-1ch-blaster.zip 1 CH Firmware V1.40]
|[http://www.modesbeast.com/resources/meaADSB-v140-2ch-blaster.zip 2 CH Firmware V1.40]
|-
|[[Mode-S Beast:Update over USB|for embedded update]] (RBF file):
|[http://www.modesbeast.com/resources/meaADSB-v140-1ch-usbupdate.zip 1 CH Firmware V1.40]
|[http://www.modesbeast.com/resources/meaADSB-v140-2ch-usbupdate.zip 2 CH Firmware V1.40]
|}

Remember that those which got their HW V1.0 Beast (sold around May 2011) updated to USB update or those who have HW V1.1 (sold after September 2011) can enjoy updating over USB.

Notes:

* The beta testers got this version as V2.0. I initally thought that the improvements are worth a major version increase, but then Andy reminded me that this might cause confusion with the next hardware release, which is often quoted as "HW V2.0", and so I decided to keep the '1' ahead.
* The Mode-A/C decoding rate of this version is <ins>in some cases lower</ins> than in the previous version. I will have a look after this, but I'm busy with other projects and don't want to hold the release longer now.
* Early upgraders have indidcated that this version produces a few <ins>ghost frames with correct CRC</ins>. Most likely it is that the frame decoder finds them in the noise. As long as you are feeding ICAO hex code databases or similar, you should be aware of that. It does not influence you as long as you simply are watching traffic.

'''Important note:'''

Remember when updating from versions before V1.32, that the serial interface needs a minor modification done. See [[Mode-S Beast:Firmware Updates|here]].