LoPy only receiving every second packet

[pkilcoyne]

Hi,
I have a LoPy set up so as to print to Standard output any receive data.

But it appears to only receive every second packet I send.

I validate all the packets are being sent via a spectrum analyser ( SDR# ).

Here is my LoPy script:

from network import LoRa
import pycom
import socket
import machine
import time

def blink_led(colour):
    pycom.rgbled(colour)
    time.sleep(0.5)
    pycom.rgbled(0x0000)

lora = LoRa(mode=LoRa.LORA, region=LoRa.EU868, sf=10, frequency=869850000, bandwidth=LoRa.BW_250KHZ, public=False, preamble=8, coding_rate=LoRa.CODING_4_5, tx_iq=False, rx_iq=False, power_mode=LoRa.ALWAYS_ON)

# create a raw LoRa socket
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
pycom.heartbeat(False)  # turn off hearbeat blue LED
rx_counter = 0

while True:

data = s.recv(64)
    if len(data) == 0:
        print('RX: nothing...\n')

    else:
        rx_counter += 1
        print('RX: data received')
        print('Data length: {}'.format(len(data)))
        print('RX: {} RX count: {}'.format(str(data), rx_counter))
        blink_led(0xff00)   # flash LED green on RX data

time.sleep(2)

Any ideas?

Thanks,

Paul

[robert-hh]

@plsecker The LoPy4 uses an TCXO as reference for the frequencies, while other boards (like for instance the Lopy) use a standard crystal. And even then the quality of the crystal may vary.

[plsecker]

Update to this [SOLVED] kind-of. I acquired a 2nd RFM95 and found RFM95 to RFM95 would have trouble sending more than 5 or 6 bytes. But the solution is to drop the spreading factors (am using 125kHz):

• SF12: Unreliable RFM95 to RFM95 and RFM95 to LoPy4 (scrambled characters and only every 2nd transmission received)

• SF11: Reliable RFM95 to RFM95, but the same issues above for RFM95 to LoPy4

• SF10 and below: Reliable RFM95 to RFM95 and Reliable RFM95 to LoPy4

Clearly high SFs are trouble for the RFM95 (oscillator stability?). Whilst the LoPy's operate between themselves quite happily at all SFs.

The unusual response of the LoPy to the high RFM95 SFs is for 'further study' .

Philip

[plsecker]

@jcaron Been through everything, except coding but pretty confident that is 4/5, as you know unless you get it right you will get no response at all. And CRC checking ought to reject any wrong config.
Sending manually, once per sec at the most.
It would be helpful if someone could let me know if the Pycom socket imposes any restrictions (using RAW mode of course) or puts any wrapper on. Really keen to understand what mechanism would result in only every second packet being returned.

Philip

NB @pkilcoyne

[jcaron]

@plsecker have you tried the various combinations of coding rate, rx_iq, etc?

Also, how fast are you sending? Is there any pause between consecutive frames?

[plsecker]

Hi Paul,
Did you ever get to the bottom of this? I have exactly the same issue, except my transmitter is an RFM95 module. Only every second message gets through and of that only the first 3 bytes are always correct. I don't see any difference between the two radically different transmission frequencies and bandwidth (915/125 and 868/250). Very puzzling as Lopy4 to Lopy4 works but I don't have a 2nd RFM95 to check against.

Further info: sending long strings, the correct number of characters always turn up and are mostly, but not always, the same (but nowhere near the same as what's transmitted). As CRC is on, this indicates the transmission is changing but I can't be sure.

If I had to guess, there is some scrambling going on at one end which is not matched at the other.

If anyone is interested, here's the captured LoPy4 response to
rfm9x.send('eeeeeeeeeeeeeeeeeeeeeeeeeeee')
(only every 2nd transmission results in a capture):

rfm95-e.py (txt file as .py)

NB, I expect the first 4 bytes to be from a header that's inserted before the string.

Philip

[pkilcoyne]

@jcaron What I have noticed is if I move to SF12 & 125KHz on both sides and reduce my message size to not more than 5 bytes every message is received.

Above 5 bytes and I'm back to only receiving every second message.

I have another eRA-LORA in the system and it receives all messages sent by the transmitter no matter the message size.

[pkilcoyne]

@jcaron Sorry you're correct. I am sending at SF=10 and bandwidth = 250KHz :)

[jcaron]

@pkilcoyne Your bandwidth and SF settings don't match with the code you posted...

lora = LoRa(mode=LoRa.LORA,
     region=LoRa.EU868,
     sf=10,                     // HERE
     frequency=869850000,
     bandwidth=LoRa.BW_250KHZ,  // AND HERE
     public=False,
     preamble=8,
     coding_rate=LoRa.CODING_4_5,
     tx_iq=False,
     rx_iq=False,
     power_mode=LoRa.ALWAYS_ON)

Frequency: 869.85MHz
Bandwidth: 125KHz
Spreading Factor: 12

It's surprising that you are still receiving some of the packets, though.

[pkilcoyne]

@jcaron said in LoPy only receiving every second packet:

All frames on the same frequency, SF, etc? How much time to you have between

Hello again,
I'm sending manually using a eRA-LORA usb module by LPRS (lprs.co.uk) plugged into my PC:

http://www.lprs.co.uk/development-tools/evaluation-tools/easyradio-usb-rf-dongles/eraconnect2pi-rf-dongle.html

I use their "easyRadio" companion software and am using the following settings:

http://www.lprs.co.uk/development-tools/easyradio-evaluation-software.html

Frequency: 869.85MHz
Bandwidth: 125KHz
Spreading Factor: 12

I've played around with different settings and get similar results.

I usually wait a few seconds between messages but it's pretty random.

Thanks,

Paul

[jcaron]

@pkilcoyne what are you sending with? All frames on the same frequency, SF, etc? How much time to you have between frames?

[pkilcoyne]

Anyone any ideas as to why the LoPy is only registering every second message?

[pkilcoyne]

@crumble said in LoPy only receiving every second packet:

@rfinkers

readin with blocking = True is better than waiting for some time.

Thanks for the reply. Could you explain your reply further please? I'm not the best coder, somewhat of a beginner :)

[pkilcoyne]

@rfinkers Yes, I have that, my pasting skills aren't the best :)

[crumble]

@rfinkers

readin with blocking = True is better than waiting for some time.

[rfinkers]

Place a tab in front of

data = s.recv(64)

and

time.sleep(2)