Post 30003 socket output format/emulation/compatibility

[DaveReid]

I've started a separate thread for this, although it's also relevant to the Future Developments thread given the stated aim of providing compatibility with the corresponding SBS/BaseStation socket output, so that applications designed for the latter will also work seamlessly with RadarBox.

Firstly, examples of the current output (spacing added to improve legibility):

Code: [Select]

RadarBox:
MSG,3, 0,  0,4006B3,      0,2009/06/19,06:15:05.984,2009/06/19,06:20:05.984,,18225,390,097,51.4870,-1.9225,-2432,4244,0,0,0,0
MSG,1, 0,  0,4006B3,      0,2009/06/19,06:15:17.421,2009/06/19,06:20:17.421,BAW4J,17750,381,097,51.4854,-1.9028,-2496,4244,0,0,0,0
MSG,3, 0,  0,4006B3,      0,2009/06/19,06:22:06.140,2009/06/19,06:27:06.140,BAW4J,16000,365,090,51.3102,-0.8433,0,4244,0,0,0,0
MSG,3, 0,  0,4006B3,      0,2009/06/19,06:22:22.406,2009/06/19,06:27:22.406,BAW4J,15875,360,091,51.3098,-0.8001,-448,4244,0,0,0,0
MSG,3, 0,  0,4006B3,      0,2009/06/19,06:22:32.171,2009/06/19,06:27:32.171,BAW4J,15800,357,091,51.3095,-0.7739,-576,4244,0,0,0,0
MSG,3, 0,  0,4006B3,      0,2009/06/19,06:22:46.031,2009/06/19,06:27:46.031,BAW4J,15700,357,091,51.3090,-0.7430,-576,4244,0,0,0,0
MSG,3, 0,  0,4006B3,      0,2009/06/19,06:24:31.562,2009/06/19,06:29:31.562,BAW4J,15000,321,091,51.3056,-0.4856,0,4244,0,0,0,0

SBS/BaseStation:
AIR,,64,522,4006B3,1509068,2009/06/19,07:12:42.179,2009/06/19,07:12:42.179
SEL,,64,522,4006B3,1509068,2009/06/19,07:12:42.945,2009/06/19,07:12:42.945,BAW4J
ID ,,64,522,4006B3,1509068,2009/06/19,07:12:42.992,2009/06/19,07:12:42.992,BAW4J
MSG,1,64,522,4006B3,1509068,2009/06/19,07:17:51.870,2009/06/19,07:22:52.273,BAW4J,,,,,,,,,,,
MSG,5,64,522,4006B3,1509068,2009/06/19,07:17:51.870,2009/06/19,07:22:52.273,,16025,,,,,,,0,,0,0
MSG,4,64,522,4006B3,1509068,2009/06/19,07:17:52.089,2009/06/19,07:22:52.273,,,365.7,105.7,,,0,,,,,
MSG,5,64,522,4006B3,1509068,2009/06/19,07:17:52.089,2009/06/19,07:22:52.273,,16025,,,,,,,0,,0,0
MSG,6,64,522,4006B3,1509068,2009/06/19,07:17:52.089,2009/06/19,07:22:52.089,,16000,,,,,,4244,0,0,0,0
MSG,3,64,522,4006B3,1509068,2009/06/19,07:17:52.089,2009/06/19,07:22:52.273,,16025,,,51.36583,-1.52344,,,0,0,0,0
MSG,8,64,522,4006B3,1509068,2009/06/19,07:17:52.089,2009/06/19,07:22:52.273,,,,,,,,,,,,0
MSG,5,64,522,4006B3,1509068,2009/06/19,07:17:52.495,2009/06/19,07:22:53.273,,16025,,,,,,,0,,0,0
MSG,4,64,522,4006B3,1509068,2009/06/19,07:17:52.495,2009/06/19,07:22:53.273,,,365.8,105.2,,,0,,,,,
And here's a somewhat edited/updated version of the documentation on the socket output format from the sticky on the Kinetic forum:

Four types of messages are currently output. They are:

NEW AIRCRAFT MESSAGE

This message is broadcast when the SBS-1 picks up a signal for an aircraft that it isn't currently tracking, i.e. it's when a new aircraft appears on the right-hand aircraft list.

It doesn't mean new aircraft in the sense of an aircraft that wasn't previously in the database.

Field 1: AIR
Field 2: [null]
Field 3: System-generated SessionID
Field 4: System-generated AircraftID
Field 5: HexIdent
Field 6: System-generated FlightID (N.B. not callsign)
Field 7: Date message generated
Field 8: Time message generated
Field 9: Date message logged
Field 10: Time message logged

Because this is a real-time message, fields 7/9 and 8/10 will have the same value.


ID MESSAGE

This message is broadcast when a callsign is first received, or changes.

Field 1: ID
Field 2: [null]
Field 3: System-generated SessionID
Field 4: System-generated AircraftID
Field 5: HexIdent
Field 6: System-generated FlightID
Field 7: Date message generated
Field 8: Time message generated
Field 9: Date message logged
Field 10: Time message logged
Field 11: Callsign

Because this is a real-time message, fields 7/9 and 8/10 will have the same value.


SELECTION CHANGE MESSAGE

This is broadcast when the user changes the selection, although because of the way the grid works, it is possible that this might also fire when new aircraft are added (with the values staying the same).

Field 1: SEL
Field 2: [null]
Field 3: System-generated SessionID
Field 4: System-generated AircraftID
Field 5: HexIdent
Field 6: System-generated FlightID
Field 7: Date message generated
Field 8: Time message generated
Field 9: Date message logged
Field 10: Time message logged
Field 11: Callsign

Because this is a real-time message, fields 7/9 and 8/10 will have the same value.

Flight ID is the database ID of the record for the flight that the aircraft is currently making.

 
TRANSMISSION MESSAGE

This is basically a delayed (5 minutes) outputting of every message received from the aircraft.

Field 1: MSG
Field 2: Transmission Type
Field 3: System-generated SessionID
Field 4: System-generated AircraftID
Field 5: HexIdent
Field 6: System-generated FlightID
Field 7: Date message generated
Field 8: Time message generated
Field 9: Date message logged
Field 10: Time message logged
Field 11: Callsign
Field 12: Altitude
Field 13: GroundSpeed
Field 14: Track
Field 15: Lat
Field 16: Long
Field 17: VerticalRate
Field 18: Squawk
Field 19: Alert
Field 20: Emergency
Field 21: SPI
Field 22: IsOnGround

However, it gets a bit more complicated, as you will see if you look in the log files, because not all messages set all fields. Basically, you have to look at field 2, the TransmissionType. This can have the following values:

1 = ID Message (1090ES DF17 or ELS DAP)
2 = Surface Position Message (1090ES DF17)
3 = Airborne Position Message (1090ES DF17)
4 = Airborne Velocity Message (1090ES DF17)
5 = Surveillance Altitude Message (DF4, DF20)
6 = Surveillance ID (Squawk) Message (DF5, DF21)
8 = All-Call Reply/TCAS Acquisition Squitter (DF11)

These messages have values in the following fields:

IDMessage: Callsign
Surface Position Message: Altitude, GroundSpeed, Track, Lat, Long
Airborne Position Message: Altitude, Lat, Long, Alert, Emergency, SPI
Airborne Velocity Message: GroundSpeed, Track, VerticalRate
Surveillance Altitude Message: Altitude, Alert, SPI
Surveillance ID (Squawk) Message: Altitude, Squawk, Alert, Emergency, SPI
All-Call Reply: None at the moment


Over to you, AirNav !

[malc41]

Dave

Very interesting, thanks for the info.

This is what makes the forum what it is.

[tarbat]

Dave, this is more or less the same information I provided to A@Airnav back in March 2008.  Back then we ended up with a compromise of getting it working for Planeplotter and sbsplotter, just using MSG 3.

My recommendation at the time was as follows:

We all know that the output on port 30003 is not complete.  Yes, Transmission Type 3 messages look okay, although many messages output as type 3 are NOT really type 3 – this one for example (it has no position data):
MSG,3,0,0,C058B0,0,2008/03/06,10:39:13.669,2008/03/06,10:44:13.669,ACA869,32975,,,0,0,0,,0,0,0,0

Looking at port 30003 output, I think all transmission types are being output, but they’ll all being marked as type 3.  You’ll need to output all transmission types if you’re going to get SBS addons working:
1=IDMessage: Callsign
2=SurfacePositionMessage: Altitude, GroundSpeed, Track, Lat, Long
3=AirbornePositionMessage: Altitude, Lat, Long, Alert, Emergency, SPI
4=AirborneVelocityMessage: GroundSpeed, Track, VerticalRate
5=SurveillanceAltMessage: Altitude, Alert, SPI
6=SurveillanceIDMessage: Altitude, Squawk, Alert, Emergency, SPI
7=AirToAirMessage: Altitude

I’d suggest a release note that states that the framework is now in place to output on port 30003, and that Transmission Type 3 messages have been tested.  Other Transmission Types should be developed over the next few weeks.  Maybe ask users which addons are important to them, so they can be tested.

Its frustrating that over a year later, we're still not nearer to a fully compliant port 30003 output.

[DaveReid]

Its frustrating that over a year later, we're still not nearer to a fully compliant port 30003 output.

Quite so.

For example I understand that an add-on application like Squawkbox has to handle RadarBox and SBS socket outputs differently, because BaseStation outputs the squawk in a MSG 6 whereas RadarBox sticks it in a MSG 3.

It's also very misleading to output all the 1090ES/ELS parameters in every MSG 3, because the aircraft never sends, for example, groundspeed and altitude in the same transmission, ditto squawk and vertical rate, etc.

[tarbat]

For example I understand that an add-on application like Squawkbox has to handle RadarBox and SBS socket outputs differently, because BaseStation outputs the squawk in a MSG 6 whereas RadarBox sticks it in a MSG 3.

But Squawkbox is pretty useless on a 5-minute delayed output anyway (sorry Andy).  And that's my overall point - Airnav need to understand what users want to use the port 30003 output for.  Many of the addons for the SBS-1 rely on a real-time port 30003 output, and that's never going to be available in Radarbox.

For example, Dave, what do you want to use the port 30003 output for?

[DaveReid]

For example, Dave, what do you want to use the port 30003 output for?

The answer's still the same as yesterday  :-)

www.airnavsystems.com/forum/index.php?topic=2885.msg25845#msg25845

[tarbat]

The answer's still the same as yesterday  :-)

www.airnavsystems.com/forum/index.php?topic=2885.msg25845#msg25845

Can't you achieve that with the current port 30003 output from RB?  All the data is there, isn't it?

[DaveReid]

Can't you achieve that with the current port 30003 output from RB?  All the data is there, isn't it?

Yes, of course it is, if only I could be bothered to rewrite my capture application so that it expects the MSGs in RadarBox format rather than BaseStation format (GS/track in MSG 4, squawk in MSG 6, etc).  But the point is that this shouldn't be necessary, the formats should be the same.

Incidentally I've never shared the view that the 5-minute delay renders the socket output useless. It's never been an issue with the LHR site and I've also been running an alerting application for OTTs for the last 3 years which reads the delayed output and simply uses DR to predict the aircraft's position in 5 minutes time (i.e. now).  I'd say that on 99% of the occasions that my BlackBerry pings to tell me there's an interesting aircraft overhead, I look up and there it is.

[OKC-Steve]

RB also has integers where SBS has floats.  ground track and ground speed should be floats of 1 decimal point accuracy.  I don't know about the current version, but the last version the booleans at the end were always false.

Code: [Select]

[0] MSG
[1] 3
[2] 0                  (Session ID not used)
[3] 0                  (Aircraft ID not used)
[4] ACID               (Hex ID)
[5] 0                  (FlightID not used)
[6] Date Detected      (YYYY/MM/DD)
[7] Time Detected      (HH:MM:SS.mmm)
[8] Date Sent          (YYYY/MM/DD)
[9] Time Sent          (HH:MM:SS.mmm)
[10] Callsign          (String)
[11] Altitude          (Integer)
[12] Groundspeed       (Integer)
[13] Groundtrack       (Integer}
[14] Lat               (Float)
[15] Lon               (Float)
[16] Vertical Rate     (Integer)
[17] Squawk            (octal Integer)
[18] Alert             (Boolean) always false
[19] Emergency         (Boolean) always false
[20] SPI               (Boolean) always false
[21] OnGround          (Boolean) always false



[DaveReid]

RB also has integers where SBS has floats.  ground track and ground speed should be floats of 1 decimal point accuracy.

And I though I was picky    :-)

The E-W and N-S velocity components are only encoded at 1kt resolution, so I wouldn't put too much faith in those tenths of knots and degrees !

[Andy Frost]

To reply to Tarbat, totally agree, a 5 minute delay makes SquawkBox fairly useless. I was led to believe that live data would be output by the new version without positional information. See reply to jgrloit on http://www.airnavsystems.com/forum/index.php?topic=2139.15. I can't see this addition in the "Official full list of suggestions/improvements" for version 3.0 so I guess it got missed.

[jmhayes]

I don't know about the current version, but the last version the booleans at the end were always false.

I haven't seen any change in this in v3.0 ...

[jmhayes]

I've never shared the view that the 5-minute delay renders the socket output useless

I totally agree with Dave: the data is useful even if not in real-time.

I saw a message today that was interesting:

Code: [Select]

MSG,1,0,0,A6A114,0,2009/06/19,01:58:12.984,2009/06/19,02:03:13.000,VRD757,12100,
374,160,38.0032,-122.7191,-1920,,0,0,0,0Note that the detected/sent times aren't exactly 5 minutes apart :D

[jmhayes]

One thing to watch out for that I just noticed: under certain circumstances, you can get duplicate rows: I've only seen this a few times now, but certain aircraft seem to trigger it.  And it's not every message: just some!  I don't see anything else binding them together, so if that matters to you, watch out.

[Harry]

I have been away for a few months from this forum and I cannot find the answer in all the messages with the release of Beta 3: is airnav going to do something about the socket output or not?