Communication between lopy and rn2483

[thibault]

Hi all, i search to make a communication between the lopy device and some electronic device who have the rn2483 chip from microchip. Actually the communication between the network of rn2483 use this parameter:

freq = "868000000"
pwr = "14"
sf = "sf12"
afcbw = "125"
rxbw = "125"
fdev = "25000"
prlen = "8"
crc = "on"
iqi = "off"
cr = "4/5"
bw = "125"
sync = "12"

from command line after use the "mac pause" command, i can send some data by using this command:
radio tx 1C610
In this example i can hear "1C610" in the air from another rn2483 chip.
For try to receive this by the lopy, i use this code:

# try_lora_receiver.py
# -*- coding: utf-8 -*-
from network import LoRa

lora = LoRa(mode=LoRa.LORA,
            frequency=868000000,
            tx_power=14,
            bandwidth=LoRa.BW_125KHZ,
            sf=12,
            preamble=8,
            coding_rate=LoRa.CODING_4_5,
            power_mode=LoRa.ALWAYS_ON)

lora.init(mode=LoRa.LORA,
          frequency=868000000,
          tx_power=14,
          bandwidth=LoRa.BW_125KHZ,
          sf=12,
          preamble=8,
          coding_rate=LoRa.CODING_4_5,
          power_mode=LoRa.ALWAYS_ON,
          tx_iq=False,
          rx_iq=False)


import socket
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
s.setblocking(False)

def receive_lora(number_of_receive=100):
    for _ in range(number_of_receive):
        response=s.recv(64)
        if response != b'':
            print(response)

receive_lora(100000)
# end of try_lora_receiver.py

But the receive_lora(100000) crash the CPU like this:

Task watchdog got triggered. The following tasks did not feed the watchdog in time:
Tasks currently running:
CPU 0: MicroPy
Aborting.
Guru Meditation Error: Core   0 panic'ed (Unhandled debug exception)
Register dump:
PC      :  400e01e6  PS      :  00060036  A0      :  800dfc10  A1      :  3ffd51f0  
A2      :  0000000a  A3      :  0000000a  A4      :  00000004  A5      :  00000000  
A6      :  00000000  A7      :  fffffff8  A8      :  00000000  A9      :  3ffd5160  
A10     :  00000000  A11     :  3ffdd7b3  A12     :  3ffd512f  A13     :  00000030  
A14     :  00000000  A15     :  00000002  SAR     :  00000011  EXCCAUSE:  00000001  
EXCVADDR:  00000000  LBEG    :  4000c46c  LEND    :  4000c477  LCOUNT  :  00000000  
CPU halted.

But if i set number_of_receive lower like 100, and i loop the rn2483 to send "1C610" continuously, i get sometimes response with like this:

b'Lq\x01'
b'\x1c\xb1\x01'
b'\x08q\x01'

not really what i expect :)

So, i will appreciate if anybody can give me some indication for set the good parameter to make a clen communication between lopy and rn2483, and for show my error in my source code wich crash the system.

Thank's

[durvesh09]

I succeeded in sending data from SX1272 to LoPy , but failed in sending data from LoPy to SX1272.
While sending data from LoPy to SX1272 i m getting some garbage values along with my actual payload with i sent from LoPy.
Anyone got this worked ?

[julz]

Bumping this topic as I have the same problem,
I upgraded to the last firmware and tested with both 0x12 and 0x34 sync parameters on the RN2483.

Sending with the RN2483:

radio tx 1234567890

On the LoPy I receive, less than 50% of the time, and when I do, it's mostly incorrect:

receive_lora(Nb_Tour=100000)
b'22a4567890'
b'1234567890'
b'123456b290'

Has anyone been able to get this working?

[Xykon]

If I switch to sf=12 (instead of sf=7 which I used previously) I can see some of the packages sent by the RN2483 on the Lopy. I've sent FF 00 00 00 - FF 00 00 1A from the RN2483 increasing by 1 every 5 seconds and the Lopy picked these up:

b'ff 00 00 01'
b'ff 00 00 02'
b'ff 00 00 04'
b'ff 00 00 05'
b'ff 00 00 07'
b'ff 00 00 08'
b'ff 00 00 0e'
b'ff 00 00 10'
b'ff 00 00 12'
b'ff 00 00 15'
b'ff 00 00 18'
b'ff 00 00 1a'

Not exactly the result I was hoping for but better than nothing. Even if I only send one packet every minute the LoPy doesn't pick them all up.

However getting anything from the LoPy sent to the RN2483 still fails. It seems to pick something up occasionally even if I don't send anything (though I've seen another LoRa device sending data in gnuradio so there must be someone else using the technology nearby) but all I get on the RN2483 is "radio_err".

I've tried listening to the traffic in gnuradio but the lora plugin I'm using doesn't seem to work well when I switch the spreading factor from 7 to 12.

[Xykon]

@livius The first 3 bytes always seem to be the same no matter what or how many bytes I'm sending.

[livius]

guessing it is some checksum

try same data sending many times in different connection - than we can see if it is always the same
if not than it is some "session" info

[Xykon]

I'm seeing the same issue. I've setup gnuradio & hackrf to see the communication between the LoPy and RN2483 (see my post here for details).

When I'm sending bytes([0xff, 0xff, 0x00, 0x00, 0x07, 0x37, 0xab]) with the LoPy I can see the following in the gnuradio output:

70 0b 08 ff ff 00 00 07 37 ab

When I send bytes([0xff, 0x00, 0x00, 0x02]) through the RN2483 I get the following in gnuradio:

40 0b 07 ff 00 00 02

It seems there is a mismatch in the first and third byte before the actual data packages begin.

It looks like I need to dig deeper into the LoRa protocol to fully understand what these first 3 bytes mean...

[DVE]

I have the same problem: no connection between LoPy and rn2483. Tried both modes, RX, TX, sf7, sf12, no success.

[daniel]

@thibault thanks for the feedback. I think the best is that we test this ourselves with a RN2483 until we find the cause and solve it. It will take a few days, but we'll keep you posted.

[thibault]

@daniel Hi, the sync word is really 0x12, but i have copy/paste the parameter that i push to rn2483, who's wait a hexadecimal value in the calling function to set it. I have make a fast try with 0x34 on rn2483 without good news.

When i use 0x12 sync on rn2483 i got few wrong response, but when i use the 0x34 word, i get no answer.

I will try later some other test by toggle tx_iq and rx_iq.

For the upgrade i have made this last few days, and the lopy are up to date (0.9.4.b1).

[daniel]

But the receive_lora(100000) crash the CPU like this:

@thibault Sorry for the delay. This WDT bug was fixed on the release from last Monday.

I think the problem between the LoPy and the rn2483 it's caused by a sync word miss match. You have sync word on the rn2483 configured as sync = "12", not sure if that's decimal 12 or 0x12, I would expect the latter, as the sync word officially can take 2 values, either 0x34 for LoRaWAN networks, or 0x12 for private networks. At this moment the LoPy in raw LoRa mode is using 0x34, which is incorrect, we should use 0x12 in that mode. Tjis will be fixed, but in the meantime, would you be able to change the sync word on the rn2483 to 0x34 and test again?

Please, before testing, update your LoPy's to the latest firmware :-):
https://www.pycom.io/support/supportdownloads/

Cheers,
Daniel

[thibault]

Hi all, i have, made some modification like this:

import time
import  binascii
import gc

def receive_lora(Nb_Tour=100):
    for _ in range(Nb_Tour):
        reponse=s.recv(64)
        time.sleep_ms(1)
        if reponse != b'':
            print(binascii.hexlify(reponse))

when i send from rn2483 the data: '1651681354' i get on lopy
80% of reponse was: b'0651681354', and sometimes i have such reponse:
b'0651681504'
b'a651381304'
b'0651381654'

But on the other direction, i can't receive anything from rn2483 when i send data by the lopy.

Nobody have the value of lora transceiver parameter use by the firmware please?