Helium network not working

[mrx23dot]

Hi All,

I'm trying to connect to Helium 868Mhz network from UK, based on map there should be coverage.

Code is closer to IBM v1.6 + RFM95 but should work same way.
Helium console:

code: (reverse order)

detailed field logs:
log1.txt
log2.txt

log summary

• JOINING
• EV_JOINING
• 94944: Ready for uplink
• EV_TXSTART
• 257613: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0

Not sure what to look for.

Code is simple as can be:

os_init();
LMIC_reset();  
LMIC_setLinkCheckMode(0);

LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); 
LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI); 
LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); 
LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); 
LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); 
LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); 
LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); 
LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); 
LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_MILLI); 

LMIC.dn2Dr = DR_SF9;
LMIC_setDrTxpow(DR_SF7, 20); 
do_send()  // auto joins 

[terrillmoore]

Can you connect to TTN with the same setup? Helium maps are not super reliable indications of coverage. I always try to test first with a gateway where I can see the logs.

[terrillmoore]

It looks like your appkey might be backwards. Appkey is big-endian; deveui and appeui are little endian, and appear to be reversed. I'm guessing appkey is too.

[mrx23dot]

Nice catch! The comment was wrong then. I will do some more testing, hopefully with rssi and SDR.
Unfortunately no TTN around, and I only have one RF module at hand.
Helium should constantly cross check cells nearby, I also tried multiple cells.

Shouldn't there be an 'EV_CREDENTIAL_ERROR' callback? It's a quite big decision point. Or at least ev_join_failed.
Thank you

[terrillmoore]

We can't tell whether there's a credential error. The only thing in the protocol is that the network doesn't respond. EV_JOIN_TXCOMPLETE tells you that this happened. But you can't tell if this means "my credentials are bad" or "no gateway in range" or "the uplink join request got smashed" or "the downlink join accept got smashed". (It can even mean "the closest gateway in range is not working right".) Just the way the spec is written. In EU, there's an additional constraint for duty cycle; the gateway might not be permitted (due to regulations) to send a downlink at the time the device has the Rx window open.

If you have a gateway for which you can get the logs, you can use a lorawan decoder to check the MIC against the expected credentials, and that will help find credential problems. I have to do that every so often.

You can distinguish between uplink and downlink problems by looking at the console. The network also cannot tell if the device has received the join accept until it gets a data message. If there's a downlink issue, the network console will show that the device is joined, with a devaddr and session keys, and will display the time of the uplink; but the device won't think it's joined. That rules out credential and transmit-path problems, but doesn't tell you which of the many downlink issues is the problem.

I generally recommend using two devices, if possible, each with the raw sketch, and make sure they can talk to each other. Once that's working, you can then work backwards towards the gateway.

[mrx23dot]

Wow it worked! Turned out to be the endianess.
I created a proposal to eliminate this once and for all for future users.
You vote would be welcome :)
https://www.thethingsnetwork.org/forum/t/node-keys-checksum-proposal-for-website/55322
Thanks for the help!