Reproducible packet error

[fedekrum]

ESPixelStick Firmware Version FW Version 4.0-ci7063024905 Build Date Dec 1 2023 - 17:15:45

Hardware Version Architecture ESP8266 Board Name espsv3 (Node MCU 1.0 v3)

Binary release or compiled yourself? Binary release

Operating System (and version) Macos Catalina

Web Browser (and version) Chrome

Access Point FritzBox 7490

Describe the bug I can reproduce a Packet Error, but I am not sure if ESPixelStick is responsible for it or the sender. I have made a script in Python using lib PyArtNet implementing E1.31 protocol. https://github.com/fedekrum/DMX/blob/main/scanDMX.py

usage: scanDMX.py [-h] -a ADDRESS -u UNIVERSE [-c CHANNEL] [-r RANGE] [-s SPEED] [-k]

Scans DMX channels with PyArtNet.

options: -h, --help show this help message and exit -a ADDRESS, --address ADDRESS IP address or hostname of the sACN node -u UNIVERSE, --universe UNIVERSE DMX universe number (1-63999) -c CHANNEL, --channel CHANNEL DMX channel number (1-512), optional -r RANGE, --range RANGE Range of channels to animate (1-512), optional -s SPEED, --speed SPEED Animation speed in milliseconds (default 500ms) -k, --key-pause Require key press to start animation for each channel

How to reproduce 1) Start fresh your ESPixelStick and notice E1.31 Status - Packet Error and Total Packets in zero.

2) Execute the script one time only python3 scanDMX.py -a192.168.188.81 -u1 -c1 You will notice that xxx Total Packets were sent and no Packer Error will occur.

3) Execute the script once more Notice that this time you get a Packet Error

4) If you keep repeating the execution you get one packet error each time, even if you change the command parameters to do an extensive scan.

Thanks in advance

[fedekrum]

I have simplified what the program does (scanDMX.py) to have fewer packets to analyze (6 packets total, 3 executions, 2 packets each execution). I have updated my previous post with newer screenshots reflecting these changes. I added Wireshark packet reports as text, .pcap and .pcapng.

[MartinMueller2003]

The problem you are seeing is session scope. The ESP has a single session for your entire test. That means it expects to see a monotomically incrementing sequence number in every packet it receives. I am betting your utility restarts the sequence number at 1 (or zero) every time you execute it. That will be seen as an unexpected shift in the sequence number. The ESP reports that and then aligns with the new number sequence.

[fedekrum]

Thanks @MartinMueller2003 So I assume that inside the E1.31 data, there is a sequential step number in each packet, right? And the problem is that my program, each time it gets executed, starts from step 0 (or 1) so the ESPixelStick gets that as a packet error for being not correlative, right? Can you confirm if my interpretation is good?

If so, it should be more of a warning than a packet error. I understand a packet error more as data loss because of a malformed packet.

[MartinMueller2003]

Yes you are correct and yes it is a packet error. We cant tell if something dropped or got reset or was restarted or if a packet got delayed and then suddenly arrived late. So the simple to implement rule is: "Not the expected number? Increment error count".

[MartinMueller2003]

can I close this as "not a bug"?

[fedekrum]

Absolutely and thanks!!