Unreliable connection to chip

[Iván Ávalos]

Three days ago, I came across this project, which is exactly what I needed, as I have an Orange Pi One and a 433MHz SX1278. I've been trying to get this working (with the default config), only partly successfully, because sometimes, randomly, the program suddenly fails with:

LoRa chip setup failed, code (65520) SPI write failed

It only works again when I manually reset the module (by disconnecting and connecting VDD) and rerun the program. I don't know why it is happening. It could be faulty wires (I did the soldering myself), some problem with spidev (/dev/spidev0.0 is present, though), or some problem with this project. I really don't know at this point.

There's another issue. I'm transmitting messages from another SX1278 module, using this board and this sketch, but the packet forwarder only receives the datagrams a few times (10 at most), and then nothing. I'm getting tired of trying. I tried with the sketch in this repository, but the packet forwarder never received anything at all.

[DiNy]

For the connection issue, I do not encounter them myself but I have the board soldered to a PCB, maybe it is a wiring issue.
But I can definitely relate for the receive part of your issue.

[Iván Ávalos]

It is not the wiring. I soldered the wires again and made sure they were working correctly, and I still get the SPI write errors, that only get fixed when I reconnect the module (without touching the wires at all).

How often do you receive packets, and how many of them when you do?

[zhgzhg]

@ivan-avalos , I've seen SPI connectivity issues with some transceivers and Orange PI boards, but usually they are unable to communicate at all, instead of stopping randomly. (In my case it was an Orange PI PC and a bare SX1276 board, while SX1278 was working without any issues.)

For your case I'd recommend checking the following:

1. Do you have the reset pin of the SX1278 connected to the Orange PI? Is it properly configured in the config.json?
2. Try reducing the spi_speed_hz in the config.json to something slower. Start reducing by a factor of 2, or 4, and see if it will make any difference.
3. If you are not using the hardware reset of SX1278, can you try with it instead?
4. Check your power supply - brownouts can be causing instabilities.
5. If possible try another transceiver (maybe with a different IC) or try the same one on another single-board computer.
6. Sometimes upgrading / downgrading the OS of the single-board computer helps with any instability issues.

Personally I've been running a similar configuration with SX1278 on Orange Pi Zero for months without any communication issues.

Regarding the missing packets - it's normal sometimes a packet to be missed, but not that often as you are describing.
The sender must have the following parameters fixed, and set to the same values the gateway is expecting, otherwise no data will be received at all:

• spreading_factor
• carrier_frequency_mhz
• bandwidth_khz
• coding_rate
• sync_word
• preamble_length

It's not rarity if LoRaWAN is used, because of the specification, the sender can randomly pick different frequency, and also adjust the SF. For e.g. the MCCI Catena's Arduino LMIC library behaves like that. In such cases extra code is needed to enforce fixed transmission parameters in order to work every time with a single channel gateway.

Lastly there's 1 more thing in the context of LoRaWAN - the node to node communication is different from the node to gateway one, because of the IQ inversion approach. I'll check both sketches (yours and mine) for discrepancies...

[zhgzhg]

I've looked at your sketch and library. The modem config is effectively:

0x72 - regmodemconfig1:

0111       = 125khz BW
       001  = 4/5 CR
            1 = implicit header

0x74 - regmodemconfig2:

0111       = SF7
       0      = single packet mode
         1    = crc on
          00 = rx timeout msb

0x26 - regmodemconfig3:

0010        = unused
        0      = no low rate optimization
          1    = agc on
           10 = reserved

Unless an explicit header is used in the sender, and the gateway has its sync word changed to 18 (the default value for the chip) you shouldn't be able to receive any data. Am I missing something?

[Iván Ávalos]

I changed loraChipRestIntervalSeconds to 20, so that every 20 seconds it resets (I connected the pin). I have received fewer SPI write errors (for some reason), and everytime the chip is reset, it receives 10 packets at most, then it stops again until the next reset. I'm sending the packets using my sketch, the one that isn't supposed to work but it's the only one that does.

[zhgzhg]

I'm also having issues receiving the data from my Transmit example. I'm looking into that as well...

[zhgzhg]

@ivan-avalos , the Transmit example should be fixed now, and if it's working for you, I hope we can safely exclude the transmission part out of the equation.

Edit: On the SPI communication: I've remembered you can enforce paranoid mode, which improves the robustness of the communication with the chip, but at the price of slowing the process down because of the extra checks, thus there's a higher chance during bidirectional communication the node to miss messages from the gateway. If that's not a problem then you can try adding -DRADIOLIB_SPI_PARANOID to the CFLAGS of the Makefile.