SDR Console: TX Relay 'Chatter' Fixed

[si...@sdr-radio.com]

All,

 

I’ve added user-configurable TX Latency and PTT hang time. With values of 20ms (TX latency) and 12ms (PTT hang time) a user’s problems are now fixed.

 

Anyone who wants an update please contact me.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

[Steve Haynal]

Hi Simon,

Thanks for the update. If those values work well on some problematic networks, then I will also make them default in the next gateware.

73,

Steve

kf7o

[Chris Gerber]

Hello Simon

 

Thanks for adding Latency and PTT Hang adjustments to Console Program. It might substitute Hermeslite.py - a real great improvement for Hermes Lite 2 Windows users, as it runs smooth and stable with all digital programs connected.

 

73 Chris HB9BDM

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/127401d6bde1%248ae96090%24a0bc21b0%24%40sdr-radio.com.

[ron.ni...@gmail.com]

Before new SDR software sets these latency and hang time values, should the software first check the gateware version number?

If so, for what gateware versions will what settings be appropriate?

73,

Ron

n6ywu

[Alan Hopper]

Hi Ron,

one thing to bear in mind is these settings clash with receiver 13 vfo on the HL1 so they should not be set there. 

73 Alan M0NNB

[ron.ni...@gmail.com]

Thanks Alan,

Is there a canonical way for software to determine whether the radio is an HL2 or not?

Are there any other parameters or values that my apps should not modify if my software detects some non-HL2 rig?

Hopefully, none are dangerous, as I've already heard from one user who (successfully) used my iPad app with a non-HL2 radio.

I only have my HL2's and a Red Pitaya 288-16 for testing.

73,

Ron

n6ywu

[Alan Hopper]

Hi Ron

HL1 & 2 both have a type id of 6 in the discovery packet, I thing HL2 always has a firmware version >=40. My preference is for  features and parameters to be identified by extra fields in the discovery packet rather than relying on a single version number, this makes keep software and firmware in sync much easier, but in this case I don't thing there is an issue with sw setting the buffer stuff on older firmware.

73 Alan M0NNB

[si...@sdr-radio.com]

Hi,

 

It does seem that they fix the issue and don’t affect users without this problem. I don’t use the HL2 on TX yet – busy doing many other things.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

--

You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9925765c-6ba7-42a4-84e0-28314a251eebn%40googlegroups.com.

[si...@sdr-radio.com]

Ron,

 

For the HL2 they’ve been in the Base Memory Map for as long as I can remember, I had just used the defaults which it seems aren’t quite high enough.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of ron.ni...@gmail.com
Sent: 19 November 2020 19:24
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: SDR Console: TX Relay 'Chatter' Fixed

 

Before new SDR software sets these latency and hang time values, should the software first check the gateware version number?

["Christoph v. Wüllen"]

Well, these bits are outside the range of the original HPSDR
protocol, so these values are never changed by piHPSDR,
and I never experienced any problems with piHPSDR.

Is it possible that reducing the buffer size
(that is, the number of TX IQ samples that
are generated „in one shot“) simply does the
same job?

I shall try to drive the HL2 into problems with
piHPSDR using large buffer sizes.

And, If I remember correctly, the whole issue
only occurs when using inadequate network
connections such as WiFi, correct?

Yours,

Christoph DL1YCF.

> --
> You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/04d601d6bf0e%24dbc5f7c0%249351e740%24%40sdr-radio.com.

[si...@sdr-radio.com]

Hi,

I never had a problem when testing, but have a good network. One user with the issue has his HL2 connected directly to a port on the PC, I should probably route data out through that port only (must check that).

Simon Brown, G4ELI
https://www.sdr-radio.com

[Matthew]

Last weekend I experimented with HL2 buffer sizes and WiFi connections. I noted the following, which may or may not apply to other systems (systems being the total of; WiFi, PC, WiFI RF environment, SDR software etc.):

- I moved my laptop to a location in the house with an average WiFi signal strength. With a good 5G WiFi signal and low WiFi traffic levels, I very rarely see "relay chatter". 2.4 GHz WiFi increases the frequency of occurrence. My PTT time and latency were very similar to those in the start of this thread.

- Using applications such as WSJTX (sending audio to linHPSDR via Pulseaudio) increased the frequency of "relay chatter". These third party applications and/or Pulseaudio are doing large audio buffer dumps to linHPSDR. This leaves the PC SDR software with a decision, if the audio buffer is empty, wait or send 0's. I experimented with the "wait" option. Watching YouTube videos through Firefox whilst using linHPSDR+WSJTX increased the frequency of occurrence of "relay chatter", likely Pulseaudio doing something it believes is clever. I played around with many settings, but had to increase the linHPSDR audio buffer sizes to over 250 ms to eliminate this problem over WiFi. This size of buffer likely starts to cause problems for timing critical data modes.

- If I connect other devices to my WiFi network and have them streaming video over the WiFi I see a reasonably significant increase in "relay chatter" (suspect WiFi AP is bursting packets when high traffic is present).

I tried pihpsdr and SparkSDR (latest versions of both) and could also hear relay chatter with a frequency of occurrence correlating with my observations above.

I then decided to dynamically react to the HL2 reported buffer size. I should state that linHPSDR schedules packets to the HL2 such that a packet is sent approx every 2.7 ms. However this schedule is triggered by a packet arriving from the HL2, so if WiFi is bursting packets from the HL2 to the PC, this causes problems. I did try a timer so that if a packet from the PC to HL2 had not been scheduled for 10 ms, it should try and catch up. But such timers with a non-real time OS are observed to be (by their design) not high priority.

If the buffer was low, I would send packets to fill it up to avoid a buffer underflow. If I saw the buffer go low (or an underflow e.g. "relay chatter") more than 2 times a second, I would increase the HL2 buffer size by 1 ms. If I received a burst of packets from the HL2, I would hold off sending a burst of TX IQ packets back to avoid a buffer overflow. For my given test conditions, this reduced the frequency of occurrence significantly. However, there was still a condition that I lost patience with. WiFi packet bursting coinciding with audio buffer bursts from WSJTX still resulted in time gaps.

My overall conclusion was that for reliable connection to the HL2 with a sub-optimal WiFi system is extremely challenging and a penalty of very large size buffers must be paid. Without careful design and consideration of the many variables, dynamically responding to the HL2 buffer can create more problems than it solves. I am still undecided if I will add this code I used to my linHPSDR github page.

One might say you could figure all this out without my experiments...

73 Matthew M5EVT.

[Steve Haynal]

Hi All,

Thanks for the discussion here. Just a few comments. Yes, I think sending smaller amounts of data more frequently to the HL2 is better then sending more data in one shot with several packets if possible. From my observations, I think Quisk is the gold standard here. I still need to finish up my analysis and share results. 

The board ID and version minor number in the discover packet can be used identify a HL2. Other radios will not fill these in.

73,

Steve

kf7o

[si...@sdr-radio.com]

Steve,

 

I just send packets as per the spec., any changes or suggestions will be appreciated.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Steve Haynal
Sent: 21 November 2020 06:33
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: SDR Console: TX Relay 'Chatter' Fixed

 

Hi All,

[ron.ni...@gmail.com]

Hi Simon,

Do you schedule sending the UDP Tx packets using an OS timer, or in sync with the receive packets?

My current iOS app does both.  It starts in sync with the received UDP packets, but if the Rx packets seem MIA for more than Tx 2 time slots, it switches to using an OS timer to try to catch up to averaging a packet per 2.625 mS rate by sending 10% faster.  Then if it gets ahead of the average Rx packet rate, the code switches back to sending in sync with the received UDP packets.  Not sure if this strategy is overkill or not.

73,

Ron

n6ywu

[si...@sdr-radio.com]

Hi Ron,

 

I use the RX packets. Windows does support very high precision timers, but using this would require the Windows and HL2 clocks to be correct. It may be that this relay issue only happens in non-standard situations and/or the defaults Steve used just weren’t high enough.

 

Anyway, the user can now select what’s needed.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

--

You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/94b40616-f28c-48cd-be38-90c7983b10c9n%40googlegroups.com.

[ron.ni...@gmail.com]

Hi Simon, 

Using the HL2's Rx packets for Tx packet timing should work fine if the OS, network routers and/or WiFi access points don't perform packet reordering, aggressive packet combining, or discarding/losing UDP packets.  I currently suspect several WiFi routers I've tested are doing aggressive packet combining, perhaps doing bursty TDMA between other neighborhood traffic on the shared radio channel(s).  Hopefully, the new latency and hang time values are enough to cover a significant majority of those cases.

73,

Ron

n6ywu

[si...@sdr-radio.com]

IMO

 

UDP is the wrong option unless the FPGA has limited resources for TCP which is a more complex implementation. UDP is easier, TCP much better, UDP is clearly used here for historic reasons.

 

You can generally tame a router to avoid many UDP pitfalls but by definition UDP is unreliable. Running any SDR over a W-Fi link can cause issues, easy to overcome on receive; for transmit with critical timing the buffering has to be increased as you say.

 

Simon Brown, G4ELI

https://www.sdr-radio.com

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of ron.ni...@gmail.com
Sent: 21 November 2020 23:07
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: SDR Console: TX Relay 'Chatter' Fixed

 

Hi Simon, 

 

Using the HL2's Rx packets for Tx packet timing should work fine if the OS, network routers and/or WiFi access points don't perform packet reordering, aggressive packet combining, or discarding/losing UDP packets.  I currently suspect several WiFi routers I've tested are doing aggressive packet combining, perhaps doing bursty TDMA between other neighborhood traffic on the shared radio channel(s).  Hopefully, the new latency and hang time values are enough to cover a significant majority of those cases.

 

73,

Ron

n6ywu

[James Ahlstrom]

Hello Group,

IMHO TCP is worse, not better than UDP for the HL2 and similar software. TCP adds defragmentation, packet re-ordering and re-transmission. These add latency and have no benefit for real-time applications.

Jim

N2ADR

[DL1YCF]

I would not agree completely with Jim.

Some time ago I had problems with „sequence errors“ using a low-cost switch, and built into piHPSDR the option to use TCP (and on the other side in the RedPitaya gateware).

Sequence errors were gone, I had a stable situation.

Another advantage of TCP is when you want to connect to a radio on a „distant“ network, say, across a VPN infrastructure.
In brief, TCP is stream-oriented so the bytes always arrive in the correct order (my low-cost switch probably does store-and-forward
and changed the order of UDP packets).

Now the drawback: if something happens, a packet is lost or so, then you have retransmission and re-negotiation and things most likely break
down, while a lost UDP packet makes a small audio glitch and then you proceed.

So I would make the focus different than Jim: UDP has better recovery from errors (TCP might wait forever).
As long as all goes well, TCP has guaranteed delivery and *no* re-ordering.

But better fault tolerance is a *big* advantage.

Yours,

Christoph DL1YCF.

> --
> You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/905e7cb3-f61c-4842-a38b-cf8a1b99cb06n%40googlegroups.com.