LoRa receiving data intermittently

  • I am trying to receive data on a LoPy transmitted from an Adafruit Feather M0 with a RFM95 radio. The M0 transmits GPS coordinates every 1 second over the radio. At first I thought the LoPy was not working at all because I only got 'b' in the print out. However I left it on for a while and noticed that every few minutes or so I get a packet transmission with the GPS data from the M0.

    Both radios are running the same default radio settings.

    F = 915
    Bw = 125 kHz
    Cr = 4/5
    Sf = 7 (128chips/symbol)
    The M0 has CRC on I am not sure where to set/verify this with the LoPy network library. I am using the RadioHead library for Arduino on the M0.

    One thing I noticed on the LoPy is that the coding rate seems to be 4/6 even if I explicitly set the coding rate to LoRa.CODING_4_5. When I retrieve the coding rate after I set it returns 1 rather than the 0 I should be seeing according to the docs. Not sure this is my issue but something looks off here regardless. If you don't explicitly set the coding rates it still returns 1 so there does not appear to be any way to set the coding rate to 4/5.

    Here's my python code, I am running firmware 1.8.0.b1. Any help would be much appreciated.

    from network import LoRa
    import socket
    import machine
    import time
    lora = LoRa(mode=LoRa.LORA)
    s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
    print("LoRa Ready")
    print("Frequency: "+ str(lora.frequency()))
    print("Spreading Factor: "+ str(lora.sf()))
    print("Coding Rate: "+ str(lora.coding_rate()))
    print("Bandwidth: "+ str(lora.bandwidth()))
    print("MAC: "+ str(lora.mac()))
    while True:
        data = s.recv(128)

  • @maelstrom

    LoRaRAW works for me between 2 LoPys both on EUR and US frequencies on the latest firmware, all the other parameters are default values.

  • Does anyone have a couple of LoPys running firmware 1.8.0.b1 and can test out the raw LoRa mode to confirm that this isn't a firmware issue?

    I got my DVB-T tuner and nothing seems out of the ordinary and 915mhz in my basement is clean of interference. Even did some additional fine tuning of the frequency that the LoPy is listening on and still got intermittent results.

    I am starting to wonder if there is a bad trace or ground that is contributing to this. I did have some issues when soldering the ground pin when I put in the headers, the board has a lot of grounding copper left on the PCB which acted as a heat sink so the solder didn't flow as well... maybe I will go resolver it to be sure.

  • @JimT I am not sure.

  • @maelstrom

    Is it possible to use FSK on the LoPy?

  • @ledbelly2142 Thanks for the info. Right now I would say I am getting ~99% packet loss when receiving on the LoPy from an Arduino driven RFM95. To double check that I wasn't getting interference I had another Arduino/RFM95 receiving next to the LoPy and I received 100% of the packets. I also tried the reverse (LoPy transmitting, Arduino receiving) and did not receive anything. However if I had my GPS transmitter sending at the same time the LoPy would interfere with it so something is happening around the 915 frequency. I get my DVB-T tuner today so I will keep poking around.

    I have a feeling there is some default setting that is different between the Arduino and LoPy, I just cant figure out what it is and having 1% of the transmissions come across randomly is adding to the confusion.

  • This is what I am using

    lora = LoRa(mode=LoRa.LORA, bandwidth=LoRa.BW_125KHZ, coding_rate=LoRa.CODING_4_8, sf=12, tx_iq=True)
    lora_sock = socket.socket(socket.AF_LORA, socket.SOCK_RAW)

    with the 'nano-gateway' inside the office, we had a good signal up to about 1/4 mile with large buildings in the way. Still have intermittent issues and occasional corrupted messages.

  • Looks there is a discrepancy between docs and implementation for coding_rate.

    modlora.c shows:

    typedef enum {
        E_LORA_CODING_4_5 = 1,
        E_LORA_CODING_4_6 = 2,
        E_LORA_CODING_4_7 = 3,
        E_LORA_CODING_4_8 = 4
    } lora_coding_rate_t;

    While docs indicate:

    lora.coding_rate([coding_rate]) Get or set the coding rate in raw LoRa mode (LoRa.LORA). The allowed values are: LoRa.CODING_4_5 (0), LoRa.CODING_4_6 (1), LoRa.CODING_4_7 (2) and LoRa.CODING_4_8 (3).

    I think this is just a documentation issue as setting the coding rate to 0 on the sx1272 would put it in FSK mode.

  • @maelstrom

    I am using firmware 1.8.0.b1
    I am using LoRa Nano-Gateway (Raw LoRa)

  • Ok so I did some poking around with different frequencies and only got one hit on 908000000 and it wasn't my GPS transmission from the M0. Also wanted to double check that the M0 was consistently transmitting so I fired up my other Arduino with the RFM95 and it picks up the transmissions perfectly every second. I am at a loss, this worked with very little troubleshooting using the RFM95 + Arduino.

    Here's what I was using to cycle through all the ISM 915 MHz frequencies at 100000 increments.

    from network import LoRa
    import socket
    import machine
    import time
    lora = LoRa(mode=LoRa.LORA)
    frequency = 902000000
    while True:
        if frequency <= 928000000:
            s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
            print("Frequency: "+ str(lora.frequency()))
            data = s.recv(128)
            frequency = frequency + 100000
            frequency = 902000000

  • @bmarkus Thanks, I just ordered a tuner to do some investigation. However I have had no issues transmitting between two RFM95 modules attached to Arduinos using the RadioHead library. Should I expect much variance in terms of tuning frequency across different LoRa radios? I did try some different frequencies around 915 but didn't know how granular I should get so
    I was pretty much poking around in the dark.

  • First I would repeat the test on different frequencies. You may have an interference from other devices. I'm not saying there is no bug in LoPy but RFI can cause issues for any properly working device.

    If you are planning to work with LoRa a bit longer time, it is worth to buy a DVB-T USB stick for few bucks and use an SDR (Software Defined Radio). With this you can see noise level on the band, what is going on adjacent channels, etc.

  • @bmarkus no problem. I wonder if the RAW implementation has a bug where it is acting like the WAN mode and receiving on different frequencies. That's why I am seeing data come across every once and awhile.

  • @maelstrom Ahhhh, sorry I was not reading it carefully. Too late for working :)

  • @bmarkus I am the original poster, @ledbelly2142 reported similar behavior so I was wondering if his configuration was similar to mine.

  • @maelstrom said in LoRa receiving data intermittently:

    @ledbelly2142 are you using LoRa raw or wan modes? What firmware? I wonder if there is a bug in the raw implementation for the recent 1.8.0 release.

    It is in the opening post.

  • @ledbelly2142 are you using LoRa raw or wan modes? What firmware? I wonder if there is a bug in the raw implementation for the recent 1.8.0 release.

  • I have similar issues with LoRa transmission consistency. Some of the transmissions are corrupted, like the check bit got flipped mid stream. Running on a battery, it gets expensive to have to attempt to re transmit.

    I'm not sure what is causing the intermittent issue.


Kickstarter Launch-Pylife

November 2018

Back Us On Kickstarter >

Pycom on Twitter