maybe a small suggestion, I have found that the IC 705 can be controlled and switched on far better by remote via wfview in the network if you have NOT set up a MESH network, but rather if you need range you should go to a repeater! The latency times are also much lower then!!! Greetings Jan-Peter-DL3KVT
That’s a good suggestion. The chip inside the 705 completely lacks mesh support and can’t be upgraded to add it apparently.
Earlier this week I up graded my 705 firmware to 1.31 and now I’m able to load Wfview and the receive audio has been stable. this is on a mesh network and on a conventional network using two different computers.
Have i just been lucky?
I work at a company that makes industrial and military mesh networking equipment. Mesh networks can have really complicated behaviors, and if they’re not designed with how they actually work in mind you can have severe latency and connectivity problems. That said, I’m not clear what kind of support might be needed in a client device for mesh support. Maybe my company’s stuff (which has a proprietary design) may avoid the need for that. For extreme ranges, a point-to-point repeater may indeed perform better. Also pay attention to your antenna gain and pointing and Fresnel zones.
I will restest the mesh network details again.
Here RX works fine but TX generally gets chopped if it works at all. Now, ICOM several times have mentioned the 75 does not support a mesh network so if it works for some, it’s nice.
Maybe, they used new firmware for the TI platform but it was not mentioned. It’s on my list here.
I see that you reported here
“My internal icom conns reported:
‘the operation of IC-705 on the mesh network is not guaranteed.
Please use it on normal APs’”
Of course, it’s not “guaranteed” there either.
Depending on all kinds of factors, WiFi performance is a black art. Admittedly, meshing introduces all kinds of additional factors, including variable latency and possibly out-of-order packet delivery. If you can accomplish what you want to do without meshing, that is undoubtedly going to be more reliable. On thinking about it, being intolerant of out-of-order delivery could be considered “not supporting meshing”.
Yes I suspect that this has a lot to do with it. The Icom UDP protocol has no mechanism to rearrange out-of-order packets. If a packet is received out of sequence, it will request retransmission of any ‘missing’ packets (each packet contains an incrementing sequence number). This can cause a flood of retransmission requests which will likely result in stuttering/no audio.
the weird experience I have is rhat rx, scope etc work fine. tx audio completely fails though… interesting
I’m not aware of ANY documentation about how the audio is sent over WiFi.
There isn’t, but I wrote the code in wfview that does it