Background

This repository is an upload of a local Git repository from an Apple XCode project that I am working on. I'm just using the tool in XCode to push it to a remote reposity. I just signed up with GitHub and don't know much about what it's doing.

I am learning Swift and SwiftUI programming on the Mac. I am trying to access the Icom IC-7610 over ethernet.

Icom has an eternet protocol for use with their RS-BA1 software, but that software is Windows only. Unlike the CI-V protocol used over USB, the details of the ethernet protocol to my knowledge have not been officially published by Icom.

I discovered two open source projects that implement this ethernet protocol: https://github.com/nonoo/kappanhang - written in the Go language https://github.com/eliggett/wfview - written in C++

In addition, I found DL2RUM's OpenWire closed source, but freely avaialable program, Without Wire. I am using this program in conjunction with DL2RUM's RumLogNG as my main amateur radio log and it works very well.

Progress

I am able to log in to the IC-7610 on the control port (UDP 50001). The LAN indicator on the radio comes on and off when I log on and off. Every once in a while, my disconnect sequence fails to disconnect, but for the most part it is working.

I am able to log into the IC-7610 on the serial port (UDP 50002) and receive CI-V data generated by the radio. I'm doing most of my testing by having the radio broadcast frequency changes and turning the tuning knob. My program correctly displays the frequency as it changes.

However, I'm having very little luck getting the radio to respond to CI-V commands from the computer. On occasion, it does respond. I have monitored the communication using Wireshark. I have also captured communication between the computer and the radio running RS-BA1, WFView and WithoutWire, all of which work. The data I am seeing from these programs and my program appear similar.

I have captured a lot of packets from these programs and my program using Wireshark. My analysis consists of capturing UDP packets and copying a Hex stream of the packet's data to a text file, then manually separating the stream into potientional fields, many of which are identified in the WFView source code. This analysis is in the RS-BA1 Analysis file in the Background Information folder. Despite the name, the file includes analysis of packets from all programs.

My understanding of the protocol so so software

(packet names are as used in the WFView code) All communication is via UDP datagrams:

• Control (port 50001)
• Serial (port 50002)
• Audio (port 50003) - I have not done anything with this yet.

Control Port (50001)

The host generates a random 32-bit ID The host sends "Are You There?" packets until the radio responds with an "I Am Here." packet including the host's ID. From the "I Am Here" packet, the host captures the radio's 32-bit ID to be used in future packets. The host sends "Are You Ready?" packets until the radio responds with an "I Am Ready." packet. The host generates a 16-bit token request The host sends a "Login packet" including the token reqest, encrypted User name and password and plaintext computer name. The radio responds with a "Login response" packet which incudes a token. The host captures the token and uses it in future packets. The host sends a Token Ack packet with the token. The radio responds with a Capabilities packet (not a token packet). At this point the LAN indicator on the radio should be on and the host and the radio are "connected." The radio also responds with a ConnInfo packet. Periodically, the radio sends a "Ping" packet. The request/response 8-bit field is 0. The computer should respond by interchanging the send and receive ID's and setting the request/response field to 1. The host should periodically send it's own "Ping" packet with a request/response field of 0. The radio should respond. After a period of no activity, the host sends and "Idle" packet. There is no response. Periodically, the radio sends it's "Idle" packets. The host does not need to respond.

Each of the packets have a sequential sequence number. If the radio receives a sequence number out of sequence it may request a retransmission of that packet. The host should retransmit that packet. It appears that the "Ping" packets need to have their own sequence separate from the sequence in the other packets.

The field starting at offset 0x2a in the token packets wasn't identified in the WFView documentation, but sometimes it contains the 6 byte MAC ID of the radio.

Peridically (every 60 seconds or so), the host sends a Token Renew packet. The radio responds with a Token renew response.

Disconnect sequence

The host sends a Token remove packet. The radio responds with a Token remove response. The host sends a Disconnect control packet. The radio stops sending and Idle packets.

Serial Port (50002)

The host generates a random 32-bit ID The host sends "Are You There?" packets until the radio responds with an "I Am Here." packet including the host's ID. From the "I Am Here" packet, the host captures the radio's 32-bit ID to be used in future packets. The host sends "Are You Ready?" packets until the radio responds with an "I Am Ready." packet. The radio responds with an "I Am Ready." packet. The host sends an OpenClose packet with an Open Request. At this point the radio will sends packets with a CI-V string (as documented in the CI-V reference guide) At this point, I would expect the radio to respond to CI-V requests. It does for WFView and RS-BA1, but not for my program. When the radio does respond to a CI-V packet, it first responds with an echo of the CI-V data sent. The CI-V data includes 8 bit ID's for the host (default 0xe0) and the radio (0x98 for IC-7610). In the echo, these fields are as sent (i.e. not interchanged), After the echo packet, the host sends another CI-V packet with the response. In the response packet, the CI-V id's are interchanged. The CI-V protocol is ask-answer. The radio will responds with the queried value or an ACK (0xfb) if no response is needed. An attempt to send a second CI-V query before the radio has responded usually results in a NAK (0xfa).

The host and radio exchange Ping and Idle packets as on the control channel.

CI-V Packet Information

The CI-V packet has a header followed by the CI-V string (ending with the CI-V's trailing 0xfd) The first 16 bytes are a "control" packet with a sequence, sendID and recvID. A CI-V packet has a command of 0xc1 in byte 0x10) Bytes 0x11 and 0x12 are the length of the CI-V datagrams Bytes 0x13 and 0x14 are another seuqence number. The radio's sequence numbers appear to be big-endian,

Disconnect

The host sends an "Open/Close" packet with a close Request. I've not identified a response from the Radio, but it should stop sending CI-V packets. The host sends a disconnect packet to stop the radio sending "Ping" and "Idle" packets.

Update 2/14/2022 💞

The radio is now responding to CI-V queries reliably. What was needed was to send a ConnInfo packet from the host.