Lora: Documentation vs. Example code regards OTAA

[robert-hh]

There is a discrepancy between the documenattion and the example cod ein the lib regarding the auth paramter.
The documentation tells, it's a 2-tuple of (app_eui, app_key)
while the example code uses a 3-tuple, of (dev_eui, app_eui, app_key).
None of them works for me, but besides that, what's the right one?

[seb]

@robert-hh said in Lora: Documentation vs. Example code regards OTAA:

dev_eui

Hi,

Could you provide a link to where you find this discrepancy?

[robert-hh]

@seb

Documentation:
https://github.com/pycom/pycom-documentation/blob/master/chapter/tutorials/lopy/lorawan-otaa.md
Line 25:
lora.join(activation=LoRa.OTAA, auth=(app_eui, app_key), timeout=0)

Example code:
https://github.com/pycom/pycom-libraries/blob/master/examples/lorawan-nano-gateway/otaa_node.py
Line 24:
lora.join(activation=LoRa.OTAA, auth=(dev_eui, app_eui, app_key), timeout=0, dr=config.LORA_NODE_DR)

[seb]

@robert-hh said in Lora: Documentation vs. Example code regards OTAA:

https://github.com/pycom/pycom-libraries/blob/master/examples/lorawan-nano-gateway/otaa_node.py

Looking at the firmware source code:
https://github.com/pycom/pycom-micropython-sigfox/blob/master/esp32/mods/modlora.c#L1573

It seems either is fine, if you don't provide the dev_eui it is automatically set to the devices lora mac, otherwise it uses what ever was provided.

[robert-hh]

@seb Thanks. As said, it makes no difference, and I did not take the time to look into the code. But maybe it could be harmonized.

[seb]

I agree, I am now updating the example in the libraries repo. What do you mean it makes no difference? Do you not see the dev_eui change, or are you having more general LoRa issue?

[robert-hh]

@seb No change when running the code in either way.

[jmarcelino]

Hi @robert-hh
Do you mean if you use auth=(dev_eui, app_eui, app_key) with OTAA you don't see the Device EUI change to the one you are specifying?

[robert-hh]

@jmarcelino In my tests so far, neither using the 2-tuple or the 3-tuple made OTAA succeed. But I'm still trying more this night.

[jmarcelino]

I think the problem you're having with OTAA is related to you not receiving downlinks properly https://forum.pycom.io/topic/1254/ttn-otaa-join-acknowledgement-not-being-received/13 and not the Dev EUI

[robert-hh]

@jmarcelino Agreed, because that's what is see with ABP mode too.

[ssmith]

@jmarcelino Since updating to 1.16 I'm getting this error when trying to connect.

[   388.642] Received packet: {"rxpk": [{"data": "AFlERE/vvq3e6FJQ/v+krjC7ifKetjw=", "time": "2018-02-19T13:38:40.120571Z", "chan": 0, "tmst": 388895160, "stat": 1, "modu": "LORA", "lsnr": 5.0, "rssi": -17, "rfch": 0, "codr": "4/5", "freq": 918.9, "datr": "SF7BW125", "size": 23}]}
[   388.675] Push ack
[   393.694] Pull rsp
Unhandled exception in callback handler
Traceback (most recent call last):
  File "lorawan_nanogateway.py", line 386, in <lambda>
  File "lorawan_nanogateway.py", line 345, in _send_down_link
ValueError: frequency 923300000 out of range

[jmarcelino]

@ssmith
Which region are you in please and what frequency is LORA_FREQUENCY set to in config.py?

This error seems related to the recent LoRa region changes in 1.16 but it's strange that the nanogateway is able to listen on the correct frequency but not transmit on 923300000.

[ssmith]

@jmarcelino, region=LoRa.US915,. This worked fine with 1.15. and here is lora config

lora.init(mode=LoRa.LORA, frequency=918900000, power_mode=LoRa.ALWAYS_ON, tx_power=20, bandwidth=LoRa.BW_125KHZ, sf=7,
              preamble=8, coding_rate=LoRa.CODING_4_8, tx_iq=False, rx_iq=False)

[jmarcelino]

@ssmith
Could you add region=LoRa.US915 as a parameter in both lora.init() please?

[ssmith]

@jmarcelino It's there, that was a different config file from my previous test just to show the frequency. Here's the config from the nano_gateway file.

        self.lora = LoRa(
            mode=LoRa.LORA,
            region=LoRa.US915,
            frequency=self.frequency,
            bandwidth=self.bw,
            sf=self.sf,
            preamble=8,
            coding_rate=LoRa.CODING_4_5,
            tx_iq=True
        )

[ssmith]

@jmarcelino I also tried AU915 with the same result. I'll try EU next. I assume with the generic FW now that it should accept it.

[robert-hh]

@jmarcelino Cannot try more, I think I expired my downlink message quota (of 10?) for the day.

[ssmith]

@robert-hh Are you going to TTN? I've sent thousands of messages there in a day during testing.

[ssmith]

@jmarcelino Wasn't able to get EU868 to work with LoRaWAN. Gave me a frequency error. I was able to set it up and send raw LoRa between 2 LoPy4's at both 868 and 915 bands without changing the FW. Looks like it is in the LoRaWAN stack.