Sequence errors in pihpsdr by DL1YCF and HL2

[Lukasz Olszewski]

I've recently received my HL2. I put it on a wired gigabit network and started testing. But my desktop PC (Linux) was on 5GHz wireless. So whenI first started getting Sequence errors and I read they are caused by packed drops I switched the desktop to wired too.

Then I thought maybe I'm running too high of a sample rate so I took it down all the way down and I'm still getting it.

Fragment of the output attached. Are these network issues or something else? It looks like something else to me, but I'm not sure:

 1001.490 old_protocol_audio_samples: output buffer overflow.
  1001.490 old_protocol_audio_samples: output buffer overflow.
  1099.376 SEQ ERROR: last 377744, recvd 377746
  1101.370 SEQ ERROR: last 378503, recvd 378505
  1102.369 SEQ ERROR: last 378884, recvd 378886
  2420.935 old_protocol_audio_samples: output buffer overflow.
  2420.935 old_protocol_audio_samples: output buffer overflow.
  3845.219 audio_open_input: allocating ring buffer
  3845.219 audio_open_input: PULSEAUDIO mic_read_thread
  3845.219 mic_read_thread: running=1
  3853.594 local_input_changed_cb: 3 alsa_input.usb-Plantronics_Plantronics_BT600_8b4b5ba38dec364a93d1bbc7755f88e5-00.3.mono-fallback
  3853.594 audio_close_input: wait for mic thread to complete
  3853.598 mic_read_thread: exit
  3853.604 audio_open_input: allocating ring buffer
  3853.604 audio_open_input: PULSEAUDIO mic_read_thread
  3853.604 mic_read_thread: running=1
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.
  4529.530 old_protocol_iq_samples: output buffer overflow.

4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.531 old_protocol_iq_samples: output buffer overflow.
  4529.536 old_protocol_iq_samples: output buffer overflow.
  5574.054 old_protocol_stop
  5574.054 metis_start_stop: 0
  5574.054 stop_program: protocol stopped
  5574.054 radio_stop: TX: stop display update
  5574.054 radio_stop: TX id=8: close
  5574.095 radio_stop: RX id=0: stop display update
  5574.095 radio_stop: RX id=0: close

  5574.121 radio_stop: RX id=1: stop display update
  5574.121 radio_stop: RX id=1: close
  5574.147 stop_program: radio stopped
  5574.165 stop_program: radio state saved

I can't tell if it's causing any issues or if it is just a warning. If someone knows, please let me know.

73,

Łukasz

[Steve Haynal]

Hi Lukasz,

Do you see errors when running other software such as Quisk or SparkSDR? That might help us determine if it is a problem with your software install or network setup.

73,

Steve

kf7o

["Christoph v. Wüllen"]

if seq errors occur only occasionally this is no reason to worry. This usually
means some I/O operation took place on the host computer that prevented it from
delivering all network packets in correct order. Such things may well happen
when opening a logbook file etc. etc. as long as it does not occur frequently
this is no problem.

At 4529.3 seconds after startup, "something happened". the WDSP "engine"
produced so many TX IQ samples "in one shot" that the output buffer
completely filled up. This happens if the WDSP engine gets too little
CPU for some time (so the input buffer fills) and then, when it gets the CPU again,
it produces all the samples in no time. This you can detect from the log file:

the output buffer overflow messages all come within 1 milli second,
there really was a "burst".

And, do not think this does not happen with other programs. They might
not tell you, but it happens.

> --
> 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 visit https://groups.google.com/d/msgid/hermes-lite/d4bcee10-83ec-4a3c-aa06-f28e4bbcc650n%40googlegroups.com.

[Lukasz Olszewski]

I believe I identified a variable that causes it, but the problem becomes even more pressing.

Essentially I get loads of these errors (they are scrolling continously) unless the PC running pihpsdr is in the same LAN segment (same LAN switch , same Vlan and so on).

I did done research and the order of UDP packets on the network is not guaranteed (especially when crossing a switch to switch uplink). So can someone please answer are these just warnings ibe can ignore or are they actual errors and HL2 can not only be used on LAN it has to be LAN within the same segment of the device. That would truly put a wrench into my use of HL2.

Can someone from the HL2 team answer this? Is receiving udp packets in order a requirement for correct working of HL2?

73,  Łukasz 

On Mon, 27 Jan 2025, 21:49 Lukasz Olszewski, <em...@lukaszolszewski.info> wrote:

Hi,

No, I never noticed any, but I only run SDR++ (with LimeSDR) rather than Quisk or SparkSDR.

I only use pihpsdr and briefly Thetis with HL2 from that PC.

It may well be some feature of my setup, but i

I doubt packets are lost. I have a fully wired connection all the way from HL2 to the PC. Perhaps packets get reordered?

I never noticed this problem on a pc that is on the same LAN segment next to HL2.

Basically my network topology is like this:

192.168.1.0/24 network 

HL2 -> Gigabit Switch -uplink->Gigabit Switch-> Linux Server 

Then the Linux Server has a 10 gig crossoverr connection to a Linux Desktop. That is the 192.168.2.0/24 network (only 2 hosts).

The default gateway is 192.168.1.1 and the Linux Desktop has a WiFi interface in the same network, but routing/firewall is set such that it can only talk to the default gateway there. All outgoing traffic except the gw is routed via 192.168.2.0 10Gig LAN. Any incoming traffic not from the gw is firewalled.

Previously this setup relied on a static route on the default gateway which would tell any device in the 192.168.1.0 network how to reach the 2.0 net. But some CCTV cameras would not pick up the static route so I enabled SNAT on the Linux Server.

This means to HL2 (and others) it appears as if traffic comes from the linux Server.

This made no difference to the sequence errors. 

I have no issues at all with this setup. I use huge bandwidth for file sharing (not while HL2 is used) as well as I play high bitrate live video from LAN CCTV cameras and I stream audio using sonobus. If there were packet drops I'd know. But I can't exclude the possibility of reordering.

My key question now is, should I be worried about these sequence errors? Everything seems to work fine?

73, Łukasz

[Clifford Heath]

While it may be legal for your router/switch to change the order of UDP packets, most will not do that.

Try a different router between those LAN segments before you give up. 

--

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 visit https://groups.google.com/d/msgid/hermes-lite/CACwB4R7A94GR58ax7VJDMbW%2BcHWUSXHNrDUPgGgduJY1eWyL9A%40mail.gmail.com.

[Josh Logan]

My setup has my network path going through 4 switches and it works correctly. 

I'll list the switches I'm using:

TP-Link TL-SG108E

MokerLink 8 Port 2.5G Managed Ethernet Switch with

MokerLink 8 Port 10Gbps SFP+ Managed Switch

keepLiNK 2.5gb managed switch features 4 x 2.5G RJ45 ports and 2 x 10G SFP+ Slots

I have also seen other traffic in my house cause problems at times.  All of the switches listed above support VLANs and I moved the radio traffic away from the general IoT traffic.

For a long time I used a USB to Ethernet adapter (I needed to try two brands to find one that worked great) and had the radio on an isolated segment, but when I moved the radio farther away from the computer I wanted to share the existing Ethernet.  I also wanted to play with 2.5g Ethernet and 10g Ethernet and make it so I could have 2 computers to use the radio, at different times.  A second run of Ethernet probably would have been quicker and simpler if you didn't want multiple computers to connect to the radio.

Before playing with fiber and faster Ethernet I was just using 2x P-Link TL-SG108E.  One in the shack and one at the radio.  I had this with 2 VLANs.  VLAN 1 was everything but radio, VLAN 2 was radio.  I had one port be a trunk port that connected the switches together.  My USB Ethernet adapter went to the VLAN 2 port in the shack and the radio was connected to the VLAN 2 port in the garage.  It acted like it did sitting on my desk, link local IP and everything.  The computer Ethernet went into VLAN 1 port, and in the garage VLAN 1 went into the Internet router.  This let me use the one cable but keep the traffic separate.

I hope this gives you some ideas to think about. 

73, KD7HGL 

Josh

To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/CAPnXPY1j%3Dv2czSfYxA%2B5RvGSh9MQ-9dJUF_8pBg7xtxbQnhhTw%40mail.gmail.com.

[Gary Abercrombie]

One option is to attempt to reassemble the UDP packets in order in the code.  Believe that Thetis does this.  Suspect you could also disable sequence checking and you wouldn't notice much difference.

---

From: herme...@googlegroups.com <herme...@googlegroups.com> on behalf of Josh Logan <kd7...@gmail.com>
Sent: Friday, January 31, 2025 8:18 AM
To: Clifford Heath <cliffor...@gmail.com>
Cc: Lukasz Olszewski <em...@lukaszolszewski.info>; Steve Haynal <softerh...@gmail.com>; Hermes-Lite <herme...@googlegroups.com>
Subject: Re: Sequence errors in pihpsdr by DL1YCF and HL2

 

To view this discussion visit https://groups.google.com/d/msgid/hermes-lite/CAPaLT3Yvsx5vnvnP7EHNuvmAkJwzDV6zJfpbvYJ1LbEegX%2Be5g%40mail.gmail.com.

[Steve Haynal]

Hi Lukasz,

No. The openhpsdr protocol 1 which the HL2 uses is resilient against some lost or out of order UDP packets. If my quick calculations are correct, you lose ~3ms of signal per lost UDP packet, which I don't think is even noticeable. You will see some lost packets on almost any network. I would say 1 error every ~5 minutes is an acceptable network. Wifi is more problematic. More complex wired networks (more hops, more traffic) can also be problematic.

I bought myself a $10 4 port gigabit PCIe card pulled from an older server. I use that in my desktop with direct connections for my HL2s. This has resulted in the fewest EP6 errors for me.

73,

Steve

kf7o