Overview
If you have been active on QO-100 then you would by now know about the High Speed Multi Media Beacon. The beacon sends high speed data within the maximum allowed bandwidth of 2.7 kHz. I’ve previously done a post on development information as well as some tips and tricks to get it going on decoding the multimedia beacon and other transmissions. The High Speed Multimedia Modem was developed by Kurt DJ0ABR specifically for the QO-100 NB transponder and out of the box you can send images, files and even do digital voice chats. But the magic behind the multimedia beacon consists of a feature called the External Data Interface. This allows you to send specific data via the modem from external sources.
The HSModem listens on a specific UDP port for data and if it falls within a certain format then it will automatically transmit this data. On the other side you have a HSModem that which receives the signal via the satellite and sends that data out again on a websocket port. The reason the output is on a websocket port is so that you can have a html file in a browser that connects to the websocket (a browser can’t normally connect to a tcp or udp port).
HSModem interleaves the data received on the external data port with any other files that it sends such as files and images. Keep that in mind when you are transmitting your data as its kept in a transmit buffer and you don’t want to send too much data too quickly.
So what do we want to do with this? Well, the example in the original wiki talks about a Weather Station sending data to clients via the satellite. We probably don’t want everybody to fill up the transponder with data from their weather stations, but its a good example to use on how it’s all put together. I’ll discuss some more practical ideas a bit further, but for now lets go with the weather station idea.
Note: Before you attempt something like this, make sure you can receive the Multimedia Beacon on the QO-100 to test your setup. It is also advised to make sure you can do a BER Test in the HSModem to test transmitting and Receiving.
Transmit Side
The concept would look something like this:
Our external application reads data from the weather station at regular intervals and then sends it through to HSModem to be transmitted. On the other side we have some custom html file that receives the data and shows it in a manner that makes sense. How you retrieve the data from your weather station depends a lot on the type of your weather station. For the example I will be randomly generating the weather station data in our external application. The basic external application in our case is a simple python script that “collects” the weather data and sends it to HSModem over the UDP port.
The code is kept simple to demonstrate the functionality. The first part is where we “collect” the weather station data. In our case we are just giving some random numbers that make sense. The second part we format the data in a way that is expected by HSModem. HSModem has the following requirements for our data packet:
The total length of the packet must be maximum 224 bytes (the rest will be zero padded if you send less) and consist of the following fields:
| Message ID | This is a 32bit magic number that is checked first to make sure to prevent random data sent to the port. If your HSModem listens on the internet for data then you want to change this in the HSModem code and kept secret. By default the current message id is 0x7743fa9f. See my notes on concerns/recommendations further below. |
| Message Type | A Message type. This is used to differentiate the data that is sent on the output. This is a single byte between 16 and 255. 16 and under is used by the current Amsat-DL Multimedia Beacon. See my notes on concerns/recommendations further below. |
| Message Data | Your only restriction here is the length which should be max 219 bytes. |
Before you can run the above script you need to enable the External Data Interface on the HSModem GUI:
As soon as you run the python script then the HSModem will start transmitting the data on your audio output as configured. You should be able to receive the signal on the same modem. Keeping in mind that everything received as a result of sending it via the external data port will come out on the websocket port. Lets put together an html file to view this data.
Receive Side
To receive and display the weather station data we need a basic html file. This file simply connects to the HSModem websocket and it updates every time new data has been received. This is based on the qo100info.html that is currently being used for the Multimedia Beacon which is designed by Flo (DF2ET).
If you are receiving the data you are transmitting then your html page when viewed in a browser will come alive showing mini graphs as the data has been received from the satellite completing the circle.
Now, if you have played with the multimedia beacon before you will know that it sends the html file at intervals while sending the data from the external interface. You can emulate a similar setup by sending your html file directly from the GUI. It will add it to the tx buffer and send it along with the data (it will only send it once though for every time you click send).
There is another UDP port that allows you to send files and images if you want to do something more automated. I’m still playing with that and will share more in a future post.
HSModem Changes 🙁
If you have followed the above and things haven’t worked, then you probably didn’t read this section. Unfortunately there are some changes required in the code of HSModem for this to work. If you don’t want to go through all that then I have already done the changes and have a compiled executable available on github that you can use for the above. Simply replace your hsmodem.exe with the one from the repository.
If you want to compile your own then you have to do the following changes.
(1) The HSModem won’t accept your UDP message since it filters specifically on existing message types. In my example I used 0x19 as the message type. You need to add the following code to allow it to accept messages of that type.
else if (pdata[4] == 25)
{
// generic data
// generate a full payload, padded with zeros
uint8_t payload[PAYLOADLEN];
memset(payload, 0, PAYLOADLEN);
if (len > PAYLOADLEN) len = PAYLOADLEN; // just for security, will usually never happen
memcpy(payload, pdata + 4, len - 4);
printf("generic data ID: %d msglen:%d \n", pdata[4], len);
// 8 ... ExternalData
// 3 ... SingleFrame
// 1 ... repeat frame if TX currently down
modem_sendPSKData(payload, 8, 3, 1, EXT_TX);
}You need to add this in the ext_rxdata function in the extdata.cpp file.
(2) You need to do a similar change on the receiving side which will forward messages of message type 0x19 to the websocket port. Here is the code:
if (payload[0] == 25)
{
// send to websocket
ws_send(payload, PAYLOADLEN);
}You add the above snippet to the ext_modemRX function in the extdata.cpp file.
Note: you only need to do these changes if you want to compile your own version. If you don’t want to go that far then you can just download a version I have already compiled here.
If you want more information on development info to compile your own version, or to contribute changes to HSModems then have a look at a previous post I made about the QO-100 HSModem Development.
Concerns/Recommendations
As you can see, its very possible to use the data interface for some real fun data transfers. I do however have some concerns about the current implementation. First off, it won’t accept any messages if it doesn’t know about the message type. This wasn’t immediately obvious in the original documentation. I’ve added the 0x19 message type to my version for my tests and you can use that for your experiments as well. Or alternatively you will need to compile your own version. If you are planning on doing a production friendly permanent thing like beacon, then I can understand adding your own secret message id and message types, but for the rest it seems like it could be a stumble block for hams to experiment with the modem, especially if they aren’t programmers. Another suggestion would be to make the secret id configurable from the GUI. Again you just use the current one (0x7743fa9f). Since the external data interface is basically just a passthrough I would almost just stick to generic message types to be allowed, but I don’t know the full plans for the HSModem from Amsat-DL so there might be reasons for that.
I will chat to the Amsat-DL developers and make a few suggestions, but all the code is there so you can make your own changes if needed.
Practical Applications
The weather station is a very simple example, and not really the most practical since it wouldn’t really mean much to others. But there are lots of real practical applications for this. I see this particularly use for adding services to the satellite. Maybe something similar to a BBS service, or a messaging service. For radio events it could also be fun to share information during the event.
We are playing along with a radio club in Secunda and will be launching another High Altitude Balloon in February 2023. My plan is to setup something that will receive telemetry from the balloon and then transmit it to the QO-100 satellite using the HSModem for everything to follow along. One could potentially send tracking information, telemetry and even pictures.
Hope this was informative, as always if you have any ideas/comments then feel free to contact me here.
73, Tom – ZR6TG
1 thought on “QO-100 High Speed Modem and Weather Station”