Helium Data-Only Hotspot project - packet forwarder keeps restarting?

[markysparks]

Hi - I thought I’d try out the Helium Hotspot project as detailed in a recent blog post. I followed through all the steps and everything seemed to go fine, my hotspot is showing up in Helium explorer but no data activity is showing up. Looking at the logs on Balena dashboard it seems that the packet-forwarder service isn’t happy and keeps restarting?

The Helium-miner service seems to be running fine.

The hardware I’m using is this:
PiHut SX1302 LoRaWAN gateway

Have attached a screenshot of my variables and what I think are the critical bits of the packet-forwarder service log files. Feel I must be missing something silly here if anybody has any ideas? thanks…

packet-forwarder INFO: upstream PUSH_DATA time-out is configured to 100 ms
packet-forwarder INFO: packets received with a valid CRC will be forwarded
packet-forwarder INFO: packets received with a CRC error will NOT be forwarded
packet-forwarder INFO: packets received with no CRC will NOT be forwarded
packet-forwarder INFO: Reference latitude is configured to 0.000000 deg
packet-forwarder INFO: Reference longitude is configured to 0.000000 deg
packet-forwarder INFO: Reference altitude is configured to 0 meters
packet-forwarder INFO: fake GPS is enabled
packet-forwarder ERROR: [main] failed to start the concentrator
packet-forwarder 2022-06-12 19:52:30,856 - [WARNING] - pktfwd.utils - (utils.py).retry_start_concentrator – /opt/pktfwd/utils.py:(226) - lora_pkt_fwd stopped with code=1.
packet-forwarder 2022-06-12 19:52:30,858 - [WARNING] - pktfwd.pktfwd_app - (pktfwd_app.py).start – /opt/pktfwd/pktfwd_app.py:(59) - Shutting down concentrator.
packet-forwarder 2022-06-12 19:52:30,859 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).stop – /opt/pktfwd/pktfwd_app.py:(79) - STOPPING PKTFWD
packet-forwarder 2022-06-12 19:52:30,863 - [INFO] - main - (main.py).start – /opt/pktfwd/main.py:(106) - Stopping and cleaning up pktfwd
packet-forwarder 2022-06-12 19:52:30,864 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).stop – /opt/pktfwd/pktfwd_app.py:(79) - STOPPING PKTFWD
packet-forwarder 2022-06-12 19:52:35,319 - [DEBUG] - main - (main.py).validate_env – /opt/pktfwd/main.py:(63) - Starting with the following ENV:
packet-forwarder VARIANT=DIY-RAK2287
packet-forwarder REGION_OVERRIDE=EU868
packet-forwarder REGION_FILEPATH=/var/pktfwd/region
packet-forwarder SX1301_REGION_CONFIGS_DIR=/opt/pktfwd/config/lora_templates_sx1301
packet-forwarder SX1302_REGION_CONFIGS_DIR=/opt/pktfwd/config/lora_templates_sx1302
packet-forwarder SENTRY_KEY=False
packet-forwarder BALENA_ID=2404e35ddf56e9d844556e368792ab67
packet-forwarder BALENA_APP=helium-data-hotspot
packet-forwarder DIAGNOSTICS_FILEPATH=/var/pktfwd/diagnostics
packet-forwarder AWAIT_SYSTEM_SLEEP_SECONDS=5
packet-forwarder RESET_LGW_FILEPATH=/opt/reset_lgw.sh
packet-forwarder UTIL_CHIP_ID_FILEPATH=/opt/sx1302/chip_id
packet-forwarder ROOT_DIR=/opt
packet-forwarder SX1302_LORA_PKT_FWD_FILEPATH=/opt/sx1302/lora_pkt_fwd
packet-forwarder SX1301_LORA_PKT_FWD_DIR=/opt/sx1301
packet-forwarder
packet-forwarder 2022-06-12 19:52:35,321 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).set_variant_attributes – /opt/pktfwd/pktfwd_app.py:(91) - Variant DIY-RAK2287 set with reset_pin 17 and spi_bus spidev0.0
packet-forwarder 2022-06-12 19:52:35,321 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).start – /opt/pktfwd/pktfwd_app.py:(39) - STARTING PKTFWD
packet-forwarder 2022-06-12 19:52:35,324 - [DEBUG] - hm_pyhelper.miner_param - (miner_param.py).await_spi_available – /opt/pktfwd-dependencies/hm_pyhelper/miner_param.py:(217) - SPI bus spidev0.0 Configured Correctly
packet-forwarder 2022-06-12 19:52:35,325 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).prepare_to_start – /opt/pktfwd/pktfwd_app.py:(73) - Region set to EU868
packet-forwarder 2022-06-12 19:52:35,326 - [DEBUG] - pktfwd.utils - (utils.py).await_system_ready – /opt/pktfwd/utils.py:(53) - Waiting 5 seconds for systems to be ready
packet-forwarder 2022-06-12 19:52:40,332 - [DEBUG] - pktfwd.utils - (utils.py).await_system_ready – /opt/pktfwd/utils.py:(55) - System now ready
packet-forwarder 2022-06-12 19:52:40,333 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).prepare_to_start – /opt/pktfwd/pktfwd_app.py:(76) - Finished preparing pktfwd
packet-forwarder 2022-06-12 19:52:41,991 - [DEBUG] - pktfwd.utils - (utils.py).is_concentrator_sx1302 – /opt/pktfwd/utils.py:(82) - Command ‘[’/opt/sx1302/chip_id’, ‘-d’, ‘/dev/spidev0.0’]’ returned non-zero exit status 1.
packet-forwarder 2022-06-12 19:52:41,992 - [DEBUG] - pktfwd.utils - (utils.py).replace_sx1301_global_conf_with_regional – /opt/pktfwd/utils.py:(131) - Copying SX1301 global conf from /opt/pktfwd/config/lora_templates_sx1301/EU-global_conf.json to /opt/global_conf.json
packet-forwarder 2022-06-12 19:52:41,997 - [DEBUG] - pktfwd.utils - (utils.py).replace_sx1301_global_conf_with_regional – /opt/pktfwd/utils.py:(134) - Copying SX1301 local conf from /opt/pktfwd/config/lora_templates_sx1301/local_conf.json to /opt/local_conf.json
packet-forwarder CONCENTRATOR_RESET_PIN parameter not passed in, using value from the environment (val=17)
packet-forwarder CoreCell reset through GPIO17…
packet-forwarder CONCENTRATOR_RESET_PIN parameter not passed in, using value from the environment (val=17)
packet-forwarder CoreCell reset through GPIO17…

Maybe these are the critical bits:

(miner_param.py).await_spi_available – /opt/pktfwd-dependencies/hm_pyhelper/miner_param.py:(217) - SPI bus spidev0.0 Configured Correctly

(utils.py).is_concentrator_sx1302 – /opt/pktfwd/utils.py:(82) - Command ‘[’/opt/sx1302/chip_id’, ‘-d’, ‘/dev/spidev0.0’]’ returned non-zero exit status 1.

I wonder if there’s a problem with the SX1302 hardware I’m using.

[nmaas87]

Hey @markysparks - this is looking good to me, but maybe adding the RUST_BACKTRACE = full variable will even output more infos (however, I think this will only be valid for the helium services).

It looks like the pinout does not match your used hat.
Looking at the original WM1302 Pi Hat: https://files.seeedstudio.com/products/113100022/5371617183671_.pic_hd.jpg
And at your Hat:
https://cdn.shopify.com/s/files/1/0176/3274/files/SX1302-LoRaWAN-Gateway-HAT-details-inter.jpg
Next to the config data of the DIY-RAK2287:
hm-pyhelper/hardware_definitions.py at f8b2d8ceb90cfcd1da658a73e3741cc6de2ff1ff · NebraLtd/hm-pyhelper · GitHub

We can see that the reset pin is wrong:

# Nebra Indoor Hotspot
'DIY-RAK2287': {
    'RESET': 17,  -> GPIO17, PIN11 (on WM1302) -> GPIO23, PIN16 (your board)
    'STATUS': 20, -> GPIO20, PIN38 (on WM1302 it is NC/not connected) -> NC on your board
    'BUTTON': 21, -> GPIO21, PIN40 (on WM1302 it is NC) -> NC on your board
    }

So basically you would need to change the RESET variable to 23 and then it should work.

But maybe @mpous wants to add something to that?

[mpous]

Thanks @nmaas87

@markysparks please test what Nico mentioned. On the other hand, i saw now that the current gatewayrs version is the 27 and the project is using the 21. I will try to upgrade it!

Let’s stay connected

Marc

[markysparks]

Hi Marc,

Is there an easy way for me to change the RESET variable to 23? I tried adding a Balena Device variable of RESET to 23 which didn’t work, also tried adding CONCENTRATOR_RESET_PIN as a variable set to 23 after looking at the reset_lgw.sh file.

I set the project up using the ‘deploy with Balena’, maybe I’ll have to clone the project from GitHub and use the Balena CLI.

Mark.

[mpous]

Hello @markysparks apologizes for the delay answering this!

Due the changes on the Light Hotspots, I will need to update the gatewayrs version. I created a github issue on the repo → Update miner version · Issue #11 · mpous/helium-data-hotspot · GitHub

I will try to work on this next week and keep you updated! Feel free to try to PR as well if you feel comfortable

[mpous]

@markysparks could you please try to re-deploy with the latest version from here? GitHub - mpous/helium-data-hotspot

I also updated the balenaHub project → balenaHub: an easier way to find and publish fleets, projects, and blocks for edge devices

I tested myself and it worked well on my side the new update! Let me know if it works for you

[markysparks]

Hi Marc,

Thanks for that - I re-deployed to my device which all went OK but unfortunately the packet forwarder still keeps restarting. On startup I can see that its still using a RESET GPIO 17 when it should be 23 according to @nmaas87 - I have two variables RESET and CONCENTRATOR_PIN_RESET set to 23 but that doesn’t make any difference. Anything else I can try?

Thanks
Mark.

packet-forwarder CONCENTRATOR_RESET_PIN parameter not passed in, using value from the environment (val=17)
packet-forwarder CoreCell reset through GPIO17…
packet-forwarder CONCENTRATOR_RESET_PIN parameter not passed in, using value from the environment (val=17)
packet-forwarder CoreCell reset through GPIO17…
packet-forwarder *** Beacon Packet Forwarder for Lora Gateway ***
packet-forwarder Version: 4.0.1
packet-forwarder *** Lora concentrator HAL library version info ***
packet-forwarder Version: 5.0.1;
packet-forwarder ***
packet-forwarder INFO: Little endian host
packet-forwarder INFO: found global configuration file global_conf.json, parsin

[mpous]

@markysparks what VARIANT variable are you using?

[markysparks]

DIY-RAK2287

[mpous]

@markysparks could you please try to define the RESET PIN on the 17?

[markysparks]

@mpous sorry did you mean set the variable RESET to 17, not quite sure if that’s what you mean or something else… (doing that or RESET_PIN 17 doesn’t work)

[mpous]

@markysparks actually i’m not sure there is any variable for defining the SPI pin on this project. The VARIANT variable might define this. However can you try CONCENTRATOR_RESET_PIN variable as i see on your logs?

Could you please try and share all the logs? Thanks!

[markysparks]

@mpous I have tried setting a variable CONCENTRATOR_RESET_PIN and have attached the log file. To me it looks like the packet forwarder is not picking up this variable (I had also tried setting this variable to 23 in the past):

CONCENTRATOR_RESET_PIN parameter not passed in, using value from the environment (val=17)

CoreCell reset through GPIO17…

helium-data-hotspot_round-car-30.06.22_10_01_42_(+0100).txt (93.9 KB)

Seems strange that the log message says ‘using value from the environment’ but obviously doesn’t pick up this value. So just to confirm, even if I set this variable to 23 I still get the log message:

CONCENTRATOR_RESET_PIN parameter not passed in, using value from the environment (val=17)
packet-forwarder CoreCell reset through GPIO17…

Thanks
Mark.

[mpous]

@markysparks sorry because i didn’t check the concentrator you are using. Did you try the CONCENTRATOR_RESET_PIN 16?

i’m trying to understand the pinout and it looks like the RESET is the D23 which is the pin 16. Am i right?

[markysparks]

@mpous Yes your pinout is correct - that is the concentrator I am using.

I tried setting CONCENTRATOR_RESET_PIN to 16 but the packet forwarder still keeps restarting and the log file still says:

CONCENTRATOR_RESET_PIN parameter not passed in, using value from the environment (val=17)
packet-forwarder CoreCell reset through GPIO17…

So it seems the CONCENTRATOR_RESET_PIN variable does not get picked up by the packet forwarder.

thanks
Mark.

[mpous]

It looks like the parameter is not properly set here.

I know another user using this UDP packet forwarder from RAK here that you can add on the docker-composefrom and change the MODELto SX1302and add RESET_GPIO: 16.

[markysparks]

@mpous great thanks! So I understand I should use the ‘udp-packet-forwarder’ section from the docker-compose file you linked to, change the ‘environment’ section variable MODEL to SX1302 and add another variable RESET_GPIO: 16. thus:

environment:
- MODEL=“SX1302”
- RESET_GPIO=16

is that what you mean?

I’m not quite sure how I can do this (i.e. change the docker-compose file) as the project was deployed using the ‘Deploy with Balena’ link. I could take a copy of the GitHub repo, make the changes and redeploy but wouldn’t I have to go through the process of setting up the hotspot again?

Sorry if I’m missing something obvious…

Thanks
Mark.

[mpous]

Yes @markysparks you need to clone the repository on your computer, and get into the docker-compose and change the variables.

If this is too complex, you can try to Deploy With balena this repo and try to change the variables from balena Cloud?

[markysparks]

@mpous I thought the quickest way was to ‘deploy with Balena’ that repo you linked to. The packet forwarder now seems to be working However I had to set the RESET_GPIO to 23 rather than 16 (see the original message in this thread from @nmaas87), I also had to set a variable CONCENTRATOR to SX1302 otherwise it complained. Have attached a screenshot of the variables I now have set. I will also attached a log file.

Only thing is I can’t see any packets being forwarded yet - maybe I have to be patient.

udp-packet-forwarder ##### 2022-06-30 12:54:25 GMT #####
udp-packet-forwarder ### [UPSTREAM] ###
udp-packet-forwarder # RF packets received by concentrator: 0
udp-packet-forwarder # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
udp-packet-forwarder # RF packets forwarded: 0 (0 bytes)
udp-packet-forwarder # PUSH_DATA datagrams sent: 1 (162 bytes)
udp-packet-forwarder # PUSH_DATA acknowledged: 0.00%
udp-packet-forwarder ### [DOWNSTREAM] ###
udp-packet-forwarder # PULL_DATA sent: 3 (0.00% acknowledged)
udp-packet-forwarder # PULL_RESP(onse) datagrams received: 0 (0 bytes)
udp-packet-forwarder # RF packets sent to concentrator: 0 (0 bytes)
udp-packet-forwarder # TX errors: 0
udp-packet-forwarder ### SX1302 Status ###
udp-packet-forwarder # SX1302 counter (INST): 390885427
udp-packet-forwarder # SX1302 counter (PPS): 389888205
udp-packet-forwarder # BEACON queued: 0
udp-packet-forwarder # BEACON sent so far: 0
udp-packet-forwarder # BEACON rejected: 0
udp-packet-forwarder ### [JIT] ###
udp-packet-forwarder src/jitqueue.c:440:jit_print_queue(): INFO: [jit] queue is empty
udp-packet-forwarder #--------
udp-packet-forwarder src/jitqueue.c:440:jit_print_queue(): INFO: [jit] queue is empty
udp-packet-forwarder ### [GPS] ###
udp-packet-forwarder # Invalid time reference (age: 1656593665 sec)
udp-packet-forwarder # GPS coordinates: latitude 51.80073, longitude 1.13367, altitude 2 m
udp-packet-forwarder ##### END #####
udp-packet-forwarder
udp-packet-forwarder JSON up: {“stat”:{“time”:“2022-06-30 12:54:25 GMT”,“lati”:51.80073,“long”:1.13367,“alti”:2,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“temp”:0.0}}

The only entry in the helium-miner log is this:

helium-miner INFO updated routing to height 1420250, module: dispatcher
helium-miner INFO no update found, module: updater

Thanks again for your help - let me know if you think I have to redo some of the helium setting up again, I’m not sure if its working correctly even now but will monitor to see if any data flows through.
helium-data-hotspot_round-car-30.06.22_13_59_10_(+0100).txt (64.9 KB)

[mpous]

@markysparks looks like it’s working, no? More questions:

Do you have the gateway_key.bin in its place?
Could you please confirm you have a node sending data and it’s managed with this hotspot?