As you might have realized, I use an Spectran V6 for my RF stuff and am absolutely happy with this unique device, not only because of it’s compact form factor or amazing looks. Also the software is absolutely great with a lot of decoders and visualization. At first glance, the software may seem very closed and difficult to extend using one’s own code, but it is not as closed as you might think.
JavaScript
First you could add blocks which are driven by JavaScript code and (seemingly) was primarily used to connect basic blocks like FFT, filters or demodulator blocks to process the incoming data stream. I am no friend of JS and avoid it where possible. However I was told that the JS engine within RTSA is quite efficient and it is worth being used for tinkering.
HTTP-Streaming
Then there is the recommended HTTP-streaming, I already used for my GSM-Analyzer and some other projects like rtl_433 or dump1090.
Basically, RTSA acts as an HTTP server that lets you GET a stream port. You can use well-known headers and methods to fetch the data from RTSA. While it also does not sound very “high-rate” capable, they made some tweaks to reduce the HTTP overhead and make it basically a TCP stream with some little overhed around that payload. If you do not implement a fully-featured HTTP parser, but design it in some more static way, the performance is also very usable.
External DLL
Another approach is loading an external DLL which will run in the context of the main binary. While this is probably the most performant way of tapping the I/Q data stream, I did not test it yet and have no experience if it is really as good as I expect it to be.
Finally creating the ISO15693 plugin
Recently I worked on ISO15693 (also called NFC-V) support for the flipper zero which was finally accepted (yay!).
During this journey I was intrigued how well I can decode the air signal using RTSA Suite and started using the JavaScript block. Using some productive scripts from the RTSA Suite as templates, I glued together I/Q processing JavaScript code.
While finding out how the data flow system works took a while, I was able to build the first prototype within the first ~4h of scripting. There is a lot of stuff going on with setting up the Mission and the DSPStream, so it is a good thing to start with a working template.
The script block is indeed very powerful, allowing you even to draw on a 2D canvas. But for the first steps, a simple list is enough.
The reader sends it’s requests by modulating the 13.56 MHz signal using either OOK (on-off-keying) or a ASK modulation (amplitude shift keying) with modulation index between 10% and 30%. The card responds with an overlayed modulation at ~423 kHz and some manchester coding. While I focused on the OOK variant with 100% modulation index, ASK with > 10% should also work.
Using “IQDemodulation” blocks, I resampled the I/Q input signal to a multiple of the ISO15693 bit rate for the reader’s signal. From there the OOK/ASK signal can be recovered by calculating the amplitude of the I/Q signal. The same block is used for the NFC chip signal, but feeding it’s output stream to a “IQToSpectrumConverter”, returning a FFT-8 to save processing power. Within this very narrow FFT, the modulated signal is recovered from the spectrum area which contains the 423 kHz modulation signal.
After about 3-4 more hours, I considered it stable enough to publish it in the forums.
This block causes an approximate load of 20% on my system, which is still okay and I can live with that.
Conclusion
In the end, the processing speed of the JavaScript engine was better than I thought. However, it was not designed to handle dozens of megabytes per second. Yet, for such low-rate signals, it performed better than I anticipated, and I will definitely experiment with it more.
What I absolutely loved was the playback feature during development. It allows you to continuously loop some previously recorded file while you edit the script, which will be recompiled immediately as you type.
