search

km4ack / K4CPO-FD-Logger

browser based logger for field day
GNU General Public License v3.0
12 stars 5 forks source link

FR: Rig control integration #3

Open xylo04 opened 4 years ago

xylo04 commented 4 years ago

In the comments of https://youtu.be/IzpBGvEF3WY, there were several requests to get flrig or similar integration in order to automatically detect and fill frequency, mode, etc. for log entries.

Lee floated the idea of using WebUSB, which was new to me and sounded like a great option. However, I did some investigation last night, and I don't think WebUSB is viable for our need in its current state. WebUSB currently requires devices to announce that they support WebUSB; specifically, section 4.1 of the draft spec requires devices to add a Platform Descriptor to the Binary Object Store response during device enumeration. This means every radio would need updated firmware with support for WebUSB. I doubt radio manufacturers are going to support that en masse.

Even if the radio manufacturers were open to adding support for WebUSB, adding a PD to the BOS requires low-level control of the USB configuration. Even the popular Arduino Uno, one of the primary motivators for WebUSB, can't be used with WebUSB because its FTDI chip doesn't expose those details to the microcontroller. So depending on how each radio implemented USB hardware, a firmware update may not even be possible.

There are other options:

  1. The server process can integrate with flrig directly. This is the simplest option, works for clients connecting to localhost and probably covers 80% of people's needs, but doesn't help clubs running a central server for several clients.
  2. An "agent" program could be made to go alongside the server. This agent would be distributed as a binary program, run on each client, would expose a Websocket server on localhost and integrate with flrig. The web client would try to connect to this agent on localhost on a hard-coded port, and if the agent was running then auto-filling frequency and mode would be available. The biggest problem here is that the agent program would have to be customized and built per-OS with all of the portability complications that entails.
N0NB commented 3 years ago

Right now Mike, W9MDB and Mikael, OH3BHX, are working on implementing a multicast server into Hamlib. This feature is slated to be introduced with Hamlib 4.3, which is probably a few months down the line and likely well after Field Day.

In the mean time there exists rigctld which is a simple TCP based daemon that receives commands and sends responses to an application.