The CCRM has always been developing in-house software for its measurements needs. Those specialized measurements are constantly changing and being renewed, so that the software behind these measurements must be readapted as well.My name is Geoffroy Hoffait. I'm the "computer man" of the CCRM. My job ranges from development to network administration to web site support, without forgetting the typical colleague help-desk. As a developer, I've been writing in LabView, C++, C#, and now Java.
Features of the CCRM's Radio Monitoring Toolkit Platform
The radio monitoring toolkit platform of CCRM looks as follows (click to enlarge):
In the screenshot, you see a spectrum of the ASTRID's TETRA channels that we receive from our 60 meter high antenna. There's also, on the right, the IQ diagram of a demodulated base station and its identification.
The purpose of the platform is to do it "all in one". In fact, we're trying combine all our radio software tools into a single application. That includes the following:
Instrument Control. All measurments are performed by external instruments. Receivers, spectrum analysers, direction finders, GPS, and so on. One main part of the platform is to communicate with those instruments with TCP/IP, USB, RS-232, GPIB, and others.
Data Displays. These include Spectrum (FFT/Waterfall), IQ Diagram, Level graphs, Multi-puspose text outputs and Maps.
Applications. Audio Scanner, where a receiver scans a list of channels and records the audio when the channel is occupied. 24/7 Spectrum Occupancy.
Remote. Spectrum occupancy measurements are run on a server. I'm currently working on a headless platform without any UI modules that can run as a service. It will have a web interface for configuration and a module manager.
License. The C.C.R.M. has a special state-independent status. We work with members that can use our Radio Monitoring Toolkit free of charge. We're also thinking about putting together a free version that could be used by the amateur radio world (and, no, our TETRA decoder won't be part of it).
Usage of the NetBeans Platform
I wrote many different applications that serve just one domain of measurement. Some are embedded in a car for radio coverage measurements. Others run on stations to help operators in their daily work. All of them were distinct software written to work with just one piece of equipment.
I needed a way to simplify development and maintenance... and be cross-platform too! The choice was obvious: I needed Java. So I started by picking NetBeans as my IDE and coding some instrument driver libraries while keeping in mind that they will be used in many future applications.
Then I found out about the NetBeans Platform : "I can use that and have just one application with many modules... instead of many applications with many libraries!".
The docking windows framework is something that I always wanted to have for my applications too.
But there is more than just the window and modules system, the NetBeans Platform has a lot to offer and I'm still discovering its capabilities.
The Modular Way: Traces and Instruments
A "Trace" is a stream of data packets. Packets are added to the trace as the data is captured from an equipement. Packets can be as simple as a frequency change information or can take more memory place like an audio packet.
Commonly used traces, such as ReceiverTrace, SpectrumTrace, AudioTrace, and IQTrace, are defined in the trace module. An instrument, when connected, creates Traces that are put into the Lookup of the Trace system. Those traces are now available for modules that define a dependency on the Trace module. They just need to add a trace listener to receive the data packets.
Each instrument driver resides in a separate module too and is registered via the "layer.xml" file. So, this creates a loose communication between the data creators (instruments) and the data consumers (applications). With this modular architechture, it's easy to add new equipments and new applications.
The Update Mechanism
The NetBeans Platform has a great update mechanism. I've set up an update center on our intranet server so all the platform users are always up-to-date.
As it is also new software and always a little 'on test', our updates are quite frequent. I found a php script here that reads NBM descriptions and creates the "update.xml" file. I can now simply drop the new NBM file into the update center NBM folder.
I also wrote an update center manager module, which scans my source files and update module versions according to the last changed source file date. This helps when working on many modules, I don't have to manually recall which source file belongs to which module and change the version accordingly. I know I can do better and automate the creation and upload of the NBM files... I'll work on this later...
Nodes and Properties
It's just great, just one standard way of seeing an object and editing its properties. No more dialog boxes. There's a node and its properties.
What we miss...
...are workspaces. The NetBeans window systems handles the layout and persists window positions and preferences. But our users, who are radio operators, can work on differents tasks. They want to have one workspace for their daily measurements, another for special mode decoding, and yet another layout when they work on some other task. Workspaces are what they've been asking for quite a long time now. And TopComponentGroups are not really that dynamic. Maybe I'll dig into the NetBeans sources to come up with something useful!