I’m just starting with IC-7100 usbport connected to RPi4 and networked to Win11 local machine, both running latest wfview .
Trying to discover what the ‘auto’ option for the repeat shift does. I thought it would select shift when in the repeater band, but it seems not… unless its me.
Also noticed a ‘feature’ that may be a local to me issue. on 145.725 FM and tuning down to 145.500 occasionally the frequency changes to 2.9 odd Mhz amd stays there until I reset. ideas ?
So far, easy set-up, no significant issues… thankyou to the developers…
73 Mike G8NXD
Thankyou, all explained.
Still getting random QSY from intended 145Mhz to erronous 2Mhz ( yes it transmits FM on 2Mhz) cannot find a reliable way to make it happen though. Running RPi4 ver. 1.61 as server for IC-7100, windows 11 as ver. 1.61 Client.
other query, why RX Latency value goes from white to red occasionally, not found it in the ‘words’ . cause for concern?
thanks. Mike
Regarding RX latency, that is showing the ‘internal’ latency of wfview (time between an audio packet arriving and it being ‘played’) there are a number of factors that can affect this but peaks in CPU activity can sometimes cause a momentary increase in RX latency. It’s nothing to worry about if the audio ‘sounds’ ok!
I’ll add the red text to the manual thank you for pointing that out.
With the random QSY, can you describe the steps and settings that precede this issue? We have not tested much on the 7100, at least not for a while anyway.
There’s so much going on with the repeater and split modes, so the more you can tell me about which checkboxes have been ticked and such, the better. I honestly got fed up with it when I was working on it and could easily have missed something.
Hi Elliot, when on 145.725 FM with - 600 repeat shift, just sitting quietly doing nothing. occasionally the rig qsy’s to 2.164188Mhz with the repeater shift and FM enabled. Waiting a few minutes, not predictable, it reverts to 145.725 and alls well. If TX is enabled while the display shows 2.164188 then it transmits there with wideband FM… nasty… never stayed transmitting to note what the frequency is, but repeat shift is there…
The PC is an HP Prodesk 600 G4, not ‘spiffing’ but adequate, also noted delay between hitting TX and enabling TX, sometimes instant, sometimes delay by 0.5 second or more…
Yes, the radio is still in the same room, through two switches and the router all in cable, no wi-fi involved - don’t ask. !!
I don’t trust unknown - to me - software so I’ve been monitoring both ends. The radio is showing, and outputting what is displayed. I have also seen jumps up to 160 Mhz area, but didn’t note the frequency. the 144Mhz to 2Mhz jump is always to the same frequency.
Can you try setting the baud rate on the radio to whatever its maximum is (also in wfview to the same baud rate), connecting, and then setting your polling time interval to a manual high value such as 250ms (settings, under User Interface)
Save Settings, as always.
It may be a serial communication error, we have seen it with older rigs sometimes.
Increasing the baud rate and decreasing the polling speed has the effect of distancing TX and RX traffic, lowering the likelihood of a collision.
I have a couple of thoughts about how we might implement collision detection in CI-V, the Icom protocol defines that if the remote end detects a collision, it will send 0xFC x 5 times to signal this has happened. If we can detect this and re-send the previous command, then that might be a solution.
The IC7100 is the newest radio that has his issue as all radios released after, use a full-duplex CI-V connection, so there is no chance of collisions with only a PC and Radio on the CI-V bus.
I’m afraid I’m no software bod. At present the RPi4 that is hosting the wfview server is also hosting wsprdaemon software reporting on wspr activity from two KiwiSDR receivers (16 frequencies) , with no errors.
BUT just entered another user with different password and now cannot access the server from local network or remote as either user.
I’ve opened ports 50001-50003 for UDP in the router
We would need to see the log from the client and/or server to be able to tell you what is happening (Press Log → Send to Termbin and post the URL received)
I have now got the polling to Manual polling at 250ms and the frequency jumps now reduced in number but still the occasional glitch. I do note that the polling time is not ‘sticky’ ie when Saved Settings, close the program and re-open it, the manual polling remains set but the period reverts to 75ms. Also I note the Frequency step is not ‘sticky’ either.
Not sure what happened to the invalid user/password problem, that is now functioning correctly.
Another interesting ‘feature’ I have found. Disconnecting from the radio does disconnect the control panel, but the audio stream continues unabated.
A nice alteration to the View Panel, if the Transmit button went red when transmitting instead of staying blue… not that important though.
Sounds like a bug for sure, I thought I had that in but I guess I missed a detail or two.
Sometimes I hear that happen, but it will usually stop in a few seconds, in my experience. Hmm.
Changing the button color is an interesting idea. You have noticed the “LED” in the bottom-right corner, right? Anyway, the blue just means the button was clicked recently – it is telling you the keyboard focus. Press tab to move the keyboard focus around.
Incidentally, Phil is experimenting with a different hardware controller for wfview, and I believe he has a red transmit light working
thank you for pointing that out.