So I will talk today about the project that I started last summer and that's TRX control
or transceiver control.
It's a, in my opinion, modern approach, client server approach about controlling amateur radio
transceivers and other hardware devices like GPIO devices, rotators for antennas, relays
and to integrate third party software systems like, for example, the DX cluster or SOTA cluster
or querying the QRZ database.
I tried some amount of my work time has gone into this project but let's start at the start.
It started actually at the SSP Field Day last summer.
We were contesting in Switzerland in our nice club station of Hotel Bravo 9 Alpha Golf.
And we had this setup where there was always one operator and one helper.
To the right you see Hotel Bravo 9 Echo Yankee Hotel, she sits here.
And she was mostly taking notes about the call signs that we heard and I was operating
the radio.
So we had during this day lots of barbecues, talks and having quite some fun.
We got ranked fourth out of seven stations.
Always was not too bad.
But that was where we had this idea that this setup was not so optimal for contesting.
And we were, normally we do search and pounce.
So you're listening to the frequencies and when you hear a station you pounce in, you
try to make the contact or the other operating mode is you're running.
So you're calling CQ, CQ, CQ, CQ, CQ until somebody replies and then you make the contact.
And what we were thinking while discussing what we are doing here is why do we run or
search and pounce?
Wouldn't it make sense to search and run or pounce?
So do it a bit different.
And that's where we had this idea.
If we had a central point where we could control the receivers then we could probably have
one station that listens to the spectrum.
And whenever it finds someone who is running, he taps on his touch screen and it will enter
this frequency and operating mode into a waiting queue.
So we have a search station that is just tuning the bands and enters heard stations into a
queue.
And then we have to run a pounce station that sees this waiting queue and can tap on a frequency
and it will tune the transceiver to this frequency and he can try to operate this station.
And of course the contest logging software in an ideal world would also be connected
to this central system, this transceiver control.
And when we have this we can also have a big display for bystanders with whom are we in
QSO, on which frequency are we operating because when we are contesting we have a camper,
a big camper and we always make this a little bit of happening so we have visitors coming
by and we talk them into what we are doing here so such a display would be nice.
So what we want to try out next time is a setup with multiple transceivers and with stations
such as listen and stations that operate.
So what we need at the very core of this system is something universal that can control our
devices and we have transceivers, we have GPIO pins to control relays, the rotors of
our antenna, we have a 20 meter mast and maybe antenna switches, maybe extensions or whatever
so in the beginning I wanted this to be as universal as possible.
So we have at the core something that is called TRXD, D for Demon and the number 8 that's
the manual page where it's documented in Linux and we have various clients to the bottom
that could be PCs, that could be whatever, that could be a mobile phone with an application
with an app on it and we have the hardware, the relays, we have GPIOs, we have the antenna
rotors and of course we have the transceivers.
So the basic idea was to have a clearing house for controlling all these devices in a common
language and most modern transceivers can be controlled by software but Jaisu uses his
own system, Kenwood uses a different system and of course ICOM has another system too
so you cannot use one system to control them all, you have to write something.
So what we do here, this is a more schematic diagram, we want to have this demon that can
be connected over TCP IP and then we can talk to this demon and instruct him in a common
language what we want to do with that and that receiver and these commands shall be
uniform for each transceiver so it is one of the jobs of the TRX control system to convert
those common commands into the device specific commands needed for example to operate a
Jaisu transceiver and we thought it would be nice if we could also connect to this system
using web sockets that makes it super easy to contact it from JavaScript or from Flutter
or from any other language system so basically playing sockets and web sockets and what you
see on this diagram you see what TRX control is not, it is not a software with a user
interface like Hamlet Delix or something like this, it is really meant as being the controlling
part of or at the center of your Shack automation and not a client to operate the radios so the
clients are not part of TRX control besides a few example clients. So TRXD accepts really
requests from the clients and controls the devices and the interesting part or one interesting
aspect changes in the operating system are detected and are sent to the clients if they
wish so they can subscribe to events and then they will receive frequency changes or new DX
cluster spots or whatever and we can do this for transceivers that are by themselves capable
of sending status updates but we can also do it for all the transceivers that cannot do it like
the YAESU FT817 by means of polling. So this really works nice with all the transceivers I have.
So what are the goals? The main goal was to create something that is modular and extensible
that is more of a solid framework than a complete program but something that can be easily extended
by yourself. So it should be easy and it is easy to add new classes of devices like one day I
decided to add GPIOs that was relatively easy and it should be very simple to add new drivers for
new transceivers. Of course I don't own all the transceivers that are around there but if
somebody has a certain transceiver it should be easy for him to add a driver for this transceiver.
The system is designed to be extensible from the ground up and it has a complete documentation.
So unlike other systems TRX control doesn't need a recompilation of the whole system if you add a
new driver. That's because you see it on the right it has this big Lua logo so at the heart of TRX
control is a lot of Lua which is a easy to learn and yet very powerful programming language.
So that's what it is. An open software design that's extensible and that uses accepted standards
like the web sockets like TCP IP IPv6 and programming like that are proven like Lua.
So the core is written in C of TRX control and I didn't want to just use C for everything.
So and I already integrated a lot of languages into C code in the past and I had a variety of
choices which language to use. So I looked at Tickle, Pearl, Python, Java and so on and we had
experience with all these languages but we looked carefully at which language to use from this choice
and we came to Lua for very good reasons. Lua virtual machine is very very small.
It's like 128 kilobytes of binary code and one Lua state uses approximately 64 kilobytes of memory.
So even if you're writing a system that runs many many many Lua virtual machines in parallel
it will not eat up a lot of money. Memory and if it doesn't need too much memory it doesn't
need too much money for the computer and it can run on a Raspberry Pi. So writing those new drivers
is done in an easy to master scripting language named Lua and as of today it supports, it's not
complete this list, it's favor, more transceivers, it supports more YASL transceivers. I didn't update
the list and ICOM and it supports, it will support the QDX from QRP Labs
and probably Kenwood transceivers because they use the same protocol as the QDX does.
So we're constantly working on adding new drivers. I had some American guy who added
driver for some Rix and this is now very easy because these drivers written in Lua, they mostly
describe these days what are the operating modes, what is the frequency range of the transceiver,
what's the name of the transceiver and the protocol being used for YASL or for ICOM is factored out.
So you describe your transceiver and probably that's all you have to do. If it's a new kind of
transceiver then you have to write the protocol converter too. But this is technical and you can
go have a look at GitHub, there's the code, it's all open source under the MIT license
and we're here to help if you get stuck writing a new driver.
So what about audio? Would it be nice if I could transport the audio as well so that maybe on my
mobile device I can select my transceiver and then listen to the audio and remote control it.
This is actually at the moment not part of the software but I think for audio processing we can
use Pipewire on Linux and for the streaming maybe Pulse Audio. So I put a question mark there,
I'm not so familiar with Pulse Audio but I think this could be a way and this will be some
experimentation to be done in the next months. So that's what it is. It's a system to control
your devices in a uniform language and maybe let's look at a few implementation details so how it's
roughly done. It uses a multi-threaded approach so if there's a lot of things to do it will use
all the CPU cores and it has asynchronous execution that means it can do a lot of things in parallel,
it supports for the connection-wise IPv4 and more important IPv6 and of course TLS,
transport layer security. The core is written in C because writing multi-threaded code correctly
is not so easy as one might think. There's a lot of synchronization issues that could arise if you
do it wrong so all the thread control and synchronization logic and everything and firing up of the
Lua virtual machines and firing up of the various threads that comprise the whole system that's
written in C and you can connect over IP and web sockets, I already mentioned that and the protocol
is JSON based, JavaScript object notation so all you have to do is to compose a JSON message with
a request for example set frequency to 14285000 hertz and send it to TRX control and route it to
the transceiver you want. It has been developed for Linux and on Linux but it can be used funny
enough on Windows 2 using Windows services for Linux which means it runs on Linux and of course
it can be dockerized containerized, it can run in a docker container so you can run it basically
on any system you want. It's developed in the open on GitHub and as I mentioned it's under the MIT license.
So how does it look when you connect to the system? We have TRX-D which when everything is set up it
will listen to connections from a client and when a client connects it will start a thread that's a
socket handler that will communicate with the client and whenever it receives a message from the client
it will send it to a dispatcher, this patcher looks where he has to route this message to, he will
send it to a device controller for a hardware device which will talk to a driver, the blue part
that's written in Lua and this driver will talk to the device to do whatever is required. It can also
talk to extensions, I have written several extensions for example to query the QRZ database or to
see cluster spots in real time so the idea is I see a cluster spot I can tap on this entry on
touch screen it will tune my transceiver to this you can look up the call sign so on
and then eventually the driver gives back a response in a device specific format which will
convert it by the driver to an internal format and the dispatcher will finally send back to the
client reply also in JSON format so all you have to understand in a client is JSON and the drivers
will convert these uniform requests to the format that the transceiver uses like cut for Yezu or
Kenwood or CIV for ICOM and the same thing is done with the return value they are converted from
the device specific format into a generalized format and send back as JSON replies for example
frequency in this system is always in hertz no matter what the transceiver uses many use like
10 hertz steps but here a frequency is always in hertz it looks very similar in the web socket case
when you listen for web socket connections there will be a web socket listener thread and when a
client connects for example a browser with JavaScript then it will set up the almost the same
the same scenario as it does for plain IP sockets it's just a little bit different the handling
of web sockets they have underlying protocol and the framing protocol so they can detect when the
other side goes out of business and they can automatically reconnect but otherwise it's the
very same and each of these boxes they stand for a thread as I said it's multi-threaded so these
things they all run in parallel it's not a this is not a sequence first it takes this then it calls
a subroutine then it calls another subroutine but this is all in parallel on the machine
so the hard part was to get the synchronization right
yeah this is a these are few implementation details when you're
want to dig deeper or see what it is there is a website of course the website has flyers we also
have flyers at the amateur radio booth and of course there's github with lots of information
and the complete source code of course I'm looking for people to support the project
I'd be happy if Linux uses tested there's now ready made binary packages for almost any distribution
that you can very easily install software to the developer could write drivers or new clients or
extensions manufacturers dealers importers they could provide us with hardware they actually
already did I got my icon this way and material support or whatever can always be helpful or
buy us coffee and so far we've been supported by my company which
shelled out a lot of working time and vice equipment and lixnet they supported us with the icon so
this is how we developed we have a of course everything in git we develop on alma linux
and when we push we push to github but not only we push to an internal git lab server as well to
have a continuous integration and deployment pipeline so that we build the packages for all
various linux distributions you find all that matters on torx-control.msys.ch
there's a matrix room and there is a github project obviously and
that's at the end of my presentation but that's not the end of what I wanted to say
because I need to synchronize the screens
during the development I got in contact with silver's area and during the last I think
months I can say not weeks it's months already we just discussed a lot about various things
SDR and he's obviously an SDR expert and with marcos too and so I learned a lot about
software defined radio and doing this together with marcos and with sylvan so
made me think about what could we do with SDR in terms of TRX control and there is a wiki on
github where I put together the ideas what we could do so that in the future
TRX control could also be an SDR system so this is where everything comes together
so we need a few more threads if you're probably not as easy as it is listed here but
one thread to gather the samples then each receiver will be a thread and then
we could probably even attach whisper to a decoded audio signal to get the transcript of what's
being said there in text so this is the future as you see I have plans with it and this
means that's it thank you very much