Jason Reiss
Forum Replies Created
-
AuthorPosts
-
Jason Reiss
Keymaster# Get downlink data delay.
#
# This is the time that LoRa Server waits between forwarding data to the
# application-server and reading data from the queue. A higher value
# means that the application-server has more time to schedule a downlink
# queue item which can be processed within the same uplink / downlink
# transaction.
# Please note that this value has influence on the uplink / downlink
# roundtrip time. Setting this value too high means LoRa Server will be
# unable to respond to the device within its receive-window.
get_downlink_data_delay=”100ms”You could try 500ms or 750ms, this should make the packet be sent to the packet forwarder later. Not certain that it will make difference.
KeymasterHow much lead time is given for the UDP packet to reach the packet forwarder?
Adjusting how early packets are sent to the forwarder from the network server can have an affect on behavior.I can’t recall if the failed to tx error is printed when the packet is too late to transmit.
KeymasterThe patch is already included in the USB packet forwarder for AEP and mLinux.
If you are able to join and receive ACK’s from the network server the the downlinks are working. What is the issue you are seeing besides this warning message?
I suggest updating to an MTAC-LORA-1.5 card. The SPI version uses much less CPU on the Conduit and the accompanying packet forwarder code has a better JIT queue with feedback to the network server.
KeymasterYou could try to remove all queued items for each device.
# lora-query -x packet queue delete <DEV-EUI>KeymasterWhat region are you looking to support?
The latest AEP 1.4.16 implements US915,EU868,AU915,AS923,IN865,KR920 regions according to the LoRaWAN 1.0.2LoRaWAN 1.1 may be ready near the end of year.
KeymasterHas the LoRaWAN > Network Settings > Queue Size setting been changed from the default of 16?
Do these commands produce the same result?
lora-query -x packet queue
lora-query -x packet queue jsonKeymasterDo you have a USB 1.0 card?
# mts-io-sysfs show lora/*With the basic_pkt_fwd-usb packet forwarder for the 1.0 cards.
When a packet is sent the forwarder for transmit it will expect it to be transmitted within 200 ms of being queued. The message you have posted will be displayed but does not always mean the packet is not transmitted. But if another downlink is scheduled it can bump the current packet from the TX buffer.Adjusting how early packets are sent to the forwarder from the network server can have an affect on behavior.
Otherwise there is an updated packet forwarder and MTAC-LORA-1.5 SPI card the queuing mechanism has changed to use the JIT queue provided by the original packet forwarder implementation.
https://github.com/Lora-net/packet_forwarderKeymasterSee bottom of page 5 or intro to lora page Network Arch section.
http://www.multitech.net/developer/wp-content/uploads/downloads/2018/04/AEP-1.4.16-UpgradeGuide.pdfKeymasterThe session is a DevAddr (4-bytes) sent in each packet, session keys and counter values. If the end-device knows the DevAddr, sessions keys and counters by creating a valid packet with authenticated MIC it will be accepted by the network server.
To remove a device from the network server list of joined devices remove the session or the device using lora-query. Either method should cause the
# lora-query -x device delete <DEV-EUI>
or
# lora-query -x session delete <DEV-EUI>Backup the database to force a write to flash. The database is backed up periodically, on restart of the network server or a soft reboot. If changes are not backed and power is lost, i.e. plug pulled, the device will return from the old backup.
# lora-query -x database backupThe whitelist is a set of credentials DevEUI/AppKey for end-device to join the network via OTAA. If an end-device sends a Join Request using the DevEUI and the associated AppKey with authenticated MIC it will be accepted by the network server and a session will be created for the device. The NetworkID/NetworkKey can also be used to authenticate a Join Request.
To dis-allow a device from joining via OTAA remove the DevEUI/AppKey from the whitelist or change the NetworkID/NetworkKey, depending on the method used by the end-device to join the network.
For more detailed information about OTA join and LoRaWAN sessions please refer to the official specifications.
https://lora-alliance.org/resource-hubPlease let us know if you have further questions.
KeymasterUpgrade the device to 1.4.16 available on the Downloads page.
KeymasterThe join delay should be set explicitly on the end-device to match the network.
The upgrade to AEP-1.4.16 should be backward compatible with 2.0.16 and 3.0.0. The Private/Public network setting and Join Delay should be preserved during the upgrade and operate on the same frequencies. AEP-1.4.16 does support the LoRaWAN 1.0.2 datarates DR0-DR6 for ADR, these will be mismatched in ADR commands sent from the network server to the 2.0.16 and 3.0.0 end-devices.
Min/Max datarates can be updated on the Conduit to accommodate the older firmware, Max DR should not be set above 4 until all end-devices are updated to the next release or dev libraries.
Private MTS mode is provided for end-devices with 2.0.16 and 3.0.0 that are set with AT+PN=0 or setPublicNetwork(false) in AU/US channel plans.
KeymasterLoRaWAN documentation is available here.
https://lora-alliance.org/resource-hubKeymasterHow many devices are trying to join at once?
Do they retry after a failed join attempt?
Is the retry successful?Keymaster2.0.16 and 3.0.0 support the LoRaWAN Regional Specs 1.0.1
AU was changed to DR0-DR6 in 1.0.2
This will be reflected in the next release.Keymaster2.0.16 and 3.0.0 versions only have ability to do the Private MTS and Public LoRaWAN modes available on AEP 1.4.16
The other thing to check is the Join Delay it must match on Conduit and End-device.
AT+JD
See troubleshooting guide for more info.
http://www.multitech.net/developer/wp-content/uploads/downloads/2018/04/LoRaWANTroubleShootingGuide-04132018.pdfJune 20, 2018 at 9:06 am in reply to: Problem received datas doesn’t appear in the debug window node-red #23921KeymasterThe device may be joining only? Otherwise the seq num would have been incremented.
To see uplink and downlink packets on command line.
# mosquitto_sub -v -t lora/+/+Otherwise have a look at the GUI on AEP, LoRaWAN > Packets page
KeymasterLooks like you have AEP 1.4.16
What version of mDot libarary are you using?Try Private MTS mode. Unless you are using the libmDot-dev-mbed5 library there is not a compatible mode on the mDot. This is the legacy private mode for mDot v3.0.0 and before. The downlink channels differ from LoRaWAN, they are fixed according to frequencySubBand setting.
Private LoRaWAN mode will have downlink channels according to the protocol using the private network sync word.
KeymasterThe uplink would need to be received on two channels with the same sequence number. Or received twice with the same sequence number and eliciting a downlink. Normally the network server will ignore a repeat packet with a LinkCheckReq, but if it was a confirmed packet an ACK would be generated.
What frequency was the packet received on?
Are there multiple packet_recv messages being output to MQTT?Is the LinkCheckReq being added to a confirmed uplink?
Is that uplink being retransmitted because of missed ACK?June 19, 2018 at 8:51 am in reply to: mdot production library 3.0.0 and mbed os library 5.4.7 #23889KeymasterKeymasterYou can perform the firmware upgrade with AEP 1.4.16 image from downloads.
This will reset the firmware files to the correct packet forwarder.
After that you can use the GUI to configure the packet forwarder to point to an external network server.KeymasterWhat type of card do you have?
# mts-io-sysfs show lora/*
If it is MTAC-LORA-1.5 then the lora_pkt_fwd process should be used.
basic_pkt_fwd uses USB for MTAC-LORA-1.0KeymasterThe 3.2.0 images can be built from source.
http://git.multitech.net/cgi-bin/cgit.cgiCheckout the 3.2.0 tag
http://git.multitech.net/cgi-bin/cgit.cgi/mlinux.git/tag/?id=3.2.0Otherwise please open a ticket at support.multitech.com.
KeymasterThe whitelist provides unique DevEUI/AppKey pairs (Authentication), the device list provides known devices joined via whitelist or NetworkID/NetworkKey AppKey authentication (Registration), and the session list contains DevAddr, keys and counters (Activation).
The whitelist of devices is not dynamic, there are no commands to add device records, it is part of the configuration of the network server, it is a static list. This way all registration information DevEUI/AppKey and NetworkID/NetworkKey (Authentication) used for devices to join the network is kept separate from the dynamic information in the database (Registration, Activation).
With AEP firmware devices can be added to the whitelist through the GUI. In mLinux they can be added to the configuration manually.
The log looks correct for a system with no devices. I would expect all packets to contain unknown device addresses.
KeymasterWhat commands are used to clear the list?
Can you show failed message (session keys)? What is failed?
What end-device is being used?KeymasterSee in GUI LoRaWAN > Network Settings > Database > Backup Interval
The default is every 1 hour to backup the database to flash.The working database is held in RAM to allow faster reads/writes and reduce wear on the flash. It is only backed up periodically to flash per Backup Interval or when the system is shutdown gracefully.
The end-devices can check that the network is available by sending a confirmed uplinks periodically. If the network does not respond the end-device can attempt a join to recover.
The database can be forced to backup with this command
lora-query -x database backupJune 13, 2018 at 7:42 am in reply to: Lora Server 2.0.19, stops publishing on broker after downlink #23816KeymasterPlease open a ticket at support.multitech.com to share config and log files.
KeymasterNot sure what you have tried. Only through the GUI or using Node-red or other application?
http://www.multitech.net/developer/software/aep/lorawan-aep/downlink-queue/
MQTT messages can be used to send downlinks from most applications.
A Class A device must send an uplink to receive the downlink payload in a receive window.
KeymasterSome node modules require cross compiling of c++ which cannot be done directly on the Conduit.
On AEP 1.4.16, you could try install from command line.
# /etc/init.d/node-red stop # npm install node-red-dashboard # /etc/init.d/node-red startKeymasterYou will have to be more specific about the product you are using.
Have you looked at this file?
/var/log/ppp_traceKeymasterWhat product do you need help with?
On most systems the logs are rotated so as to not exhaust the system of RAM.
The logs are kept in RAM so they do not wear out the flash.
Depending on the level of logging configured there may only be 24 hours of log available due to log rotation. -
AuthorPosts