GSM Analyzer – Support for Aaronia RTSA / Spectran V6

Before I go into GSM Analyzer details a few words regarding the hardware. I was using various SDR devices in the last years. Started using specialized hardware named USB-RX a friend designed and also HiQ-SDR, RTL dongles etc. The most mature one was the USB-RX with up to ~12MHz IQ bandwidth, which back then was even too much for some Intel chipset/driver combos, resulting in blue screens.

And just recently I got my hands on an amazing piece of hardware – a Spectran V6 spectrum analyzer made by Aaronia, a german company that I did not know until a few weeks ago.

Hardware design and pricing

I will not do a review here – too low is my professional skill level in this domain to judge adequately. But I also cannot resist writing a bit about this piece of hardware.

Coming from the automotive industry I am quite used to companies, selling devices like bus interfaces for four-figure price labels. The design of these devices is neither visually appealing nor even functional, giving you the feel of having a prototype device, boxed in some off-the-shelf aluminium extrusion housing. They still charge you more than a monthly salary, counting in the most basic software licenses you definitely will require.

Now in contrast to the domain I professionally work in, the Spectran V6 is boxed into more like a piece of art. While you also pay between 3.5k€ up to 10k€ depending on the feature set hardware-wise, it gives a much better overall picture. When unboxing, you feel like opening the box of a flagship mobile phone with a box that magnetically locks. Printed with the company’s unicorn logo you somewhat forget that this is all about a spectrum analyzer and not a new top class mobile phone.

Small device, great unboxing experience

The housing, still aluminium extrusion is – as you’d expect from RF devices in that several k€ class – feels solid, compact and still very functional. It is quite small, comparable to a 3.5″ HDD just a bit longer, being able to easily be used in a portable setup. The front connectors (2x Rx, 1x Tx) are SMA, the rear ones (GPS, PPM, Sync and 10 MHz ref) are SMA, while the power and dual-data connectors are USB-C type. Looks it could even be used in some kind of bay with their handles, allowing to quickly plug and unplug it like a server HDD.

The Spectran V6 as 3D rendering (Source: aaronia.com)

Now the part that really caught my attention were the small LEDs on every single connector, showing the user its current state. So the both USB 3.0 ports show you green when connected/enumerated. If there was some error, the affected port is lit red. If the device was not initalized yet, white. etc. Same for all the other connectors on this device. Again – every single connector has a status LED. Damn, someone over there loves such details as much as I do.

Power port shows green (ok) and the data ports blue (transfers active).
Notice that the USB-C cables are with screw lock and labelled for allowing a clean cable management.

Don’t get me wrong, that eye candy is not mission critical and probably you sometimes wished not every device on your computer setup had an annyoing blue status LED, blinding out half your photoreceptors during nighttime. Okay, to be fair – the LEDs are dimmed with a ~30% duty cycle and if you stop the software, all of them will go dark.

But to me it is the amount of effort put in such little details, shows they take their job serious: build a solid device that not just works, but also does the best to reduce headache or incorrect usage while in rush. It not just came with cables with company logo and their intended use printed on them, but also with a tiny little brush that tries to tell you: “please keep your connectors and this device clean”. Never seen something like that before in my entire life, except for my electric shaver.

Spectrum analyzer software

From the software point of view, their RTSA Suite PRO (Realtime Spectrum Analyzer) reminded me a lot of my own projects, of which you can find some of them here in my blog. However the RTSA is commercial and no hobby project, so figure which one is order of magnitudes more professional. Especially for visualizations it has loads of different blocks you can choose from. There are also analyzer blocks that try to figure out the modulation of the signals in the visible spectrum.

Still I miss some features, I was used to from my own tools. Like a simple right- or double-clicking a signal, causing the device to tune into exactly this frequency, the ultra cool black/blue/purple/white colored waterfall gradient I use in my FFTs or some interactive/programmable way of demodulating digital signals. There were also a few crashes, leading me to a bug report form on the next software start. Good they implemented an auto-save feature which saves your work in these cases. But the devs are very active and pick up every bug report or feature request, improving the software continuously. So if you miss something just report it – they are really into it.

One of the demo missions, showing the WiFi 2.4G / Bluetooth spectrum

So RTSA Suite PRO has all the features you would expect from such software and even has blocks that e.g. live-decode WiFi signals and show you a list of WiFi devices transmitting within the visible spectrum. This revealed that I seem to have 15 ESPs in my house. At least those which are always on and not buried in some device that I have to power on. Did not expect that. Who has 15 ESPs and is not aware of that?! I should definitely try to find them all again. Physically.

The software can also be used standalone, but only with a small set of blocks being licensed. This is good enough to play a few minutes, but not (yet?) enough to just develop software around their system without having a license. Cool would be a 1-minute limited execution per session of the non-licensed blocks to prevent unintended use, but allow devs or future users to get comfortable and develop software with it.

Or what about a radical step, making it an open sourced, multiplatform GnuRadio alternative / companion, just having the very special blocks regarding drone detection etc licensed closed source? I am sure they already thought about that and if it is time for steps like these, they will do. This of course highly depends on the money you make with just the software and how much less you will make if you publish the software for free. And if you have paid 3rd party code or hardware options based on software licensing in your code as well, you do not want this to get into public. This is still a company that has to pay its emploees in the end.

RX-FFT – adding .rtsa / HTTP Stream interfaces

So having this monster of device, I felt I really had to extend my tools to be able to connect to the RTSA Suite PRO and be able to process data produced by it. There were two possible ways of interaction that I could start with. Either reading the .rtsa files that could either IQ data or spectrum data (FFTs) or connecting to the RTSA Suite using their HTTP-based interface.

I started with the .rtsa file reader, as it was the simpler of the two options.

Checking the file format, they have used a file format style I also have chosen years ago for the Magic Lantern Video file format (.mlv): Chunks/blocks with the block size and then block-specific payload. This is nothing special, being used in RIFF formats since ages. But still a very flexible and future proof design if you do it correctly.

Here you see a few blocks of a .rtsa file with a few block headers highlighted

First the file has a few blocks describing the file content type and some information about your setup, like the antenna. It seems to also support substreams, so you theoretically could save multiple streams at once. Each block starts with the same header, having the same information across all possible blocks: type, length, flags, version and headersize. Unknown (new) blocks can be skipped if your parser does not know them yet and you can skip parsing blocks you do not require for your use case.

C# is quite good in mapping managed structures to native binary data, if you know the best practices.
(well, if you don’t know, google always leads you towards the right answer)
There are still a few unknown fields, but they seem not to be used or zeroed out mostly.

After I figured out the structure of the file by writing various variants and building my own interpretation of how it should get parsed, I received the hint that there is a specification online, that however didn’t seem to perfectly match my reversing results. Nevertheless I could parse the saved file and extract the IQ stream from that file.

The next steps were to connect GSM Analyzer to the HTTP Streaming port RTSA provides. While the JSON format is nothing for IQ data streams, but fortunately there is also a float raw binary stream available. This way there is no conversion overhead. This code is available in my RXFFT / GSM Analyzer repository as well.

They also plan to improve the way of interfacing to the data streams and maybe that chunked HTTP / JSON thingie will get extended by a full binary interface or they add a local shared memory or stream based interface. We will see in the upcoming versions of the software, which also is available for Linux.

Sometimes GSM Analyzer struggles a bit of a rate offset, having to manually reduce the sampling rate to get it on track again. This is a sign that my code doesn’t properly compensate for clock drifts and alike. This might be a ToDo for later when I ehh have a bit of extra spare time… if I ever do.

But aside of that rate issue, reading .rtsa files or live of the IQ streaming mode, is both possible and works like charm. When you capture nano cells that only provide one RF channel, I wonder if the old burst plaintext guessing for kraken still works. I bet the 2B fill bytes are now randomized in SDCCHs as you would expect after all these articles about GSM being vulnerable.

So the latest release v1.1 I just uploaded has all that stuff built in and can directly connect to RTSA for decoding some GSM channel’s data right off the air. Currently there is only downlink supported, also channel hopping is not implemented.

Conclusion

It was absolute fun, adding the input interface to my GSM Analyzer and also the RX-FFT framework. I am thinking about extending it to allow full U/D channel hopping, based on system information messages. However this would require a bit more effort, especially in cleaning up internal code and remotely configuring RTSA via HTTP.

While doing this and trying to build some antennas, I also had some more ideas of things to implement. Lets see if they get that mature :)

Leave a Reply