[Dan, KG7PAR]

Hi Randy,

Looks like the forum move unsubscribed me from the thread.

Sounds like you have the hardware figured out but let me summarize to make sure i am on the same page as you.

You have 2 radio for full duplex, one is tx only and one is rx only (wiring forces this)

The rx radio is wired to cos pin with the cos switch set to active high. When the rx is triggered, the led closest to the front will turn on.

If configured correctly, this will cause the software to notify you via the logs of squelch open, and then the transmitter will turn on. This is the second red led you will see at the back of the board.

Upon releasing the RX, the front led will extinguish immediately, but the tx will be delayed about 4 seconds unless you have updated the delay.

[Dan, KG7PAR]

Hi Randy,

If you have ground and COS from the 6 pin connector you should be good for cabling. I suspect you need to move the COS switch on the controller board. The default setting is active low COS as all our radios are active low for testing. Looking at the operating manual for your radio, it is active high. This should get you going with the COS opening the repeater.

[Dan, KG7PAR]

Gregg, I think your approach is the best one for now. Build out some limited scope functions in TCL that are discrete and easily testable in isolation. Once you have the basics in place, we can put them into a framework where the DTMF gets involved for higher level integrations.

As you write your functions, try to include control variables that will enable abstraction to other rigs later, something like this as a prototype (note the syntax is likely wrong, and will need to be adjusted based on the RigCtl functionality):

#start with constants, these can be abstracted later when integrated
set RigType IC7100
set MemoryChannelToRecall 5

func RadioRecallMemory { $RigType $MemoryChannelToRecall } {
  switch $RigType {
    IC7100 {
       #send command to recall the memory channel $MemoryChannelToRecall
    }
  }
}

• This reply was modified 5 years, 11 months ago by Dan, KG7PAR.

[Dan, KG7PAR]

I can’t say that I have found anything useful, although I have not really looked much. I pretty much studied some existing code (Remote Relay) and counted on my script programming background to get through it on the ones I have done so far.

I have heard the nutshell series are pretty decent in general, but can’t comment from personal experience. The dummies series might be a consideration as well, depending on your background with code.

One thing I would warn you about is the use of spaces. TCL uses white spaces as code breaks, so while normally this “}{” would be okay, it will break TCL. You instead need to put the space between them like this “} {“. This took me a painful amount of time and trial/error to figure out and find in the code.

I would say keep it crude for now, get what you want working and it can always be improved later if someone else wants additional functionality, or if you come across a better reference for the TCL library for rigctl.

Functional before pretty 🙂

For executing system/console calls, you can do something like this, note that I have ignored the stderr response so it wouldn’t know if something went wrong or not, the console portion below starts at “sudo…”, exec is TCL version of making a console type call.

if {$cmd == “999”} {
# restart the service
exec -ignorestderr sudo /usr/sbin/service svxlink restart
}

[Dan, KG7PAR]

How are you interacting with the rigctl currently?

If you can use the console you could use system calls to call the commands from tcl.

[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.

[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.

[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.

[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]

Yes we do test the boards before shipping, specifically for the audio and gpio expanders functionality.

You suggestions are right Aaron, the next step is to confirm which board is bad if possible by installing on another pi and running the i2cdetect command again. This should be the last test to confirm which board is having problems

[Author]

Posts