squawk code port 30003

Started by flyfish, March 30, 2010, 06:38:53 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

flyfish

Hi,

I have been searching this forum, but couldn't find any topics related to my question.

I have a program that listen to port 30003 and looks for MSG6 messages. I noticed that most time the squawk field is empty. My program also works with SBS-1. It seems that every MSG6 messages contains a squawk there.

I thought that the 30003 output from RB and SBS1 where the same or I'm missing something?

Albert





Allocator

I'm not entirely sure about the data on the individual MSG types, but I use a number of SBS/RB programs that get their data from port 30003 and they work just fine.  What program are you using - is it one you have written yourself?

flyfish

Written by myself. The program is used for feeding a website.
The program works OK. If there is a squawk in the MSG6 message it is send to the website, but when compared to the SBS1 messages there a few squawks from Radarbox users.

Albert



Quote from: Allocator on March 30, 2010, 06:47:33 AM
I'm not entirely sure about the data on the individual MSG types, but I use a number of SBS/RB programs that get their data from port 30003 and they work just fine.  What program are you using - is it one you have written yourself?

tarbat

I think this has been asked before.  I think SBS1 makes the mistake of outputing the squawk code on all MSG6 messages, whereas Radarbox only outputs squawk on MSG6 messages when the squawk code is received.

flyfish

Tarbat,

Sorry, I couldnt find it. Thanks for your reply.

Albert


Quote from: tarbat on March 30, 2010, 07:46:02 AM
I think this has been asked before.  I think SBS1 makes the mistake of outputing the squawk code on all MSG6 messages, whereas Radarbox only outputs squawk on MSG6 messages when the squawk code is received.

DaveReid

Quote from: tarbat on March 30, 2010, 07:46:02 AM
I think this has been asked before.  I think SBS1 makes the mistake of outputing the squawk code on all MSG6 messages, whereas Radarbox only outputs squawk on MSG6 messages when the squawk code is received.

This has indeed been raised before, though whether it's a bug or a feature in either SBS/BaseStation or RadarBox is a moot point. :-)

Given that the socket message standard was devised by Kinetic, and they decided to output the most recent altitude and squawk in every MSG Type 6, personally I think that an application like RadarBox which aims to emulate the Kinetic output should stick to exactly the same format.

As Albert says, that way third-party add-ons which work with the SBS socket output would be guaranteed to work in the same way with RadarBox.
This post has been scanned for any traces of negativity, bias, sarcasm and general anti-social behaviour

jmhayes

On the other hand, it's arguably a bug in the Kinetic code: sending it when it wasn't decoded is less capable, even if it's easier to write add-ons for ... but anyway, it would be nice to confirm that this is the case.

If you're bug-for-bug compatible, you become the one with the bug if Kinetic fixes theirs :)

gleff

I was the one that asked this the first time.. Although I just did a search and can't find the post either.. oh well.  It was easily fixed at the time. 
http://www.flighttracker.gleff.com - based in Sydney, Australia

DaveReid

Quote from: jmhayes on April 05, 2010, 04:34:22 PMOn the other hand, it's arguably a bug in the Kinetic code: sending it when it wasn't decoded is less capable, even if it's easier to write add-ons for ... but anyway, it would be nice to confirm that this is the case.

If you're bug-for-bug compatible, you become the one with the bug if Kinetic fixes theirs :)

Here's the spec:

Not all messages set all fields. Basically, you have to look at field 2, the TransmissionType. This can have the following values:

1 = IDMessage
2 = SurfacePositionMessage
3 = AirbornePositionMessage
4 = AirborneVelocityMessage
5 = SurveillanceAltMessage
6 = SurveillanceIDMessage
7 = AirToAirMessage
8 = AllCallReply

These messages have values in the following fields:

IDMessage: Callsign
SurfacePositionMessage: Altitude, GroundSpeed, Track, Lat, Long
AirbornePositionMessage: Altitude, Lat, Long, Alert, Emergency, SPI
AirborneVelocityMessage: GroundSpeed, Track, VerticalRate
SurveillanceAltMessage: Altitude, Alert, SPI
SurveillanceIDMessage: Altitude, Squawk, Alert, Emergency, SPI
AirToAirMessage: Altitude
AllCallReply: None at the moment (need to do a further check).


See www.kinetic-avionics.co.uk/forums/viewtopic.php?f=14&t=1402

So I guess that makes it a documented bug :-)
This post has been scanned for any traces of negativity, bias, sarcasm and general anti-social behaviour