Jason Reiss
Forum Replies Created
-
AuthorPosts
-
June 3, 2021 at 12:15 pm in reply to: Varying Downlink Packet size, based on the "datr" attribute of an Uplink Pkt? #31880
Jason Reiss
KeymasterTheoretically if a device can join using DR0 (SF10BW125) using 20 dBm then the gateway will be able to reach the same distance using DR10 (SF10BW500) using 27 dBm
June 2, 2021 at 2:15 pm in reply to: Varying Downlink Packet size, based on the "datr" attribute of an Uplink Pkt? #31844KeymasterHow much data are you looking to send in the downlink?
In US915 the uplink and downlink datarates and limits are different.The Rx1 and Rx2 datarates may be different. The Rx2 datarate is fixed and Rx1 can vary based on the uplink datarate and Rx1 Offset.
Class C will use the Rx2 datarate.
Maximum packet sizes for uplink and downlink are detailed in the regional parameters document.
53 bytes is the maximum payload at the lowest downlink datarate DR8 (SF12BW500) This can only be used if the Rx2 datarate is set to DR8 or the Rx1DROffset is increased above default of 0.
With default settings Rx1 will be at least DR10 (SF10BW500) and can carry up to 242 bytes.
The network may need to send MAC commands for ADR so allowing some bytes below maximum can help with network messages. An ADR command is 5 bytes.
KeymasterThe UI field is tied to the /api/loraNetwork/whitelist/enabled field.
The “enabled” flag can be added to the object containing the “devices” array.
KeymasterInside the zip file are release notes and a signed upgrade.bin file to use to update the Conduit.
April 26, 2021 at 2:33 pm in reply to: Installing Node Red Custom App on LVW2 and L4N1 Models with AEP 5.3.3 firmware? #31762KeymasterHave a look at this article. The custom-app is available on device HQ. A support case can be created to share a tar.gz file if needed.
http://www.multitech.net/developer/software/aep/creating-a-custom-application/installing-node-red-as-a-custom-app/KeymasterThe packet forwarder process may exit if the fields in a received packet are not within the expected range. This can happen occasionally and may be caused by the hardware getting in a bad state. This exit on error is the reason for the angel process that restarts the packet forwarder as a child process.
See packet processing starting on line 842
https://github.com/Lora-net/packet_forwarder/blob/v1.4.1/basic_pkt_fwd/src/basic_pkt_fwd.cKeymasterThe Conduit gateway in packet forwarder mode can send packets to a remote network server.
What network server software will you be using? TTN or Chirpstack?
https://www.chirpstack.io/
https://www.thethingsnetwork.org/The network server may also be able to use the basic station on Conduit to forwarder packets over an SSL connection.
https://github.com/lorabasics/basicstationKeymasterTo perform FOTA there is a multicast session and a fragmentation session. The multicast session has a timeout in seconds sent in the multicast session setup command as 4 bits. So the maximum is 2 to the power of 15 or ~32K seconds or ~9 hours. When the multicast session expires a device that is normally class A will close the class C window.
KeymasterPage 11 shows the timeout field available for a multicast session is 4-bits. This setting has a maximum of 9 hours.
The FOTA service in mPower will set a timeout at 9, 4, 2 or 1 hours depending on the datarate and Rx2 Duty-Cycle for the selected region. Each datarate step takes half the time on air to send the same number of bytes.
$ lora-query -x config plan rx2 { "datarate" : 2, "duration" : 698, "duty_cycle" : 0.10000000000000001, "frequency" : 869525000, "max_payload" : 51 }The timeout is not currently reduced according to file size. In the future it may.
KeymasterWhat is difference in received RSSI at the gateway between reduced power and max power transmissions?
The only indicator to the network that tx power has changed is the RSSI/SNR.
March 26, 2021 at 8:26 am in reply to: Support for managing FOTA operations via Conduit mPower API? #31693KeymasterI would look for these paths in the debug window. It will take some time to look into this and create documentation for each call.
/api/lora/groups/
/api/lora/fotafirmware/
/api/lora/fotaschedule/
/api/lora/fotaresults/KeymasterDouble check the key values. The eui is not “known” unless it has the correct key. This is a verification of the deveui identity.
March 25, 2021 at 10:07 am in reply to: Support for managing FOTA operations via Conduit mPower API? #31686KeymasterEverything that can be done it in UI is using the API. The best source for example API calls is the debug window of a browser. All API calls and JSON payloads are shown.
LoRaWAN > Device Groups can be used to create groups
LoRaWAN > Operations can schedule a FOTA for a device groupKeymasterBoth gateways must be configured for the same channel plan.
Only one channel plan is supported by the embedded network server.KeymasterWhat about the end-devices? How are they configured to connect to the LoRaWAN network?
Are you connecting with ABP or OTAA?
KeymasterAre your devices joined to the network?
Is node-red running on the 1st gateway or 2nd gateway? Only the 1st gateway would have packets arrive.
March 4, 2021 at 2:16 pm in reply to: Questions regarding operating mDot in European LORA Channel. #31667KeymasterIf you do not check the nexttxms value to calls to send or join will fail. The time can better be used to sleep.
KeymasterCode is not running while the device is in sleep mode. When code is running the device is awake.
I think the mDot does not enter the deepsleep mode regardless of requested sleep. This should show in the debug logs. Debug version of at firmware could be used to test.
https://github.com/MultiTechSystems/Dot-AT-FirmwareThe mDot lib does not allow deepsleep as the hardware cannot reach the lowest expected current.
Deep sleep on mDot does not retain ram and lowpowertimeout would not work.
Deepsleep options to wake up would by RTC alarm or interrupt.
KeymasterThe Conduit will work with any LoRaWAN certified device.
KeymasterYou can download the latest mLinux 5.3.0 commissioning images or mPower firmare from here.
Instructions to install an upgrade image can be found here.
February 22, 2021 at 11:26 am in reply to: question regarding servertime method in mDotEvent Class #31636KeymasterThe Conduit does not have an application that sends the APP TIME SYNC.
The handling is there for cases where DEVICE TIME is not available. Then an application can provide the time sync.
The application on the Dot would also need to send APP TIME requests.
KeymasterSee Using Auto-Flash During Reboot with image upgrade.bin
KeymasterLora.h would be for use with libxDot.
LoRaPHYEU868.cpp is from the mbed lorawan stack? It is not part of libxDot.
KeymasterThe frame counters are important for security.
MAX_FCNT_GAP is applied to an increasing FCNT.
The downlink frame counter would need to be reset to 0 on the end-device. Unfortunately a downlink cannot be used to reset it otherwise it would not need to be reset in the first place as the network would already know the correct value.
If the downlink counter is reset on the end-device it may be functional up to the MAX_FCNT_GAP at least and at most the two byte in packet FCNT value (~65k)
As long as the network does not advance passed the 2 byte FCNT value then resetting the downlink counter should work but will not be secure. Over time a 3rd party could reverse engineer the Session Keys given enough packets using the same FCNT values.
KeymasterThe basic station mode is a packet forwarder architeture where the packets are sent from gateways to a central network server. The gateways are stateless and are configured with only IP connection information to connect to the network server.
All end-device key information will reside in the AWS LNS.
https://aws.amazon.com/blogs/iot/introducing-aws-iot-core-for-lorawan/
https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.htmlFebruary 9, 2021 at 1:20 pm in reply to: How to send a multicast msg through lora-network-server #31573KeymasterFebruary 9, 2021 at 1:19 pm in reply to: How to send a multicast msg through lora-network-server #31572KeymasterWhat is your mLinux version?
Checkout lora-query -x help
Add a dummy ABP device and session with “multicast”: “C” in the session.
lora-query -x device add
lora-query -x session adddevice – end-device commands
add – add a new end-device record
format: device add
example: device add ‘{“deveui”:”00-80-00-00-00-00-e1-9c”,”class”:”C”}’session – session commands
add – add a session for a device
format: session add
example: session add ‘{“deveui”:”00-80-00-00-00-00-e1-9c”,”dev_addr”:”00112233″,”appeui”:”00-88-88-88-00-00-e1-9c”,”joineui”:”00-99-99-99-00-00-e1-9c”,”net_id”:”000017″,”app_senc_key”:”531bd9c5ec5d8ba5ef3b262cebfb3e66″,”fnwk_sint_key”:”531bd9c5ec5d8ba5ef3b262cebfb3e66″}’
fields: deveui, appeui, joineui, dev_addr, net_id, app_senc_key, fnwk_sint_key, multicast (B or C)KeymasterKeymasterYes it is supported, is it not working?
-
AuthorPosts