Strange transmission behavior on DIY nodes

Support
1

Hi all :slight_smile:
May be this question for Development thread, i don’t know.

I have a trouble with my diy nodes in transmitting ‘long’ messages with certain settings.
My nodes:

  • promicro (nrf52840 ) + e22-900mm22s (sx1262)
  • ebyte E73-2G4M08S1C + heltec HT-RA62 (sx1262)

Using LongFast preset.

Both nodes has problems when I try to send message with more than ~20 symbols.
Short messages (1-10) has near 100% delivery, but long - dramatilally descrease to 1-5% of delivery.

I have a set of other nodes (esp32 and nrf5284 based), whey doesn’t have such problem.
SDR shows that node transmits, but no one other node replies (2-3 meters between nodes)

Everything works fine with medium fast/short fast/long moderate presets.

First mind was about frequency drifting with xtal module (900mm22s), but got the same problem with tcxo.

So I need help to discover and solve problem.

2

how is power supplied to the lora module you using bypass and or filter caps at all or no?

anything showing up in the logs ?

3

There are few caps before and after 3.3v LDO (as I remember 10uF and 220uF)

In the transmitting node logs all is ok - as normal transmission, but other nodes don’t reply (and problem node tries to transmit 3 times).
On receiving node - need to check again, early I saw logs that packet received but it is possible a noise. I’ll return with logs later.

1 Like
4

ah ok, i had noise issues lots reported with that rp2040-lora board at some stage also, not looked at it since

suggest: just try the one device at a time with a 3rd known working device to see if logs report no issue

1 Like
5

I have 3 working nodes and one problem online :slight_smile:
Part of log on recieving side from one of nodes

b’DEBUG | ??:??:?? 162 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=255, time 2131 ms\r\n’
b’ERROR | ??:??:?? 162 [RadioIf] ignoring received packet due to error=-7\r\n’
b’DEBUG | ??:??:?? 162 [RadioIf] AirTime - Packet received (noise?) : 2131ms\r\n’
b’DEBUG | ??:??:?? 173 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=255, time 2131 ms\r\n’
b’ERROR | ??:??:?? 173 [RadioIf] ignoring received packet due to error=-7\r\n’
b’DEBUG | ??:??:?? 173 [RadioIf] AirTime - Packet received (noise?) : 2131ms\r\n’

6

Ok so which device is causing the noise ? the HT-RA62?

they not too close to each other ?

7

In this case HT-RA62 transmits, heltec CT-62 receives
Near 2 meters between nodes

8

Very strange.

What most odd is that the received ‘packets’ are all at maximum packet size (255) not sometimes less, its almost as if someone else it transmitting max size packets on purpose.

Are the reported RSSI and SNR for these ‘packets’ consistent ?

What does error -7 mean ?

9

Here are success log with short message

2024-07-02 16:40:29,026 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=25, time 419 ms\r\n’
2024-07-02 16:40:29,033 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [RadioIf] Lora RX (id=0x3c847ad2 fr=0x1c to=0x60, WantAck=1, HopLim=7 Ch=0x8 encrypted rxSNR=5.5 rxRSSI=-38 hopStart=7)\r\n’
2024-07-02 16:40:29,037 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [RadioIf] AirTime - Packet received : 419ms\r\n’
2024-07-02 16:40:29,042 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [Router] Add packet record (id=0x3c847ad2 fr=0x1c to=0x60, WantAck=1, HopLim=7 Ch=0x8 encrypted rxSNR=5.5 rxRSSI=-38 hopStart=7)\r\n’
2024-07-02 16:40:29,044 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [Router] Using channel 0 (hash 0x8)\r\n’
2024-07-02 16:40:29,046 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [Router] Expanding short PSK #1\r\n’
2024-07-02 16:40:29,047 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [Router] Using AES128 key!\r\n’
2024-07-02 16:40:29,050 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [Router] ESP32 crypt fr=88cbb31c, num=3c847ad2, numBytes=9!\r\n’
2024-07-02 16:40:29,053 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [Router] decoded message (id=0x3c847ad2 fr=0x1c to=0x60, WantAck=1, HopLim=7 Ch=0x0 Portnum=1 rxtime=1719927627 rxSNR=5.5 rxRSSI=-38 hopStart=7)\r\n’
2024-07-02 16:40:29,058 ~ Serial Logger ~ INFO ~ b’DEBUG | 13:40:27 207 [Router] handleReceived(REMOTE) (id=0x3c847ad2 fr=0x1c to=0x60, WantAck=1, HopLim=7 Ch=0x0 Portnum=1 rxtime=1719927627 rxSNR=5.5 rxRSSI=-38 hopStart=7)\r\n’
2024-07-02 16:40:29,061 ~ Serial Logger ~ INFO ~ b"DEBUG | 13:40:27 207 [Router] Module ‘text’ wantsPacket=1\r\n"
2024-07-02 16:40:29,062 ~ Serial Logger ~ INFO ~ b’INFO | 13:40:27 207 [Router] Received text msg from=0x88cbb31c, id=0x3c847ad2, msg=12345\r\n’

and additional log with unsuccess (shorter message. not 255 len)

2024-07-02 16:38:42,237 ~ Serial Logger ~ INFO ~ b’DEBUG | ??:??:?? 100 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=109, time 1050 ms\r\n’
2024-07-02 16:38:42,237 ~ Serial Logger ~ INFO ~ b’ERROR | ??:??:?? 100 [RadioIf] ignoring received packet due to error=-7\r\n’
2024-07-02 16:38:42,251 ~ Serial Logger ~ INFO ~ b’DEBUG | ??:??:?? 100 [RadioIf] AirTime - Packet received (noise?) : 1050ms\r\n’

10

RadioLib docs says

|#define|RADIOLIB_ERR_CRC_MISMATCH (-7)|
| — | — |
||The calculated and expected CRCs of received packet do not match. This means that the packet was damaged during transmission and should be sent again.|

https://jgromes.github.io/RadioLib/group__status__codes.html

11

What are the RSSI and SNR of the error packets ?

12

I don’t see it in a logs for error packets.
I can try later to disable error handling in fw and check what will be in logs.

13

Its possible its not printed, they might have given a clue as to where the packets are coming from.

LoRa devices dont tend to report ‘packets’ from noise.

Radiolib does define an error for a problem with the packet header;

RADIOLIB_ERR_LORA_HEADER_DAMAGED
(-24) LoRa packet header has been damaged

The packet header does have a seperate CRC so you might think that if no packet header damaged is being reported, then the header is geniune, further implying a LoRa packet is being received.

14

So, with no error handling

DEBUG | 14:24:18 105 [Router] handleReceived(REMOTE) (id=0x3c847ad9 fr=0x1c to=0xff, WantAck=0, HopLim=7 Ch=0x0 Portnum=1 rxtime=1719930258 rxSNR=6 rxRSSI=-31 hopStart=7)
DEBUG | 14:24:18 105 [Router] Module ‘text’ wantsPacket=1
INFO | 14:24:18 105 [Router] Received text msg from=0x88cbb31c, id=0x3c847ad9, msg=For the update on the same thing I think I have a new phonU ane it"doesn’t n!|ter%if yu have a nw phOn

Message was sent

For the update on the same thing I think I have a new phone and it doesn’t matter if you have a new phone and it doesn’t matter if you have a new phone and it doesn’t matter if you have a new phone and it doesn’t matter if you have a

So yes, packet corrupted

15

Who is sending this packet ?

16

I’m :sweat_smile: From meshtastic android app

Sended

image
image1080×380 59 KB

Received

image
image1080×473 61.2 KB

17

Well, the problem you are seeing appears to be that the ‘error’ packet starts off OK, but that bit errors start occuring later on in the packet. One of the useful thing about LoRa devices is that the packet buffer is not lost when there is an error.

When the symbol time gets larger then LoRa packets are subject to this type of error for longer (as in more bytes) packets. I recall way back in time (2014) seeing the same issue and the cause was not setting the low data rate optimisation flag, which according to the datasheets you need to set at symbol lengths of greater than 16mS.

But the symbol time here, SF11, BW 250khz is 8mS, so the flag should not need to be set.

18

I can find low data rate optimization only in SX127x logic in radiolib, not in 1262
So I can’t try set it by hardcode)

19

Its here;


int16_t SX126x::setModulationParams(uint8_t sf, uint8_t bw, uint8_t cr, uint8_t ldro) {
  // calculate symbol length and enable low data rate optimization, if auto-configuration is enabled
  if(this->ldroAuto) {
    float symbolLength = (float)(uint32_t(1) << this->spreadingFactor) / (float)this->bandwidthKhz;
    if(symbolLength >= 16.0) {
      this->ldrOptimize = RADIOLIB_SX126X_LORA_LOW_DATA_RATE_OPTIMIZE_ON;
    } else {
      this->ldrOptimize = RADIOLIB_SX126X_LORA_LOW_DATA_RATE_OPTIMIZE_OFF;
    }
  } else {
    this->ldrOptimize = ldro;
  }
  // 500/9/8  - 0x09 0x04 0x03 0x00 - SF9, BW125, 4/8
  // 500/11/8 - 0x0B 0x04 0x03 0x00 - SF11 BW125, 4/7
  uint8_t data[4] = {sf, bw, cr, this->ldrOptimize};
  return(this->mod->SPIwriteStream(RADIOLIB_SX126X_CMD_SET_MODULATION_PARAMS, data, 4));
}

Use a tool such as AstroGrep to text search the library for ‘optimize’ or ‘optimization’

Cannot see an option to force it on or off though, its calculated.

20

Thanks, my bad.
Forcing LDRO (forceLDRO() method ) makes all received messages as corrupted (on problem node) and it doesn’t transmit at all.
I just try to invoke it right after lora.begin() method.