Spis treści
Obsolete
For the most up to date information, please visit https://wfview.org/wfview-user-manual/
OLD INFORMATION
For installation directions, please see INSTALL.md in the repo.
What language is wfview coded in?
wfview is coded in c++ and makes heavy use of qt and qcustomplot. Because of the use of c++, wfview runs great on humble hardware and feels very responsive. The IDE used is QtCreator, and files for this IDE are included in the repo (the .pro file and .ui file).
How is serial port traffic handled?
Serial port traffic is handled by the comm-handler. comm-handler and rig-commander run in a separate thread instantiated by wfmain. The comm-handler listens for signals from QSerialPort to know when traffic occurs. This is why wfview feels so responsive to changes on the radio -- just try spinning the VFO knob and watch how quickly wfview reacts. There is no polling in wfview, we simply listen to the radio spitting out "broadcast" CI-V traffic and act accordingly. The pseudo terminal is also set up from the comm-handler.
Where are commands parsed?
A preliminary look at the data from the radio happens in the comm-handler. This is only to parse out the CI-V "packets" and do any necessary packet stitching. This is needed because sometimes we receive an incomplete packet. Fortunately, Icom's command dictionary has specific command start and end phrasing, so it is usually possible to figure out what we missed. The real meat of the command parsing happens in the rigcommander class. In rigcommander, the data go from to parseData to parseCommand. The former function is to further prune the data (if needed) and to parse out commands that are echos of our commands. Within parseCommand, a switch case handles the first level of command detection. From there, other functions are called depending upon the command. Ultimately, signals are emitted from the comm-handler (typically UI updates) which are handled in the wfview main class, wfmain.
How are outbound commands queued?
Outbound commands, generally started from wfmain, are added to a command queue, which is just a simple QVector of enums. The command queue is processed in runDelayedCommand. There are actually two systems inside this class. The first one should not be used as it could fall to a race condition of sorts. It's there because it hasn't been removed yet. The second system uses the QVector mentioned before and emits signals to the rigcommander about what things have been requested. The loop runs at 100ms intervals, which seems to work fine.
How does the spectrum data come out from the radio?
Unlike most commands which are sort of "call and response", the spectrum, once enabled, comes out until the radio is powered down or until a command is sent to make it stop. wfview has a button to stop the waterfall display, which you can press if you need to.
Why not just use hamlib or some other library?
I tried! But basically, every existing library I found was not designed to work asynchronously. wfview has to respond to data that it can't know to expect. We have to parse whatever comes in and act on it right away. From what I can tell, hamlib (which is excellent software by the way) listens for rig data only after it has sent a request. It can't just parse whatever is coming out from the port. This means it can't look at CI-V "broadcast" data, so we would need to periodically poll the radio (and this makes a lot of CI-V traffic that is totally unnecessary when your radio is already sending data about frequency, mode, and TX/RX status). It also means we would not be able to parse spectrum data since these data come automatically.
How can you run flrig and fldigi with wfview?
wfview makes a pseudo terminal device using the comm-handler. This happens when the program starts. The pseudo term is generally something like /dev/pts/0, but the number can change if another program is making pseudo terms. wfview always tells you the device number in the console output. (Note, wfview automatically symmlinks the psudo term to /tmp/rig on startup). Within comm-handler, it is easy to discern if incoming traffic is intended for the pseudo term device or to wfview (each packet has a TO and FROM clearly indicated). However, we cheat a little here -- all packets received get parsed into wfview, because, why not. Any packet from the pseudo terminal client gets sent to the serial port. To make this work, first configure flrig to connect to the pseudo terminal device, and then launch fldigi and tell it to use flrig for the radio interface. In practice this works pretty well except for the following issues:
- Most if not all client programs will reject device names like /dev/pts/0. Thus I have to write them into the preference files (~/.flrig/IC-7300.prefs) and be careful not to touch those
- On the Raspberry Pi, last I checked, it seemed like sometimes client programs couldn't latch to the pseudo terminal device reliably. More work to be done there. Fortunately, fldigi isn't that great on a pi...
- There is an issue where, if the client program is closed, the pseudo term remains locked or something, and new programs can't attach. If you know how to fix this, please tell me!