Question: How to configure for 915 Mhz LoraWAN Gateway? about iotedge-lorawan-starterkit

[ronniesa]

We already have tested and adapted our code for 915. In the dev-02-oneweek branch you can find a version that works with the Seeed 915 kit. You can also find in the Arduino "US" folder examples for the device part using US freq. We will merge it all back to master once we are ready with the next preview. Btw pay attention in the doc that the new dev-02.... uses desired properties instead on tag for lora device twin

[gerfen]

Thanks for the quick reply! I'll take a look. I'd like to leave this issue open for a bit longer in case I have further questions.

[ronniesa]

Rember to set on the LoRaWanPktFwrModule the environment variable: REGION="US"
"env": {
"REGION": {
"value": "US"
},

[ronniesa]

if the container LoRaWanPktFwrModule fails to start and you are creating the container in Windows make sure that this file: LoRaEngine\modules\LoRaWanPktFwdModule\start_pktfwd.sh is using LF and not CRLF. You can set it in VSCode

[gerfen]

To set the environment variable I need to add a ".env" file LoRaEngine\modules\LoRaWanPktFwdModule or should I add that to local_conf.json?

[ronniesa]

you add on the deployment manifest: iotedge-lorawan-starterkit\LoRaEngine\deployment.template.json or via the portal. In the manifest is better because it stays there.....

[gerfen]

Ah, makes sense. Thanks!

I believe this is the correct placement?

"LoRaWanPktFwdModule" {
... elided..
"env": {
"RESET_PIN": {
"value": "7"
},
"REGION": {
"value": "US"
}
},
...elided..
}

__

[Mandur]

Yes, this is correct, did it work ?

[gerfen]

Well the LoRaWanPktFwdModule starts and stays running now -- it ran the entire weekend. I have yet to see any data captured from my sensor. FWIW, I have a couple of The Things Nodes. I am able to get one to connect to the gateway but I'm not seeing any data arrive in the Azure IoT Hub. I was going to start digging into log files a bit later today. Do you have any suggestions on how to diagnose? Thanks!

[Mandur]

Sure, normally you could see the output in the pktFwdContainer logs with the command
docker logs -f LoRaWanPktFwdModule
By default our Packet Forwarder module send the data to our local LoRaWan network server, you can see the logs with the command:
docker logs -f LoRaWanNetworkSrvModule
You can configure additional logs or monitoring by following options here : https://github.com/Azure/iotedge-lorawan-starterkit/tree/dev-0.2#monitoring
Our network server module then send directly the data to IoT Hub and there are no TTN node by default involved by default. So, normally you should see your data on your IoT hub without any additional configuration necessary.
Let me know if this help! Otherwise please feel free to paste some snippet of the logs here so I can help you out troubleshoot it.

[gerfen]

Thanks for the guidance. Here is a small amount of output from docker logs -f LoRaWanPktFwdModule:

2018-10-30 13:57:24 GMT

[UPSTREAM]

RF packets received by concentrator: 1

CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%

RF packets forwarded: 0 (0 bytes)

PUSH_DATA datagrams sent: 1 (111 bytes)

PUSH_DATA acknowledged: 0.00%

[DOWNSTREAM]

PULL_DATA sent: 3 (100.00% acknowledged)

PULL_RESP(onse) datagrams received: 0 (0 bytes)

RF packets sent to concentrator: 0 (0 bytes)

TX errors: 0

BEACON queued: 0

BEACON sent so far: 0

BEACON rejected: 0

[JIT]

SX1301 time (PPS): 1652386336

src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty

[GPS]

GPS sync is disabled

END

JSON up: {"stat":{"time":"2018-10-30 13:57:24 GMT","rxnb":1,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
INFO: [down] PULL_ACK received in 1 ms
INFO: [down] PULL_ACK received in 1 ms
INFO: [down] PULL_ACK received in 1 ms

I notice that CRC_Fail is 100%. I'm not sure how to interpret the logs WRT whether or not I'm receiving data from the node.

When I attempt to look at "docker logs -f LoRaWanNetworkSrvModule" I get the following error:

"error from daemon in stream: Error grabbing logs: open /var/lib/docker/containers/c45ca26398aaaa435a134c6e69b09e58c6f47e146b7ea2f5dbb81080c8e56d4/c45ca26398aaaa435a134c6e69b09e58c6f47e146b7ea2f5dbb81080c8e56d4-json.log: no such file or directory".

Any advice on how to resolve this issue would be appreciated.

Thanks!

[gerfen]

I was able to get docker to output the logs for the LoRaWanNetworkSrvModule. It started working after I robooted my RPi. I'm now seeing this in VS Code. Should the LoRaWanPktFwdModule aslo show up as running (green) lie the other modules shown below? FWIW, executing sudo iotedge list shows that the LoRaWanPktFwdModule is running.

Also I'm a bit unclear as to how to generate the AppEUI and AppKey. The Things Network auto generates those when an application is created. Is there something equivalent for Azure IoT Hub? Can you provide guidance on how to generate the identifiers and keys.

Thanks again for all of the assistance.

[Mandur]

Thanks for the information, a few more questions to help you drill down on the problem: (sorry I know it is a lot of question but I want to make sure to get the issue quick enough ;), feel free to reply in multiple messages when you have time)

• Can you check at the very start of the LoRaWanPktFwdModule logs if it boots up in EU or US configuration? (There should be a line "US region detected." or "EU region detected." )
• Regarding the AppEUI and AppKey, you can choose your keys (of correct length), the important part is to correctly input them into your device twin as described here : https://github.com/Azure/iotedge-lorawan-starterkit/tree/dev-0.2#abp-personalization-and-otaa-over-the-air-provisioning
• Just checking : You took the code and rebuilt the container from the dev-0.2 branch correct? did you redeployed the container to the iotedge? Did you also republished the function?
• What is the code running on your Arduino? Are you running one of our US samples ?
• I am not familiar with the VS Code view you pasted here above, but I find it strange, Could you also check the log of the LoRaWanNetworkSrvModule (docker logs -f LoRaWanNetworkSrvModule) ?

[ronniesa]

You can generate the keys with this tool: https://www.loratools.nl/#/keys (for testing). We will have in the future a cmd util that does the device provisiong and generate the keys....

[gerfen]

@Mandur - I have been working off the dev-0.2-oneweek. I will switch to dev-0.2 and will rebuild and republish. I should reiterate that I am using the Things Network Node for my node/sensor.

My configuration appears to be broken as the logs for LoRaWanPktFwdModule has "No region detected in environment variables, defaulting to EU" so that may explain why I'm not seeing any data.

The logs for the LoRaWanNetworkSrvModule show that an attempt is made to get the "properties from the device twin". However this morning the initialization is failing due to a timeout. I will recheck after switching branches and redeploying.

@ronniesa - Thanks for the info on generating keys

[gerfen]

Here is the sketch that I am using for my TTN node:

`#include <TheThingsNode.h>

// Set your AppEUI and AppKey

const char *appEui = "70B3D57ED0013BA7";
const char *appKey = "c44b40833bb049c1b47d974e53cbdf3c";

#define loraSerial Serial1
#define debugSerial Serial

// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan TTN_FP_US915

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);
TheThingsNode *node;

#define PORT_SETUP 1
#define PORT_INTERVAL 2
#define PORT_MOTION 3
#define PORT_BUTTON 4

//Decoder payload function
//------------------------

function Decoder(bytes, port) {
var decoded = {};
var events = {
1: 'setup',
2: 'interval',
3: 'motion',
4: 'button'
};
decoded.event = events[port];
decoded.battery = (bytes[0] << 8) + bytes[1];
decoded.light = (bytes[2] << 8) + bytes[3];
if (bytes[4] & 0x80)
decoded.temperature = ((0xffff << 16) + (bytes[4] << 8) + bytes[5]) / 100;
else
decoded.temperature = ((bytes[4] << 8) + bytes[5]) / 100;
return decoded;
}
*/

void setup()
{
loraSerial.begin(57600);
debugSerial.begin(9600);

// Wait a maximum of 10s for Serial Monitor
while (!debugSerial && millis() < 10000)
;

// Config Node
node = TheThingsNode::setup();
node->configLight(true);
node->configInterval(true, 60000);
node->configTemperature(true);
node->onWake(wake);
node->onInterval(interval);
node->onSleep(sleep);
node->onMotionStart(onMotionStart);
node->onButtonRelease(onButtonRelease);

// Test sensors and set LED to GREEN if it works
node->showStatus();
node->setColor(TTN_GREEN);

debugSerial.println("-- TTN: STATUS");
ttn.showStatus();

debugSerial.println("-- TTN: JOIN");
ttn.join(appEui, appKey);

debugSerial.println("-- SEND: SETUP");
sendData(PORT_SETUP);
}

void loop()
{
node->loop();
}

void interval()
{
node->setColor(TTN_BLUE);

debugSerial.println("-- SEND: INTERVAL");
sendData(PORT_INTERVAL);
}

void wake()
{
node->setColor(TTN_GREEN);
}

void sleep()
{
node->setColor(TTN_BLACK);
}

void onMotionStart()
{
node->setColor(TTN_BLUE);

debugSerial.print("-- SEND: MOTION");
sendData(PORT_MOTION);
}

void onButtonRelease(unsigned long duration)
{
node->setColor(TTN_BLUE);

debugSerial.print("-- SEND: BUTTON");
debugSerial.println(duration);

sendData(PORT_BUTTON);
}

void sendData(uint8_t port)
{
// Wake RN2483
ttn.wake();

ttn.showStatus();
node->showStatus();

byte *bytes;
byte payload[6];

uint16_t battery = node->getBattery();
bytes = (byte *)&battery;
payload[0] = bytes[1];
payload[1] = bytes[0];

uint16_t light = node->getLight();
bytes = (byte *)&light;
payload[2] = bytes[1];
payload[3] = bytes[0];

int16_t temperature = round(node->getTemperatureAsFloat() * 100);
bytes = (byte *)&temperature;
payload[4] = bytes[1];
payload[5] = bytes[0];

ttn.sendBytes(payload, sizeof(payload), port);

// Set RN2483 to sleep mode
ttn.sleep(60000);

// This one is not optionnal, remove it
// and say bye bye to RN2983 sleep mode
delay(50);
}`

[Mandur]

This is interresting, would you be available for a remote session in the next days. I feel we could be much faster in addressing your problems.

[gerfen]

Yes. I'm available today and tomorrow. I'll be OOO on Friday. How would you like to do the remote session? Skype?

Thanks!

[gerfen]

After switching to the dev-0.2 branch, setting the region to US and redeploying, I can see that the LoRaWanPktFwdModule is now being configured to use the US region. Sadly, I'm still not seeing any data from my node.

[Mandur]

Let's do it tomorrow then, Skype is perfect here is my Skype handle : XXX

[Mandur]

Oh that's good new, we are making progress.
I suspect the problem comes from the fact TTN frequency plan is different from the one we use in US. You could try to change the content of the file in /LoRaEngine/modules/LoRaWanPktFwdModule/global_conf.us.json to match ttn configuration (just replace everything) here : https://github.com/TheThingsNetwork/gateway-conf/blob/master/US-global_conf.json.
then rebuild containers and republish everything. Otherwise we can try tomorrow together :)

[gerfen]

I'm in the PDT time zone. Please let me know what time works best for you tomorrow. I have sent a Skype message to you as well.

[Mandur]

We were able to make the gateway running. It was probably a version mix deployment problem and the frequency list had to be the one's from TTN as suspected.
I will close the issue if no other problems.