Here’s an Interesting solution. Converts Beast binary, then acts as a server for ASCII comma separated values.
DF11,C018C8,081,2016-11-15 04:58:03.73,5DC018C8905A24
DF04,C018C8,085,2016-11-15 04:58:03.73,20001910DE27CF
DF17,AA56F8,063,2016-11-15 04:58:03.73,8DAA56F858C904889D427B5A6BC8
DF18,A8BBBC,000,2016-11-15 04:58:03.73,92A8BBBC907B31A4AF665F5AE665
Seems a bit overkill since dump1090 and mlat-client can both output ascii basestation format.
But I do like that this project adds the DF number, especially for anonymized MLATs.
One thing I have observed is that the input to VRS from ports 30005/30106/30105, after conversion to Basestation MSG format by VRS, has Call Sign missing. Is the Call Sign supplied by databases of VRS and dump1090 for their map display?
Output from VRS after converting input from dump1090 port 30005 to Basestation MSG format.
Note missing Call Sign
MSG,7,0,0,AC7C67,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,10600,0
MSG,7,0,0,C04D74,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,2800,0
MSG,5,0,0,A00A31,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,43000,0,0,0
MSG,3,0,0,C058D5,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,31300,45.31398,-77.969775,0,0,0
MSG,4,0,0,C058D5,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,465.4,216.5,-1984,0
MSG,8,0,0,780560,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,0
MSG,8,0,0,C07EEE,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,0
MSG,3,0,0,A699AA,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,35275,44.469131,-75.837904,0,0,0
MSG,4,0,0,A699AA,0,2016/11/15,11:38:13.568,2016/11/15,11:38:13.568,511.1,52.2,-1856,0
Output from VRS after converting input from dump1090 port 30105 to Basestation MSG format.
Note missing Call Sign
MSG,3,0,0,A50C7C,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,36575,41.297516,-78.93457,0,0,
MSG,3,0,0,A50C7C,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,36575,41.297514,-78.934583,0,0,
MSG,4,0,0,A50C7C,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,471.9,98.3,-704,
MSG,3,0,0,A4E108,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,34025,42.882614,-78.049494,0,0,
MSG,3,0,0,A4E108,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,34025,42.882618,-78.049491,0,0,
MSG,4,0,0,A4E108,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,444.9,275.3,0,
MSG,3,0,0,C02C81,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,20200,44.330704,-78.132869,0,0,
MSG,3,0,0,C02C81,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,20200,44.330718,-78.13289,0,0,
MSG,4,0,0,C02C81,0,2016/11/15,11:44:00.763,2016/11/15,11:44:00.763,340.4,242.5,-1408,
Output from VRS after converting input from dump1090 port 30106 to Basestation MSG format.
Note missing Call Sign
MSG,3,1,1,ACB2C2,1,2016/11/15,11:47:03.738,2016/11/15,11:47:03.738,34225,473,256,40.338,-81.5694,-1972,
MSG,3,1,1,~F53993,1,2016/11/15,11:47:03.740,2016/11/15,11:47:03.740,26573,439,105,40.7625,-79.1948,-1007,
MSG,3,1,1,AD928E,1,2016/11/15,11:47:03.741,2016/11/15,11:47:03.741,38959,458,97,41.3931,-79.8171,-22,
MSG,3,1,1,C067E7,1,2016/11/15,11:47:03.743,2016/11/15,11:47:03.743,3640,196,317,43.7736,-79.3972,-579,
MSG,3,1,1,A3F120,1,2016/11/15,11:47:03.745,2016/11/15,11:47:03.745,38063,456,280,40.9354,-78.9083,50,
MSG,3,1,1,C0636C,1,2016/11/15,11:47:03.746,2016/11/15,11:47:03.746,1499,174,334,43.5691,-79.4661,-11,
MSG,3,1,1,A0A6C2,1,2016/11/15,11:47:03.783,2016/11/15,11:47:03.783,37004,444,95,41.9451,-78.9629,24,
MSG,3,1,1,AD928E,1,2016/11/15,11:47:03.785,2016/11/15,11:47:03.785,38951,451,97,41.3933,-79.816,-26,
MSG,3,1,1,A570AC,1,2016/11/15,11:47:03.787,2016/11/15,11:47:03.787,45003,465,75,41.4256,-80.2392,36,
The dump1090 basestation is kind of defective. I think the MLAT basestation output even more defective.
For example, the speed and track are supposed to be 1 decimal point floats, and the booleans on the end are supposed to be 0 or -1. But they show up often as null, so it is basically it’s own version of the Kinetic one.
edgy: do you have a spec for the format? dump1090’s version is mostly guessing at it, because I don’t have any real documentation of the format or a real Basestation to compare to.
The Bones documentation was derived at from watching Basestation.
woodair.net/sbs/Article/Barebone … t_Data.htm
For example MSG 3 in the chart with green blocks shows the booleans that should be included. This means 0 or -1. Then the example given, shows the booleans, alas, as all zeros:
MSG,3,496,211,4CA2D6,10057,2008/11/28,14:53:50.594,2008/11/28,14:58:51.153,,37000,,,51.45735,-1.02826,,,0,0,0,0
In the example of groundspeed and track it shows the 1 decimal place. It probably should mention that in the text. The altitude and vertical speed are integers.
MSG,4,5,276,4010E9,10088,2008/11/28,14:53:50.188,2008/11/28,14:58:51.153,,,459.4,20.2,,,64,,,,,
This is the only place I’ve seen it documented. It was discussed for awhile on the Kinetic forum as the doc was being built.
dump1090 internally stores track/speed as integers. Are you saying I should tack on a .0 to that?
The booleans are emitted whenever dump1090 has them available, do you have an example of when they’re not emitted when they should be?
edit: note that MSG,3 (ES airborne position message) does not carry squawk, alert, or SPI information, so MSG,3 from dump1090 is always going to omit those despite them being listed in the MSG,3 description you referenced. dump1090 could always put 0s in there but that’s pretty misleading; the message just does not have the data either way.
As a minimum. Better would be to change to a float and compute in floating point.
The booleans are emitted whenever dump1090 has them available, do you have an example of when they’re not emitted when they should be?
telnet to port 30106
MLAT,3,1,1,A3A082,1,2016/11/15,20:45:31.059,2016/11/15,20:45:31.059,,36995,479,146,35.1257,-98.5817,7,,,,,,,,
The MSG’s have 12 items. The MLAT has 14. To decode these would be a special case. I’m not sure what the extra values are. I tried searching, but would have to delve into the code. Basically, a MSG,3 should end in some valid boolean (0, or -1). If it’s a null then it takes a special case to parse it. For example, my basestation decoder can’t decode dump1090 because the code is expecting a boolean. I put in some special code, but I’ve since decided to abandon the whole basestation format.
edit: note that MSG,3 (ES airborne position message) does not carry squawk, alert, or SPI information, so MSG,3 from dump1090 is always going to omit those despite them being listed in the MSG,3 description you referenced. dump1090 could always put 0s in there but that’s pretty misleading; the message just does not have the data either way.
I believe basestation plugs in these values from previous DF replies.
Bottom line, I think the basestation output format is obsolete legacy. It’s done it’s job, it’s now time to move on. In my case I’m just going to send the Mode-S and you’ll have to deal with it 
I’m not advocating your doing any work. Obviously others have developed parsers to deal with your version, and they are happy.
edit: added some code I used to deal with finding a NULL rather than a 0, or -1:
try {
temp = token[GROUND].trim();
if (!temp.equals("")) {
gnd = Integer.parseInt(temp);
isOnGround = (gnd == -1);
} else {
isOnGround = false; <--- oops found a null, punt
}
} catch (Exception eg) {
isOnGround = false; <--- no clue, spike the ball
}
The port 30106 output doesn’t try to be compatible.
I think you need to at least tolerate missing values on the regular output. The Basestation format is mostly message-oriented so it really doesn’t make sense to propagate values from old messages - it’s not done in any of the other messages. (I say “mostly” because positions often reflect data from a pair of messages, not a single message)
Note that there is a semantic difference between “0” and “no data”
(Another case I just thought of will be vrate - you can get velocity messages with no vrate data available, dump1090 will leave the vrate field empty in that case)
Ack, looks like my MLAT was turned off. Maybe I violated the terms of use. Oh well… I’ll just use the beast-splitter and radio.
Nov 15 20:13:51 piaware piaware[711]: mlat-client(736): Server status: synchronized with 80 nearby receivers
Nov 15 20:13:51 piaware piaware[711]: mlat-client(736): Receiver: 638.5 msg/s received 200.5 msg/s processed (31%)
Nov 15 20:13:51 piaware piaware[711]: mlat-client(736): Server: 0.0 kB/s from server 0.0kB/s TCP to server 2.5kB/s UDP to server
I think that is normal. I think the booleans were a special case.
I mean, callsign, lat/lon, vrate, etc normally have blanks for no data, but the booleans only had 0 or -1 as an option.
It was a special case I guess. But as you have figured out the docs are not good. Kinetic was not an open source company, and while it let the forum try and figure it out, it wouldn’t let the programmer help.
Nothing deliberate. What site?
Edit: from your stats it looks like mlat was dropping in and out over the last month but your feeder is not currently connected so I’ll need to go back through the logs to find out why
You appear to have turned mlat off via the stats control panel at some point, it’s not just that is it?
Looking further back I don’t see any obvious problems, your clock sync doesn’t seem bad you just don’t seem to be contributing to many results for some reason (you should be seeing some at least, and there is a strange burstiness about it, e.g. you got plenty of mlat on the 15th but not much on the 12/13/14)
I’d need to look at the server state while the feeder is connected to diagnose this further.
The doc you referenced says that the booleans are not present in many message types? e.g. MSG,1 and MSG,4 omit them all, MSG,5 omits the emergency indicator.
You are right. But I go back to that chart with the green blocks that shows which fields are used for that MSG.
It looks like you are right. A green block means fill it in, no green block means it isn’t used, so can be null. Clear as mud
No, I shut it off to stop the upload. I figured if there was no download I’d save my meager bandwidth.
I turned it on this morning and it seems to be operating normally again.
If it breaks again give me a yell and I’ll take a look.
A 2012 document from Kinetics Site:
BaseStation Raw Data Socket (pdf)
http://www.kinetic.co.uk/DownloadFiles/Assorted/BaseStationRawDataSocket_103.pdf
That describes a different data format.