VE3NEA/OmniRig

Modes (dig/data/rtty)

Closed this issue · 4 comments

I'm extensively using OmniRig for rig control and logging of my Icom IC-7300 and occasionally my Yaesu FT-857d. I started looking at the OmniRig configuration and code. I've been tinkering with the Delphi example to give me a better understanding of how to use OmniRig.

Anyway, the Icom has a few different modes than what OmniRig by default supports. It has the RTTY and RTTY-R modes. Does not have the DIG_U/DIG_L modes, instead the IC-7300 has a mode modifier that can be applied to the SSB, AM and FM modes.

So I started pondering if OmniRig should support more modes and a mode modifier out of the box (i.e. not via a custom command). For example a pmRTTY, pmRTTY_R, pmDataOn, and pmDataOff. These would be new commands as to not impact and break existing programs that rely on the current OmniRig api.

I see that there was a similar idea in the Add-RTTY-&-PSK-modes branch. However, those changes seem dangerous as the current api is being modified. Support for pmDIG_U and pmDIG_L are dropped while pmRTTY and pmPSK are added.

Modes do vary quite a bit between radios. E.g.:
IC-7300: AM, FM, USB, LSB, CW, CW-R, RTTY, RTTY-R
FT-857: AM, FM, WFM, NFM, USB, LSB, CW, CWR, CW-N, DIG, PKT
FT-991: AM, AM-N, FM, FM-N, DATA-FM, C4FM, USB, LSB, CW, CW-R, RTTY-LSB, RTTY-USB, DATA-LSB, DATA-USB

What are your thoughts about supporting more modes? I wonder if there exist a history and maybe good reason not to go forward with any changes. Also is the OmniRig project still being supported and improved?

One of the main purposes of OmniRig is to provide a radio-independent interface to CAT control so that the client program does not need to know what kind of radio is connected and what specific commands that radio supports. Because of this, the methods and properties of OmniRig represent only the basic functionality common to most radios.

These methods and properties, such as Mode and SetRxFrequency(), are here only for convenience, the user still can send any command to the radio she wants using the SendCustomCommand() method. Some developers choose not to use the properties at all and just send everything as custom commands via OmniRig instead of talking directly to the COM port. This approach is based on another main advantage of OmniRig, its ability to serve multiple programs without creating any conflicts.

It follows from the above that the pmDataOn and pmDataOff commands that are available only in IC-7300 and perhaps in a few other ICOM radios should be sent as custom commands.

OmniRig is now used by several dozens of Ham programs, including my own software, and thus is alive and up to date. Its set of INI files is frequently updated, mostly due to the user contributions. New functionality is welcome but not at the expense of backward compatibility.

I got the SendCustomCommand() method to work (the HexToSafeArray() method comes straight out of the OmniRig Client source code):

OmniRig.Rig1.SendCustomCommand(HexToSafeArray('FEFE94E01A0601FD'), 13, HexToSafeArray(';'));

What I don't quite get is how to read the response. Is the only way to read responses by registering an event handler like the CustomReplyEvent in the OmniRig Client and there handle all the difference responses I might get?

procedure TForm1.CustomReplyEvent(Sender: TObject; RigNumber: Integer;
  Command, Reply: OleVariant);
begin
  if RigNumber <> 1 then Exit;

  RichEdit1.Lines.Add(Format('Reply to custom command "%s":'#13'"%s"',
    [SafeArrayToHex(Command), SafeArrayToHex(Reply)]));
end;

Thanks for your help.

You should implement an event handler for CustomReply, it will be called only when a response to your own command is received.

Thanks