TX methode

[Art]

Hello Group and Steve.

I still understood all the improvements of the gateway version 7 compared to version 6. And these are good and necessary improvements. At first, I didn't understand why I was having problems with the version 7 gateway. But then, after doing tests, I figured it out.

I am using OpenVPN from various locations. And my hobby colleagues also use this technology to work remotely through my workplace.

I have done quite a few tests with VPN technology to remotely manage Hermes Lite. And as I already wrote, it works quite well if you approach this issue correctly. But I still could not solve the problem of working through VPN with the 7 version of the gateway. I have done a lot of tests flashing gateware 6 and gateware 7 one at a time. My hobby colleague took part in these tests. We have different Internet providers, but we live in the same city. The ping between our networks is 20-25 ms. These are good indicators. But the unpredictability of packet loss does not allow it to work normally with my transceiver on version 7 of the gateway (sometimes the relay clicks - the transmission is turned off). On the 6th version of the gateway there are no problems - it controls my transceiver in FT8 and SSB modes. Even with high jitter, Hermes Light works quite well. And I want to give an example of online radio, which also uses the UDP protocol. And if out of 1 second 100 ms are lost, no one will hear it on the air.

Tx_buffer_latency parameter greater than 20 - 40 ms is very negative for Quisk and SDR Console programs. When switching to receive, the operator hears his own voice for some time in SSB mode. But even with maximum buffers and PTT_hang = 31 ms, the unpredictability of packet loss sometimes puts the transceiver in receive mode for a while. And the main problem is the transmission is cut off.

I have real experience of working through VPN and I can confidently say that I successfully use this technology for remote work.

Of course, it's up to you to decide, but I would really like to see the 7th version of the gateway with a method for switching to receive mode from the SDR software. So that the user can optionally choose what to use - a new method or an old one.

The 7th version of the gateway with TX-RX mode from the software will solve 2 problems:

1. This will allow the gateway to be used over VPN networks with unnormal packet loss.

2. Allows to use in low quality networks.

I really hope that you understood me correctly. I've spent a huge amount of time testing. I can confidently say that such an option is very much needed.

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

Packet jitter effects on receive are probably better handled in the SDR receiver software, rather than adding complexity to the gateware.  Just IMHO.

73,

Ron

n6ywu

[Steve Haynal]

Hi Art,

I think what you are asking for is a mode where the HL2 stays in TX until the TX flag from software is cleared, or at least a long time has elapsed. This should be possible. I will have to think about how to do it easily. Feel free to experiment with your own changes to the RTL and let me know if anything works well for you.

Note that this will just replace a relay chatter with a lapse in TX audio. Both are fatal errors in my opinion, but if you say a 100ms loss of audio is preferable to a relay change, then we can try to support both failure modes.

I am not familiar with the problem you describe when tx_buffer_latency is greater than 20-40ms. Can you post a recording or video?

73,

Steve

kf7o

On Friday, April 16, 2021 at 11:39:09 PM UTC-7 Art wrote:

[Art]

Hi, Steve.

 You understood me correctly about the bounce of the relay. The fact is that the bounce of the relay "shakes the arrow in the antenna indicator" and part of the transmission is lost. This is clearly audible on the SSB signal and FT8 stops being decoded. But when there is no relay bounce, the signal is perfectly understood in SSB and decoded in FT8 even with some UDP packet loss. I have already cited online radio as an example.

At least the old method TX-RX will solve the problem of working through OpenVPN and in networks with unknown jitter.

P.S. I will record a video about the tx_buffer soon.

понедельник, 19 апреля 2021 г. в 07:36:25 UTC+3, softerh...@gmail.com:

[Steve Haynal]

Hi Art,

I would not describe this as solving any problem, but rather replacing one problem (relay clicks) with another (gaps in TX signal). With my experience, loss of TX audio was occurring for me during FT-8 with some degradation in receive by the operator on the other end, but I did not fully understand the problem until the newer gateware. Once I heard the relay clicks, I new there was trouble feeding the HL2 data during TX and could solve that problem. This mode selection would just allow someone to pick their preferred poison.

73,

Steve

kf7o

[Art]

I understand that very well, Steve. But there is real experience that with a ping of 20-25 ms and different ISPs, the old method allows you to work without problems, and the new method does not work, no matter what I do. I think this is due to the fact that, for example, if after 51 ms (eg tx_buffer_latency = 20 ms, ptt_hang = 31 ms) packets arrive immediately, but the relay needs to switch for a while.

In any case, with my colleague, such an experiment has already been carried out with different gateways. He has a very wide experience of working on the air, he has been dealing with SDR technologies since 2008.

There are no problems if the transceiver is near me and there is a high-quality network. This is a good option and the right option that will suit most HL2 users. But please do not forget about those users who work like me, controlling their transceiver remotely.

понедельник, 19 апреля 2021 г. в 08:13:48 UTC+3, softerh...@gmail.com:

[Art]

Maybe this is not very important, but on the 7th version of the gateway (when switching to the receive mode) with the values tx_buffer_latency = 60 ms and ptt_hang = 31 ms there is a very unpleasant pop. These are the remnants of voice samples, I guess. Sometimes this kind of clap will disturb the operator. In any case, this is not the main problem that worries. Just for information ...

P.S. the values in the 7th gateway was changed from via the Python module, the gateway 6.4 was downloaded from GitHub and flashed via Ethernet.

понедельник, 19 апреля 2021 г. в 08:33:03 UTC+3, Art:

[Steve Haynal]

Hi Art,

Thanks for the videos. When I try, I can hear a short blip when I have the latency set to 60ms, but it is not nearly as bad as your video and does not make any mark on the waterfall. Also, I do not hear it in full duplex, which I usually use. Quisk 4.1.54 is more than a year old. Do you see this problem with the latest Quisk 4.1.80? Do you see it when you enable FDX? The newer Quisk allows you to set TX buffer latency and PTT hang directly from Quisk. Jim did some work this last year to make sure Quisk supported the latest HL2 changes. 

Finally, why are you running your LNA gain at 0 db? I typically recommend between +12 and + 20dB. I guess you only need enough gain to see signals rise above the noise floor, but that is usually more than 0dB.

73,

Steve

kf7o

[Art]

Hi Steve.

 I don’t use Quisk. This video was recorded by my hobby colleague. He very rarely uses Quisk, so all sorts of nuances are possible. LNA is really set to 0 dB, which is not correct. I think there are no problems with Quisk software, and for me this is not relevant. I think your comment on this is enough for a complete picture of what is happening. I have nothing to add. The question is closed for me.

вторник, 20 апреля 2021 г. в 08:17:42 UTC+3, softerh...@gmail.com:

[Art]

And according to the old version of Quisk, when I tried to install a new version and versions higher than 4.1.54 did not start in Windows 10 x64, so now I use such commands. Considering that I only use Quisk for an antenna analyzer, that's enough for me. I did not bother to figure out why new versions do not start. The program window just flashes and closes.

cd c:\python27\scripts

pip install --upgrade pip 

pip install --upgrade setuptools 

pip install wxPython==4.0.7.post2 

pip install --upgrade pyserial 

pip install quisk==4.1.54

вторник, 20 апреля 2021 г. в 08:34:42 UTC+3, Art:

[Roger David Powers]

Suggest you check that Python is version 3.8.x not 3.9.x.

Ref:  https://james.ahlstrom.name/quisk/docs.html

Regards,

RDP

--
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/243532a9-5955-4e84-afcd-cc66a17c95fen%40googlegroups.com

.

[Steve Haynal]

Hi Art,

Which software do you usually use? PowerSDR? Do you see this problem with the latest PowerSDR maintained by Reid?

73,

Steve

kf7o

[Art]

Hi Steve. 

Yes, I am using PowerSDR.

If from the default values I change the parameters tx_buffer_latency = 60 ms and ptt_hang = 31 ms - then there is such a clap in PowerSDR. But after rebooting HL2 on power supply (OFF-ON), this effect disappears and does not appear anymore.

I still try to use the 6th version, only occasionally flashing the 7th version of the gateway for the test. If the 7th version of the gateway with the TX flag appears from the software, I will switch to it completely.

среда, 21 апреля 2021 г. в 08:09:19 UTC+3, softerh...@gmail.com:

[Steve Haynal]

Hi Art,

I implemented the change we discussed. When entering the error state of no data in the TX buffer, the HL2 will stay in TX mode until the watchdog time expires (several seconds) or arriving packets indicate a switch to RX. Please test this gateware and let me know if it does what you would like.

https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/testing/20210509_73p0

73,

Steve

kf7o

[Art]

Hi Steve. Thank you. I have installed a new gateway and so far I have not noticed any problems. Everything works as it should. I will observe and, if necessary, I will give more detailed information later.

понедельник, 10 мая 2021 г. в 08:06:10 UTC+3, softerh...@gmail.com:

[Art]

Hi Steve.

I'll try to explain the situation - the remote operator is located in my city. The connection between our providers is very good.

The selected frequency for the test is 14 MHz. A tone signal lasting from a minute to several minutes was turned on from the PowerSDR and Quisk software.

Gateway version 6.6 - very rarely, once or twice a minute there is a break in the tone signal. The rest of the time, a very clear tone. It is very good.

Gateway version 7.3 - tone drops are much more frequent. Almost every few seconds. I tried changing the TX buffer from 10 to 100 ms - it doesn't help.

Yes, the relay no longer clicks. If at this moment in time the relay would click, it would further aggravate the situation.

That is why I said that in FT8 you can safely work on version 6 of the gateway.

Gateway version 7.3 works fine on the local network.

The video shows signal reception with the gateway version 7.3

вторник, 11 мая 2021 г. в 04:41:36 UTC+3, Art:

[Art]

Gateware 7.3, TX freq. = 14 MHz

https://drive.google.com/file/d/1CYmB_eTOxPvCuY3pIw91f0AoJAajOj0f/view?usp=sharing

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

When comparing different versions of gateware, are the MAC addresses, IP addresses, ping latency variations (max and standard deviation over a long run), sample rates, and number of receivers all the same?  I've only seen HL2 Tx cut-out issues (and relay chatter) when the network ping latency variation changes to a much larger value.

73,

Ron

n6ywu

[Art]

The tests were carried out at the same time without time delays. The gateways were installed in turn. The software didn't even shut down during the tests. Of course, all the settings were the same. The ping did not change. The tests were carried out several times in a circle:

-6.6 gateware

-7.3 gateware

-6.6 gateware

-7.3 gateware

etc.

Ping was always constant - 25ms

вторник, 11 мая 2021 г. в 19:22:36 UTC+3, ron.ni...@gmail.com:

[Steve Haynal]

Hi Art,

When you say the tone drops more with 7.3, are the drops shorter? I want to understand if 7.3 has similar total dropped time, but just spread out over several drops. For example, does 7.3 drop 10 times, but only for 1ms each time, versus 6.6 dropping one time but for 10ms?

Also, which software are you using and how are you setting the TX buffer latency? I am surprised that you see no effect when changing the TX buffer latency. There was a bug in PowerSDR which kept setting the TX buffer latency to zero. If you are using PowerSDR, can you try the latest HL2 version from Reid? If you are setting the TX buffer latency via hermeslite.py, can you set it after PowerSDR starts?

73,

Steve

kf7o

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

A ping latency of 25 mS seems rather long, as HL2 transmit requires sending a UDP packet every 2.6 mS to maintain a constant transmit buffer level.  When doing a long sequence of ping testing, do any pings time out?

- Ron (n6ywu)

On Tuesday, May 11, 2021 at 9:50:14 AM UTC-7 Art wrote:

[Art]

Hi Steve, Ron and the Group.

Yes. In the last test, the PowerSDR 3.4.9 program was used. Today we conducted one more test with the PowerSDR 3.5.0 program. No cardinal differences were noticed. With default buffers in the PowerSDR program, the behavior of the gateways is the same as I described in previous messages. When I increase the TX buffer in the program or through hermeslite.py, it may melt a little better on gateway 7.3, but there are still no cardinal improvements. Moreover, when the buffer increases, a pop appears in the headphones when switching from the TX-RX mode.

By ear - the drop in tone on the gateway 6.6 is brighter in sound.

And I think your assumption about 10ms and 1ms is correct.

We also measured the ping today between networks. It was 20-22 ms.

I still think this is due to a slightly modified algorithm for working with the TX buffer in the 7th version gateway.

If we take real practice, then the gateway of the 6th version certainly works fine in my case through OpenVPN.

I’ll watch and run tests. So far, this is a preliminary result.

вторник, 11 мая 2021 г. в 21:48:39 UTC+3, ron.ni...@gmail.com:

[Art]

I may be wrong, but in my opinion in the 6th version of the gateway the default values are TX_buffer = 10 ms and PTT_hang = 4ms, in the 7th version of the gateway TX_buffer = 20 ms and PTT_hang = 12 ms.

If you take these gateways like this and install them without any additional settings, then the 6th gateway is much better for OpenVPN, even despite the smaller buffer. It does not make much sense to set the TX buffer for more than 20 ms, since an unpleasant pop appears for the operator when switching to the receive mode.

среда, 12 мая 2021 г. в 19:23:51 UTC+3, Art:

[Steve Haynal]

Hi Art,

If you ignore the pop, do you see improvement at TX buffer latency setting of 40 to 60 ms?

The HL2 is always full duplex, even if software is set for that, and the pop is from delayed TX data heard at the beginning of RX. You may not notice the pop so much if you set software for full duplex. Also, there is a LNA setting for TX. You might try lowering that. I'll also see about blocking RX data in the gateware until all TX data is sent, at least if not in full duplex mode.

Since your radio is on OpenVPN, can you share access with me temporarily? I'd like to run the debug gateware and collect the waveforms:

https://groups.google.com/g/hermes-lite/c/91uSCsAmQp4/m/Q2vgfnLpAwAJ

73,

Steve

kf7o

[Art]

Hi Steve.

Yes, there are improvements with a TX buffer of 40-60 ms. You understood correctly.

You can easily connect to my transceiver via OpenVPN. I am in Eastern Europe and the ping between us will not be small. But in any case, there will be a connection.

I sent the connection data to you by email.

четверг, 13 мая 2021 г. в 06:09:00 UTC+3, softerh...@gmail.com:

[Steve Haynal]

Hi Art,

Thanks for making your OpenVPN HL2 available to me. The variety of stations heard at your QTH is very interesting to me. All of them would be good DX from my QTH!

I measured ping latency and jitter with "sudo ping -f -i 0 -c 1000 10.10.0.180" several different (days apart) times. The results were pretty consistent. Note that on my end I have a consumer 50Mbs up/down internet connection.

1000 packets transmitted, 1000 received, 0% packet loss, time 11691ms

rtt min/avg/max/mdev = 219.153/220.268/230.535/0.711 ms, pipe 21, ipg/ewma 11.702/220.443 ms

rtt min/avg/max/mdev = 219.165/220.263/228.872/0.602 ms, pipe 20, ipg/ewma 11.547/220.257 ms

rtt min/avg/max/mdev = 219.234/220.270/230.330/0.634 ms, pipe 21, ipg/ewma 12.075/220.168 ms

rtt min/avg/max/mdev = 219.316/220.257/230.110/0.565 ms, pipe 20, ipg/ewma 11.837/220.295 ms

You can see that the typical latency is about 220ms and the largest jitter is about 12ms. The jitter is what matters and indicates that I need a TX buffer latency setting of at least 12ms. 

I enabled the debug gateware and captured data when transmitting with Quisk. I did not see the audio drops you report. The data was very much like this post:

https://groups.google.com/g/hermes-lite/c/91uSCsAmQp4

Except the worst dips in buffer fullness were ~11ms instead of the ~4 ms seen on my local network.

I did not get PowerSDR on Windows working with the VPN connection so did not directly test that, but I think the results will be similar to this post:

https://groups.google.com/g/hermes-lite/c/91uSCsAmQp4/m/ljOKo1FABAAJ

but require an extra 7 or 8 ms of buffer data to handle the jitter in the VPN connection.

So, again I could not replicate your problem. Maybe the path from my QTH to your radio has less jitter than what you see from your home to the radio. If you like, we can schedule a time when you are operating the radio and I can collect some debug data of your use. This is possible since the debug uses a different port.

I reviewed gateware 66, which you say works better for you. That old version of gateware has the same TX buffer size. It also had no notion of TX buffer latency and instead simply tried to keep the TX buffer half full, or ~42ms of latency. The newer gateware allows you to precisely set this. The old gateware also did not attempt to transmit all data that was received in transmit packets. Instead, once it received a message from the host to exit TX and enter RX, it simply flushed any remaining data in the TX buffer. The newer gateware does transmit all IQ values which were in TX packets. This is important for word level correctness, especially with full duplex. But it may be that this is causing the pop you hear when setting the buffer to 40ms or 60ms. Software can be tuned to avoid this pop.

I released a "crippled" testing gateware here:

https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/testing/20210516_73p1

This gateware enters a special mode when PTT hang time is set to 31ms. First, when entering the error state of an empty TX buffer, it stays in TX mode until told to go to RX by the software or the watchdog times out. This is essentially a very long PTT hang time. It is meant to replace relay clicks with dead time in TX audio. Second when told by software to change from TX to RX, it does so immediately and discards data sent by software which should be transmitted. This mimics the poor behavior of the 66 gateware and may avoid the pops you hear. Please test again with this new gateware and TX buffer latency set to 42ms (same as 66 gateware) and PTT hang set to 31ms (mimic 66 gateware).

73,

Steve

kf7o

[Art]

Hi Steve and the Group.

I checked out the new test gateware. When TX _buffer = 42 ms and PTT_hang = 31 ms, the transceiver starts to hang up for transmission, from which you can exit only after turning off the program. Usually it turns on several times, and then freezes.

I liked the idea with 31 ms. It will be very good.

I also checked the test gateway with the parameters: TX_buffer = 42 ms and PTT_hang = 30 ms. Yes, there is pop.

Then I loaded gateway 6.6 again - there was no pop.

I think you can do the same. I am ready to help with testing.

Before the tests, the network parameters were measured:

ping = 19 ms, (+ 1ms max),  test command: ping 10.10.0.180 -l 1000 -t 

понедельник, 17 мая 2021 г. в 02:03:55 UTC+3, softerh...@gmail.com:

[Steve Haynal]

Hi Art,

I have seen the same stuck in TX with this gateware this week. I will try to debug later. I have other commitments this weekend.

73,

Steve

kf7o