[Gregg, WB6YAZ]

Hi All,

I am interested in creating a module similar to the RemoteRelay module that would take DTMF commands and output CI-V sequences via a GPIO pin (or via USB).

I have looked through the RemoteRelay.tcl and ModuleRemoteRelay.tcl files and not being familiar with tcl am having a hard time deciphering how the DTMF digits are decoded.

If someone could provide a brief description of how this is accomplished, it would help get me going in the right direction.

Is tcl the right application for this task? It is unclear to me if there may be a speed limitation to sending the CI-V sequences. I believe the newer ICOM radios support 19.2 kb/s.

Thanks for any help you can provide,

-Gregg (WB6YAZ)

[Dan, KG7PAR]

Hi Greg,

The dtmf codes are decoded automatically, but you have to obey some constraints such as only using the numbers only as the other characters are all reserved.

I have a framework started that should be easily adapted to your needs.

https://github.com/Dloranger/svxlink/tree/15.99/src/svxlink/contrib_modules/

Have a look at svxlink config and txfan, svxlink config has a menu tree started and manipulates files (poorly). This module was started to add much more remote config options to the software.

Txfan is a better reference in terms of proper usage of using config files properly and monitors and writes to gpio.

Not the branch is old and dirty for svxlink, but the module is version independant.

I can help some with the module if you get stuck, i have built a few now.

As a side note, we (orp) are building a framework in the gui for loading modules. This is not ready for public release just yet, but we would love a copy of your working module to add to the repository we are planning to build.

[Dan, KG7PAR]

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

AWFUL

and that is being very generous.

[Gregg, WB6YAZ]

Hi Dan,

Thanks for all the info.

CI-V is ICOMs remote control protocol. It is a serial interface consisting of a sequence of 8bit words for control of a radios various functions.

A good description is located at: http://www.plicht.de/ekki/civ/civ-p0a.html

Is there a way within the dtmfCmdReceived method to output a number to a file or memory location that could be read by via python? It is not clear to me how tcl outputs data to files. I see in the svxlink logfile an entry every time a dtmf digit is received, but am not sure how this accomplished.

I would like to setup a number of memory locations in my IC-7100 so that the CI-V commands could be used to change the radios configuration. Each memory location storing various parameters such as frequency, mode, filter width, etc.

I currently have working a UHF repeater on Rx1/Tx1 and the IC-7100 on Rx2/Tx2 using an ICS PI REPEATER 2X board. I can control the IC-7100 remotely with ICOMs remote control software via USB on a PC, but I would like to be able to be able to perform simple memory changes via a UHF radio and DTMF.

Thanks again for your help,

-Gregg (WB6YAZ)

[Dan, KG7PAR]

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.

[Aaron, N3MBH]

Hello guys,
I would recommend looking into using something like Hamlib / Rigctrl. It supports a number of radios and can be accessed via the command line. We might be able to use the module/tcl to decode the DTMF commands and pass commands along to rigctrl to interface with the radio. The hamlib library would need installed on the Pi along with the the module, but then we don’t have to maintain or worry about the direct radio support and all the variations. No need to reinvent that wheel. It would also allow the flexibility for the module to work with a number of other radios.

As of Hamlib 3.0.1, the list of supported radios looks to be around 200+ radios.
https://github.com/Hamlib/Hamlib/wiki/Supported-Radios

73,
Aaron – N3MBH / WRFV871

OpenRepeater is offered free of charge. Find out how you can support us.

[Aaron, N3MBH]

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.

73,
Aaron – N3MBH / WRFV871

OpenRepeater is offered free of charge. Find out how you can support us.

[Gregg, WB6YAZ]

Thanks Aaron,

I looked over the Hamlib documentation and it looks very promising. I have a spare RPi 3 I can use to check it out with my IC-7100.

-Gregg (WB6YAZ)

[Aaron, N3MBH]

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.

73,
Aaron – N3MBH / WRFV871

OpenRepeater is offered free of charge. Find out how you can support us.

[Dan, KG7PAR]

okay, I have a template built that should get you started, it loaded on my pi, so it should in theory work for you once the files are loaded.

https://github.com/dloranger/MODULE_template

You will need to manually place the files, but Aaron and I can help with that once you get done checking out the hamlib stuff and are ready to start coding the module.

Let me know if you get stuck, I will do what I can to help get you going.

[Author]

Posts