azure / iotedge-lorawan-starterkit Goto Github PK

Sample implementation of LoRaWAN components to connect LoRaWAN antenna gateway running IoT Edge directly with Azure IoT.

Home Page: https://azure.github.io/iotedge-lorawan-starterkit/2.2.1

License: Other

C++ 1.52% C# 96.99% Shell 0.48% HCL 0.07% PowerShell 0.19% Bicep 0.75%

azure-iot iot-edge lorawan azure-deployment raspberry-pi lora-gateway basics-station iot azure hacktoberfest

iotedge-lorawan-starterkit's Introduction

Azure IoT Edge LoRaWAN Starter Kit

The LoRaWAN starter kit is an OSS cross platform private network implementation of the LoRaWAN specification built for connectivity to Azure IoT Hub. It enables users to setup their own LoRaWAN network that can connect to LoRa based nodes (sensors) and send decoded message packets to Azure IoT Hub for cloud based processing, analytics and other workloads. Alternatively, it allows sending commands from the cloud to the end nodes. The goal of the the project is to provide guidance and a reference for Azure IoT Edge users to experiment with LoRaWAN technology.

Features
Prerequisites
Getting Started
Known Issues and Limitations
Tested Gateways
Support
Contributing

Features

LoRaWAN 1.0.2 implementation (see LoRaWAN Specification Support for more details)
Device and Gateway management done completely through Azure IoT Hub.
Bi-directional communication between LoRa end devices and Azure cloud.
Custom packet decoding framework.
Identity Translation for LoRa devices with caching support.
Partial Offline and Casually connected Gateways scenarios.*
Easy deployment and setup using Azure ARM templates.
Small to Midsize Scalability Tests.
Simulator for development and testing without the need to own a Gateway.

Prerequisites

The following should be completed before proceeding with the LoRaWAN starter kit development or deployment in your environment.

You must have an Azure subscription. Get an Azure Free account to get started.
We are based on Azure IoT Edge so it is important that you understand the concepts and deployment model for Azure IoT Edge. Refer to Azure IoT Edge documentation to see how it works.
Understand how LoRa and LoRaWAN works. A great primer is available at the LoRa Alliance website.
To test the solution on a device, you need to have a LoRaWAN Device Kit Gateway and a LoRa end node. We have some recommendations in the Tested Gateways section below.

Getting Started

We have a variety of ways you can get started with the kit, chose the appropriate documentation based on your persona and applicability.

Setup a LoRaWAN Gateway: We provide an easy to use Azure ARM template and deployment guidance to get you quickly started with the LoRaWAN starter kit. Use the Quick Start to setup a LoRaWAN Gateway and connect to LoRA end nodes.
Upgrade an existing installation: Refer to the upgrade guide for instructions and tips for a clean upgrade.
Develop and debug the LoRaWAN starter kit: If you are a developer and want to contribute or customize the LoRaWAN starter kit, refer to our Developer Guidance for more details on how to build, test and deploy the kit in your dev environment. We also support a
Enable a gateway or device to be compatible with the starter kit: We have developed the LoRaWAN starter kit agnostic of a device manufacturer implementation and focussed on the specifics on underlying architectures (arm, x86). However, we understand that device manufacturers can have specific requirements; these could be specific to a gateway and the packet forwarders they use or to the LoRa nodes and the decoders the device may use. We have provided specific instructions on making these specialized hardware compatible with our kit. You can follow these instructions depending on your scenarios and also have your device gateway highlighted on our repo.

Known Issues and Limitations

Refer to Known Issues for known issues, gotchas and limitations.

Tested Gateways

Support

The LoRaWAN starter kit is an open source solution, it is NOT a Microsoft supported solution or product. For bugs and issues with the codebase please log an issue in this repo.

Contributing

If you would like to contribute to the IoT Edge LoRaWAN Starter Kit source code, please base your own branch and pull request (PR) off our dev branch. Refer to the Dev Guide for development and debugging instructions.

Create a release

You can create a release with the following steps:

Write release notes

Write release notes to the release notes documentation.

Run the Release workflow to create a draft release

Go to the Create draft release workflow and specify the release version before running the workflow.

Create and merge 2 PRs

The release workflow will create 2 branches:

docs/release-${RELEASE_VERSION}-${GITHUB_RUN_ID} This branch updates the Button URL.
feature/update-version-${RELEASE_VERSION}-${GITHUB_RUN_ID} This branch updates the Starter Kit version in Bicep.

Created 2 PRs from these branches, verify the PRs look good and merge them.

Update master

Push dev branch to master

Add a release description and publish the release

In Github, select the release created by the workflow, add a good description, and publish the release.

iotedge-lorawan-starterkit's People

Contributors

Stargazers

Watchers

iotedge-lorawan-starterkit's Issues

An AMQP error occurred (condition='amqp:internal-error') during join requests

I'm receiving "An AMQP error occurred (condition='amqp:internal-error')" for some of my devices when they are trying to join my gateway. I started to get this error afterjoining 97 devices. Is this some sort of limitation of the iotedge-lorawan-starterkit code or Azure IoT? Or is is a bug?

Expected Behavior

Hope to be able to join about 120 devices to a single gate/Azure IoT hub.

Current Behavior

After

Steps to Reproduce

Set up gateway with 1.0.0 release
Register 110 or more devices with Azure IoT Hub
Power up the devices to initiate the join sequence.
Around 97 device the error starts to appear.

Context (Environment)

Device (Host) Operating System

Ubuntu 16.04

Architecture

arm32

Container Operating System

LoRaWAN Module Version

Docker

Logs

2019-04-11 20:06:23.100 Physical dataUp {"rxpk":[{"tmst":1941663867,"chan":8,"rfch":0,"freq":903.000000,"stat":1,"modu":"LORA","datr":"SF8BW500","codr":"4/5","lsnr":-3.5,"rssi":-110,"size":23,"data":"AAAAAAAQehMAXUIAABB6EwBDikN1caQ="}]}
2019-04-11 20:06:23.101 00137A100000425D: join request received
2019-04-11 20:06:23.101 00137A100000425D: querying the registry for OTAA device
2019-04-11 20:06:23.157 00137A100000425D: using edgeHub local queue
2019-04-11 20:06:23.158 00137A100000425D: getting device twin
2019-04-11 20:06:23.222 00137A100000425D: could not retrieve device twin with error: An AMQP error occurred (condition='amqp:internal-error').
2019-04-11 20:06:23.222 00137A100000425D: join refused: error initializing OTAA device, getting twin failed
2019-04-11 20:06:23.222 00137A100000425D: processing time: 00:00:00.1220033
2019-04-11 20:06:23.222 00137A100000425D: join refused: unknown device
2019-04-11 20:06:26.317 Statistic: {"stat":{"time":"2019-04-11 20:06:26 GMT","rxnb":9,"rxok":8,"rxfw":8,"ackr":100.0,"dwnb":0,"txnb":0}}

Additional Information

Question: Response message from Class C direct message?

My class C devices have the ability to send a response message after receiving a direct message. For example:

Currently the returned payload from my successful calls are null.

{"status":200,"payload":null}

Is this scenario supported in the currently release?

Question: OS for AAEON AIOT-ILRA01 LoRa® Certified Intel® Based Gateway and Network Server?

Hi,

I just received an AAEON AIOT-ILRA01 gateway configured for US 915 Mhz. I'm in the process of configuring the gateway and I was surprised to see that I have a choice to boot into Windows 8.1 or Android. I expected to see some flavor of Linux. Could you provide an overview on how your team configured the 868 Mhz unit?

Thanks!

--Michael

How authentication works

How does the authentication works? A device (leaf) is pushed the AppKey from IoT Hub device twin. Is IoT Edge afterwards quering IoT Hub to retrieve th AppKey for that device and authenticate the communication with it? My understanding is that IoT Edge running the LoRaWAN Server should in fact be responsible about authentication with devices...

Quick Start Deploy fails on function

Quick Start template fails.

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{\r\n "Code": "BadRequest",\r\n "Message": "There was a conflict. The remote server returned an error: (400) Bad Request.",\r\n "Target": null,\r\n "Details": [\r\n {\r\n "Message": "There was a conflict. The remote server returned an error: (400) Bad Request."\r\n },\r\n {\r\n "Code": "BadRequest"\r\n },\r\n {\r\n "ErrorEntity": {\r\n "ExtendedCode": "01020",\r\n "MessageTemplate": "There was a conflict. {0}",\r\n "Parameters": [\r\n "The remote server returned an error: (400) Bad Request."\r\n ],\r\n "Code": "BadRequest",\r\n "Message": "There was a conflict. The remote server returned an error: (400) Bad Request."\r\n }\r\n }\r\n ],\r\n "Innererror": null\r\n}"}]}

Question: How to resolve deployment issues from VS Code?

When I attempt to Build and Push IoT Edge Solution I get the following error:

Sending build context to Docker daemon 2.523 MB
Step 1/13 : FROM microsoft/dotnet:2.0-sdk AS build-env
Error parsing reference: "microsoft/dotnet:2.0-sdk AS build-env" is not a valid repository/tag: invalid reference format

I've confirmed that my Docker installation matches the server. I'm running 17.03.1-ce-rc1-win3.

As far I can tell, I've set up VS Code with all of the tooling to publish IotEdge modules. Any suggestions to resolve this would be greatly appreciated.

LoRaEngin gives MIC validation error with ABP message from Simulator

I want to test the Lora Engine separated by the Simulator as described in the documentation.
I've created a simple ABP device in testconfig.json used for both Engine and Simulator. I've added the AppSKey, NetSkey, DevAddr as desired props in IoT Hub.

Now if I run from VS first the Simulator and then the Engine I seed that the device is found in IoT hub, but I get an error validating the MIC in the Engine

I didn't expect a validation error for MIC, debugging with VS it seems related to the 32SupportdFcnt that should be true to go on, but in my case it's false.

What am I missing?

The Docker can not work in US915

Hi,
I'm testing the IoT edge Docker on RAK833 + RPi.
It works fine in EU868, but it can not work in US915.
Then i compare the central frequency of this Docker with TTN, the result is shown in the following picture:

As you see, they are different.
Then, i modify the Azure central frequency from "902700000" to "904300000" manually, it works fine!
Why? Is there a bug in the Docker?

join refused: DevNonce already used by this device

I recently made a change to my device twins to specifically set the GatewayID. After clearing the cache I started getting this message when many but not all of my devices are trying to connect to the gateway:

2019-08-16 21:15:18.171 1114611693080229: join request received
2019-08-16 21:15:18.172 1114611693080229: querying the registry for OTAA device
2019-08-16 21:15:18.282 1114611693080229: join refused: DevNonce already used by this device
2019-08-16 21:15:18.282 1114611693080229: processing time: 00:00:00.1123217
2019-08-16 21:15:18.282 1114611693080229: join refused: unknown device
2019-08-16 21:15:19.813 Statistic: {"stat":{"time":"2019-08-16 21:15:19 GMT","rxnb":11,"rxok":11,"rxfw":11,"ackr":100.0,"dwnb":0,"txnb":0}}
2019-08-16 21:15:22.965 Physical dataUp {"rxpk":[{"tmst":3635755724,"chan":1,"rfch":0,"freq":902.500000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":10.5,"rssi":-29,"size":23,"data":"AExrbmlMQHJVcVYGkxZhFBFed8V73ss="}]}
2019-08-16 21:15:22.966 1114611693065671: join request received
2019-08-16 21:15:22.966 1114611693065671: querying the registry for OTAA device
2019-08-16 21:15:23.101 1114611693065671: join refused: DevNonce already used by this device
2019-08-16 21:15:23.101 1114611693065671: processing time: 00:00:00.1364838
2019-08-16 21:15:23.101 1114611693065671: join refused: unknown device
2019-08-16 21:15:24.288 Physical dataUp {"rxpk":[{"tmst":3637081948,"chan":7,"rfch":1,"freq":903.700000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":13.8,"rssi":-77,"size":24,"data":"QKdIvQKAXo8G+WdQZlSpmP2wRjYnQ3LI"}]}

I also tried restarting my gateway but nothing seems to help. What do I need to do to resolve this issue?

Thanks.

How can I send all the devices messages to my application?

Now I can received all my devices messages by the "iotedge-lorawan-starterkit" to the IotHub. I need to send this to my application.Before I use TTN and it can POST this using Http method.you can see here.
Can IotHub use this method?
Thank you.

Class C devices cannot receive direct messages after gateway reboot

I am seeing an issue where my class C devices are not able to receive direct messages after I reboot my gateway. The only way I am able to get them to receive messages again is to cycle the power on the devices so that they rejoin.

I'm currently still on the 1.0 release but I am using 1.0.7 of the Azure Edge components. As a reminder I am working with US 915 frequencies.

I've included the logs I see from the LoRaWanNetworkSrvModule [1]. I don't see anything telling in the LoRaWanPktFwdModule logs.

I'm not really sure how to debug this issue further. Any advise would be greatly appreciated.

[1] LoRaWanNetworkSrvModule logs

2019-09-04 17:03:12.119 1114611693080229: received cloud to device message from direct method: {"devEUI":"1114611693080229","fport":"55","confirmed":false,"payload":"CurtainDown","MessageId":"629195547c9a46ff8961ca5a20813ecc"}
2019-09-04 17:03:12.119 1114611693080229: [class-c] down frame counter: 2
2019-09-04 17:03:12.120 1114611693080229: UnconfirmedDataDown {"txpk":{"imme":true,"data":"YIMxbgIAAgA30V/ru0Wd3RsuNpVB7ZdH","tmst":0,"size":24,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF10BW125","codr":"4/5","powe":14,"ipol":true}}
2019-09-04 17:03:12.120 UDP: sending message with ID 8C69, to 172.18.0.1:40482
2019-09-04 17:03:12.121 UDP: message sent with ID 8C69
2019-09-04 17:03:12.127 UDP: packet with id 8C69 successfully transmitted by the aggregator
2019-09-04 17:03:12.536 1114611693065671: received cloud to device message from direct method: {"devEUI":"1114611693065671","fport":"55","confirmed":false,"payload":"CurtainDown","MessageId":"7d600e00743f48699fb2f0e28848d38a"}
2019-09-04 17:03:12.536 1114611693065671: [class-c] down frame counter: 6
2019-09-04 17:03:12.537 1114611693065671: UnconfirmedDataDown {"txpk":{"imme":true,"data":"YA75qgMABgA3X+euOBFp92gXGNYyDKox","tmst":0,"size":24,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF10BW125","codr":"4/5","powe":14,"ipol":true}}
2019-09-04 17:03:12.537 UDP: sending message with ID 1A2B, to 172.18.0.1:40482
2019-09-04 17:03:12.538 UDP: message sent with ID 1A2B
2019-09-04 17:03:12.539 UDP: packet with id 1A2B successfully transmitted by the aggregator

[2] LoRaWanPktFwdModule logs

##### 2019-09-04 17:07:38 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 (113 bytes)
# PUSH_DATA acknowledged: 100.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
# TX rejected (collision packet): 0.00% (req:4, rej:0)
# TX rejected (collision beacon): 0.00% (req:4, rej:0)
# TX rejected (too late): 0.00% (req:4, rej:0)
# TX rejected (too early): 0.00% (req:4, rej:0)
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
# SX1301 time (PPS): 3271166958
src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####

JSON up: {"stat":{"time":"2019-09-04 17:07:38 GMT","rxnb":1,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}
INFO: [up] PUSH_ACK received in 1 ms
INFO: [down] PULL_ACK received in 0 ms
INFO: [down] PULL_ACK received in 1 ms
INFO: [down] PULL_ACK received in 1 ms

INFO: Disabling GPS mode for concentrator's counter...
INFO: host/sx1301 time offset=(1567613557s:293557µs) - drift=29µs
INFO: Enabling GPS mode for concentrator's counter.


##### 2019-09-04 17:08:08 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (113 bytes)
# PUSH_DATA acknowledged: 100.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
# TX rejected (collision packet): 0.00% (req:4, rej:0)
# TX rejected (collision beacon): 0.00% (req:4, rej:0)
# TX rejected (too late): 0.00% (req:4, rej:0)
# TX rejected (too early): 0.00% (req:4, rej:0)
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
# SX1301 time (PPS): 3331167881
src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####

JSON up: {"stat":{"time":"2019-09-04 17:08:08 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}
INFO: [up] PUSH_ACK received in 1 ms
INFO: [down] PULL_ACK received in 1 ms
INFO: [down] PULL_ACK received in 1 ms
INFO: [down] PULL_ACK received in 1 ms

##### 2019-09-04 17:08:38 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (113 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)

DeviceEUI captialization bug?

I'm not sure if this is a bug or the expected behavior. I just received some sensors form a new vendor. When I scan their QRCode, the DeviceEUI is presented like: 39:34:35:37:7e:37:7e:15. Before registering the device with Azure IoT Hub I removed the colons so that the DeviceEUI looked like this: 393435377e377e15. However the gateway refused to join the device until I deleted the original registration and changed the DeviceEUI to look like this: 393435377E377E15.

Expected Behavior

I expect that the gateway should be able to normalize the DeviceEUI so that the join works regardless of the capitalization, i.e. either 393435377e377e15 or 393435377E377E15 should work when a join request is made.

Current Behavior

The join request is refused.

Steps to Reproduce

Take any device which has letters in it's DeviceEUI and make one or more of the letters lowercase. Register the device with Azure IoT Hub with the lowercased DeviceEUI
Turn on the device and allow it to make a join request

Context (Environment)

Device (Host) Operating System

Ubuntu 16.04

Architecture

arm32v7 and amd64

Container Operating System

LoRaWAN Module Version

Docker

Version 18.03.0-ce-win59 (16762)

Logs

Additional Information

Unfortunately I don't have any logs to share at the moment as I got the devices to join after correcting the DeviceEUI to have capital letters. I can produce the logs if necessary.

Question: How to decode messages with multiple headers?

I have a soil moisture sensor which sends data with multiple headers. I'm not really sure how to distinguish the type of message I'm receiving so that I can proceed to decode the messages. I've attached the documentation from the manufacturer to this issue.
Sen Deca Probe LR Datasheet.pdf

I would appreciate some advice on how I should go about decoding the messages using the current decoding infrastructure.

Logs:

2019-04-21 23:45:18.321 Physical dataUp {"rxpk":[{"tmst":2786119676,"chan":2,"rfch":0,"freq":902.700000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":-14.0,"rssi":-109,"size":21,"data":"QO8xdgKABwABE7JxjBGR/NFen4FD"}]}
2019-04-21 23:45:18.322 393435377D377016: device in cache
2019-04-21 23:45:18.326 393435377D377016: converted 16bit FCnt 7 to 32bit FCnt 7
2019-04-21 23:45:18.326 393435377D377016: no Deduplication Strategy selected
2019-04-21 23:45:18.326 393435377D377016: FunctionBundler request: {"GatewayId":"evolution-gateway","ClientFCntUp":7,"ClientFCntDown":0,"Rssi":-109,"AdrRequest":{"DataRate":0,"RequiredSnr":-15.0,"PerformADRCalculation":false,"FCntUp":7,"FCntDown":0,"MinTxPowerIndex":13,"GatewayId":"evolution-gateway","ClearCache":false},"FunctionItems":4}
2019-04-21 23:45:18.628 393435377D377016: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":3,"TxPower":0,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":0,"NumberOfFrames":20},"NextFCntDown":null,"PreferredGatewayResult":null}
2019-04-21 23:45:18.628 393435377D377016: valid frame counter, msg: 7 server: 5
2019-04-21 23:45:18.628 393435377D377016: no decoder set in device twin. port: 1
2019-04-21 23:45:18.629 393435377D377016: sending message {"time":null,"tmms":0,"tmst":2786119676,"freq":902.7,"chan":2,"rfch":0,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","rssi":-109,"lsnr":-14.0,"size":21,"data":{"value":"LBUVAAAAABU="},"port":1,"fcnt":7,"rawdata":"LBUVAAAAABU=","eui":"393435377D377016","gatewayid":"evolution-gateway","edgets":1555890318321} to hub
2019-04-21 23:45:18.657 393435377D377016: message '{"value":"LBUVAAAAABU="}' sent to hub
2019-04-21 23:45:18.657 393435377D377016: checking cloud to device message for 00:00:00.2637728
2019-04-21 23:45:18.921 393435377D377016: done checking cloud to device message, found no message
2019-04-21 23:45:18.922 393435377D377016: processing time: 00:00:00.6009532

Later...

2019-04-21 23:55:18.337 Physical dataUp {"rxpk":[{"tmst":3386133724,"chan":2,"rfch":0,"freq":902.700000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":9.5,"rssi":-35,"size":21,"data":"QO8xdgKACQABc0IVhC8irfn4S73y"}]}
2019-04-21 23:55:18.338 393435377D377016: device in cache
2019-04-21 23:55:18.340 393435377D377016: converted 16bit FCnt 9 to 32bit FCnt 9
2019-04-21 23:55:18.340 393435377D377016: no Deduplication Strategy selected
2019-04-21 23:55:18.340 393435377D377016: FunctionBundler request: {"GatewayId":"evolution-gateway","ClientFCntUp":9,"ClientFCntDown":0,"Rssi":-35,"AdrRequest":{"DataRate":0,"RequiredSnr":-15.0,"PerformADRCalculation":false,"FCntUp":9,"FCntDown":0,"MinTxPowerIndex":13,"GatewayId":"evolution-gateway","ClearCache":false},"FunctionItems":4}
2019-04-21 23:55:18.401 393435377D377016: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":3,"TxPower":0,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":0,"NumberOfFrames":20},"NextFCntDown":null,"PreferredGatewayResult":null}
2019-04-21 23:55:18.402 393435377D377016: valid frame counter, msg: 9 server: 7
2019-04-21 23:55:18.402 393435377D377016: no decoder set in device twin. port: 1
2019-04-21 23:55:18.402 393435377D377016: sending message {"time":null,"tmms":0,"tmst":3386133724,"freq":902.7,"chan":2,"rfch":0,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","rssi":-35,"lsnr":9.5,"size":21,"data":{"value":"LBUVAAAAABU="},"port":1,"fcnt":9,"rawdata":"LBUVAAAAABU=","eui":"393435377D377016","gatewayid":"evolution-gateway","edgets":1555890918336} to hub
2019-04-21 23:55:18.428 393435377D377016: message '{"value":"LBUVAAAAABU="}' sent to hub
2019-04-21 23:55:18.428 393435377D377016: checking cloud to device message for 00:00:00.5080509
2019-04-21 23:55:18.937 393435377D377016: done checking cloud to device message, found no message
2019-04-21 23:55:18.937 393435377D377016: processing time: 00:00:00.6014300
2019-04-21 23:55:21.408 Physical dataUp {"rxpk":[{"tmst":3389208636,"chan":6,"rfch":1,"freq":903.500000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":10.5,"rssi":-35,"size":20,"data":"QO8xdgKACgABCl8QTOAvouLOh8o="}]}
2019-04-21 23:55:21.409 393435377D377016: device in cache
2019-04-21 23:55:21.410 393435377D377016: converted 16bit FCnt 10 to 32bit FCnt 10
2019-04-21 23:55:21.410 393435377D377016: no Deduplication Strategy selected
2019-04-21 23:55:21.410 393435377D377016: FunctionBundler request: {"GatewayId":"evolution-gateway","ClientFCntUp":10,"ClientFCntDown":0,"Rssi":-35,"AdrRequest":{"DataRate":0,"RequiredSnr":-15.0,"PerformADRCalculation":false,"FCntUp":10,"FCntDown":0,"MinTxPowerIndex":13,"GatewayId":"evolution-gateway","ClearCache":false},"FunctionItems":4}
2019-04-21 23:55:21.472 393435377D377016: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":3,"TxPower":0,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":0,"NumberOfFrames":20},"NextFCntDown":null,"PreferredGatewayResult":null}
2019-04-21 23:55:21.472 393435377D377016: valid frame counter, msg: 10 server: 9
2019-04-21 23:55:21.472 393435377D377016: no decoder set in device twin. port: 1
2019-04-21 23:55:21.472 393435377D377016: sending message {"time":null,"tmms":0,"tmst":3389208636,"freq":903.5,"chan":6,"rfch":1,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","rssi":-35,"lsnr":10.5,"size":20,"data":{"value":"bAAAAAAAAA=="},"port":1,"fcnt":10,"rawdata":"bAAAAAAAAA==","eui":"393435377D377016","gatewayid":"evolution-gateway","edgets":1555890921407} to hub
2019-04-21 23:55:21.500 393435377D377016: message '{"value":"bAAAAAAAAA=="}' sent to hub
2019-04-21 23:55:21.500 393435377D377016: checking cloud to device message for 00:00:00.5068171
2019-04-21 23:55:22.008 393435377D377016: done checking cloud to device message, found no message
2019-04-21 23:55:22.008 393435377D377016: updating twin
2019-04-21 23:55:22.019 393435377D377016: twin updated
2019-04-21 23:55:22.020 393435377D377016: processing time: 00:00:00.6124707
 
Later...

2019-04-22 00:05:07.404 Statistic: {"stat":{"time":"2019-04-22 00:05:07 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":0,"txnb":0}}
2019-04-22 00:05:18.200 Physical dataUp {"rxpk":[{"tmst":3985997372,"chan":1,"rfch":0,"freq":902.500000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":12.0,"rssi":-32,"size":21,"data":"QO8xdgKACwABSntmPFojPj0KjUDX"}]}
2019-04-22 00:05:18.201 393435377D377016: device in cache
2019-04-22 00:05:18.202 393435377D377016: converted 16bit FCnt 11 to 32bit FCnt 11
2019-04-22 00:05:18.202 393435377D377016: no Deduplication Strategy selected
2019-04-22 00:05:18.203 393435377D377016: FunctionBundler request: {"GatewayId":"evolution-gateway","ClientFCntUp":11,"ClientFCntDown":0,"Rssi":-32,"AdrRequest":{"DataRate":0,"RequiredSnr":-15.0,"PerformADRCalculation":false,"FCntUp":11,"FCntDown":0,"MinTxPowerIndex":13,"GatewayId":"evolution-gateway","ClearCache":false},"FunctionItems":4}
2019-04-22 00:05:18.247 393435377D377016: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":3,"TxPower":0,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":0,"NumberOfFrames":20},"NextFCntDown":null,"PreferredGatewayResult":null}
2019-04-22 00:05:18.248 393435377D377016: valid frame counter, msg: 11 server: 10
2019-04-22 00:05:18.248 393435377D377016: no decoder set in device twin. port: 1
2019-04-22 00:05:18.248 393435377D377016: sending message {"time":null,"tmms":0,"tmst":3985997372,"freq":902.5,"chan":1,"rfch":0,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","rssi":-32,"lsnr":12.0,"size":21,"data":{"value":"LBUVAAAAABU="},"port":1,"fcnt":11,"rawdata":"LBUVAAAAABU=","eui":"393435377D377016","gatewayid":"evolution-gateway","edgets":1555891518200} to hub
2019-04-22 00:05:18.282 393435377D377016: message '{"value":"LBUVAAAAABU="}' sent to hub
2019-04-22 00:05:18.282 393435377D377016: checking cloud to device message for 00:00:00.5177399
2019-04-22 00:05:18.803 393435377D377016: done checking cloud to device message, found no message
2019-04-22 00:05:18.803 393435377D377016: processing time: 00:00:00.6031722

join refused: AppEUI for OTAA does not match device

I have new class C devices which I have not been able to join to my gateway. I have double checked the AppEUI in the devices configuration[1] and in the device twins[2] multiple times. I have older versions of the same devices which do connect as expected with the same AppEUI and ApplicationKey.

This could be a issue with the devices but I wanted to see if there maybe some issue with the v1.0.2 release. I'm willing to upgrade to v1.0.3 if this issue has been addressed there.

Expected Behavior

The device connects to the gateway.

Current Behavior

The device does not connect to the gateway.

Device (Host) Operating System

Ubuntu 16.04

Architecture

amd64

Container Operating System

Linux containers

Logs

2020-05-11 21:05:40.186 Physical dataUp {"rxpk":[{"tmst":617733892,"chan":7,"rfch":1,"freq":903.700000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":8.2,"rssi":-103,"size":23,"data":"AExrbmlMQHJVllmWkxZh4SSAshyvEyU="}]}
2020-05-11 21:05:40.186 24E1611693965996: join request received
2020-05-11 21:05:40.186 24E1611693965996: querying the registry for OTAA device
2020-05-11 21:05:40.268 24E1611693965996: processing time: 00:00:00.0829052
2020-05-11 21:05:40.268 24E1611693965996: join refused: AppEUI for OTAA does not match device

Additional Information

[1] Image of the Ursalink configuration:

[2] IoT Hub Twins:

"desired": {
"AppEUI": "5572404c696e6b4c",
"AppKey": "**********",
"SensorDecoder": "http://decoder/api/DecoderUrsalinkUc1114",
"GatewayID": "",
"ClassType": "C",
"RX2DataRate": 10,
... elided for clarity
}

Receive messages delay issue

Now I am testing the engine with devices only on ABP mode and have not downstream messages. I am in china and using 470M-510M band. And I found the upstream messages are delayed more came back to my monitor. The detail as below:
1、I use the VScode for device messages monitoring.
2、My devices send messages every 10 second.(three devices)
3、For example, after sending for a few times.Now I am sending the message with cnt number 600,but the monitor message is still show the message with cnt number 520, there are 80 messages delayed.
4、When I stop sending messages, the delayed messages will come back to the monitor for a few times.
5、I saw the monitor about every 20 second received one message,but I sended every 10 second.

I used the TTN lorawan server before, it can work well on every 1 second messages sending.
So,dose somebody know what is the problem?

Question: Support for Azure IoT Edge 1.0.7?

I'm curious when there will be a release which as been tested with azureiotedge-agent:1.0.7 and azureiotedge-hub:1.0.7?

I was force to use these on my test gateway in order to send direct messages to class C devices. I will soon need to roll out class C devices to a production gateway but I am hesitant to do so until there is a supported release.

Issues with class C device

We're running into a couple of issues with our class C device.

First issue - our class C (ABP) device sends a message to the gateway once at power up and every hour thereafter. At first, we were having issues when the NetworkSrvModule attempts to identify the device, but we were able to get past it, and so eventually we got this:

Our device:
DevAddr: 12000003
DevEUI: 0000000000000007

2020-02-07 04:04:23.718 12000003: querying the registry for device
2020-02-07 04:04:28.749 Physical dataUp {"rxpk":[{"tmst":3425803172,"time":"2020-02-07T04:04:28.747801Z","chan":0,"rfch":0,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","lsnr":12.0,"rssi":-39,"size":104,"data":"gAMAABKAAwAJaVmujv9obNJMdTVmG3/V/5kjwKDfuyoqea0/Q1wvNMYMvV123ClrXbshfhw8M1T7zCqh73ll1ymef59gJxWoNZX86SDxYhnwTLbIZQDjc+GCMOLIbe3g25XHFmmwG1U="}]}
2020-02-07 04:04:32.085 12000003: querying the registry for devices by devAddr 12000003 found 1 devices
2020-02-07 04:04:32.123 0000000000000007: using edgeHub local queue
2020-02-07 04:04:32.428 0000000000000007: getting device twin
2020-02-07 04:04:33.637 0000000000000007: done getting device twin
2020-02-07 04:04:34.301 0000000000000007: device added to cache
2020-02-07 04:04:34.495 0000000000000007: converted 16bit FCnt 3 to 32bit FCnt 3
2020-02-07 04:04:34.549 0000000000000007: no Deduplication Strategy selected
2020-02-07 04:04:34.596 0000000000000007: FunctionBundler ADR request finished preparing.
2020-02-07 04:04:34.665 0000000000000007: FunctionBundler request: {"GatewayId":"loragw01","ClientFCntUp":3,"ClientFCntDown":0,"Rssi":-41,"AdrRequest":{"DataRate":2,"RequiredSnr":-10.0,"PerformADRCalculation":false,"FCntUp":3,"FCntDown":0,"MinTxPowerIndex":13,"GatewayId":"loragw01","ClearCache":false},"FunctionItems":13}
2020-02-07 04:04:35.879 0000000000000007: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":null,"TxPower":null,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":null,"NumberOfFrames":1},"NextFCntDown":1,"PreferredGatewayResult":{"DevEUI":"0000000000000007","RequestFcntUp":3,"CurrentFcntUp":3,"PreferredGatewayID":"loragw01"}}
2020-02-07 04:04:35.901 0000000000000007: preferred gateway changed from '' to 'loragw01'
2020-02-07 04:04:35.904 0000000000000007: down frame counter: 1
2020-02-07 04:04:35.920 0000000000000007: valid frame counter, msg: 3 server: 0
2020-02-07 04:04:35.955 0000000000000007: no decoder set in device twin. port: 9
2020-02-07 04:04:36.126 0000000000000007: sending message {"time":"2020-02-07T04:04:23.547161Z","tmms":0,"tmst":3420600068,"freq":923.2,"chan":0,"rfch":0,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","rssi":-41,"lsnr":11.8,"size":104,"data":{"value":"AQNAACoSAwEAATs6BAAAAAAAAAjKAAAThAAAAAAAAAEOAAAAAAAABtwAAAAAAIgBMy4YLhgAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAFCTQ=="},"port":9,"fcnt":3,"rawdata":"AQNAACoSAwEAATs6BAAAAAAAAAjKAAAThAAAAAAAAAEOAAAAAAAABtwAAAAAAIgBMy4YLhgAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAFCTQ==","eui":"0000000000000007","gatewayid":"loragw01","edgets":1581048263548} to hub
2020-02-07 04:04:37.029 0000000000000007: message '{"value":"AQNAACoSAwEAATs6BAAAAAAAAAjKAAAThAAAAAAAAAEOAAAAAAAABtwAAAAAAIgBMy4YLhgAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAFCTQ=="}' sent to hub
2020-02-07 04:04:37.039 0000000000000007: too late for down message (00:00:13.4902565)
2020-02-07 04:04:37.183 0000000000000007: updating twin
2020-02-07 04:04:37.423 0000000000000007: twin updated
2020-02-07 04:04:37.439 0000000000000007: converted 16bit FCnt 3 to 32bit FCnt 3
2020-02-07 04:04:37.439 0000000000000007: processing time: 00:00:13.8910019
2020-02-07 04:04:37.442 0000000000000007: resubmit from confirmed message detected, msg: 3 server: 3
2020-02-07 04:04:37.443 0000000000000007: no Deduplication Strategy selected
2020-02-07 04:04:37.444 0000000000000007: FunctionBundler ADR request finished preparing.
2020-02-07 04:04:37.445 0000000000000007: FunctionBundler request: {"GatewayId":"loragw01","ClientFCntUp":3,"ClientFCntDown":1,"Rssi":-39,"AdrRequest":{"DataRate":2,"RequiredSnr":-10.0,"PerformADRCalculation":false,"FCntUp":3,"FCntDown":1,"MinTxPowerIndex":13,"GatewayId":"loragw01","ClearCache":false},"FunctionItems":13}
2020-02-07 04:04:37.729 0000000000000007: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":null,"TxPower":null,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":null,"NumberOfFrames":1},"NextFCntDown":2,"PreferredGatewayResult":{"DevEUI":"0000000000000007","RequestFcntUp":3,"CurrentFcntUp":3,"PreferredGatewayID":"loragw01"}}
2020-02-07 04:04:37.730 0000000000000007: down frame counter: 2
2020-02-07 04:04:37.730 0000000000000007: no decoder set in device twin. port: 9
2020-02-07 04:04:37.730 0000000000000007: too late for down message (00:00:08.9816327)
2020-02-07 04:04:37.730 0000000000000007: processing time: 00:00:08.9819513

For the next 2 hours, it did the same entries in the log - until the 4th one when it changed to this:

2020-02-07 05:04:23.279 0000000000000007: device in cache
2020-02-07 05:04:23.280 0000000000000007: converted 16bit FCnt 4 to 32bit FCnt 4
2020-02-07 05:04:23.280 0000000000000007: no Deduplication Strategy selected
2020-02-07 05:04:23.280 0000000000000007: FunctionBundler ADR request finished preparing.
2020-02-07 05:04:23.281 0000000000000007: FunctionBundler request: {"GatewayId":"loragw01","ClientFCntUp":4,"ClientFCntDown":2,"Rssi":-48,"AdrRequest":{"DataRate":2,"RequiredSnr":-10.0,"PerformADRCalculation":false,"FCntUp":4,"FCntDown":2,"MinTxPowerIndex":13,"GatewayId":"loragw01","ClearCache":false},"FunctionItems":13}
2020-02-07 05:04:24.537 0000000000000007: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":null,"TxPower":null,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":null,"NumberOfFrames":2},"NextFCntDown":3,"PreferredGatewayResult":{"DevEUI":"0000000000000007","RequestFcntUp":4,"CurrentFcntUp":4,"PreferredGatewayID":"loragw01"}}
2020-02-07 05:04:24.537 0000000000000007: down frame counter: 3
2020-02-07 05:04:24.538 0000000000000007: valid frame counter, msg: 4 server: 3
2020-02-07 05:04:24.538 0000000000000007: no decoder set in device twin. port: 9
2020-02-07 05:04:24.539 0000000000000007: sending message {"time":"2020-02-07T05:04:23.270970Z","tmms":0,"tmst":2725358868,"freq":923.4,"chan":1,"rfch":0,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","rssi":-48,"lsnr":11.2,"size":104,"data":{"value":"AQNAACoSAwEAAjs6BAAAAAAAAAjUAAATgwAAAAAAAAEOAAAAAAAABtwAAAAAAIgBNS4YLhgAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAHOQQ=="},"port":9,"fcnt":4,"rawdata":"AQNAACoSAwEAAjs6BAAAAAAAAAjUAAATgwAAAAAAAAEOAAAAAAAABtwAAAAAAIgBNS4YLhgAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAHOQQ==","eui":"0000000000000007","gatewayid":"loragw01","edgets":1581051863271} to hub
2020-02-07 05:04:24.580 0000000000000007: message '{"value":"AQNAACoSAwEAAjs6BAAAAAAAAAjUAAATgwAAAAAAAAEOAAAAAAAABtwAAAAAAIgBNS4YLhgAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAHOQQ=="}' sent to hub
2020-02-07 05:04:24.644 0000000000000007: checking cloud to device message for 00:00:00.2827146
2020-02-07 05:04:25.172 0000000000000007: done checking cloud to device message, found no message
2020-02-07 05:04:25.227 0000000000000007: processing time: 00:00:01.9553016
2020-02-07 05:04:29.245 Physical dataUp {"rxpk":[{"tmst":2731325332,"time":"2020-02-07T05:04:29.243155Z","chan":1,"rfch":0,"freq":923.400000,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","lsnr":11.8,"rssi":-51,"size":104,"data":"gAMAABKABAAJNcjOmijRpSOokCoVqheNtFqSRKV9xZh/PwE3Klmy6wyfDCkSFK2lbQ34kUXJYy/E7Ixs1mgAKpS746SFXJuh+yYPrNWWpmV74cvFRIquZkb+Jt/hkiQPeEAtBaYi7Dg="}]}
2020-02-07 05:04:29.246 0000000000000007: device in cache
2020-02-07 05:04:29.246 0000000000000007: converted 16bit FCnt 4 to 32bit FCnt 4
2020-02-07 05:04:29.246 0000000000000007: resubmit from confirmed message detected, msg: 4 server: 4
2020-02-07 05:04:29.247 0000000000000007: no Deduplication Strategy selected
2020-02-07 05:04:29.247 0000000000000007: FunctionBundler ADR request finished preparing.
2020-02-07 05:04:29.247 0000000000000007: FunctionBundler request: {"GatewayId":"loragw01","ClientFCntUp":4,"ClientFCntDown":3,"Rssi":-51,"AdrRequest":{"DataRate":2,"RequiredSnr":-10.0,"PerformADRCalculation":false,"FCntUp":4,"FCntDown":3,"MinTxPowerIndex":13,"GatewayId":"loragw01","ClearCache":false},"FunctionItems":13}
2020-02-07 05:04:29.537 0000000000000007: FunctionBundler result: {"DeduplicationResult":null,"AdrResult":{"NbRepetition":null,"TxPower":null,"DataRate":0,"CanConfirmToDevice":false,"FCntDown":null,"NumberOfFrames":2},"NextFCntDown":4,"PreferredGatewayResult":{"DevEUI":"0000000000000007","RequestFcntUp":4,"CurrentFcntUp":4,"PreferredGatewayID":"loragw01"}}
2020-02-07 05:04:29.537 0000000000000007: down frame counter: 4
2020-02-07 05:04:29.538 0000000000000007: no decoder set in device twin. port: 9
2020-02-07 05:04:29.538 0000000000000007: checking cloud to device message for 00:00:00.3056907
2020-02-07 05:04:29.845 0000000000000007: done checking cloud to device message, found no message
2020-02-07 05:04:29.950 0000000000000007: sending a downstream message with ID FEA4
2020-02-07 05:04:30.023 0000000000000007: UnconfirmedDataDown {"txpk":{"imme":false,"data":"YAMAABKgBADWnIhm","tmst":2732325332,"size":12,"freq":923.9,"rfch":0,"modu":"LORA","datr":"SF8BW500","codr":"4/5","powe":14,"ipol":true}}
2020-02-07 05:04:30.055 UDP: sending message with ID D67A, to 172.18.0.1:35245
2020-02-07 05:04:30.060 UDP: message sent with ID D67A
2020-02-07 05:04:30.060 0000000000000007: processing time: 00:00:00.8163665

It does the same for the next hour, but an hour later, it changed to this:

2020-02-07 07:04:22.914 12000003: querying the registry for device
2020-02-07 07:04:28.465 Physical dataUp {"rxpk":[{"tmst":2320665340,"time":"2020-02-07T07:04:28.462983Z","chan":0,"rfch":0,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","lsnr":12.2,"rssi":-49,"size":104,"data":"gAMAABKABgAJtZcgBF4kSGOp1KFSNkVodCEGtuQj8lsL889CxtX+ZUESjT+rJ9ihCzLnSd4MxlEWraJ8015rUng1Xyy4c+sQAQBbzI3Bxn8/gY3WO1HkaxgbpP1BKopxxdvwSZYyG84="}]}
2020-02-07 07:04:30.922 12000003: querying the registry for devices by devAddr 12000003 found 1 devices
2020-02-07 07:04:30.984 12000003: **device is not our device, ignore message**
2020-02-07 07:04:30.984 12000003: processing time: 00:00:08.2418586
2020-02-07 07:04:30.984 12000003: device is not our device, ignore message
2020-02-07 07:04:30.984 12000003: processing time: 00:00:02.5209429
2020-02-07 07:04:30.991 0000000000000007: **device added to cache**

Why is it saying "device is not our device, ignore message" and then at the end: "device added to cache"?

Second issue - wWhen attempting to send C2D messages to our class C device, we're running into validation issues.
At first, we encountered this:
2020-02-07 05:34:54.901 0000000000000007: [class-c] could not obtain fcnt down for class C device
And then this:
2020-02-07 07:56:24.290 0000000000000007: [class-c] device does not have a region assigned. Ensure the device has connected at least once with the network

The latter one is actually executed earlier in the DefaultClassCDevicesMessageSender.SendAsync method - so it seems we were getting past it at 05:34:54.901, and then later at 07:56:24.290 - we're not able to get past it anymore. So question - where do we need to configure everything that's getting validated in this DefaultClassCDevicesMessageSender.SendAsync method? There doesn't seem to be anything in the documentation.

Thank you.

Intercepting NetworkSrvModule upstream messages

Hi, I'm reasonably new to both LoRa and Azure and I'm currently working on a project that is looking to apply some ML to a LoRa network. In the root readme file there is a diagram that shows custom IoT Edge modules tapping into upstream messages from NetworkSrvModule. Ideally, I want to deploy a docker image on the edge device to do the ML processing. I haven't had much luck finding details on how to do this and any help would be much appreciated.

Originally we thought the module was using the routing between docker modules (ie. FROM /* INTO $upstream). However, this appears to be for logging only and the device payloads are sent using SendEventAsync() of DeviceClient.

I guess my question is two parts:
What was the intended implementation of the architecture mentioned in the readme?
and,
Is it possible to intercept the upstream payload using docker endpoints before using SendEventAsync()?

Thanks in advance :)

Class A - out of time for downstream message

I am successfully sending C2D messages to my Class A devices but on occasion I get the error shown in my gateway logs below. I haven't been able to see any reproducible pattern but it seems to happen if I have not been sending messages for a long period of time. The message always seems to succeed the next time the device sends an upstream message. It concerns me because I will be controlling irrigation valves and then will typically be configured to send upstream messages on an infrequent basis. This could be catastrophic on a hot day if the period between upstream messages is long.

I'm not sure if this is an issue with the device, the gateway or something I will just need to live with?

Device (Host) Operating System

Ubuntu 16.04

Architecture

AMD64

Container Operating System

LoRaWAN Module Version

PKT_FWD_VERSION=1.0.7
NET_SRV_VERSION=1.0.7

Docker

Version: 3.0.3
API version: 1.40
Go version: go1.11.4
Git commit: 48bd4c6d
Built: Wed Jan 23 16:17:56 2019
OS/Arch: linux/amd64
Experimental: false

Logs

2019-07-24 04:04:37.262 0004A30B00240C03: done checking cloud to device message, found message id: c3a0c03d-a205-4b20-9b47-feeef02333f0
2019-07-24 04:04:37.262 0004A30B00240C03: syncing FCntDown for multigateway
2019-07-24 04:04:39.425 0004A30B00240C03: down frame counter: 43
2019-07-24 04:04:39.425 0004A30B00240C03: out of time for downstream message, will abandon cloud to device message id: c3a0c03d-a205-4b20-9b47-feeef02333f0
2019-07-24 04:04:39.426 0004A30B00240C03: abandoning cloud to device message, id: c3a0c03d-a205-4b20-9b47-feeef02333f0
2019-07-24 04:04:39.427 0004A30B00240C03: updating twin
2019-07-24 04:04:39.437 0004A30B00240C03: twin updated
2019-07-24 04:04:39.437 0004A30B00240C03: processing time: 00:00:02.2117083
2019-07-24 04:04:39.505 0004A30B00240C03: done abandoning cloud to device message, id: c3a0c03d-a205-4b20-9b47-feeef02333f0

Question: Cloud to Device messages

I would like to adjust the reporting frequency from a couple of the devices I have joined to my gateway. The documentation I have indicates that I should send "set period 60 seconds + save" to set the reporting frequency to 60 seconds. It's not clear to me how send this command through the Azure IoT Hub, realizing that I may need to send multiple commands.

Any insight would be appreciated. Note: I have the ability to do this via a USB to serial adapter but would like to understand how to achieve the same result through C2D messaging.

Thanks!

Newbie Questions

Hi, I'm new to Azure Iot and I would like to know the answer to some questions, if possible:

I'm trying to run your Lorawan modules in a Iot Edge device with windows containers, is it possible ? I builded to windows-amd64, and changed the start_pktfwd.sh to CRLF ... The modules don't even appear in my Container Registry.
You use Redis Cache in your architecture, is it needed or just advised ? Is there any alternative way to store the keys ?
Can I use an Iot edge device just to send Lorawan Packets to The Things Network Server outside Iot Edge (Maybe like your LoRaWanPktFwdModule module) ? If so, how can I implement it ?

Deployment from Quick Start template appears to fail

Using Quick Start template taking a long time to complete.

Expected Behavior

All of the requisite Azure resources are successfully created.

Current Behavior

After almost an hour, the deployment appears to fail -- I don't see that an Azure function was created. The Redis cache and the IoTHub were both created but no gateway has been added to the IoT hub.

Steps to Reproduce

Click on the "Quick Start' button
Wait (almost an hour in my case)
At some point during the deployment, see a deployment failure (logs below)
Deployment seems to recover but then nothing else happens
Wait some more
The template appears to get stuck at "Get all Iot Hub keys" which appears to get called
repeatedly as shown in the uploaded image.
At this point I'm not sure what to do as it doesn't appear that I can stop the template.

Context (Environment)

Device (Host) Operating System

Architecture

Container Operating System

LoRaWAN Module Version

Docker

Logs

{
    "authorization": {
        "action": "Microsoft.Resources/deployments/write",
        "scope": "/subscriptions/42d031ca-ae31-4c28-baff-23438604f5ae/resourceGroups/Production-Resource-Group/providers/Microsoft.Resources/deployments/Microsoft.Template"
    },
    "caller": "[email protected]",
    "channels": "Operation",
    "claims": {
        "aud": "https://management.core.windows.net/",
        "iss": "https://sts.windows.net/f0dfc3bb-3339-4276-a0cc-e5d1835a5aaf/",
        "iat": "1574711601",
        "nbf": "1574711601",
        "exp": "1574715501",
        "http://schemas.microsoft.com/claims/authnclassreference": "1",
        "aio": "AUQAu/8NAAAAJy9NlFk0FDB/NsU4rsVfjWEghpYi60xQBmml042v3sYyf1OibdiPkaCxLFBtllcagnaLdO4NHDZrdsYuQbZenA==",
        "altsecid": "1:live.com:000340011F0A7D8E",
        "http://schemas.microsoft.com/claims/authnmethodsreferences": "pwd",
        "appid": "c44b4083-3bb0-49c1-b47d-974e53cbdf3c",
        "appidacr": "2",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress": "[email protected]",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "Gerfen",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "Michael",
        "groups": "81b08094-7fab-449b-97e8-53abedf77ec0",
        "http://schemas.microsoft.com/identity/claims/identityprovider": "live.com",
        "ipaddr": "72.0.168.220",
        "name": "Michael Gerfen",
        "http://schemas.microsoft.com/identity/claims/objectidentifier": "0b448951-84ef-43ce-a7fe-7757b4ba4e69",
        "puid": "100320007D9BA485",
        "http://schemas.microsoft.com/identity/claims/scope": "user_impersonation",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "uRFezc_uiK5Z9VwT-Fvxtm6CV8eDXJO5sfDlmtBvUXs",
        "http://schemas.microsoft.com/identity/claims/tenantid": "f0dfc3bb-3339-4276-a0cc-e5d1835a5aaf",
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": "live.com#[email protected]",
        "uti": "Cyfb8ywJQ0KO4bpDpWoaAA",
        "ver": "1.0",
        "wids": "62e90394-69f5-4237-9190-012177145e10"
    },
    "correlationId": "d5d20b2a-1cc4-44e5-8459-65afd0e770fa",
    "description": "",
    "eventDataId": "c381cd48-ea6e-4331-b478-b4127bfa773f",
    "eventName": {
        "value": "EndRequest",
        "localizedValue": "End request"
    },
    "category": {
        "value": "Administrative",
        "localizedValue": "Administrative"
    },
    "eventTimestamp": "2019-11-25T20:26:05.6161459Z",
    "id": "/subscriptions/42d031ca-ae31-4c28-baff-23438604f5ae/resourceGroups/Production-Resource-Group/providers/Microsoft.Resources/deployments/Microsoft.Template/events/c381cd48-ea6e-4331-b478-b4127bfa773f/ticks/637103103656161459",
    "level": "Error",
    "operationId": "69d40079-f8d4-4353-b6f4-09f0d61b7b26",
    "operationName": {
        "value": "Microsoft.Resources/deployments/write",
        "localizedValue": "Create Deployment"
    },
    "resourceGroupName": "Production-Resource-Group",
    "resourceProviderName": {
        "value": "Microsoft.Resources",
        "localizedValue": "Microsoft Resources"
    },
    "resourceType": {
        "value": "Microsoft.Resources/deployments",
        "localizedValue": "Microsoft.Resources/deployments"
    },
    "resourceId": "/subscriptions/42d031ca-ae31-4c28-baff-23438604f5ae/resourceGroups/Production-Resource-Group/providers/Microsoft.Resources/deployments/Microsoft.Template",
    "status": {
        "value": "Failed",
        "localizedValue": "Failed"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2019-11-25T20:27:32.1971747Z",
    "subscriptionId": "42d031ca-ae31-4c28-baff-23438604f5ae",
    "relatedEvents": []
}

Additional Information

FWIW, it appears that the creation of the Azure functions is what failed.

Join issues

06:36:13.684 47AAC86800430028: join request received
2018-12-28 06:36:13.686 47AAC86800430028: querying the registry for device key
2018-12-28 06:36:13.964 47AAC86800430028: using edgeHub local queue
2018-12-28 06:36:13.967 47AAC86800430028: using cached twins for OTAA device
2018-12-28 06:36:13.980 Error processing the message Object reference not set to an instance of an object., at LoRaWan.NetworkServer.MessageProcessor.ProcessJoinRequest(LoRaMessageWrapper loraMessage) in /app/LoRaWan.NetworkServer/MessageProcessor.cs:line 579
at LoRaWan.NetworkServer.MessageProcessor.ProcessMessageAsync(Byte[] message) in /app/LoRaWan.NetworkServer/MessageProcessor.cs:line 55
at LoRaWan.NetworkServer.UdpServer.<>c__DisplayClass10_1.<b__0>d.MoveNext() in /app/LoRaWan.NetworkServer/UdpServer.cs:line 105

#############################
The isssues above from the "iotedge logs LoRaWanNetworkSrvModule" when my device started to join,but join fail. Do somebody know why ?

Implementation of RX1DRoffset

RX1DRoffset field is currently ignored by current implementation (EU/US)

Error building image for decoder samples on master branch

I've added code to support decoding for more device to the Samples project -> LoraDecoder.cs. I can build just fine but when I go to build the image I'm getting this error[1]. I get the same error for amd64 and arm32v7 images. FWIW, I'm developing on Windows 10. This appears to be a regression from the 0.3.0 release. Please advise.

Thanks!

[1] Build image error

PS D:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit> docker build --rm -f "Samples\DecoderSample\Dockerfile.arm32v7" -t <my repository>.azurecr.io/decodersample:1.1.8.arm32v7 Samples\DecoderSample
Sending build context to Docker daemon  33.79kB
Step 1/9 : FROM microsoft/dotnet:2.1-sdk AS build-env
 ---> 6e1c48456450
Step 2/9 : WORKDIR /build/Samples/DecoderSample/
 ---> Using cache
 ---> e496422db033
Step 3/9 : COPY ./Samples/DecoderSample ./
COPY failed: stat /var/lib/docker/tmp/docker-builder882806683/Samples/DecoderSample: no such file or directory
PS D:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit>

Gateway stops sending data for devices after running for a period of time.

I have a gateway running on the 1.0.2 release. It's been operational for many months - since September 2019. Over those months I have experienced the gateway no longer sending data for devices after many weeks of operation - this usually occurs after an interruption to internet connectivity. If the gateway is rebooted, all of the associated devices reconnect and start sending data until the internet connectivity is interrupted. I am currently rebooting the gateway once a week which has helped but I really need to get to the bottom of the issue.

Unfortunately I am not able to remotely connect to the gateway to collect the log files without the assistance of IT personnel who are sadly not co-located at the facility so I must schedule assistance in advance. I know that I can have the LoRaWanNetworkSrvModule send logs to the IoT Hub infrastructure but unfortunately I have also experienced the LoRaWanNetworkSrvModule not restarting properly when I turn on logging from the IoT Hub portal. This leaves the gateway in a broken state until I can get IT assistance.

I tried clearing the Redis cache from the Azure portal but this has no effect. As noted toggling remote logging from the LoRaWanNetworkSrvModule was effective at resolving the issue since it caused the module to restart but as noted in recent months the module has failed to restart which leaves me in a worse situation.

I really don't want to force a gateway reboot on a daily basis as it's masking the core issue. I'd appreciate any insight into how I might manage this situation. Being able to force an on demand reboot from the IoT Hub portal would be helpful.

Device (Host) Operating System

Ubuntu 16.04

Architecture

x64

[Spike]Investigate deployment simplification

Due to recent ARM improvement, we might be able to decommission the provisioning part of the function

Question: cloud to device message too large

I have a class C device which on occasion, gets into a state where I can no longer send it a direct message. I get a message in my logs which state "cloud to device message too large, rejecting" as shown in the logs[1] below.

The only way I can get the device to receive messages again is to reboot my gateway or clear it's cache and have the device rejoin. Neither of which is very practical.

I'm still running on the 1.0.0 release of the starter kit but with the IoT Edge 1.0.7 release which is required to send direct messages. Is this a known issue? Please let me know if I can provide more information.

[1] Logs.

2019-08-04 02:11:40.661 1114611693080229: device in cache
2019-08-04 02:11:40.662 1114611693080229: converted 16bit FCnt 2916 to 32bit FCnt 2916
2019-08-04 02:11:40.662 1114611693080229: valid frame counter, msg: 2916 server: 2915
2019-08-04 02:11:40.663 1114611693080229: no decoder set in device twin. port: 55
2019-08-04 02:11:40.663 1114611693080229: sending message {"time":null,"tmms":0,"tmst":1668170140,"freq":903.7,"chan":7,"rfch":1,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","rssi":-50,"lsnr":11.2,"size":25,"data":{"value":"fvQMANk+Rl03AAB+"},"port":55,"fcnt":2916,"rawdata":"fvQMANk+Rl03AAB+","eui":"1114611693080229","gatewayid":"evolution-gateway","edgets":1564884700659} to hub
2019-08-04 02:11:40.689 1114611693080229: message '{"value":"fvQMANk+Rl03AAB+"}' sent to hub
2019-08-04 02:11:40.689 1114611693080229: checking cloud to device message for 00:00:00.5707346
2019-08-04 02:11:41.260 1114611693080229: done checking cloud to device message, found no message
2019-08-04 02:11:41.260 1114611693080229: processing time: 00:00:00.6007272
2019-08-04 02:11:43.974 1114611693080229: received cloud to device message from direct method: {"devEUI":"1114611693080229","fport":"55","confirmed":false,"payload":"CurtainLeftUp","MessageId":"b1f726eb6f0349308d077a8d9621bd6c"}
2019-08-04 02:11:43.975 1114611693080229: [class-c] down frame counter: 16
2019-08-04 02:11:43.975 1114611693080229: [class-c] cloud to device message too large, rejecting. Id: b1f726eb6f0349308d077a8d9621bd6c

Sending direct message to Class C device

I'm in the process of testing sending direct messages to class C devices - specifically UrsaLink UC1152 devices. My device is set up for US915 frequencies. I worked through an issue with the edgeHub which resulted in the following error message while invoking a direct message to the LoRaWanNetworkSrvModule

[DirectMethod] Invoking Direct Method [ClearCache] to [xxxxxx/LoRaWanNetworkSrvModule] ...
[DirectMethod] Failed to invoke Direct Method: Not found

To resolve the aforementioned error, I shutdown my device and invoked

sudo iotedge restart edgeHub
sudo iotedge restart LoRaWanNetworkSrvModule

then restarted my device to rejoin the network - thanks to @Mandur and @fbeltrao for helping me resolve that issue. After that I was able to successfully send a direct message to the LoRaWanNetworkSrvModule as seen in my logs[1] however the message does not appear to be reaching my device as I am not seeing any downlink messages being recorded in the devices management utility[2].

I have tried to send messages with "payload" and "rawPayload" with the latter being base64 encoded. Both message result in the same behavior.

At this point I am at a loss on how to debug why my direct messages are not reaching the class C device. Any help would be much appreciated.

[1] LoRaWanNetworkSrvModule logs

2019-06-13 16:19:26.733 Log Level: Debug
2019-06-13 16:19:26.753 LoRaWAN server started on port 1680
2019-06-13 16:19:51.497 Statistic: {"stat":{"time":"2019-06-13 16:19:51 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
2019-06-13 16:20:21.469 Statistic: {"stat":{"time":"2019-06-13 16:20:21 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}
2019-06-13 16:20:51.473 Statistic: {"stat":{"time":"2019-06-13 16:20:51 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}
2019-06-13 16:21:21.469 Statistic: {"stat":{"time":"2019-06-13 16:21:21 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}
2019-06-13 16:21:47.851 Physical dataUp {"rxpk":[{"tmst":733168242,"chan":8,"rfch":0,"freq":903.000000,"stat":1,"modu":"LORA","datr":"SF8BW500","codr":"4/5","lsnr":8.2,"rssi":-48,"size":23,"data":"AExrbmlMQHJVIjATkiJhUhHQPfWvc7M="}]}
2019-06-13 16:21:48.105 1152612292133022: join request received
2019-06-13 16:21:48.118 1152612292133022: querying the registry for OTAA device
2019-06-13 16:21:48.889 1152612292133022: using edgeHub local queue
2019-06-13 16:21:49.072 1152612292133022: getting device twin
2019-06-13 16:21:50.102 1152612292133022: done getting device twin
2019-06-13 16:21:50.560 1152612292133022: updating twin
2019-06-13 16:21:50.996 1152612292133022: twin updated
2019-06-13 16:21:51.051 1152612292133022: device added to cache
2019-06-13 16:21:51.322 UDP: sending message with ID 6DC9, to 172.18.0.1:57992
2019-06-13 16:21:51.325 UDP: message sent with ID 6DC9
2019-06-13 16:21:51.327 UDP: packet with id 6DC9 successfully transmitted by the aggregator
2019-06-13 16:21:51.330 1152612292133022: processing time: 00:00:03.4792686
2019-06-13 16:21:51.330 1152612292133022: JoinAccept {"txpk":{"imme":false,"data":"IKo385Fl2h2z22Fe2rbjJUU=","tmst":738168242,"size":17,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF7BW500","codr":"4/5","powe":14,"ipol":true}}
2019-06-13 16:21:51.473 Statistic: {"stat":{"time":"2019-06-13 16:21:51 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":1,"txnb":0}}
2019-06-13 16:21:57.281 Physical dataUp {"rxpk":[{"tmst":742597868,"chan":1,"rfch":0,"freq":902.500000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":9.0,"rssi":-47,"size":23,"data":"AExrbmlMQHJVIjATkiJhUhHLpggUmj0="}]}
2019-06-13 16:21:57.282 1152612292133022: join request received
2019-06-13 16:21:57.283 1152612292133022: querying the registry for OTAA device
2019-06-13 16:21:57.425 1152612292133022: updating twin
2019-06-13 16:21:57.436 1152612292133022: twin updated
2019-06-13 16:21:57.443 1152612292133022: device added to cache
2019-06-13 16:21:57.443 1152612292133022: previous device devAddr (03A79CF8) removed from cache.
2019-06-13 16:21:57.443 UDP: sending message with ID 550B, to 172.18.0.1:57992
2019-06-13 16:21:57.444 UDP: message sent with ID 550B
2019-06-13 16:21:57.444 1152612292133022: processing time: 00:00:00.1643870
2019-06-13 16:21:57.444 1152612292133022: JoinAccept {"txpk":{"imme":false,"data":"IBdvBR2dWP4qsq1tKU0zeqA=","tmst":747597868,"size":17,"freq":923.9,"rfch":0,"modu":"LORA","datr":"SF10BW500","codr":"4/5","powe":14,"ipol":true}}
2019-06-13 16:21:57.445 UDP: packet with id 550B successfully transmitted by the aggregator
2019-06-13 16:22:09.399 1152612292133022: received cloud to device message from direct method: {"devEUI":"1152612292133022","fport":"1","messageId":"0001","confirmed":true,"payload":"HeaterOn"}
2019-06-13 16:22:09.438 1152612292133022: [class-c] down frame counter: 1
2019-06-13 16:22:09.453 1152612292133022: using standard second receive window
2019-06-13 16:22:09.645 1152612292133022: ConfirmedDataDown {"txpk":{"imme":true,"data":"oFRmYAMAAQABRH8lpTaUh5JKSS4o","tmst":0,"size":21,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF12BW500","codr":"4/5","powe":14,"ipol":true}}
2019-06-13 16:22:09.645 UDP: sending message with ID 4370, to 172.18.0.1:57992
2019-06-13 16:22:09.645 UDP: message sent with ID 4370
2019-06-13 16:22:09.647 UDP: packet with id 4370 successfully transmitted by the aggregator
2019-06-13 16:22:21.470 Statistic: {"stat":{"time":"2019-06-13 16:22:21 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":2,"txnb":3}}
2019-06-13 16:22:51.477 Statistic: {"stat":{"time":"2019-06-13 16:22:51 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}

[2] UrsaLink device utility

Question: Docker Version?

I'm getting ready to install a fresh install of 1.0.2 to a new instance of Azure IoT Hub. I currently have Docker Version 18.03.0-ce-win59 (16762) installed on my dev box. What is the recommended Docker version for the latest code?

Thanks!

Aaeon support for US915?

https://www.aaeon.com/en/p/intel-lora-gateway-system-server
Can you confirm that this device supports US915? I had a sensor vendor tell me it only supports EU, but your Read.me here says both. Their specs don't say US915 exactly.

In my use case, I'll have Lora devices on a farm in Ohio. I want to get access to their data on an Azure IoT Edge device in the greenhouse. That is why I'm looking at using this starter kit.

Just wanted to confirm that this device is still good and will work with your kit.
Thanks!
Donnie

Question: How to configure for 915 Mhz LoraWAN Gateway?

I'd like to adapt the starter kit to work with the Seeed LoRa/LoRaWAN Gateway - 915MHz for Raspberry Pi 3. Can you provide some guidance on how to modify the configuration to work with the 915 Mhz board please?

Error on receiving message in LoRaWanNetworkSrvModule (EU868)

Hi,
After some messages arrived at the LoRaWanNetworkSrvModule on the IoT edge, a error like this will be shown, does anyone have any idea what the cause of this error is?

2019-01-17 10:18:13.561 Statistic: {"stat":{"time":"2019-01-17 10:18:13 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":0.0,"dwnb":0,"txnb":0,"ping":10}}
2019-01-17 10:18:26.830 Physical dataUp {"rxpk":[{"tmst":1155992083,"time":"2019-01-17T10:18:26Z","chan":4,"rfch":0,"freq":867.900000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":10.2,"rssi":-61,"size":32,"data":"XXXX"}]}
2019-01-17 10:18:26.917 Error processing the message No such device or address,    at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask`1 creationTask)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at LoRaWan.NetworkServer.LoraDeviceInfoManager.GetLoraDeviceInfoAsync(String DevAddr, String GatewayId) in /app/LoRaWan.NetworkServer/LoraDeviceInfoManager.cs:line 75
   at LoRaWan.NetworkServer.MessageProcessor.ProcessLoraMessage(LoRaMessageWrapper loraMessage) in /app/LoRaWan.NetworkServer/MessageProcessor.cs:line 87
   at LoRaWan.NetworkServer.MessageProcessor.ProcessMessageAsync(Byte[] message) in /app/LoRaWan.NetworkServer/MessageProcessor.cs:line 52

Payload in HEX

Is your feature request related to a problem? Please describe.
We are working with a customer that is using two different lora gateways, one of them being this SW. The data comes encoded as HEX from the otherGW and base64 from this SW. They decode the data using a stream analytics, which needs a hex input. They have attempted to write a base64 to hex converter but it has proved hard in plain js. We were wondering if this SW must base64 encode or if it could send payload in HEX instead.

Describe the solution you'd like
Payload upload to iot hub as HEX

Describe alternatives you've considered
Tried to write a simple base64 to hex using plain javascrict as UDF in stream analytics. It can be done but maybe this is easier to do at the gateway

Additional context
Add any other context or screenshots about the feature request here.

Migrate \Samples and \Tools projects to .Net 3

Error deploying docker image to Azure container registry

With the latest released code 1.0.2, I can no longer deploy my docker modules to my Azure container registry.

Expected Behavior

The docker modules should be built and pushed to the Azure container registry

Current Behavior

When I choose Build and Push IoT Edge Solution, the deployment fails with:

Error response from daemon: mkdir /var/lib/docker/tmp/docker-builder667908891: read-only file system

Steps to Reproduce

Build the current source code in VS code - CTRL-SHFT-B
Right click on deployment.template.json and choose ``Build and Push IoT Edge Solution`

Context (Environment)

Device (Host) Operating System

Architecture

amd64

Container Operating System

Windows containers

LoRaWAN Module Version

Docker

Client:
 Version:       18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24
 Built: Wed Mar 21 23:06:28 2018
 OS/Arch:       windows/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.03.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   0520e24
  Built:        Wed Mar 21 23:14:32 2018
  OS/Arch:      linux/amd64
  Experimental: true

Logs

docker build  --rm -f "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.2\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanNetworkSrvModule\Dockerfile.amd64" -t xxxxxxxxxxx.azurecr.io/lorawannetworksrvmodule:1.0.0-amd64 "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.2\iotedge-lorawan-starterkit" ; if ($?) { docker push xxxxxxxxxxx.azurecr.io/lorawannetworksrvmodule:1.0.0-amd64 } if ($?) { docker build  --rm -f "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.2\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanPktFwdModule\Dockerfile.amd64" -t xxxxxxxxxxx.azurecr.io/lorawanpktfwdmodule:1.0.0-amd64 "d:\dev\GitHub\iotedge-lorawan-starter\iotedge-lorawan-starterkit-1.0.2\iotedge-lorawan-starterkit\LoRaEngine\modules\LoRaWanPktFwdModule" } if ($?) { docker push xxxxxxxxxxx.azurecr.io/lorawanpktfwdmodule:1.0.0-amd64 }
Error response from daemon: mkdir /var/lib/docker/tmp/docker-builder610627006: read-only file system

Additional Information

Encoder-decoder for STREGA devices

The Strega Smart Valve sent me this link
https://github.com/Strega-Technologies/Strega
It is Javascript.

Does that mean I need to go through this custom setup?
https://github.com/Azure/iotedge-lorawan-starterkit/blob/dev/Samples/DecoderSample/ReadMe.md

Or do I need your help since it is a different language?

Windows IoT Enterprise?

Does this starterkit work with an Edge Device running Windows? It doesn't say or at I don't see OS requirement stated.

Thanks,
Donnie

Class C devices are not receiving direct messages

I'm having an issue with some new Class C devices, I have older versions of the same device which work as expected. I'm not sure if this related to AppKey and AppEUI issue - lowercase vs upper case. I have configured the new devices exactly as I configured the older version of the same device.

Here are the network server logs when a direct message is received:

2020-05-15 16:46:24.277 Statistic: {"stat":{"time":"2020-05-15 16:46:24 GMT","rxnb":2,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":0,"txnb":0}}
2020-05-15 16:46:37.884 24E1611693965996: received cloud to device message from direct method: {"devEUI":"24E1611693965996","fport":"55","confirmed":false,"payload":"CurtainDown","MessageId":"79d963f35f834250a180d4cd78660740"}
2020-05-15 16:46:37.884 24E1611693965996: [class-c] down frame counter: 11
2020-05-15 16:46:37.885 24E1611693965996: using device rx2: 10, datr: SF10BW500, region: US915
2020-05-15 16:46:37.886 24E1611693965996: cloud to device message: 4375727461696E446F776E, id: 79d963f35f834250a180d4cd78660740, fport: 55, confirmed: False, cidType: Zero
2020-05-15 16:46:37.886 24E1611693965996: sending a downstream message with ID D914
2020-05-15 16:46:37.886 24E1611693965996: UnconfirmedDataDown {"txpk":{"imme":true,"data":"YHzudwIACwA3pdc05aaKR8iFWkNgR4Gz","tmst":0,"size":24,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF10BW500","codr":"4/5","powe":14,"ipol":true}}
2020-05-15 16:46:37.886 UDP: sending message with ID 8F7A, to 172.18.0.1:52297
2020-05-15 16:46:37.887 UDP: message sent with ID 8F7A
2020-05-15 16:46:37.888 UDP: packet with id 8F7A successfully transmitted by the aggregator
2020-05-15 16:46:38.013 24E1611693947029: received cloud to device message from direct method: {"devEUI":"24E1611693947029","fport":"55","confirmed":false,"payload":"CurtainDown","MessageId":"80108a1a2fbd4ef3ad7f948c4e9c6d32"}
2020-05-15 16:46:38.013 24E1611693947029: [class-c] down frame counter: 11
2020-05-15 16:46:38.013 24E1611693947029: using device rx2: 10, datr: SF10BW500, region: US915
2020-05-15 16:46:38.014 24E1611693947029: cloud to device message: 4375727461696E446F776E, id: 80108a1a2fbd4ef3ad7f948c4e9c6d32, fport: 55, confirmed: False, cidType: Zero
2020-05-15 16:46:38.014 24E1611693947029: sending a downstream message with ID EEA6
2020-05-15 16:46:38.014 24E1611693947029: UnconfirmedDataDown {"txpk":{"imme":true,"data":"YHSakAMACwA3gQ/lndnHfY/OTMMd00S2","tmst":0,"size":24,"freq":923.3,"rfch":0,"modu":"LORA","datr":"SF10BW500","codr":"4/5","powe":14,"ipol":true}}
2020-05-15 16:46:38.014 UDP: sending message with ID C617, to 172.18.0.1:52297
2020-05-15 16:46:38.017 UDP: message sent with ID C617
2020-05-15 16:46:38.018 UDP: packet with id C617 successfully transmitted by the aggregator

And here are the logs from the packet forwarder:

JSON up: {"stat":{"time":"2020-05-15 16:45:54 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":100.0,"dwnb":0,"txnb":0}}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_ACK received in 0 ms
INFO: [down] PULL_ACK received in 0 ms

INFO: Received pkt from mote: 03FDA89F (fcnt=59497)

JSON up: {"rxpk":[{"tmst":2815279628,"chan":4,"rfch":1,"freq":903.100000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":6.5,"rssi":-35,"size":18,"data":"QJ+o/QMAaegEIdyfWFbpJyKp"}]}
INFO: [up] PUSH_ACK received in 1 ms

INFO: Disabling GPS mode for concentrator's counter...
INFO: host/sx1301 time offset=(1589558364s:830447µs) - drift=-182µs
INFO: Enabling GPS mode for concentrator's counter.


##### 2020-05-15 16:46:24 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 2
# CRC_OK: 50.00%, CRC_FAIL: 50.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (18 bytes)
# PUSH_DATA datagrams sent: 2 (312 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 2 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
# TX rejected (collision packet): 0.00% (req:77, rej:0)
# TX rejected (collision beacon): 0.00% (req:77, rej:0)
# TX rejected (too late): 0.00% (req:77, rej:0)
# TX rejected (too early): 0.00% (req:77, rej:0)
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
# SX1301 time (PPS): 2939226827
src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####

Here is my redacted twins for one of the devices:

{
  "deviceId": "24E1611693965996",
  "etag": "AAAAAAAAAAg=",
  "deviceEtag": "OTQ4MjI3MjQy",
  "status": "enabled",
  "statusUpdateTime": "0001-01-01T00:00:00Z",
  "connectionState": "Connected",
  "lastActivityTime": "2020-05-15T15:40:38.4191822Z",
  "cloudToDeviceMessageCount": 0,
  "authenticationType": "sas",
  "x509Thumbprint": {
    "primaryThumbprint": null,
    "secondaryThumbprint": null
  },
  "version": 27,
  "properties": {
    "desired": {
      "AppEUI": "*****************",
      "AppKey": "**************************************",
      "SensorDecoder": "http://decoder/api/DecodeUrsaLinkUc1114",
      "GatewayID": "evolution-indoor",
      "ClassType": "C",
      "RX2DataRate": 10,
      "$metadata": {
        "$lastUpdated": "2020-05-14T17:16:02.6554813Z",
        "$lastUpdatedVersion": 8,
        "AppEUI": {
          "$lastUpdated": "2020-05-14T17:16:02.6554813Z",
          "$lastUpdatedVersion": 8
        },
        "AppKey": {
          "$lastUpdated": "2020-05-14T17:16:02.6554813Z",
          "$lastUpdatedVersion": 8
        },
        "SensorDecoder": {
          "$lastUpdated": "2020-05-14T17:16:02.6554813Z",
          "$lastUpdatedVersion": 8
        },
        "GatewayID": {
          "$lastUpdated": "2020-05-14T17:16:02.6554813Z",
          "$lastUpdatedVersion": 8
        },
        "ClassType": {
          "$lastUpdated": "2020-05-14T17:16:02.6554813Z",
          "$lastUpdatedVersion": 8
        },
        "RX2DataRate": {
          "$lastUpdated": "2020-05-14T17:16:02.6554813Z",
          "$lastUpdatedVersion": 8
        }
      },
      "$version": 8
    },
    "reported": {
      "AppSKey": "",
      "NwkSKey": "",
      "DevAddr": "0277EE7C",
      "FCntDown": 7,
      "FCntUp": 70,
      "DevEUI": "24E1611693965996",
      "NetId": "010000",
      "DevNonce": "89F3",
      "Region": "US915",
      "RX2DataRate": 10,
      "$metadata": {
        "$lastUpdated": "2020-05-15T15:10:33.937785Z",
        "AppSKey": {
          "$lastUpdated": "2020-05-14T22:38:36.476482Z"
        },
        "NwkSKey": {
          "$lastUpdated": "2020-05-14T22:38:36.476482Z"
        },
        "DevAddr": {
          "$lastUpdated": "2020-05-14T22:38:36.476482Z"
        },
        "FCntDown": {
          "$lastUpdated": "2020-05-15T15:10:33.937785Z"
        },
        "FCntUp": {
          "$lastUpdated": "2020-05-15T15:10:33.937785Z"
        },
        "DevEUI": {
          "$lastUpdated": "2020-05-14T22:38:36.476482Z"
        },
        "NetId": {
          "$lastUpdated": "2020-05-14T22:38:36.476482Z"
        },
        "DevNonce": {
          "$lastUpdated": "2020-05-14T22:38:36.476482Z"
        },
        "Region": {
          "$lastUpdated": "2020-05-14T16:53:46.3250049Z"
        },
        "RX2DataRate": {
          "$lastUpdated": "2020-05-14T22:38:36.476482Z"
        }
      },
      "$version": 19
    }
  },
  "capabilities": {
    "iotEdge": false
  },
  "deviceScope": "ms-azure-iot-edge://"
}

Any insight into why my old devices receive messages but the new devices do not would be greatly appreciated.

Newbie questions

Hi I'm new to the IoT world and Azure and would like to create a gateway on a Raspberry PI with a Lora hat.

I don't really understand what I should install on the Pi, should I need to create a gateway first and then install the edge or is everything needed in this repo?

Is there any configuration to make this work with a specific Lora hat? I'm doing a proof of concept so I'm making a simple single channel gateway with the Dragino Lora hat.

Deploying LoraKeysManagerFacade results in no functions

After creating and deploying the function app with the Functions plugin in VS Code, there are no functions visible in the Azure Portal.

In the .vscode/settings.json I already adjusted the deploy path to: LoraKeysManagerFacade/bin/Release/netstandard2.0/publish

Does anyone know how to resolve this issue?

Hex messages receive issue

Can the engine receive the hex type lora payload? I tested it, but seems wrong.

"ClearCache" method issue

Cache Clearing
Due to the gateway caching the device information (tags) for 1 day, if the device tries to connect before you have provisioned it, it will not be able to connect because it will be considered a device for another LoRa network. To clear the cache and allow the device to connect follow these steps:

IoT Hub -> IoT Edge -> click on the device ID of your gateway
Click on LoRaWanNetworkSrvModule
Click Direct Method
Type "ClearCache" on Method Name
Click Invoke Method
Alternatively you can restart the Gateway or the LoRaWanNetworkSrvModule container.

I followed the step above,but it can't work.
I change to "clear cache",it can work but the gateway log is still here after I restart.
Can you fix it?

[REOPENED]Configure AAEON AIOT-IP68 Gateway and Network Server/ LoRaWanPktFwdModule fails to start

I am trying to configure an AAEON AIOT-IP68 gateway which is based on upboard 2 (up2). I am not able to get the LoRaWanPktFwdModule to start. I'm looking for any insight into what I need to do to properly configure the gateway.

Expected Behavior

The LoRaWanPktFwdModule starts

Current Behavior

The LoraWanPktFwdModule fails to start.

Steps to Reproduce

Installed Ubuntu 16.0.4 and configured following the instructions here: https://wiki.up-community.org/Ubuntu
Installed IoT Edge following the instructions here: https://docs.microsoft.com/en-us/azure/iot-edge/how-to-install-iot-edge-linux
Configured .env with proper GPIO pin (430) and SPIDEV (1)
Deploy software to the gateway via VS Code

Context (Environment)

Windows 10/ VS Code

Device (Host) Operating System

Ubuntu 16.04

Architecture

AMD64

Container Operating System

Docker

LoRaWAN Module Version

Using code from 0.4.0-preview (i.e. current master branch)

Docker

Version 18.03.0-ce-win59 (16762)

Logs

US region detected.
Accessing concentrator reset pin through GPIO430...
Using SPI dev 1 from environment variables
*** Beacon Packet Forwarder for Lora Gateway ***
Version: 4.0.1
*** Lora concentrator HAL library version info ***
Version: 5.0.1;
***
INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 1
INFO: no configuration for LBT
INFO: antenna_gain 0 dBi
INFO: Configuring TX LUT with 16 indexes
INFO: radio 0 enabled (type SX1257), center frequency 902700000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 0
INFO: radio 1 enabled (type SX1257), center frequency 903400000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0
INFO: Lora multi-SF channel 0>  radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1>  radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2>  radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4>  radio 1, IF -300000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5>  radio 1, IF -100000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6>  radio 1, IF 100000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7>  radio 1, IF 300000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 0, IF 300000 Hz, 500000 Hz bw, SF 8
INFO: FSK channel 8 disabled
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to AA555A0000000000
INFO: server hostname or IP address is configured to "192.168.0.17"
INFO: upstream port is configured to "1680"
INFO: downstream port is configured to "1680"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: found local configuration file local_conf.json, parsing it
INFO: redefined parameters will overwrite global parameters
INFO: local_conf.json does not contain a JSON object named SX1301_conf
INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to AA555A0000000101
INFO: server hostname or IP address is configured to "172.17.0.1"
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
ERROR: [main] failed to start the concentrator

Additional Information

I was told to use GPIO 430 and SPIDEV 1 by AAEON technical support. I have set those properties correctly in my .env file.

LMIC support for class C devices

Is your feature request related to a problem? Please describe.
In order to facilitate testing it would be useful to add class C support for Heltec device. Currently we are running the version available here: https://github.com/ronniesa/ArduinoESP32LoRaWAN

Describe the solution you'd like
Add possibility to switch between class A and C based on long clicks of the PRG button.

1x long PRG click: switch between confirmed and unconfirmed
2x long PRG click: switch between class A and C type. In class C mode, display the incoming message in the display

How to add two or more edge gateway devices?

So I want to use two or more edge gateway devices for my lorawan network, how to add them? Should set something different for the Azure?Thank you.

Join failures

Using the code form the current master branch (0.3.0) I am receiving Error processing the message The given key '6' was not present in the dictionary. for devices from one particular device manufacturer. I asked the manufacturer to set up the devices with this frequency plan[1]. I'm trying to determine if there is something incorrectly configured on the devices or if there is a bug in the gateway code? Here is a sampling of the logs[2].

Any insight as to where the issue lies would be much appreciated.

Thanks!

--Michael

[1] US frequency plan

 {
    "SX1301_conf": {
             "lorawan_public": true,
        "clksrc": 1, /* radio_1 provides clock to concentrator */
        "antenna_gain": 0, /* antenna gain, in dBi */
        "radio_0": {
            "enable": true,
            "type": "SX1257",
            "freq": 902700000,
            "rssi_offset": -166.0,
            "tx_enable": true,
            "tx_freq_min": 902000000,
            "tx_freq_max": 928000000
        },
        "radio_1": {
            "enable": true,
            "type": "SX1257",
            "freq": 903400000,
            "rssi_offset": -166.0,
            "tx_enable": false
        },
        "chan_multiSF_0": {
            /* Lora MAC channel, 125kHz, all SF, 902.3 MHz */
            "enable": true,
            "radio": 0,
            "if": -400000
        },
        "chan_multiSF_1": {
            /* Lora MAC channel, 125kHz, all SF, 902.5 MHz */
            "enable": true,
            "radio": 0,
            "if": -200000
        },
        "chan_multiSF_2": {
            /* Lora MAC channel, 125kHz, all SF, 902.7 MHz */
            "enable": true,
            "radio": 0,
            "if": 0
        },
        "chan_multiSF_3": {
            /* Lora MAC channel, 125kHz, all SF, 902.9 MHz */
            "enable": true,
            "radio": 0,
            "if": 200000
        },
        "chan_multiSF_4": {
            /* Lora MAC channel, 125kHz, all SF, 903.1 MHz */
            "enable": true,
            "radio": 1,
            "if": -300000
        },
        "chan_multiSF_5": {
            /* Lora MAC channel, 125kHz, all SF, 903.3 MHz */
            "enable": true,
            "radio": 1,
            "if": -100000
        },
        "chan_multiSF_6": {
            /* Lora MAC channel, 125kHz, all SF, 903.5 MHz */
            "enable": true,
            "radio": 1,
            "if": 100000
        },
        "chan_multiSF_7": {
            /* Lora MAC channel, 125kHz, all SF, 903.7 MHz */
            "enable": true,
            "radio": 1,
            "if": 300000
        },
        "chan_Lora_std": {
            /* Lora MAC channel, 500kHz, SF8, 903.0 MHz */
            "enable": true,
            "radio": 0,
            "if": 300000,
            "bandwidth": 500000,
            "spread_factor": 8
        },
        "chan_FSK": {
            /* FSK 100kbps channel, 903.0 MHz */
            "enable": false,
            "radio": 0,
            "if": 300000,
            "bandwidth": 250000,
            "datarate": 100000
        },
                "tx_lut_0": {
                        "desc": "TX gain table, index 0",
                        "pa_gain": 0,
                        "mix_gain": 8,
                        "rf_power": -6,
                        "dig_gain": 0
                },
                "tx_lut_1": {
                        "desc": "TX gain table, index 1",
                        "pa_gain": 0,
                        "mix_gain": 10,
                        "rf_power": -3,
                        "dig_gain": 0
                },
                "tx_lut_2": {
                        "desc": "TX gain table, index 2",
                        "pa_gain": 0,
                        "mix_gain": 12,
                        "rf_power": 0,
                        "dig_gain": 0
                },
                "tx_lut_3": {
                        "desc": "TX gain table, index 3",
                        "pa_gain": 1,
                        "mix_gain": 8,
                        "rf_power": 3,
                        "dig_gain": 0
                },
                "tx_lut_4": {
                        "desc": "TX gain table, index 4",
                        "pa_gain": 1,
                        "mix_gain": 10,
                        "rf_power": 6,
                        "dig_gain": 0
                },
                "tx_lut_5": {
                        "desc": "TX gain table, index 5",
                        "pa_gain": 1,
                        "mix_gain": 12,
                        "rf_power": 10,
                        "dig_gain": 0
                },
                "tx_lut_6": {
                        "desc": "TX gain table, index 6",
                        "pa_gain": 1,
                        "mix_gain": 13,
                        "rf_power": 11,
                        "dig_gain": 0
                },
                "tx_lut_7": {
                        "desc": "TX gain table, index 7",
                        "pa_gain": 2,
                        "mix_gain": 9,
                        "rf_power": 12,
                        "dig_gain": 0
                },
                "tx_lut_8": {
                        "desc": "TX gain table, index 8",
                        "pa_gain": 1,
                        "mix_gain": 15,
                        "rf_power": 13,
                        "dig_gain": 0
                },
                "tx_lut_9": {
                        "desc": "TX gain table, index 9",
                        "pa_gain": 2,
                        "mix_gain": 10,
                        "rf_power": 14,
                        "dig_gain": 0
                },
                "tx_lut_10": {
                        "desc": "TX gain table, index 10",
                        "pa_gain": 2,
                        "mix_gain": 11,
                        "rf_power": 16,
                        "dig_gain": 0
                },
                "tx_lut_11": {
                        "desc": "TX gain table, index 11",
                        "pa_gain": 3,
                        "mix_gain": 9,
                        "rf_power": 20,
                        "dig_gain": 0
                },
                "tx_lut_12": {
                        "desc": "TX gain table, index 12",
                        "pa_gain": 3,
                        "mix_gain": 10,
                        "rf_power": 23,
                        "dig_gain": 0
                },
                "tx_lut_13": {
                        "desc": "TX gain table, index 13",
                        "pa_gain": 3,
                        "mix_gain": 11,
                        "rf_power": 25,
                        "dig_gain": 0
                },
                "tx_lut_14": {
                        "desc": "TX gain table, index 14",
                        "pa_gain": 3,
                        "mix_gain": 12,
                        "rf_power": 26,
                        "dig_gain": 0
                },
                "tx_lut_15": {
                        "desc": "TX gain table, index 15",
                        "pa_gain": 3,
                        "mix_gain": 14,
                        "rf_power": 27,
                        "dig_gain": 0
                }
    },

    "gateway_conf": {
        "gateway_ID": "AA555A0000000000",
        /* change with default server address/ports, or overwrite in local_conf.json */
        "server_address": "192.168.0.17",
        "serv_port_up": 1680,
        "serv_port_down": 1680,
        /* adjust the following parameters for your network */
        "keepalive_interval": 10,
        "stat_interval": 30,
        "push_timeout_ms": 100,
        /* forward only valid packets */
        "forward_crc_valid": true,
        "forward_crc_error": false,
        "forward_crc_disabled": false
    }
}

[2] logs

2019-01-28 20:48:15.193 Statistic: {"stat":{"time":"2019-01-28 20:48:15 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":0,"txnb":0}}
2019-01-28 20:48:34.087 Physical dataUp {"rxpk":[{"tmst":3869713428,"chan":7,"rfch":1,"freq":903.700000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":12.5,"rssi":-32,"size":23,"data":"AAMAABECxSYsQAMGEQJ3SgAzh8+51yM="}]}
2019-01-28 20:48:34.088 004A770211060340: join request received
2019-01-28 20:48:34.088 004A770211060340: querying the registry for device key
2019-01-28 20:48:34.245 004A770211060340: using edgeHub local queue
2019-01-28 20:48:34.246 004A770211060340: using cached twins for OTAA device
2019-01-28 20:48:34.247 004A770211060340: saving join properties twins
2019-01-28 20:48:35.568 004A770211060340: done saving join properties twins
2019-01-28 20:48:35.569 4B914702: JoinAccept {"txpk":{"imme":false,"data":"INMnrTn9EvAi2JyiaW93klU=","tmst":3874713428,"size":17,"freq":927.5,"rfch":0,"modu":"LORA","datr":"SF11BW500","codr":"4/5","powe":14,"ipol":true}}
2019-01-28 20:48:35.569 004A770211060340: join accept sent with ID B873
2019-01-28 20:48:35.569 004A770211060340: processing time: 00:00:01.4818369
2019-01-28 20:48:35.570 Packet with id B873 successfully transmitted by the aggregator
2019-01-28 20:48:41.379 Physical dataUp {"rxpk":[{"tmst":3877001644,"chan":8,"rfch":0,"freq":903.000000,"stat":1,"modu":"LORA","datr":"SF8BW500","codr":"4/5","lsnr":10.2,"rssi":-34,"size":23,"data":"AAMAABECxSYsQAMGEQJ3SgCJRmabVd8="}]}
2019-01-28 20:48:41.379 004A770211060340: join request received
2019-01-28 20:48:41.380 004A770211060340: querying the registry for device key
2019-01-28 20:48:41.441 004A770211060340: using edgeHub local queue
2019-01-28 20:48:41.441 004A770211060340: using cached twins for OTAA device
2019-01-28 20:48:41.445 004A770211060340: saving join properties twins
2019-01-28 20:48:41.701 004A770211060340: done saving join properties twins
2019-01-28 20:48:41.706 Error processing the message The given key '6' was not present in the dictionary.,    at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at LoRaTools.Regions.Region.GetDownstreamDR(Rxpk upstreamChannel) in /app/LoraTools/Regions/Region.cs:line 137
   at LoRaWan.NetworkServer.MessageProcessor.ProcessJoinRequest(LoRaMessageWrapper loraMessage) in /app/LoRaWan.NetworkServer/MessageProcessor.cs:line 613
   at LoRaWan.NetworkServer.MessageProcessor.ProcessMessageAsync(Byte[] message) in /app/LoRaWan.NetworkServer/MessageProcessor.cs:line 55
   at LoRaWan.NetworkServer.UdpServer.<>c__DisplayClass10_1.<<RunUdpListener>b__0>d.MoveNext() in /app/LoRaWan.NetworkServer/UdpServer.cs:line 105
2019-01-28 20:48:45.194 Statistic: {"stat":{"time":"2019-01-28 20:48:45 GMT","rxnb":2,"rxok":2,"rxfw":2,"ackr":100.0,"dwnb":1,"txnb":1}}
2019-01-28 20:48:49.525 Physical dataUp {"rxpk":[{"tmst":3885147356,"chan":5,"rfch":1,"freq":903.300000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":12.5,"rssi":-34,"size":23,"data":"AAMAABECxSYsQAMGEQJ3SgB7totqHk0="}]}
2019-01-28 20:48:49.526 004A770211060340: join request received
2019-01-28 20:48:49.526 004A770211060340: querying the registry for device key
2019-01-28 20:48:49.579 004A770211060340: using edgeHub local queue
2019-01-28 20:48:49.579 004A770211060340: using cached twins for OTAA device
2019-01-28 20:48:49.580 004A770211060340: saving join properties twins
2019-01-28 20:48:49.851 004A770211060340: done saving join properties twins
2019-01-28 20:48:49.852 9F0E6502: JoinAccept {"txpk":{"imme":false,"data":"IJlFzfXgCeAEZ9kN2N7rtuQ=","tmst":3890147356,"size":17,"freq":926.3,"rfch":0,"modu":"LORA","datr":"SF11BW500","codr":"4/5","powe":14,"ipol":true}}
2019-01-28 20:48:49.853 004A770211060340: join accept sent with ID 28CD
2019-01-28 20:48:49.853 004A770211060340: processing time: 00:00:00.3283120
2019-01-28 20:48:49.855 Packet with id 28CD successfully transmitted by the aggregator

Redis cache usage

Hello

I just read the documenation and I know a redis cache is needed, however it doesnt mention whats the usage of it in the entire solution, can you please explain me? What do we store in there?

Thanks in advance?

AS923 Support

Is your feature request related to a problem? Please describe.
Support of AS923 frequency range

Describe the solution you'd like
LoRa starter kit should support AS 923 freq range

Describe alternatives you've considered
N/A

Additional context
Requested by community

Device is not our device

I just did a clean install of version 1.0.2 to a brand new Azure account using the Quick Start template. After updating the IoT Edge connection string on my gateway device, all of the various modules started as expected after a reboot however none of the child devices associated to the gateway are able to connect. I get an message "device is not our device" for each device which is trying to connect.

I should note that the gateway was previously running version 1.0.0 of the LoraWan Starter Kit prior to updating to version 1.0.2.

I'm using version 1.0.7 of azureiotedge-agent and azureiotedge-hub. I tried restarting the redis cache but this had no effect. This is a production deployment so it important that I am able to resolve this quickly.

any ideas as to what I can do to resolve this issue?

Device (Host) Operating System

Ubuntu 16.04

Architecture

amd64

Logs


2019-11-30 18:54:40.938 0343AA7F: querying the registry for device
2019-11-30 18:54:41.071 0343AA7F: querying the registry for devices by devAddr 0343AA7F found 0 devices
2019-11-30 18:54:41.071 0343AA7F: device is not our device, ignore message
2019-11-30 18:54:41.071 0343AA7F: processing time: 00:00:00.1340335
2019-11-30 18:54:41.854 Statistic: {"stat":{"time":"2019-11-30 18:54:41 GMT","rxnb":14,"rxok":13,"rxfw":13,"ackr":100.0,"dwnb":0,"txnb":0}}
2019-11-30 18:54:56.018 Physical dataUp {"rxpk":[{"tmst":2073527212,"chan":2,"rfch":0,"freq":902.700000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":7.5,"rssi":-101,"size":24,"data":"QIZ6fAOAoAYG1/L8GliPtZ92d0vgcBR5"}]}
2019-11-30 18:54:56.019 037C7A86: querying the registry for device
2019-11-30 18:54:56.106 037C7A86: querying the registry for devices by devAddr 037C7A86 found 0 devices
2019-11-30 18:54:56.106 037C7A86: device is not our device, ignore message
2019-11-30 18:54:56.106 037C7A86: processing time: 00:00:00.0878935
2019-11-30 18:55:00.368 Physical dataUp {"rxpk":[{"tmst":2077877516,"chan":0,"rfch":0,"freq":902.300000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":9.8,"rssi":-90,"size":24,"data":"QJv5HAKAuwYG7RIa1QBt93368VUjT+8J"}]}
2019-11-30 18:55:00.368 021CF99B: querying the registry for device
2019-11-30 18:55:00.428 021CF99B: querying the registry for devices by devAddr 021CF99B found 0 devices
2019-11-30 18:55:00.428 021CF99B: device is not our device, ignore message
2019-11-30 18:55:00.428 021CF99B: processing time: 00:00:00.0606845
2019-11-30 18:55:04.284 Physical dataUp {"rxpk":[{"tmst":2081795868,"chan":7,"rfch":1,"freq":903.700000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":12.5,"rssi":-86,"size":24,"data":"QPeImQKAiQcGW2/bbwVX8Ym5gPxcYIqq"}]}
2019-11-30 18:55:04.285 029988F7: querying the registry for device
2019-11-30 18:55:04.362 029988F7: querying the registry for devices by devAddr 029988F7 found 0 devices
2019-11-30 18:55:04.362 029988F7: device is not our device, ignore message
2019-11-30 18:55:04.362 029988F7: processing time: 00:00:00.0777311
2019-11-30 18:55:06.023 Physical dataUp {"rxpk":[{"tmst":2083540188,"chan":1,"rfch":0,"freq":902.500000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":13.0,"rssi":-77,"size":24,"data":"QIBPbAOAigcGlZSdiOzp+ZCSEOvEKrJr"}]}
2019-11-30 18:55:06.023 036C4F80: querying the registry for device
2019-11-30 18:55:06.087 036C4F80: querying the registry for devices by devAddr 036C4F80 found 0 devices
2019-11-30 18:55:06.087 036C4F80: device is not our device, ignore message
2019-11-30 18:55:06.087 036C4F80: processing time: 00:00:00.0649193
2019-11-30 18:55:08.386 Physical dataUp {"rxpk":[{"tmst":2085902516,"chan":0,"rfch":0,"freq":902.300000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":9.0,"rssi":-65,"size":24,"data":"QNL/SAKAPwMBO1jZxRkS78+EqPhH7CcA"}]}
2019-11-30 18:55:08.387 0248FFD2: querying the registry for device
2019-11-30 18:55:08.451 0248FFD2: querying the registry for devices by devAddr 0248FFD2 found 0 devices
2019-11-30 18:55:08.451 0248FFD2: device is not our device, ignore message
2019-11-30 18:55:08.451 0248FFD2: processing time: 00:00:00.0653935

azure / iotedge-lorawan-starterkit Goto Github PK

iotedge-lorawan-starterkit's Introduction

Azure IoT Edge LoRaWAN Starter Kit

Features

Prerequisites

Getting Started

Known Issues and Limitations

Tested Gateways

Support

Contributing

Create a release

Write release notes

Run the Release workflow to create a draft release

Create and merge 2 PRs

Update master

Add a release description and publish the release

iotedge-lorawan-starterkit's People

Contributors

Stargazers

Watchers

Forkers

iotedge-lorawan-starterkit's Issues

Expected Behavior

Current Behavior

Steps to Reproduce

Context (Environment)

Device (Host) Operating System

Architecture

Container Operating System

LoRaWAN Module Version

Docker

Logs

Additional Information

Expected Behavior

Current Behavior

Steps to Reproduce

Context (Environment)

Device (Host) Operating System

Architecture

Container Operating System

LoRaWAN Module Version

Docker

Logs

Additional Information

Expected Behavior

Current Behavior

Device (Host) Operating System

Architecture

Container Operating System

Logs

Additional Information

Device (Host) Operating System

Architecture

Container Operating System

LoRaWAN Module Version

Docker

Logs

Expected Behavior

Current Behavior

Steps to Reproduce

Context (Environment)

Device (Host) Operating System

Architecture

Container Operating System

LoRaWAN Module Version

Docker

Logs

Additional Information

Device (Host) Operating System

Architecture

Expected Behavior

Current Behavior

Steps to Reproduce

Context (Environment)

Device (Host) Operating System

Architecture

Container Operating System

LoRaWAN Module Version

Docker

Logs