NEW!!! The Mode-S Beast 2nd Generation: "Radarcape"

Introduction

I am totally happy to introduce the next generation hardware here, the so called Radarcape.

The idea behind the Radarcape is that there are many ideas of applications which require a high performance backend. For a while I thought that a so called "embedded core" (*1) on the FPGA itself would be the solution, but finally I found that there is a low cost Linux board, supporting add on components, the Beaglebone. This is a 700MHz ARM Cortex^TM-A8 based board, supporting Linux, Android and other operating systems. It has USB host and slave connectivity, a 10/100MBit LAN, an internal Micro-SD card, 100kSample ADC, I²C, SPI and plenty of other interfaces. It is supported by official Linux Kernel, and there are ready-to-go Linux distributions available which can simply become installed on the system. Writing software for the Beaglebone is as easy as writing software for a DOS box in Windows.
Two other outstanding facts are the price, which is in the range of a single Xport, and the small size, see the Beagebone link above.

• The Radarcape is based on the prooven technics of the Mode-S Beast, so all experience and performance can 1:1 be transfered to it. It still has one receiver on boards plus a connector for external signals.

• The FPGA is from the next generation compared to the Mode-S Beast, and offers enough resources for other modulation schemes and even internal preprocessing (*1)

• Most probable the sample rate will be 32MSample per second, twice as high as of the Mode-S Beast. There is an experimental platform foreseen for 64MSamples. Due to this the timestamp accuracy will be increased, and also weak frames can be resolved much better.

• There is a connectivity for a Trimble GPS module for timestamp and location services. GPS information will be available to the Linux system, too.

• The FPGA firmware will become downloaded from the Linux System and no longer be stored in a local flash. This makes firmware handling much easier and also allows bundling of applications with the FPGA firmware like in many professional systems.

• The Radarcape interfaces to an internal 3.3V TTL UART of the Beaglebone and no longer has USB on board, however there is a USB connectivity in the traditional way through the Beaglebone. Actually the Beaglebone already in its basic delivery configuration already provides a FTDI serial interface towards USB.

• The Beaglebone's SPI and I²C interfaces can be used in order to initalize exernal hardware,  for example in order to set external receivers to a dedicated frequency.

• The mechanical design is will allow an integration into a small box with all externals accessible.

• The total power consumption is expected to be around 5W.

Ideas For Applications

1. The most simple: Replacing the combination of Mode-S Beast and Xport and simply forwarding of all Mode-S frames to USB or a local network, even parallel or multiple pathes. Such as has already been set up using SOCAT with a Mode-S Beast and a opened Dockstar or Beagleboard.
   This means that the AVR- or binary format frames are without preprocessing transmitted on either Ethernet or USB virtual COM port. Main advantage here is that there is no longer a capacity bottleneck as it is with the Xport (due to its maximum 921600bit/sec data rate).

2. Prefiltering and compression of information that is sent to the main processor. This might be of interest when the unit is operated remotely with slow speed links, even GPRS or UMTS.
   When beeing used at remote locations or behind slow speed internet connections, it might be useful to limit the information by filters, and/or compress the data so that a minium only is beeing transmitted to the host.

3. Low cost Asterix CAT 21 decoder: Mode-S frame contents therefore are decoded and output in a CSV string..

4. Standalone Port 30003 server: Mostly the same as above

5. Standalone data gathering for sharing networks. You no longer need to run a power consuming PC in order to supply data to your favorized sharing network.

6. Data recording or event recording using the local SD card or an external mass storage connected via USB

7. Standalone use with LCD touch screen display: On top of the Beaglebone/Radarcape one can install available LCD monitors, and have a small GPS navigator size standalone unit.

8. ACARS and VDL can be demodulated/decoded with the Beaglebone's 100kSample ADC.

9. It might be an idea to connect a SDR receiver like the Funcube dongle to the USB port and use this with some SDR software in order to receive air traffic, ACARS, VDL and similar.

10. Standalone web or Google Earth server: On a development platform based on the previous product I have already seen an application which displays the sky occupation on just a web browser. So all you need for this is putting the Radarcape somewhere on the world, and you either connect to it with a web browser or download a Google Earth KMZ continuously and you keep up to date. See an early example on the right side, click on it for getting it full scale. This image was totally produced on the receiving system, and I only used Firefox in order to get the display.

11. Of course this can become expanded until the clients exchange their information internally.

12. Peer-to-peer multilateration: The Radarcape will be designed to provide timestamps as accurate as possilble and synchronized with GPS. At least three Radarcapes at decent locations will exchange their information and with simple triangulation they can localize all non-ADS-B traffic in addition to the already known aircraft.

How far is the development and when will it be available?

• With a prototype based on the current Mode-S Beast the TTL UART interface and code downloading from the Linux system have successfully been verified

• GPS timing synchronisation has been done with a modified Mode-S Beast.

• Initial steps of the Port 30003 server are working.

• The web interface for Google Earth is working on a compatible development platform.

• A moderate number of alpha phase boards are in production (as of  March 1st, 2012).

Potential Questions:

Q: Will you provide solutions of all the application ideas?
A: This is far outside my capabilities and it is left to some skilled people in the community. However, I will provide some basic services like 1) or some code libraries that will make Mode-S decoding easier. I most probably will also enforce the idea of peer-to-peer multilateration.

Q: What will be the price?
A: Good question....

Q: Will you offer ready made units in a
A: Not yet finally decided, but chances are good.

Q: When will it be available to public?
A: Well, we got very far in early testing, and actually there are only a few things that need to be clarified before a final design decision, so a long shot guess is in the 2nd half of 2012.

Q: What if I am not familiar with Linux at all?
A: It much looks as if it as easy as handling of a USB stick, since the Beaglebone comes with a Mass Storage service, so the harddisk appears on the host in the same way as a USB stick does. Copying software to it and handling it from there should be easy.

Q: How can I get one the alpha boards?
A: This can just then become decided when the first alpha boards are in my hands and tested. Anyway you need a good reason for one of the rare boards or for me to start a new production batch.

Q: Why did you select the Beaglebone and not the Raspberry Board
A: Never say never... In my opinion there is a better support for the Beagles than it is for the Raspberry, since TI pushes the Beagles quite heavily. An adaptation of the Radarcape to the Raspberry is definitly possible. Not at least I have some experience with the Beagles from other projects. Not at least the cape concept and availability are convincing factors.

Footnote

(*1): When talking about FPGA interal processing, I often use the phrase "embedded core". What is that?
You know that a FPGA is nothing than thousands of gates which are wired exactly as if you pick logic gates and flipflops out of a shelf, and wire them by software until you reach a dedicated functionality. Now it is that due to this wiring each gate and each register has its own and single functionality but with the the advantage that every function is present all the time, and not just when the CPU accesses a specific piece of code. But, some tasks can much better be handled by software, and for that puprose a CPU can be built internally in the FPGA. This means that such a CPU can nicely and broadly access any information of the decoding process without interface bottlenecks.