Now that I am at a real keyboard I can add some additional commentary about these pieces of code.

The svxlink config module creates a list of dtmf codes and associated svxlink config variables that increments the DTMF codes starting at 500 <arbitrary starting code>. In each row of the list is also a variable field that contains a 0/1/X.

This 0/1/x variable field indicates if the code is disabled, enabled, coded respectively, mostly to help me remember what I had worked on and what still needed work. I would use a 1 to say the work was done and usable (including generating the audio files), this would toggle the audio system to announce the subcommand (this read-out could get tiring to listen to if they all get done eventually) and also allow execution of the desired changes.

This is all setup at launch of svxlink and will be static until svxlink is restarted.

The work really happens in the code block starting at line 545
proc dtmfCmdReceived {cmd} {
….
}

which is essentially a massive switch structure that has a case for each possible config variable/optional function, which then calls the actual function associated with the desired task as appropriate.

The TxFan module is a daemon module that was written to drive an enable pin for a fan on/off relay to actively cool a transmitter rig/cabinet. This was written as a customer request to replicate the feature on an existing system.

The key points to look at from this module of code is 1) the proper usage of the config file and calling the variables from the config file rather than having them hard coded like they are in the svxlink config module (follow the TxFan method to do things the right way), and 2) interacting with the GPIO as a file source (input) and as a file sync (output).

If you need help, I will do what I can to help you get it working, although I have no idea what a CI-V sequence is. There may be a more graceful approach.

One additional thing to keep in mind as you get started is to never put in any type of waiting loops in the code, no Sleep, wait until, etc. These will prevent SVXLINK from running properly as the code is single threaded so the whole system comes to a stop until the task is completed.

Anything handled in human time scales should ideally be done in a separate piece of code that gets launched external to svxlink code. This also gives you more flexibility of language selection, and more importantly, intelligent debugging capability. The TCL fault reporting for code/modules in svxlink is

and that is being very generous.

I am pretty sure we can get this going without a lot of energy.

I will see if i can tear down the svxlink config reference and setup a framework for you to build against. I need to do this for ORP development as well anyways.

I have a lot of misc projects going, if you don’t hear back in a couple days, poke me as a reminder.

As Dan had mentioned, we are working on a new module framework for the next release that will facilitate development and installation of easier to install modules by end users. Still a work in progress, but looking very promising.

Yes that would be a great starting point. If you can just do a straight raspbian install on your spare Pi, get serial working and see if you can communicate with the radio via HamLib/Rigctrl…that would be a great first step and proof of concept.