ModeSDeco2 and ModeSMixer2 for the Dongle?

I forgot to say, ModeSDeco2 is an Mode-S Decoder that was made for reading & decoding Dongle data.
(I've heard rumors that it's a little better than RTL1090).. :p

So, the other stuff you need is a dongle radio and a display program,
that can receive decoded S-mode data from the ModeSDeco2.
Now that I have my Dongle back upstairs, I decided to download and try ModeSDeco2 on my Windows 7 PC.
I was missing a file, but found out how to get it from the readme file.. See light blue text below. (The red text is my edit).

Anyways, using my dongle and a 65 mm antenna, I experimented with adsbScope and VRS (Virtual Radar Server) and got both of them working,
with ModeSDeco2.
It took about an hour of correcting my typos.. I'm sure it still needs more tweaks, but my goal was to see if I could get the decoder working..
The 65 mm indoor antenna on has a range of about 75km.. :(

I did learn that before you can edit a GoForIt.Bat file in Win7, you have to tweak the properties, so it's not protected..

Over-all, it seems like ModeSDeco2 is pretty dang good.. But might be easier for a novice (like me) to get running,
if someone wrote a step-by-step set of directions..

readme file:
ModeSDeco2 v.20140616

+ changed the algorithm for determining of PI (Parity/interrogator identifier) - downlink field that have parity overlaid on the interrogator’s identity code and shall appear in the Mode-S all-call reply, DF = 11 and in the extended squitter, DF = 17 or DF = 18

+ changed the algorithm for processing of Interrogator Codes II (Interrogator Identifier) and SI (Surveillance Identifier) for data transcoding in RAW SBS format (--sbs10001)

+ added decoding DF17 type 28 data by ICAO 9871 v.2 (2012)
+ changed options for output listen ports
- deleted option "--net <arg>"
+ modified decoding algorithm for DF18 (TIS-B) messages
+ modified the algorithm of automatic detection of receiving area
+ added mode a single reception can be decoded into the correct location without an even/odd pair
+ modified decoding algorithm for Mode A/C
+ modified algorithm of determining magnitudes of I/Q signals
+ added option "--verbose" - extended mode console output for decoded information from messages
+ changed format options "--avr-mlat" to "--avrmlat"
+ added option "--input-file <arg>" - read mode of I/Q signals that were recorded to binary file by rtl_sdr program from package

This is a console (command line) Mode-S decoder program specifically designed for RTLSDR devices,that can do:
- Decode Mode-S and Mode-A/C messages by software defined radio (SDR) method.
- Setup the DVB-T dongle: Select RTL device, Set gain in Receiver, Enable Automatic Gain Control in RTL, Set channel frequency, Set frequency correction (in units of parts per million (ppm)).
- Output received messages on the console screen or to network. The output data stream may be in the following formats: BEAST binary, AVR ascii, AVR-mlat, SBS10001 (for BaseStation.exe) and MSG.
- Output data checked for validity ICAO standards and lack of ghosts.
- To decode data from aircraft standing on the ground, you need to specify the coordinates of a place of accommodation of the receiver.
- Mode RBS allows to receive Mode A/C messages simultaneously.

C:\>modesdeco2 --gain 49.6 --freq-correction 68 --sbs10001 10001 --beast 33033 --msg 30003 --rbs --location 43.25:39.33 --filter-nocountry

~~~~I'm using this in my batch file in Red text~~~~
@echo off
cmd /c modesdeco2.exe --device-index 0 --gain 49.6 --freq-correction 64 --rbs --avrmlat 33033 --location 42.4660:-71.2008

C:\>modesdeco2.exe --help
YYYY-MM-DD INFO ModeSDeco v.20140616
Program options:
-h [ --help ] This help message
--device-list List Available devices
--device-index arg Select RTL device (default: 0)
--gain arg Set gain in Receiver, dB (default: Auto)
--agc Enable Automatic Gain Control in RTL (default: off)
--freq arg Set frequency, Hz (default: 1090000000)
--freq-correction arg Set frequency correction, ppm (default: 0)
--input-file arg Set input filename with I/Q signals
--rbs Enable RBS decoding
--beast arg Enable Beast output listen port (default: off)
--avr arg Enable AVR output listen port (default: off)
--avrmlat arg Enable AVR MLAT output listen port (default: off)
--sbs10001 arg Enable SBS-3 output listen port (default: off)
--msg arg Enable MSG output listen port (default: off)
--localtime Local Time in MSG format output (default: UTC)
--filter-expire arg Filter record expire time, sec (default: 20)
--filter-count arg Filter record min count (default: 6)
--filter-time arg filter record min time, sec (default: 60)
--filter-nocountry Disable ICAO Country filter (default: on)
--location arg Receiver location Lat:Lon
--verbose Verbose mode

When try to launch the modesdeco can get an error that msvcp110.dll or/and msvcr110.dll is missing.
Please, get the actual Microsoft Visual C++ Redistributable for Visual Studio 2012 Update 4 from the Microsoft site:
Download Visual C++ Redistributable for Visual Studio 2012 Update 4 from Official Microsoft Download Center.

You will need the 32 bit version: VSU_4\vcredist_x86.exe regardless of what bitness have your operating system.
The Visual C++ Redistributable Packages install runtime components that are required to run C++ applications built with Visual Studio 2012.
Cancel the program by <Control-C>

Last edited:
Here's a little show-n-Tell picture.

Today (June 20), I edited the GoForIt.bat file. Changed the data feed mode to "--beast 33033 ". It was --avrmlat 33033.
I wanted to get the RF signal levels of the packets, which is provided in Beast mode..

Last edited:
After repairing the old Dell desktop,(down in the basement Ham shack) I was able to install ModeSDecod2_xp.exe on it, to make a Dongle look like a Beast. :)
Then, I ran VRS on it.. The dongle antenna is not suitable for 1090 MHz, so it only has about a fifty mile range..

The Dell has outdated XP, and I had to do a lot of updating. Also had to install the ZADIG USB driver to get the dongle recognized by ModeSDecod2_xp.exe .
It seems like a pretty solid decoder. I've been using adsbScope on my upstairs Win7 PC to plane watch, or use FireFox on with the VR server, I left running on the remote Dell..

Remote Dell 'Decoder, Plane Data Server' is near the antenna cables.

After installing a 1/4 wave GP, I'm getting more planes. It looks like this Deco program is able to sort out the mess of signals pretty well.

It seems like adsbScope is updating much faster than when using the RTL1090 decoder.
Last edited:
Ran ModeSdec2_xp just about the whole day. It's on the basement XP PC with the dongle on the 1/4 wave ground plane.
VRS is running upstairs, fetching it's data from the modesdec2_xp in the basement.

In 9 hr 13min, we heard about 3.8 million messages. 452,216 were ADS-B messages. 2.05% were rejected.


I believe (not 100% sure) those not displaying Distance are not sending ADS-B (88.15%). So, they aren't visible on the map.

Just the same, their signals can be very strong here, and those squawks are very plentiful in the Boston area.
I supect that many ADS-B packets are not being heard, because of the massive amount of 1090 traffic.
Makes me wonder what it's going to be like when the deadline hits and almost all AC are sending full length ADS-B packets.

Overall, I'm impressed by the performance (with a dongle) of the modesdeco2 (decoder) and the generous amount of data and maps provided by VRS..

Hello Richard,

Thank you for your interest to the program and for its testing. I hope for some time to release a version with web management command line options.

In your's VRS statistics screenshot, I noticed quite a high percentage of messages has a checksum PI error. This is possibly due to the presence of interference.
However, this may be the result of other causes. In this version I have experimented with maximum efficiency decoding interrogator identifier II/SI codes. This could to result in reduced efficiency of recovering the error bits.

Could you repeat the test with this other version of ModeSDeco2 ( and compare the results of "Bad parity Pi" by VRS counter?

Also I can recommend you disable receiving Mode A/C messages mode if you are not using beamfinder+ mode of PlanePlotter. Remove from the command line option --rbs.
In all other cases they can not be used and only useless loaded the computer and network.

I noticed on your desktop icon of BaseStation. With the option --sbs10001 10001 the program more turns to the Kinetic SBS-3 receiver :). And output data can be obtained directly in BaseStation.exe.

Hi sergsero!

Thanks for posting here. It looks like the same percentage of errors today, after 4 hours. (pic below). Amazingly similar!
I'm a novice at this, but I have been meaning to delete that --rbs, thanks for reminding me. It's gone now.

I have not been able to install BaseStation on any of my PCs.. I gave up trying, and used the database writer plug-in for VRS.

I am downloading
now and will install the XP version downstairs tonight and let it run for 4 or 5 hours..


Last edited:
After 5 min, the percentage of Bad parity PI: is almost the same.. No rejected ADS-B packets yet (now 15 minutes).

I also changed the receiver correction from 64 PPM to 58 PPM, which I believe is correct for the dongle.

I still have to try turning down the gain, to see if it helps any. I am driving the dongle with an LNA and filter, from a 1/4 wave ground plane.
Last edited:
After two hours.. Same percentages..


I really admire this decoder and I do like VRS.. My dream system would be to have
both Programs running on a BeagleBoneBlack, fed by dongle. (or maybe 2 or 3 dongles)?

Last edited:
Hi Richard,

Thanks for your testing. Indeed your tests showed that the reason for the rather high percentage of bad parity PI messages is not in the program. The number of Mode-S messages carrying a PI field (PI - parity/interrogator identifier) that indicated that the received message was corrupt.
The downlink sequence facilitates the use of error correction in downlink decoding. The code used in downlink PI field generation shall be formed by a sequence of 24 bits, where the first 17 bits are ZEROs, the next three bits are a replica of the code label (CL) field and the last four bits are a replica of the interrogator code (IC) field.

I think the reason be may indicate a poor signal to noise ratio at receiver input. Perhaps if modify the antenna-feeder device, you will be able to additionally reduce the number received messages with a parity error.

However, I do not think that this statistic values is important if you do not use beamfinder modes.

Last edited:
Since I'm using a tiny 65mm ground plane antenna, with a very small capture area,
I am using an LNA ( <= 0.4dB NF) and a 1-2Ghz filter.

My goal in using the LNA was to get max range/weak signals, (may not be so good for very strong signals)
and it might be causing saturation, front-end-overload, intermod(?) or other problems that could be the reason the parity errors.

I will remove the LNA and filter today, and see if there is improvement.
If not, I'll try slowly reducing the gain of the dongle's LNA..

I might end up with less errors at the cost of max-range..

Removing the LNA didn't help. I have changed the dongle gain down to 32.8dB.
Still getting 53% parity error rate.. (And very short range.. around 50 miles)..

Doesn't look like too much signal.. Max signals now are under 70 (out of 0 to 255)..

What's next?


Within two or three weeks I should be getting a Beast port installed on the PlaneFinder system I'm running.
It's using a 1090 Puck (built-in decoder) and a BBB, and using VRS, I should be able to compare
it's parity error rate with the Dongle's, to see if I'm getting hit with RFI here..
It will be interesting to compare the results of the reception of signals on the dongle and puck in parity errors PI in VRS.
Other parameters in my tests - the maximum range is similar in comparison with SBS-3 and BEAST. It is about 450 kilometers (242 nautical miles) and is limited to direct visibility due to the curvature of the earth.

The only thing dongle lose in this competition for the number of received messages per second. Also dongle has less dynamic range of about 45 dB and lack of preselector input. The receiver is easily jam out-of-band interference. But dongle has high gain. The LNA need only for compensation feeder cable loss when its length is big.
The Software Pros at should be pushing a Beast Port upgrade into my BeagleBoneBlack/Puck any day now.
I don't have a great line-of-sight here. Limited by hills mostly. Range is also limited by nearby 70 foot tall trees.

The new Dongle should be here within a few days. I'll just swap out the old one, check the freq calibration and make a quick compare.
On this dongle, the parity error rate instantly comes up with a 50 to 63% rate, within a few seconds, after VRS start-up.

IIRC, the MGA-86576 LNA (measured at 1296 MHz), had about 20 dB of gain, with a noise figure at 1.6 dB.
It does make a major range improvement, when using the 1/4 wave ground plane.
That antenna is so small (65mm), it needs a little help, to feed the dongle.

When I tested the 1090Puck+DPD gain antenna, with this LNA, it really didn't make any noticeable difference.
Right now, the 1090 Puck is being fed directly from the DPD antenna.
I hope that with the new dongle number of bad parity PI packets will decrease. Additionally I would like to draw your attention to this quote from the VRS documentation about features some receivers:

"Bad parity PI
The number of Mode-S messages carrying a PI field that indicated that the message was corrupt. For SBS-3 users this will usually be zero because the receiver will not (by default) pass on corrupt messages. For other users it is not unusual to see some corrupt messages but an excessively high value may indicate a poor signal to noise ratio."

Unfortunately, I don't know how this situation with PUCK, but with SBS-3 have common roots...
New Dongle came in today. It's been on the air for 3.5 hours.


I moved the new dongle upstairs to run on the Win7 PC with a just a small antenna.
Same parity results, just a lot less planes, due to no LNA or outdoor antenna.
Last edited:
LOL! It's good I retired early. Didn't think logically about this..

This morning, after coffee, I loaded the RTL1090 decoder..
It appears that modeSdeco2 and RTL1090 work about the same..
The bad PI parity numbers are the same..

Well, the port has been installed on the BBB and the Bad Parity PI:
numbers are about the same as they were.. So it's nothing to do with the modeSdeco2 decoder..