LoRa operational false when no region asserted

[shawaj]

 packet-forwarder          BALENA_APP=HELIUM-TESTNET
 packet-forwarder          DIAGNOSTICS_FILEPATH=/var/pktfwd/diagnostics
 packet-forwarder          AWAIT_SYSTEM_SLEEP_SECONDS=5
 packet-forwarder          RESET_LGW_FILEPATH=/opt/sx1302/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  2021-10-28 17:38:11,713 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).set_variant_attributes -- /opt/pktfwd/pktfwd_app.py:(91) - Variant NEBHNT-OUT1 set with reset_pin 38 and spi_bus spidev1.2
 packet-forwarder  2021-10-28 17:38:11,714 - [DEBUG] - pktfwd.pktfwd_app - (pktfwd_app.py).start -- /opt/pktfwd/pktfwd_app.py:(39) - STARTING PKTFWD
 packet-forwarder  2021-10-28 17:38:11,717 - [DEBUG] - hm_pyhelper.miner_param - (miner_param.py).await_spi_available -- /opt/pktfwd-dependencies/hm_pyhelper/miner_param.py:(217) - SPI bus spidev1.2 Configured Correctly
 packet-forwarder  2021-10-28 17:38:11,719 - [DEBUG] - hm_pyhelper.miner_param - (miner_param.py).retry_get_region -- /opt/pktfwd-dependencies/hm_pyhelper/miner_param.py:(199) - No region override set (value = False), will retrieve from miner.
 packet-forwarder  2021-10-28 17:38:11,720 - [WARNING] - hm_pyhelper.miner_param - (api.py).__retry_internal -- /opt/pktfwd-dependencies/retry/api.py:(40) - [Errno 2] No such file or directory: '/var/pktfwd/region', retrying in 60 seconds...

The latest updates to diag, pktfwd have introduced a race condition / block on starting I think.

Diag waits for "lora module ready" - Miner waits for diag, packet forwarder waits for miner.

But the way we have it set now, the packet forwarder will not return ready, stopping diag, miner and packet forwarder from operating at al

[shawaj]

[KevinWassermann94]

I am seeing this error on https://dashboard.balena-cloud.com/devices/2d271ad7452d58cf41b8848ada1c41c6/summary even though it has the location asserted

[shawaj]

Maybe we can add a way to check the LoRa will start or something similar using one of the LoRa concentrator tests.

Or, possibly a better way - would be to just have False (Awaiting Location Assert) and just normal coloured text when it is not working intentionally (i.e. when no location asserted)

Although - having a way to test the concentrator is working ok would be useful for the manufacturing tests as well...

[DCukeric]

More tickets with this issue..

[shawaj]

I am seeing this error on https://dashboard.balena-cloud.com/devices/2d271ad7452d58cf41b8848ada1c41c6/summary even though it has the location asserted

This is shows fine for me @KevinWassermann94

[KevinWassermann94]

@shawaj Not sure if it is caused by upstream? Definetly had that error

[shawaj]

Yeah it's probably due to either an upstream helium thing, or if it's pulling in a snapshot, it fails to the the region and packet forwarder gets confused

[ddn]

Just wanted to comment for anyone who panics a bit seeing this error. I also experienced it on 2021.11.30.1 on a miner that wasn't yet asserted. It resolved when it was location asserted.

[shawaj]

@ddn glad you found this then.

Whilst the error is actually true (the LoRa isn't operational when no location asserted) it's a bit of a concerning error message.

Our plan is to change it to have three different options:

• True (i.e. LoRa operational)
• False (no location asserted)
• False (potential error)

If that makes sense 🙂

[ddn]

That would be a great improvement. I was in a panic swapping Lora modules etc.

Panic partially induced by (successfully) converting an outdoor US915 nebra to a EU868 by swapping the EMMC and LoRa module from an indoor. It works perfectly but the first time I tried it was a month or so ago and I didn’t get any error. When I went to prepare to assert location, I got that error. Suffice to say I thought maybe I damaged something.

That said, from visual inspection the modules seem identical anyway and I believe the band is set in software. But I digress.

On Dec 5, 2021, at 2:13 PM, Aaron Shaw @.***> wrote:

 @ddn glad you found this then.

Whilst the error is actually true (the LoRa isn't operational when no location asserted) it's a bit of a concerning error message.

Our plan is to change it to have three different options:

True (i.e. LoRa operational) False (no location asserted) False (potential error) If that makes sense 🙂

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[shawaj]

868 and 915 are actually different hardware. They will work on the wrong frequency, but not very well... They have different SAW filters and some other things that make them different.

868 can do RU864, EU868, IN865 915 can do AU915, AS923-1/2/3/4, US915, KR920

Just FYI

[ddn]

Great info. In any case I did swap the module.

Appreciate the responses here!

On Dec 5, 2021, at 6:02 PM, Aaron Shaw @.***> wrote:

 868 and 915 are actually different hardware. They will work on the wrong frequency, but not very well... They have different SAW filters and some other things that make them different.

868 can do RU864, EU868, IN865 915 can do AU915, AS923-1/2/3/4, US915, KR920

Just FYI

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.