Brief summary of problem (put in title as well): Possible error in serial connection style spectrum export
Radio Model: IC-7610
Connectivity (USB/Ethernet/Wifi/Other): Ethernet
Operating System: Windows 10
wfview version (press “About”): 1.64
Checked the wfview manual (Y/N): Y
Checked the wfview FAQ (Y/N): Y
Tried to google it (Y/N/NA): Y
What I did: I am experimenting with using wfview’s TCP server to communicate CI-V traffic between my IC-7610’s LAN port and N1MM Logger+. (Other than the spectrum display, this is working as expected.) N1MM+ is configured to use the IC-7610’s CI-V spectrum output on the radio control port. Using this method N1MM+ expects spectrum data to be in multiple chunks (serial connection style), so I have set the Waterfall Format (under External Control in the Settings window) to Multi (serial) in order to be able to view spectrum data in N1MM+'s spectrum display window. (Changing this setting to Default or Single (network) results in no spectrum display in N1MM+ - no surprise.)
Expected behavior: Correct spectrum display in N1MM+, the same as the display I see when I connect N1MM+ directly to the radio’s USB port.
Observed behavior: Spectrum and waterfall traces in the N1MM+ spectrum display appear at incorrect positions in the display. The error is zero at the low-frequency (left) end of the spectrum display, and increases steadily across the display. The spectrum trace for a signal at the right end of a 30 kHz-wide display appears in the display at a frequency that is too low by about 1 kHz.The N1MM+ display is correct if I connect N1MM+ directly to the IC-7610’s USB port instead of communicating through wfview. The spectrum display in the wfview window is correct.
This looks to me suspiciously like an “off-by-one” error in wfview’s unpacking of the original single waveform data packet into the 15 separate packets used in the multi-chunk serial-style output, leading to an increasing offset error across the width of the display.
So far I have only tried this with TCP export, not with the virtual serial port interface, but if my hypothesis is correct, a similar issue might exist there as well.
This is quite possibly correct; the waterfall format option is not something that I have looked at for quite some time. I had hoped by now that N1MM+ would finally support single packet scope data, as I was never particularly happy with the way the splitting works, but I will definitely take a look at it.
Evidently N1MM+ was programmed to process the data as emitted by the IC-7610 over the serial port assuming little need for error-checking. From a reading of the CI-V manual for the radio, I can see that this data includes one packet of frequency and display mode data, 13 packets each containing 50 one-byte spectrum data points, and a final packet containing 39 spectrum data points for a total of 689 (the width in pixels of the 7610’s bandscope).
From a comparison of the wfview and N1MM+ spectrum windows, I had provisionally concluded that it looked as if wfview was splitting the 689 bytes into 13 52-byte packets plus a final 13-byte packet and sending them in full, but N1MM+ was only processing the first 50 bytes and discarding the last two bytes of each 52-byte packet. This would result in 663 bytes of actual spectrum data being displayed instead of the expected 689, which corresponds to approximately 28.9 kHz of spectrum data in a 30-kHz wide display (see attached screenshot). The missing spectrum points would be in 13 small two-byte chunks distributed across the display, which would only be visually noticeable if one of the missing chunks happened to land on a signal. Oddly enough, this happened in my screenshot - note how narrow the waterfall trace is at 28024.4 kHz in the N1MM+ display as compared with the same waterfall trace in the wfview display, corresponding to (a) missing pixel(s) at the break between the second and third packets in the split-up data.
Other than this spectrum glitch (which I have ways to work around), everything else seems to be working in this setup.
Just out of curiosity, how imminent is version 2.0 (or 1.9)?
