SBS-1e and SBS-3 difference in data from ethernet

[Anmer]

Ethernetovich was middleware that delivered "raw" data for PlanePlotter Mlat for those connecting to the SBS-1 via Ethernet.

Then PP found away around this and no longer needed Ethernetovich or the DLL patch for those using USB.

Then it all became a blur and I confess I'm not sure if the latest firmware for the SBS-1 family provides "raw data" and on which port?

[Takashi]

I'm not sure I understand all this. I've been trying to solve this out for over 2 days now and it's all just getting more messy...

1. Attached is a screenshot of the telnet output. What DF-types are of interest to me? (As I'm only interested in ADS-B tracks)
2. In your sbsnet-pdf, your syntax is <DF type...>....<Mode-S data>... is there any spec on the mode-S data?
3. Can I connect to tcp port 30006 (when basestation is running)? And in what format will I get the data? Is there anything special I have to click on in basestation to have it transmitting data on 30006?

[Attachment deleted by Admin to save file space]

[edgy]

It may be, you just need to connect to port 30003. This has the data already decoded for you.  Port 30006 and 10001 are binary data and you have to write software to break down the protocol.  You will not be able to go to the pub every night.

Anyway, DF17 is ADS-B and to decode the ADS-B packets is done using various snippets from google, on decoding the bits.  Are you sure you want to kill yourself over this, or just grab the port 30003 ascii data?

I see in your telnet output that both DF11 and DF17 don't have CRC in the last 6 digits, they are 000000, while the other DF's do. This is a change from the old firmware.  Basically, the later SBS-1 only sends validated packets, and you don't have to decode the CRC yourself on DF11 or 17.  The 6 hex digits after the first two are the aircraft ICAO address.  The first two hex digits are what DF is being received. The other DF's do have a CRC included (not zeroed).

[Takashi]

Edgy, thank you! I've written a small application that connects to port 30003 (whilst running basestation). It seems to be working! The format for which I receive data looks like this now:

MSG,3,36,111,400B4B,154,2013/02/12,13:49:31.906,2013/02/12,13:49:32.609,,38025,,,59.38864,17.73724,,,0,0,0,0
MSG,5,36,111,400B4B,154,2013/02/12,13:49:31.906,2013/02/12,13:49:32.609,,38025,,,,,,,0,,0,0
MSG,4,36,111,400B4B,154,2013/02/12,13:49:32.234,2013/02/12,13:49:32.609,,,455.0,284.8,,,0,,,,,
MSG,1,36,111,400B4B,154,2013/02/12,13:49:32.343,2013/02/12,13:49:32.609,TOM327,,,,,,,,,,,
MSG,1,36,111,400B4B,154,2013/02/12,13:49:32.453,2013/02/12,13:49:32.609,TOM327,,,,,,,,,,,
MSG,6,36,111,400B4B,154,2013/02/12,13:49:32.453,2013/02/12,13:49:32.609,,38025,,,,,,4031,0,0,0,0
MSG,4,36,30,4AC8B5,149,2013/02/12,13:49:32.796,2013/02/12,13:49:33.609,,,387.6,217.1,,,2688,,,,,

Seems pretty straightforward to interpret this data. There seems however to be a delay of the data published on this TCP-socket. Is this anything you heard something of?

Edit: Useful link:
http://www.homepages.mcb.net/bones/SBS/Article/Barebones42_Socket_Data.htm

[edgy]

There seems however to be a delay of the data published on this TCP-socket. Is this anything you heard something of?

No delay (maybe millisecond processing delay), but not seconds or minutes.