15Apr/0833
SBS1 under Linux and Mac OS X
Maybe there ain't too many SBS1 owners who'd like to use their boxes under Linux or OS X, but still I think I'm not the only one. This is why I started reverse engineering the BaseStation application and protocol to make an equivalent piece of software that would work *natively* under other operating systems.
I guess it would take a few months to accomplish the task, but I was lucky enough to be contacted with a person who had already been one step further. Thanks to the anonymous, at least for now, coder I was able to save a lot of time. I believe native library for Windows, Linux and OS X will be available within a few weeks from now.
Stay tuned!
April 23rd, 2008 - 04:11
Hi …
I see that you are a greate coder.
I think it’ll be nice if we have “driver” of SBS-1 or RadarBox … so that we can use a simple think like stty to dumb realtime decoded data from sbs-1/RadarBox.
With this we’ll have more way to synergy the data of multi sbs-1.
Also … we’ll easy to find embeded system to be mounted along with SBS-1 at some hills or rural area.
well .. basicly … i think it’s not wise to use windows based system to do real work of monitoring (24 hours a day , 7 days a week , 365 days a year no holiday no vacancy).
There is a lot of emebeded system that run linux for hars environtment … and capable to be combined with GPRS/Wifi/ etc etc … still it’s “embeded” not suited to run fatware like Basestation.
keep up the good work
Sincerely
-bino-
April 23rd, 2008 - 07:54
This’s exactly what I’m planning to do:) Use the Linksys NSLU2 solid state device running Linux and connect it to sbs1 + gprs/umts modem:) The driver od already working on my mac, x86 linux as well as the ARM based Linksys device I mentioned before.
piotr
April 24th, 2008 - 03:14
Do you mean that you fond how to decrypt the Xillinx encryption ??
If so , thats really wonderful
BTW .. I have no SBS-1 on hand.
I just verry sad of to much aircraft accident in indonesia.
Most of the reported as “missing from radar”
I SBS-1 is quite cheap .. in matter of safety.
But for this purpose, I think we’ll need not to use windows base monitoring system.
Keep up your good hack
regards
-bino-
April 24th, 2008 - 21:41
I’m afraid SBS-1 box is not the kind of radar you need.. Sorry, but this device was never meant for professional purposes. Regarding the algorithm, I can just say it is working. More details will be published later.
April 25th, 2008 - 03:17
Still… i’ll keep waiting for that great news
regards
-bino-
April 26th, 2008 - 19:34
I’ve been working with the bits from the hardware (using the Vodka socket tool), and after decoding quite a bit of data, it’s finally dawning on me that the output of the SBS-1 is too limiting. The radarbox sends everything to the PC, while the SBS-1 only sends a few downlink formats. When it’s all said and done you are left with pretty much the same crap you see on the Basestation Socket interface. Why reinvent the wheel?
I’m giving up on the SBS-1 and going with the radarbox…
April 26th, 2008 - 21:32
I know about vodka interface, it’s great but it requires BaseStation and this is what I don’t want. I just want to get real-time data under Linux, Mac OS X and other operating systems without using original software. I can’t compare sbs-1 with radarbox, but the AirNav’s software is so slow and heavy I wouldn’t even wanna try it.
April 28th, 2008 - 14:28
Yea, that’s a limitation with vodka, but I do like the idea of a single module that translates the USB data to a socket interface. That would be a common part to just about any OS, and then the bigger program to process the data into displays or tables. Have fun, wish you success!
Max
April 29th, 2008 - 03:14
Max,
What OS are you playing ?
for USB data to “socket” .. I read http://jetvision.de/xport.shtml and yes it’s for SBS-1 … but I think it’s still need some kind of “Virtual USB” at the BaseStation.
I’m pretty sure that what pio plan to do is more than just “remote USB”.
He plan to read and decrypt/decode sbs-1 plain usb output and dump it somewhere (i.e:console , files .. etc etc).
In unix (BSD, Linux, etc ) once a data can be dumped to console .. it’ll means it can be transported anywhere easily. i.e :
–> http://spritesmods.com/?art=gp2xgps , take a zoom in http://sprite.student.utwente.nl/~jeroen/foto/foto/gpsgp2x/img_0979.jpg
I tried this methode before, using xmpp in Ruby Language.
I pipe the “cat” out put to a ruby script that do XMPP to send it to another Jabber Client ( I use my own JabberD server)
See … a dumb people like me can duplicate the work just with looking at that screen shot. But the hardest part with SBS-1/Radarbox is that propietary encrypted usb output
Just If SBS-1/RadarBox act like GPS that keep sending output directly to it’s USB port … I think what Pio need to do is finding away to decript it. But AFAIK … SBS-1 wait for some “input” before start sending output stream cmiiw..
If He (Pio) succed in doing his evil work … all we need to do is writing Jabber Client (Bot) script that do :
1. Login on a Jabber Server
2. Joining in a chat room
3. Listening on every public msg in the room , parse as necessary , put it in an sql …
4. writing a cgi script that generating a dynamic kml .. (3D if you wish)
5. Voila …. google earth of around the world air traffic
For people with SBS-1/RadarBox on hand :
1. Listen to USB ..
2. Pipe/feed/inject it to Pio’s work
3. Reformat it’s output to XMPP .. send it via Chat room to the entiore world
I think the delay will less then 5 minutes
Pio .. I’m waiting for your “alakazam !!!” :)
regards
-bino-
April 29th, 2008 - 10:49
There is no doubt it will be done as I’m already past the decrypting (again, lots of time saved thx to an anonymous code doner).
I got the raw data and now all I gotta do is decode it according to ICAO docs. This is not difficult as it’s very well documented, there’s just a lot of coding and testing to do and this takes time.
April 29th, 2008 - 13:30
oops! Don’t click on that vodka.zip. Just go to the web site (take the vodka.zip off the end). Looks like some kind of virus there if you try to download direct, as it redirects you to some other web site.
Caution Will Robinson!
May 9th, 2008 - 05:03
Pio ..
If you did the decryption … I think we can throw the ICAO decoding job to the “Host” PC.
With this scheme you can decrease CPU consumsion of planned NSLU2.
How big is that raw data ?
regards
-bino-
May 22nd, 2008 - 20:30
Piotr,
I would be very interested in finding out about your progress. I would like to be able to retrieve and decode the USB transmissions from either the Kinetic SBS-1 or the AirNav RadarBox (directly from the hardware via the USB without running their GUI). I am in the process of ’sniffing’ the USB traffic to/from the RadarBox. But if you have a method for talking directly to the box already I would be very interested…
Thanks,
Rob
May 24th, 2008 - 01:46
The problem with the SBS-1, is that after you’re all done decoding everything, you are left with pretty much what you get off the socket of basestation. They only pass DF4,5,11,17,20,21.
On the other hand, the radar box hardware passes everything, as the bit decoding is all done in the PC.
I’d use the radar box, and junk the SBS-1.
But–I’m waiting for the second generation products though, as I’m hoping it will be cheaper. I can’t see how they justify the price of their USB designs.
May 24th, 2008 - 11:19
I absolutely agree with you, but as I said before my point is to port the software to other operating systems and to run my radar 24/7 using 5W linux device and not a 200W PC. Also, the BS seems not to be the most stable piece of software as it crashes every few days.
I agree that it would be cool to get the DF 16 and 24 but I’m trying to work with what I got. I never used the RadarBox and I have no idea about it’s data protocol etc. On monday I’ll go to the electronics lab at my university and ask if there is a chance to disassemble the firmware and remove the ‘if & else’ responsible for filtering the DF 16/24.
About the price.. Well I agree Ł380 is quite a lot, but they just don’t sell enough devices to get the price lower.. + no competition around :/
May 25th, 2008 - 16:23
That’s the great part — getting it to run on another OS! All I have is the vodka shim thing, so while it is fun to decode the bits, I don’t have any way of using that on another machine. Your’s will be much better in that regard. You might consider making a module that does the USB to UDP or TCP. That way instead of making a monolithic program, you can write smaller processes that work together. I found an old program called freesimrc on sourceforge that was abandoned in 2004. Which is good, as all I want is the display code, ha. He actually did a pretty good job on it. So far I’ve got it converted to read the socket data, but I plan on using it with the vodka shim as well. Good luck with your studies, the degree is more important than airplanes!
May 26th, 2008 - 18:43
sorry for my english.
Do you know how to decode the data’s on usb port ?
When i saw a paquet it looks like that in hexa:
10 02 07 2D 81 49 EF 4A 9A D0 18 33 95 93 10 03 BA 3E
at the begining of this message i found DLE STX (10 02) and at the end DLE ETX (10 03) plus a CRC (BA 3E), but between i never recognised an adress mode S in clear for example.
May 27th, 2008 - 12:32
The NavAir RadarBox is a bit more complicated. The box locks itself by power on and when the application program request it to unlock it will respond with:
QUESTION xxxxxxxx (where the xxxxxxxx is a hex number)
The application answer with
ANSWER xxxxxxxxx (again a hex number)
and the box goes
UNLOCKED
Seems that they are very keen not to let people interface directly to the box.
May 28th, 2008 - 06:46
I had a closer look at the RadarBox (and some other documentation) and realized that it is a very simple design. It is basically a 1090 MHz reciever with a simple audio sampler. The audio (pulses) from the reciever is sampled with a rate of 8 times the pulse time and is transferred as a string of hex characters to the software. The sample rate ensures that the pulses are detected properly and also allows for recovering colliding transmissions (more on that at a later time).
What it means is that it would make sense to write a simple sampler and decoder taking samples from the audio in port (or another source). Plug in the audio from a 1090 MHz reciever (or find the pin inside the box) and you have your Mode-S receiver.
May 28th, 2008 - 15:54
@ éric
That looks like a 112 bit message. The ModeS ID is on an uneven byte boundary, that is why you dont see it. Take a look at this site :
http://www.icao.int/icao/en/ro/apac/2005/ADSB_ADSB_TF3/SP01.pdf
That gives you an idea of how the messages look (for a 56 bit package it is control, ID, parity). The control part is 18 bits, the ID is 24 bits, and the rest is for parity. Try to take the hex code that you posted (leave out the DLE sequences) and “split” it bitwise. Then you should be able to extract the ID starting from bit 19.
May 28th, 2008 - 16:49
According to Boris it is a 56 bit message:
10 02 07 2D 81 49 EF 4A 9A D0 18 33 95 93 10 03 BA 3E
A Message type 7 is a Mode-S Short, 5 is a Mode-S Long, and type 1 is ADS-B.
I don’t know how to decrypt. That’s the job for our leader :-)
May 28th, 2008 - 16:51
oops, it took out some of my post. after the 07 there comes 4 byte counter.
May 28th, 2008 - 17:06
Well, I count too many bytes. 14 x 8 = 112. I did not know about the leading bytes/nibbels after the DLE sequence.
I would guess that the data is translated date. So it is only about counting bits and split the message into the correct segments.
May 29th, 2008 - 10:43
Is someone have some informations about CRC computing on USB output (type of CRC …)
May 30th, 2008 - 23:18
I tried several checksums and crc-16 algothms, and none come-up with that value in the example. I even tried without the packet header, 07, and the counter bytes. Wierd. But I didn’t try all the different starting values for the polynomial that is in the different standards.
That’s what I like about standards–there’s so many of them!!
June 4th, 2008 - 05:12
Well Max, it seems that you are right. It is a 56 bit message. Here is the hex of the aircraft:
4060CE
The message starts at byte number eight and the 56 bits looks like this:
01001010100110101101000000011000001100111001010110010011
The first 18 bits are the control section (transponder capabillities and stuff), the next 24 is the ICAO Hex and the last 14 bits are supposed to be parity bits (but they dont make sense to me in this message).
So sorry Max for jumping to conclusions.
June 4th, 2008 - 23:29
Chris, a few corrections. The bits actually line-up on 8 bit (byte) boundaries.
The first 5 bits are the downlink format (DF) code, but combined with the next 3 bits, make it a byte boundary.
DF11 (01011XXX) is different than DF4, and 5, in that the 24 bit ICAO address comes next, while in DF4, 5 it comes last.
On DF4, 5 the next data is a 5 bit data field, followed by a 6 bit data field, followed by a 13 bit data field. Again, this makes it run on a byte boundary.
Course, this example is encrypted, so we don’t know whether it is a DF4,5, or 11 in there. DF17, 20, and 21 are Long Messages (112 bits).
All this is available on the internet under the ICAO Annex 10 Volume IV publication.
I think Piotr probably has a handle on that!
August 17th, 2008 - 03:21
Your blog is interesting!
Keep up the good work!
January 11th, 2009 - 08:43
This discussion may now be dated, but there was some conversation about a reversing the AirNav RadarBox and it looks like Pio was working on an SBS1 application while others were working on something for the RadarBox.
I have the RadarBox and was wondering if anyone had written anything for OS-X that I could play with?
February 12th, 2009 - 02:17
I am also wondering if there is yet anything for OS-X and radar box.
Is anyone still working on the project, or done???
March 31st, 2009 - 23:39
I don’t understand. With soo many Mac users arround, especially pilots and air traffic controllers, there is a market out there!
Instead having to have work-arrounds – SBS-1 should be produced Mac compatible!
January 31st, 2010 - 10:57
>Instead having to have work-arrounds – SBS-1 should be produced Mac compatible!
A couple of times they’ve promised OSX software for the SBS-1, but never delivered.
According to their support downloads page, they’ve release a firmware update that gets rid of the data transmission delay. Since I think the delay requirement was what caused them to encrypt the control mechanism in the first place, the removal a delay require removes the need for encryption?
So they could un-encrypt, publish the interface specs and the linux/OSX worldwide community could have the software written in about 7 days (and 7 lines of PERL code).
Or should we just all go out and buy scanners that receive 1090MHz, feed the audio into the Mac’s mic port and write some software to decode from there? Makes the cost of the SBS-1 look a bit outrageous, doesn’t it?
I’ve had mine about 2 years now, sitting in the cupboard waiting for them to produce the long-promised OSX software. :^(
February 3rd, 2010 - 23:43
As much as I would like to get a well coded Mac or Linux version of ‘Basestation’ I do understand Kinetic and Airnav that they do not provide such software. The reason is very simple.. it’s all about the money and no apparent need for Mac or Linux version. Most of aviation enthusiasts use Windows anyway, so why bother? The only solution would be to use portable graphics libraries like Qt, SDL or OpenGL.
About the scanner thing, it’s not that simple and there is no way you could feed this data directly into the mic-in of your computer. Just check the ModeS specification and your sound card sampling rate + scanners are generally focused on receiving audio and not digital transmission, it’s not acars.