Feature Request: Von Zeit zur Zeit Missing Frames, Retransmit missing packets in order 0x81, 0x82, ... 0x8x

[kawi73]

Hardware

• ESP8266
• ESP32
• Raspberry Pi

Modelname: ______
Retailer URL: ______

nRF24L01+ Module

• nRF24L01+ you verified this is a Plus model capable of the required 256kBit/s mode
• square dot indicates original Nordic Semicon chip
• round dot indicates copy-cat / counterfeit SI labs chip

Antenna:

• circuit board
• external antenna

Power Stabilization:

• 100uF Electrolytic Capacitor
  connected between +3.3V and GND (Pin 1 & 2) of the NRF Module
• Voltage stabilizing motherboard

Connection diagram:

• Image of the your wiring attached

Connection diagram I used:

nRF24L01+ Pin	ESP8266 GPIO
Pin 1 GND [*]	GND
Pin 2 +3.3V	+3.3V
Pin 3 CE	GPIO2 CE D4
Pin 4 CSN	GPIO15 CS D8
Pin 5 SCK	GPIO14 SCLK D5
Pin 6 MOSI	GPIO13 MOSI D7
Pin 7 MISO	GPIO12 MISO D6
Pin 8 IRQ	GPIO0 IRQ D3

Software

• AhoyDTU
• OpenDTU

Version / Git SHA:

Version: 0.5.41
Github Hash: 0a5833e

Build & Flash Method:

• Arduino
• ESP Tools
• Platform IO

Desktop OS:

• Linux
• Windows
• Mac OS

Debugging:

• USB Serial Log (attached)
• Setup settings (use our templates ... to be added)

[kawi73]

Dasist das Log aus der Web Serial Console inklusive Debug Info

15:51:24 I: (#0) Requesting Inv SN 114173307265
15:51:24 I: (#0) enqueuedCmd: 11
15:51:24 I: (#0) sendTimePacket
15:51:24 I: TX 27B Ch40 | 15 73 30 72 65 82 68 04 12 80 0b 00 63 86 1c 6c 00 00 00 08 00 00 00 00 6d 4f 89
15:51:25 W: while retrieving data: last frame missing: Request Retransmit
15:51:25 I: TX 11B Ch61 | 15 73 30 72 65 82 68 04 12 83 3e
15:51:25 I: RX 23B Ch3 | 95 73 30 72 65 73 30 72 65 83 00 00 00 07 03 e8 00 7b 00 08 5f 6b bd
15:51:26 W: while retrieving data: Frame 1 missing: Request Retransmit
15:51:26 I: TX 11B Ch75 | 15 73 30 72 65 82 68 04 12 81 3c
15:51:26 I: RX 27B Ch23 | 95 73 30 72 65 73 30 72 65 01 00 01 01 41 00 1a 00 55 01 44 00 1b 00 56 00 00 92
15:51:26 W: while retrieving data: Frame 2 missing: Request Retransmit
15:51:26 I: TX 11B Ch3 | 15 73 30 72 65 82 68 04 12 82 3f
15:51:26 I: RX 27B Ch40 | 95 73 30 72 65 73 30 72 65 02 b6 5b 00 00 96 2c 00 56 00 58 09 1c 13 89 00 a3 e2

[kawi73]

Woran könnte das liegen?

[jimknopf63]

Dasist das Log aus der Web Serial Console inklusive Debug Info

15:51:24 I: (#0) Requesting Inv SN 114173307265
15:51:24 I: (#0) enqueuedCmd: 11
15:51:24 I: (#0) sendTimePacket
15:51:24 I: TX 27B Ch40 | 15 73 30 72 65 82 68 04 12>80<0b 00 63 86 1c 6c 00 00 00 08 00 00 00 00 6d 4f 89
15:51:25 W: while retrieving data: last frame missing: Request Retransmit
15:51:25 I: TX 11B Ch61 | 15 73 30 72 65 82 68 04 12>83<3e
15:51:25 I: RX 23B Ch3 | 95 73 30 72 65 73 30 72 65>83<00 00 00 07 03 e8 00 7b 00 08 5f 6b bd
15:51:26 W: while retrieving data: Frame 1 missing: Request Retransmit
15:51:26 I: TX 11B Ch75 | 15 73 30 72 65 82 68 04 12>81<3c
15:51:26 I: RX 27B Ch23 | 95 73 30 72 65 73 30 72 65>01<00 01 01 41 00 1a 00 55 01 44 00 1b 00 56 00 00 92
15:51:26 W: while retrieving data: Frame 2 missing: Request Retransmit
15:51:26 I: TX 11B Ch3 | 15 73 30 72 65 82 68 04 12>82<3f
15:51:26 I: RX 27B Ch40 | 95 73 30 72 65 73 30 72 65>02<b6 5b 00 00 96 2c 00 56 00 58 09 1c 13 89 00 a3 e2

Das habe ich auch seit dem Upgrade von 0.32 auf die 0.41

(edit use triple backticks ``` and >< to show frame/packet numbers in TX/RX messages)

[kawi73]

Die gleichen Meldungen kommen auch in der Development Version 0.5.44. Habe es gerade ausprobiert

[stefan123t]

Das ist alles soweit in Ordnung die Kommunikation ist nicht immer 100%ig daher fragt die AhoyDTU manche Pakete einfach nochmal an. Die RX Pakete kommen ja auch danach und die Payload kann wenn alle Pakete zusammen sind gelesen werden.

[stefan123t]

Du kannst ggf die Antenne anders ausrichten oder evtl auf PA Level LOW/HIGH erhöhen und nachsehen ob es besser / schlechter wird. Die Ausrichtung der Antenne hat meist sogar größeren Einfluss 🤷

[stefan123t]

@lumapu vielleicht sollten wir doch eine andere Vorgehensweise wählen:

• request 80 multi frame response, wait 500 ms + N-1 frames ( max 12 Bytes each ) * 300 ms for response
  • either re-request multi frame response if none / last packet did not arrive
  • or request first missing packet if one or more packets arrived.

Normal ist ja alles eine Antwort Sequenz

sequenceDiagram
    AhoyDTU->>WR: Request_0x80;
    WR->>AhoyDTU: Response_0x01;
    WR->>AhoyDTU: Response_0x02;
    WR->>AhoyDTU: Response_0x83; 

Loading

also wenn ein Paket verloren geht müssen wir es neu abfragen

sequenceDiagram
    AhoyDTU->>WR: Request_0x80;
    WR->>AhoyDTU: Response_0x01;
    WR-->>AhoyDTU: Response_0x02;
    WR->>AhoyDTU: Response_0x83;
    AhoyDTU->>WR: Request_0x82;
    WR->>AhoyDTU: Response_0x02;

Loading

Aber anstelle des bisherigen Vorgehens zuerst das letzte Paket zu forcieren würde ich erst einmal die Kommunikation sicher aufbauen.
Das Forcieren geht ja nur unter der Annahme dass der WR die erste MultiFrame Anfrage überhaupt mitbekommen hat und wir die Antwort nur nicht gesehen haben!
Sonst könnte das auch eine Antwort auf ein anderes Kommando sein, je nach dem in welchem MainCmd/SubCmd State der WR gerade steht.

sequenceDiagram
    AhoyDTU-->>WR: Request_0x80;
    WR-->>AhoyDTU: Response_0x01;
    WR-->>AhoyDTU: Response_0x02;
    WR-->>AhoyDTU: Response_0x83;
    AhoyDTU->>WR: Request_0x83;
    WR->>AhoyDTU: Response_0x83;
    AhoyDTU->>WR: Request_0x81;
    WR->>AhoyDTU: Response_0x01;
    AhoyDTU->>WR: Request_0x82;
    WR->>AhoyDTU: Response_0x02;

Loading

Daher würde ich es bevorzugen einfach nochmal die komplette Multi Frame Anfrage 0x80 zu stellen, bis mindestens eines der Antwort-Pakete auch bei uns ankommt.
Dann können wir in aller Ruhe die fehlenden Pakete einzeln übertragen lassen. Auch hier würde ich von vorne 0x01 .. nach hinten 0x8X vorgehen bis alle Pakete da sind, so macht es auch die Original DTU Pro laut den Traces von Ichirou und anderen.

sequenceDiagram
    AhoyDTU-->>WR: Request_0x80;
    WR-->>AhoyDTU: Response_0x01;
    WR-->>AhoyDTU: Response_0x02;
    WR-->>AhoyDTU: Response_0x83;
    AhoyDTU->>WR: Request_0x80;
    WR-->>AhoyDTU: Response_0x01;
    WR->>AhoyDTU: Response_0x02;
    WR-->>AhoyDTU: Response_0x83;
    AhoyDTU->>WR: Request_0x81;
    WR->>AhoyDTU: Response_0x01;
    AhoyDTU-->>WR: Request_0x83;
    WR->>AhoyDTU: Response_0x83;

Loading