CongducPham / LowCostLoRaGw

Low-cost LoRa IoT & gateway with SX12XX (SX1261/62/68; SX1272/76/77/78/79; SX1280/81), RaspberryPI and Arduino boards
703 stars 354 forks source link

Receive Error 2 #267

Closed vdbpeter closed 4 years ago

vdbpeter commented 4 years ago

Hi I'm working through building your system and making some slow progress, but still progress!

The GW running on the RPi2 with RFM95W resets every 22-23 seconds. 2020-01-07T20:47:52.524649> Receive error 2 2020-01-07T20:47:52.525875> Resetting radio module 2020-01-07T20:47:52.526831> SX1276 detected, starting. 2020-01-07T20:47:52.527747> SX1276 LF/HF calibration 2020-01-07T20:47:52.528566> ... 2020-01-07T20:47:52.529321> Setting power ON: state 0 2020-01-07T20:47:52.530088> LoRa mode 1 2020-01-07T20:47:52.530794> Setting mode: state 0 2020-01-07T20:47:52.531499> Frequency 913.880000: state 0 2020-01-07T20:47:52.532222> Use PA_BOOST amplifier line 2020-01-07T20:47:52.532946> Set LoRa power dBm to 14 2020-01-07T20:47:52.533658> Power: state 0 2020-01-07T20:47:52.534448> Get Preamble Length: state 0 2020-01-07T20:47:52.535244> Preamble Length: 8 2020-01-07T20:47:52.536002> LoRa addr 1: state 0 2020-01-07T20:47:52.536802> Raw format, not assuming any header in reception 2020-01-07T20:47:52.537597> SX1272/76 configured as LR-BS. Waiting RF input for transparent RF-serial bridge 2020-01-07T20:47:52.538555> Low-level gw status ON 2020-01-07T20:48:15.210631> Receive error 2 2020-01-07T20:48:15.211943> Resetting radio module 2020-01-07T20:48:15.212952> SX1276 detected, starting. 2020-01-07T20:48:15.213822> SX1276 LF/HF calibration 2020-01-07T20:48:15.214902> ... 2020-01-07T20:48:15.215800> Setting power ON: state 0 2020-01-07T20:48:15.216622> LoRa mode 1 2020-01-07T20:48:15.217373> Setting mode: state 0 2020-01-07T20:48:15.218127> Frequency 913.880000: state 0 2020-01-07T20:48:15.218865> Use PA_BOOST amplifier line 2020-01-07T20:48:15.219645> Set LoRa power dBm to 14 2020-01-07T20:48:15.220397> Power: state 0 2020-01-07T20:48:15.221133> Get Preamble Length: state 0 2020-01-07T20:48:15.221881> Preamble Length: 8 2020-01-07T20:48:15.222689> LoRa addr 1: state 0 2020-01-07T20:48:15.223450> Raw format, not assuming any header in reception 2020-01-07T20:48:15.224494> SX1272/76 configured as LR-BS. Waiting RF input for transparent RF-serial bridge 2020-01-07T20:48:15.225647> Low-level gw status ON

To be clear, the GW DOES process some data soon after a reboot (if I'm lucky), then nothing apart from the regular resets. (The python ThingSpeak scripts work fine if I trigger that manually).

Reading your comments on other people's experiences, it looks like things are timing out, however, this instability is getting in the way of the system working.

I found this in SX1272.h: const uint16_t MAX_TIMEOUT = 10000; //10000 msec = 10.0 sec const uint16_t MAX_WAIT = 12000; //12000 msec = 12.0 sec

That equals 22 seconds combined. Coincident?

Please give me some direction to troubleshoot this further.

Many thanks Peter

vdbpeter commented 4 years ago

Hi- an update. I had a play with the MAX_TIMEOUT, trying 30000 & 5000. Had more success with 5000. 30 sec didnt respond to any transmissions.

Returning the MAX_TIMEOUT to 10 sec and restarting the GW, I caught a transmission, then the GW resumed its 23 sec radio reset:

root@rpi-lora-gw:/home/pi/lora_gateway# python ./start_gw.py sudo ./lora_gateway --raw --mode 1 --freq 913.88 --ndl | python post_processing_gw.py | python log_gw.py ./lora_gateway: unrecognized option '--ndl' raw output from low-level gateway. post_processing_gw will handle packet format post_processing_gw.py found an alert_conf section Parsing cloud declarations [u'python CloudThingSpeak.py'] Parsed all cloud declarations post_processing_gw.py got cloud list: [u'python CloudThingSpeak.py'] Parsing cloud declarations Parsed all cloud declarations post_processing_gw.py got encrypted cloud list: [] Parsing cloud declarations [u'python CloudTTN.py'] Parsed all cloud declarations post_processing_gw.py got LoRaWAN encrypted cloud list: [u'python CloudTTN.py'] Starting thread to perform periodic gw status/tasks 2020-01-08 11:15:29.761363 post status: gw ON post status: executing periodic tasks post status: start running post status: exiting Starting thread to perform fast statistics tasks

Current working directory: /home/pi/lora_gateway SX1276 detected, starting. SX1276 LF/HF calibration ... **Power ON: state 0 LoRa mode 1 Setting mode: state 0 Frequency 913.880000: state 0 Use PA_BOOST amplifier line Set LoRa power dBm to 14 Power: state 0 Get Preamble Length: state 0 Preamble Length: 8 LoRa addr 1: state 0 Raw format, not assuming any header in reception SX1272/76 configured as LR-BS. Waiting RF input for transparent RF-serial bridge Default sync word: 0x12 Low-level gw status ON --- rxlora. dst=0 type=0x00 src=0 seq=0 len=14 SNR=6 RSSIpkt=-35 BW=125 CR=4/5 SF=12 2020-01-08T11:15:35.742226 rcv ctrl pkt info (^p): 0,0,0,0,14,6,-35 splitted in: [0, 0, 0, 0, 14, 6, -35] rawFormat(len=14 SNR=6 RSSI=-35) rcv ctrl radio info (^r): 125,5,12,913880 splitted in: [125, 5, 12, 913880] (BW=125 CR=5 SF=12) rcv timestamp (^t): 2020-01-08T11:15:35.740

adding time zone info new rcv timestamp (^t): 2020-01-08T11:15:35.740+11:00 got first framing byte --> got LoRa data prefix raw format from LoRa gateway Header[dst=1 ptype=0x10 src=8 seq=83] update ctrl pkt info (^p): 1,16,8,83,10,6,-35 valid app key: accept data number of enabled clouds is 1 --> cloud[0] uploading with python CloudThingSpeak.py python CloudThingSpeak.py "TC/99.99" "1,16,8,83,10,6,-35" "125,5,12,913880" "2020-01-08T11:15:35.740+11:00" "0000B827EBC8BB92" ThingSpeak: uploading (multiple) rcv msg to log (!) on ThingSpeak ( default , default ): ThingSpeak: will issue curl cmd curl -s -k -X POST --data field8=99.99 https://api.thingspeak.com/update?key= ThingSpeak: returned code from server is 424426 --> cloud end

Receive error 2 Resetting radio module SX1276 detected, starting. SX1276 LF/HF calibration ... Setting power ON: state 0 LoRa mode 1 Setting mode: state 0 Frequency 913.880000: state 0 Use PA_BOOST amplifier line Set LoRa power dBm to 14 Power: state 0 Get Preamble Length: state 0 Preamble Length: 8 LoRa addr 1: state 0 Raw format, not assuming any header in reception SX1272/76 configured as LR-BS. Waiting RF input for transparent RF-serial bridge Low-level gw status ON

Can you shed any light on this please? Thanks Peter

CongducPham commented 4 years ago

Hi, I really don't think it is a matter of MAX_TIMEOUT which actually only returns from the receive low-level function regularly, this in order to not being constantly in receive mode to be able to perform some other tasks. However, the fact that there is a receive error 2, may come from the reception of some bad formatted packet, which normally are discarded by CRC checking. Do you also have this issue of periodic reset when there is no message sent (just let the gw run with no sending end-device)?

vdbpeter commented 4 years ago

Thanks for your response. With no nodes running, with just the GW running, the reset occurs every 22-23 seconds.

CongducPham commented 4 years ago

Hi, how did you wired your RFM95 module on the gateway?

vdbpeter commented 4 years ago

Hi As per your documents: RPI -> RFM95W Pin17 +3.3v -> +3.3v Pin25 gnd -> gnd Pin19 MOSI -> MOSI Pin21 MISO -> MISO Pin23 SCLK -> SCK Pin7 GPIO4 -> RESET Pin24 CEO_N -> NSS

CongducPham commented 4 years ago

Because the only reason I see for the periodic reset is either loose wire or power issue. How are you powering your RPI and what model is it?

vdbpeter commented 4 years ago

It's a RPi 2B. The PSU is a 5v 2A (OEM). I swapped PSU and still have the regular reset.

Any other clues? Parts of the code I should dig deeper into?

Many thanks

vdbpeter commented 4 years ago

image Even with the radio resetting every 23 sec, and with the node transmitting every minute, the GW appears to process 1 transmission about every 5 minutes, with a few exceptions of sequential 1 minute transmissions. Any help diagnosing the problem will be appreciated. Thanks

CongducPham commented 4 years ago

Look strange, it is the first time this kind of issue is mentioned. I have currently no clue. Can you check your wiring to see if there are no loose wire? Can you also set -1 to freq in order to use the default freq to see if it is a problem with the freq setting? regards,

CongducPham commented 4 years ago

Hi, I've tested again with what I believe is exactly your settings and I have no issues. Please try to make another radio module with clean soldering or wiring to test further. regards,

vdbpeter commented 4 years ago

Hi- thanks for that. I'll test another radio module later today, but can confirm that the current wiring is correct and solid.

Please confirm that the GW as designed should respond to EVERY transmission? At this stage I only have 1 node waking and transmitting about 1/minute (still rock solid after 3 days! :-) ), so my natural expectation is that the GW processes each transmission. Is this your experience?

Just to be clear with the "default" Frequency setting. My RFM95W is the 900MHz model. If I set the "frequency" to "-1", will it still set to 913.88? Before explicitly setting it to 913.88, it was reporting as setting to 865.2 (I think- but definitely wrong band). I'll double check all that.

Thanks for your help and patience. In my experience, these sorts of issues come down to 1 of 2 things: something REALLY complex...or something REALLY silly....I hope it's at the silly end of the scale! I really like your solution, and look forward to having a solid foundational system to develop off for my IOT applications.

CongducPham commented 4 years ago

Yes, the GW should catch all uplink messages. No your frequency settings is right, set 913.88 in gateway_conf.json. BTW I believe that there is no specific version of RFM95W for 900MHz, it is same module that can be used for 868MHz and 900MHz bands. Just the antenna needs to be different. Hope that it will finally work, I see no obvious reason right now. My settings reproducing your configuration works fine for more than a day now.

vdbpeter commented 4 years ago

Hi- an update. I tried another radio module- same result. Swapped the RPi, also with same result. So, these results suggest the hardware is OK.

Next, I'll rework the source & recompile etc.

My modules are RFM95W, 915MHz version: RFM95W HopeRF

Thanks for your help.

vdbpeter commented 4 years ago

I recompiled the source, and got the same result. Is your RFM95 the same as mine? Thanks

CongducPham commented 4 years ago

Yes, it is. What is your antenna? Looks like a simple wire? It may come that. Try soldering a thin metal wire, using a paperclip for instance. I don't know how you position the radio module on the RPI but it is better if it is well positionned with the antenna up and straight.

vdbpeter commented 4 years ago

Hi. Yes, the antennae is a 78mm wire (cut to 1/4 wave length) on both radio modules. I have an SDR that verifies the node is transmitting every minute, so I'm satisfied I'm meeting basic radio parameters here. For my testing, the gw & node were very close (20cm separation). I could have over driven the receive function on the gateway radio. So I have now separated them by about 5m. No change.

What would be good is some low level utility on the RPi that verifies the radio is fully functional. Do you have anything based on the sx1272 library that would do that?

The decoding interval and resets seem too regular to be related to analog antennae function. I'm just really suspicious of the 23sec error 2 resets, and the almost exact 5 min decodes, so every 5th node transmission.

So, it still seems like it's in the gateway code.

Any chance of getting an exact copy/image of your fully working RPi2 version that you have verified works properly with the RFM95W on 913.88 MHz, please? One that I don't need to recompile? Selecting the BAND_900 on line 234 of lora_gateway.cpp necessitates recompiling (maybe shift that setting to the conf file in a future ver?). Just thinking, compiling on my machine could be doing something odd with the code.

Thanks for your help.

CongducPham commented 4 years ago

You radio seems functional, but with some stability issue that can have several reasons. As it is working some time, it is difficult to test for functionality.

The fact is that the code has been tested for a long time now and my RPI2 with the github version running at 913.88 works fine. BTW, you don't have to change anything in lora_gateway.cpp if you are using an RPI for the gateway. Just set 913.88 as frequency in gateway_conf.json.

vdbpeter commented 4 years ago

Hi, I decided to start again from fresh and configure the RPi via webadmin (no updates, no editing files, no compiling etc), following your instructions to the letter...and it now works. No resets. Rock solid all day.

Now that I have a stable system, I'll work through the Update and check out the broad feature set you've built into this system.

Thanks again for your help and patience.

CongducPham commented 4 years ago

Good to hear! best regards,