CI-V transceive and band decoder

[ik3umt]

I have an Arduino band decoder connected to CI-V connector of my IC-7800 listening to 7800 CI-V output in transceive mode (Log4OM CAT via serial port).
It works no more unless I disabled (commented out) transceive mode [init] paragraph on 7800 ini file.
Issue:
When I change band from Log4OM , IC7800 changes accordly, but arduino decoder doesn't follow.
If I change band from 7800 keypad or vfo knob, arduino decoder works properly following radio.
No issue with same connections using Easylog.

Suggestions please ?

[G4POP]

I have an Arduino band decoder connected to CI-V connector of my IC-7800 listening to 7800 CI-V output in transceive mode (Log4OM CAT via serial port).
It works no more unless I disabled (commented out) transceive mode [init] paragraph on 7800 ini file.
Issue:
When I change band from Log4OM , IC7800 changes accordly, but arduino decoder doesn't follow.
If I change band from 7800 keypad or vfo knob, arduino decoder works properly following radio.
No issue with same connections using Easylog.

Suggestions please ?

Ciao Fredrico,

This is one to ask Omnirig or rhe Arduino forum about as I have no knowledge of the device.

[ik3umt]

From what i've understood, Log4OM , as well as all other softwares, passes comands like "pmFreq" , "pmFreqA" , "pmFreqB" and so on , to Omnirig , then dialogue between PC and radio via serial interface is an Omnirig thing.
So, I should be able to test behavior with Omnirig client tool...

[G4POP]

From what i've understood, Log4OM , as well as all other softwares, passes comands like "pmFreq" , "pmFreqA" , "pmFreqB" and so on , to Omnirig , then dialogue between PC and radio via serial interface is an Omnirig thing.
So, I should be able to test behavior with Omnirig client tool...

Yes but you might have to open all programs to 'run as an administrator'

[nq4t]

It works no more unless I disabled (commented out) transceive mode [init] paragraph on 7800 ini file.

I dug in to this and calling this "disable transceive mode" is wrong.

Code: Select all

[INIT1]
;disable transceive mode
Command=FEFE6AE0.1A050102.00.FD

On the IC-7800; Command 1A - Subcommand 050102 sets the RS-232C function; 00 sets it to CI-V. That doesn't disable trasceive mode and forces the 9-pin 232C D-Sub connector to CI-V mode. It can also output decoded RTTY as ASCII over it.

It has no effect on the remote jack.

I won't say this isn't a funky transcieve configuration issue. But the issue isn't Log4OM and it's not OmniRig. The radios might not transcieve packets they're designed for; but if it's sending it's VFO changes on the bus then it *should* broadcast those.

A hack in the Omnirig config might be to send to radio address 00h; that's sometimes an "all hands" call.

[ik3umt]

Further investigation and results:

Easylog uses the "choose VFOx then change its operating frequency" method:

TXFrequencyVFOA=FEFE6AE007D0FDFEFE6AE005%fFD

that concatenates two Omnirig command
[pmVfoA]
Command=FEFE6AE0.07D0.FD
[pmFreq]
Command=FEFE6AE0.05.0000000000.FD

Log4OM uses the single command "change VFOx frequency" method:

[pmFreqA]
Command=FEFE6AE0.25.00.0000000000.FD

I suspect the issue is , being in "transceive mode" , the 25 00 command is recognized by 7800 (that changes frequency) then "transceived" to arduino decoder that doesn't recognize it.

In fact, with a fake

[pmFreqA]
Command=FEFE6AE0.05.0000000000.FD

Log4OM changes 7800 frequency and arduino decoder changes accordly.

Anyway there's a note on 7800 ini files:

Removed by N6TV - pmFreq command should not be used if pmFreqA and pmFreqB avail. per VE3NEA

and again:

compound CI-V commands not processed consistently per VE3NEA

The ones I'm looking for....

[ik3umt]

Question: is Omnirig command issued by Log4OM when needed (i.e. double click on cluster row produces a [pmvfoA] ), hardcoded into program or is it user-configurable ?

[G4POP]

Hard coded

[nq4t]

I will simply say this:

A lot of this stuff is pretty horrible; OmniRig, FLRig, even hamlib are pretty janky for what they're trying to do. I wrote one application that used hamlib, was pretty shocked at how poor it performed, and wound up moving the entire project to Arduino and writing my own CI-V communication library.

If it was me I'd start poking the Omnirig configs, putting the commands you want to send in place of what they do, and see what happens. Change [pmFreqA] to command 05.

When I was doing my Arduino project...I would literally just have the thing blast commands until I figured out when the radio got angry.

[ik3umt]

I will simply say this:

A lot of this stuff is pretty horrible; OmniRig, FLRig, even hamlib are pretty janky for what they're trying to do. I wrote one application that used hamlib, was pretty shocked at how poor it performed, and wound up moving the entire project to Arduino and writing my own CI-V communication library.

If it was me I'd start poking the Omnirig configs, putting the commands you want to send in place of what they do, and see what happens. Change [pmFreqA] to command 05.

When I was doing my Arduino project...I would literally just have the thing blast commands until I figured out when the radio got angry.

Yes, I think that the solution for customized features is to poking and fooling up original Omnirig commands.
just an example, with Easylog I modified rig .ini file for the simple "vfo frequency setting" to "set vfo A"-"change its frequency"-"shut SPLIT"- "shut dual-watch"
Unless radio doesn't get angry, it's ok ....