I develop my software on a Linux box. Windows versions of the programs are usually done using a cross-compilation facility (mingw) on this box. I am not very familiar with Windows and personally I am not happy with Windows as development envirinment.
Nevertheless, since I am an enthousiastic user of the SDRplay devices,
and the plugin interface for plugins in SDRuno is reasonably easy, I
converted some of the decoders that were written for the sw software
to plugins for the SDRuno environment.
Plugins are there for weatherfax, FT8 psk, rtty,
navtex, cw, drm, acars and wspr plugins.
The group of plugins for cw, rtty and psk is relatively simple. The real problems with handling the kind of signals for these plugins is in accurate tuning. An offset of 20 to 30 Hz is sufficient to make decoding of e.g. psk31 signals, especially qpsk31 signals, impossible. For an amateur RTTY signal the space between mark and space is 170 Hz, so a tuning offset of even less than 100 Hz ruins decoding here.
Of course, each of the plugins has a number of switches for settings, such as filterdepth, normal or reverse encoding etc etc.
Another simple plugin is the one for decoding navtex> signals. Navtex signals are (mostlly) transmitted on 518 KHz by coastal services. The encoding of the signal is simple, a 100 baud FSK signal with a width between Mark and Space of 170 Hz. A few layers of protection and error correction ensure that only real Navtex messages are shown. Of course protection can be switched off, such that all signals (garbage or not) are "decoded".
When invoking the plugin, the SDRuno is automatically set to the frequency of 518 KHz. The plugin has some selectors to bypass some validity checks on the messages.
A more complex plugin is the weatherfax plugin. On shortwaves there is still a number of stations transmitting weather information. With my limited antenna equipment I receive stations transmitting such charts on 3588, 4610, 7880 and 8040 KHz regularly, all from this region. In other regions there are obviously other frequencies. The US National Weather Service publishes a document Worldwide marine radio facsimile Broadcast Schedule which can be found on the internet.
A weatherfax transmission starts with a tone on a given frequency (usually 450 Hz), followed by a simple black/white pattern with which the receiver can synchronize. Then, line by line the image is transmitted in either AM or FM mode. The precise parameters are detemined by the mode, the picture here was transmitted in WeFax576 mode. The transmission btw shows that there is a small clock error.
A transmission with 2 lines a second and 1200 lines takes 10 minutes, so when testing there was a need for a button with which the sync procedure could be overruled. A button on the widget (the button "cheat") - when touched - tells the software that it should behave as if a sync was detected.
Note that the picture on the computer screen is reduced in size, however, the program has the original picture "in core" and when dumping the picture, it will have the original size.
The FT8 plugin decodes - as the name suggests - FT8 messages and shows the decoded messages on the screen. If you fill in your home location (station identification or, as I do, a(n official) NLXXX number) the software - when switched on - sends data about the caller on the received messages to the PSK recorder. (the button callsign shows - when touched - a small field where the callsign can be written).
To ease tuning, the plugin is equipped with presets, where frequencies like 14075, 21075 KHz etc are listed. The plugin allows user manipulation of the preset list, so deleting and adding frequencies is supported. Contents of the list is obviously saved between invocations of the plugin.
A plugin for one of the more interesting broadcasting schemes is the plugin for decoding DRM (Digital Radio Mondiale). As mentioned elsewhere, DRM is a scheme for transmitting digital radio on short and medium waves.
The plugin shows the decoding of the the French transmission on 6175 Khz,
transmissions on this frequency started not long ago, and can be
received here fairly well.
The widget shows that the transmission is in Mode B, with spectrum occurrence 3,
telling that the transmission was 10 Khz wide, and telling what the
layout of the digital raw data frames is. DRM transmits - next to
the payload, a number of signals with which the software is - in principle -
able to decode the payload.
The widget also shows that the format in which audio was encoded was AAC,
and the bit pattern used was QAM64, with a resulting 12000 Samples/second
signal..
The transmission contained text as well, as can be seen at the bottom line.
More technical details state that the receiver was almost exactly tuned to
the transmission frequency (the 0 top left), which only a frequency offset
of 6.7 Hz), while the time was 20:47 (UTC).
The picture finally shows that all required steps for synchronization
were found OK. The FAC, Fast Access Channel, the SDR,
Service Description Channel and the AAC could all be decoded
without errors or with sufficient error correction.
If any of these synchronizations is faulty, then it is unlikely that
there is any audio output.
At the right side of the widget one sees the "constellation diagram"
of the decoded signal. The (audio of the) service) was encoded in QAM64,
telling that values in the carriers that are being decoded are assumed
to take one of 64 positions (which could be mapped on 6 bits).
The constellation diagram shows that it takes some effort to decide
on which position the different carriers are supposed to be.
One comment is in order: the plugin does not have much controls. Settings
have to be detected by the software, by interpreting the incoming signal.
The only control on the widget is one with which one of three "views"
on elements of the decoded signal can be made visible.
The three views represent the constellation of the carriers for the
FAC bits, the carriers for the SDC bits or - the default - the carriers
for the selected audio service.
Of course, the setting of the frequency was done in SDRuno itself.
Frequency correction - as said here 6 Hz - is done in software.
A recent plugin (actually, there are two versions implemented) is for decoding Acars signals, aircraft communication signals in the 130 MHz band, There is a lively (automatically generated) conversation between planes and airfields, and each and every event - such as open a door, close a latch - is signaled by the plane and transmitted. These messages are encoded, obviously augmented with plane identification and time - and encoded messages are then transmitted.
A few years back I rewrote the excellent software of Thierry Leconte in C++, in order to create support for devices like the SDRplay and - recently - derived these plugins. So, copyrights of some parts of the plugin code are Thierry's.
The left picture shows the "simple" version, the decoder decodes the signals - if any - on a single selected frequency. Acars frequencies are standardized per continent, the plugin lets you choose the continent and then shows a list of frequencies commonly used in that continent.
The picture on the right is slightly more advanced, it handles more channels simultaneously. The picture shows that signals on 131725KHz, 131525KHz and 131825KHz are being dealt with. The bandwidth selected for the SDRplay is 2 MHz, and a group of transmitters, within the width of 2 MHz can be selected. In a few cases the maximum frequency distance between transmitters is more than the 2 MHz, and then more entries for the continent are made.
The last - and most recent - plugin is the wspr plugin. Wspr signals,
whisper signals, are to be found in amateur bands.
The signals themselves are low power and occupy a very small band (app 6 Hz).
A message takes no less than app 113 seconds
and is made up from a few "tones", just app 1.5 Hz distance to each other.
Decoding is rather tough. Happily the core of a decoder consists of a few
functions, written in C (originally Fortran) that can be used in a decoder.
The core code, the code doing the hard part, is copyright
Joe taylor and Steven Franke, with minor modification by Guanael Jouchet.
The plugin is essentially a kind of front end to that code.
The plugin has selector for one of the known frequencies where wspr signals
are sent, of course, using the tools of sdrUno, it is possible to
select whatever frequency you want to use.
If - as with the ft8 plugin - you have entered a callsign and a location (mine are shown on the widget),
it is possible to upload the results to the PSKreporter site.
One thing, the transmission of messages starts (should start) at
the even minutes, so when running the plugin it will wait until an even minute
with reading in data. As said, a message takes app 114 seconds, the plugin tells
how many seconds it is reading the current message.
After reading the message it will (try) to decode it and report the results.
The plugins are all in the repository "unoPlugins-jan" in my github account.