Jason Reiss
Forum Replies Created
-
AuthorPosts
-
Jason Reiss
Keymaster“DgL/DwgF/IAFANYLAWM=” => ‘0e02ff0f0805fc800500d60b0163’
0e 02ff0f Accel
08 05fc80 Pres
05 00d6 Lux
0b 0163 TempKeymasterLookup Linux init.d and update-rc.d instructions.
KeymastergetNextTmMs will only return a value in US915 in a join backoff scenario.
Check it after a join failure.KeymasterNope, that is defined behavior of the protocol for join requests.
KeymasterLoraWAN 1.0.1 specifies the join procedure as alternating between DR0 and DR4. This is for instances when many nodes are attempting to join, some may be close enough for DR4.
The module can sleep while waiting for join backoff to expire. What else can the module do?
KeymasterUse the lora-query utility or the command interface via UDP on port 6677.
KeymasterDetails can be found here.
KeymasterThe hardware is capable of FSK mode.
The software provided is a LoRaWAN client library.
LoRaWAN in US915 does not have an FSK datarate.SxRadio level libraries are available on mbed. They will allow full configuration of the radio.
https://developer.mbed.org/teams/Semtech/code/SX1272Lib/
https://developer.mbed.org/users/dudmuck/code/KeymasterThe SNR is a measure of the lora demodulation signal to noise, it is not RSSI above the noise floor.
https://www.semtech.com/images/datasheet/LoraDesignGuide_STD.pdf
KeymasterThe ACK is requested from the device. To disable the device would need to send an unconfirmed message.
There is no setting to ignore the ACK from an uplink, unless you disable both receive windows.
See test settings to disable RX windows.
KeymasterIt is a byte to be used by the application in LoRaWAN. It is sent as an identifier for the payload. It’s use is determined by the application.
0: mac commands in payload
1-223: application specific
224-255: reservedhttps://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf
KeymasterThe 1-byte Port field can be used.
Call setAppPort before sending the payload.
March 20, 2017 at 3:24 pm in reply to: Cannot send ACK from GW to endpoint when working as packet forwarder #17938KeymasterI would expect a pull response from the network server to be logged.
# PULL_DATA sent: 2 (0.00% acknowledged) # PULL_RESP(onse) datagrams received: 0 (0 bytes) # RF packets sent to concentrator: 0 (0 bytes)Check that you are following the packet forwarder downlink protocol correctly.
https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXTOutput from successful TX
##### 2019-01-13 04:58:21 GMT ##### ### [UPSTREAM] ### # RF packets received by concentrator: 1 # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% # RF packets forwarded: 1 (23 bytes) # PUSH_DATA datagrams sent: 1 (204 bytes) # PUSH_DATA acknowledged: 0.00% ### [DOWNSTREAM] ### # PULL_DATA sent: 2 (100.00% acknowledged) # PULL_RESP(onse) datagrams received: 1 (259 bytes) # RF packets sent to concentrator: 1 (17 bytes) # TX errors: 0 ##### END #####KeymasterPlease open a support ticket and attach debug output files and configuration information to the ticket.
Thanks.
KeymasterApplication source code for MTDOT EVB can be found here on mbed.
https://developer.mbed.org/platforms/mdotevb/March 17, 2017 at 7:13 am in reply to: Node-Red LORA Out Node & MDot that has not joined yet! #17874KeymasterIf the node has never joined, then there is no record of the device and a downlink will not be queued.
If the device is registered or has joined before, then it can be queued.
This is an interesting use case to consider, thanks.
KeymasterWith the proliferation of regions being added to the LoraWAN specification. We will most likely not be able to include them all in one build, especially for the limited resources available on xDot.
KeymasterActually the duty-cycle is managed on subsets of frequencies.
The default channels are in h1.4.
If one channel in the subset is used then the device must wait before using any channel in the subset. Another subset may be used.March 16, 2017 at 2:39 pm in reply to: MDot Transmission fails consistently, once the conduit reboots. #17859KeymasterPlease open a support ticket at support.multitech.com for further assistance. This will get your issue greater visibility with our support staff.
Thanks.
KeymasterACK is enabled above 2 retries
AT+ACK=8
or
setAck(8)Keymaster— But for the conduit to lower the rate, it needs the mdot to communicate with it right?
Since this is not possible, this is not what is happening. “It” can only be the device.
The lack of ACKs from the server is the indicator to the device that the packet is lost. At which point the device will raise the power and begin to lower the datarate to regain connectivity.
KeymasterAnother option would be to lower the MaxDatarate setting used for ADR if you find DR4 unreliable in the deployment environment.
KeymasterIf ACK is enabled above 2 retries on the mdot, after two missed packets the device will restore max tx power. Then after 2 more missed packets it will lower the datarate.
This IS NOT detailed in the lorawan protocol specification, it is implemented in Semtech reference LoraWAN project. https://github.com/Lora-net/LoRaMac-node
If ACK is disabled the same will happen after 96 uplinks without a downlink. First after 64 uplinks a bit is set to request a downlink from the network server. Then if a reply is not heard in the next 32 packets the max power is restored or the datarate is lowered. This is then repeated until lowest datarate or downlink is received. The counter is reset with every downlink.
This IS detailed in the lorawan protocol specification. See ADR_ACK_LIMIT and ADR_ACK_DELAY.
Cheers!
March 10, 2017 at 8:45 am in reply to: Send a Mac Command in the optionnal field of the downlink #17760KeymasterOur bitbake recipes for building lora support
http://git.multitech.net/cgi-bin/cgit.cgi/meta-mlinux.git/tree/recipes-connectivity/loraOtherwise when the /opt/lora/lora_pkt_fwd process is running it will report received packets to the network server and packets can be scheduled for downlink. The protocol is explained in the link from the previous post. It communicates over UDP.
https://github.com/Lora-net/packet_forwarder/March 10, 2017 at 8:24 am in reply to: Send a Mac Command in the optionnal field of the downlink #17758KeymasterThese test scenarios have been performed in the LoRaWAN certification testing. A certification network server implementation would be needed.
– Modify RxDelay, RX1DRoffset, RX2Data rate, CFList in the join-accept
See http://www.multitech.net/developer/software/lora/conduit-mlinux-lora-communication/conduit-mlinux-advance-lora-configuration/
See rx1DatarateOffset, rx2Datarate
See frequencyEU to change the CFList
RxDelay cannot be modified with current network server. This will become available in next release.– Sending the command MAC in the optional field
Sending AT+NLC will perform Link Check MAC command exchange.
There is no way to inject MAC commands through the network server in the optional field. MAC commands can only be sent with port 0 from an application.– Sending a downlink with invalid sequence number
– Sending a downlink with invalid MIC
The network server will not generate these packets.The NetworkSessionKey could be reconfigured for the device to generate invalid MIC.
One could add a UDP proxy between network server and packet forwarder and modify the packet to be transmitted. The MIC and FCNT values are in the clear. Changing the FCNT will create invalid MIC.
https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXTKeymasterMellow greetings, citizen.
There is a join backoff built into the libmDot within the AT firmware. It is based off requirements built into the lorawan 1.0.2 spec.
LoRaWAN recommended back-off
1 hour 1% duty-cycle
1-11 hours 0.1% duty-cycle
11+ hours 0.01% duty-cycleWith TX time of 400 ms max for US the backoff would be 40 seconds.
However the base case for the backoff algorithm assumes a 64 channel mode and allows 16 attempts before back-off to allow a join request in each 8 channel sub section of the frequency band chosen at random alternating between DR0 and DR4.There for in the first hour there can be up to 2 minutes of join attempts before a 40 second back-off with random +/-1 second.
There for in the next ten hours there can be up to 2 minutes of join attempts before a 400 second back-off with random +/-1 second.
Thereafter there can be up to 2 minutes of join attempts before a 4000 second back-off with random +/-1 second.
In a Multitech Private network setting the Join Delay is 1 second and allows 16 join attempts to be made in less than 1 minute.
In AT command AT+TXN will return amount off back off.
The library call getNextTxMs() will return the amount off back off needed before the next join.KeymasterDid you install the AEP version on mLinux?
The mLinux version is required on mLinux.
Open /etc/init.d/lora-network-server and see if there is reference to 127.0.0.1/api. If there is then AEP version is installed.
KeymasterWhat AEP version are you running?
KeymasterYou can check both if you want.
KeymasterIn module calibration we have noticed issues with DR0 and DR1 when the crystal tuning was off by 10 KHz. Being near to the gateway also affects the low-datarates and leads to packet loss when not in a chamber, multi-path effects.
You may want to look at the frequency accuracy of the module.
-
AuthorPosts