Jason Reiss
Forum Replies Created
-
AuthorPosts
-
Jason Reiss
KeymasterUpgrade AEP to 1.4.16
network server 2.0.19 is not supported on AEP 1.4.3
KeymasterThere is an updated firmware image for the Conduits.
You should update the unit to the latest version.AEP 1.4.16 and mLinux 3.3.24
Device registration has changed from using the node-add command through lora query.
I suppose this is your hardware?
http://wiki.seeedstudio.com/Seeeduino_LoRAWAN/
I don’t see a direct link to the application code.
If you could provide some example of the configuration options we could help to setup the device.There are two methods of activation OTAA or ABP for LoRaWAN devices.
OTA will setup the ABP session using a join process where the DevEUI is shared over the air. ABP will manually associate the DevEUI with the DevAddr and session keys at the network server and end-device.
OTAA
DevEUI
AppKeyABP
DevEUI
DevAddr
NetSKey
AppSKeyKeymasterLooking in /var/log/app/node-red.log I see
/opt/node-red/node_modules/node-red-node-email/node_modules/mailparser/node_modules/uue/uue.js:184 matches.forEach(nextMatch => { ^ 29 Mar 16:40:49 - [warn] ------------------------------------------------------ 29 Mar 16:40:49 - [warn] [email] SyntaxError: Unexpected token >This looks to be a node.js incompatibility with the versions being installed.
KeymasterAdd a custom radio event handler to accept the received packets.
Here is an example. The handler code is at the top of main.cpp file.https://os.mbed.com/teams/MultiTech/code/mDot_LoRa_CLASS_C_P2P/
April 16, 2018 at 1:27 pm in reply to: LoRaWAN Network Settings and Key Management Pages Not Displayed on Conduit AEP #23119KeymasterPlace the MTAC-MFSER-DTE card in AP1 and lora card in AP2.
There appears to be a javascript error if the LORA card is in AP1 and MFSER in AP2.
The system should run in either case but the UI pages cannot load as you have found.
KeymasterSounds like the uboot environment is not setup properly please contact support.
KeymasterThe do_flash_upgrade is a file created to notify the system that a upgrade is ready to be performed with the bin file in the flash-upgrade directory.
# mkdir /var/volatile/flash-upgrade # cp aep-1.4.1-upgrade.bin /var/volatile/flash-upgrade/upgrade.bin # touch /var/volatile/do_flash_upgradeKeymasterDowngrading will require a reset to defaults.
Try to reset the 1.4.16 to defaults. Hold the reset button 30 seconds.
See if the unit comes up with 192.168.2.1.Otherwise to continue with the downgrade, create the do_flash_upgrade directory and follow the instructions.
KeymasterNow set the session uplink counter to 1.
lora-query -x device <DEVEUI> update ulc 1This should allow the downlinks to be sent.
Normally the network server will wait for one uplink from an end device before scheduling downlinks.KeymasterIt is possible but not easy.
To send a multicast all receiving device must have the same session keys and counters.
A fake ABP device can be added to the network server. Then the dev addr and session keys can be sent from the application to all receiving end devices. After which downlinks sent to the fake ABP multicast eui will be received be all devices.
The mDot/xDot libraries have functions to setup multicast sessions.
KeymasterI would upgrade both if possible.
At least the Conduit running the network server should definitely be upgraded.
The packet forwarder unit, if used with a USB card, has had a patch removed so it will exit if the MTAC card gets in a bad state and attempts to report invalid packet fields for datarate and size.
Otherwise a Conduit with an SPI card may not need updating.Both Conduits should use have a monit configured to ensure the network server and packet forwarder process are restarted in case of unexpected exit.
AEP firmware includes an angel process that handles this feature. mLinux does not provide this out of the box, monit should be used.
KeymasterThanks for the extended logging.
I see you have remote gateways in packet forwarder mode.
An upgrade to the v2.0.19 network server has better support for a network configured with central network server and packet forwarding gateways.
There may an issue using the v1.0.43 network server in this setup as the feature was not fully tested at that point.
KeymasterWe have new versions of mLinux and network server available
You may want to see if the issue persists after upgrading.
Info for configuring logging:
# vi /var/config/lora/lora-network-server.conf "log": { "syslog": false, "path": "/var/log/lora-network-server.log", "level": 100, "console": true }KeymasterWhat version of mlinux and network server are you running?
# cat /etc/issue
# /opt/lora/lora-network-server –versionCan you increase the logging level to maximum and provide a bit more logging context?
KeymasterAre your end-devices able to communicate with the gateway?
If your devices are operating OK there may not be an issue.
CRC errors cannot be eliminated completely. It is a filter of bad packets. Some packets may be received with errors the CRC looks for errors and reports the packet as bad. The packet may be noise that looks like a lora packet.
Even in a shielded chamber we will see some CRC errors received without another transmitter present. It is an artifact of being able to receive LoRa modulated packets below the noise floor. There will be some false positives.
KeymasterOnly one downlink will be sent in either the Rx1 or the Rx2 window in response to the uplink. The network server will not schedule a downlink for both windows.
The LoRaWAN protocol cannot support sending two packets in response to an uplink. It would compromise the MAC command and ACK behavior. There is only one outstanding packet in either direction.
The two Rx windows can be used to attempt to respond to simultaneous uplinks from two devices. Depending on the datarate used the downlink may exceed the 1 second between Rx windows. A packet could not be scheduled for the seconds device.
KeymasterCan you provide examples of the behavior?
Perhaps it is the first downlink of MAC commands, this is seen on mDot 2.0.16 firmware.KeymasterUse packet forwarder mode. The will run just the radio and send as udp packets to configured server.
Both AEP and mLinux can be configured.
Source and protocol reference.
https://github.com/Lora-net/packet_forwarderKeymasterThe upgrade from 1.4.3 to 1.4.14 had an issue with persistent db location.
This caused the db to be held only in RAM and not backed up to flash.
If after the upgrade to 14.14 the nodes were reset and rejoined this would only remain until reboot.Upgrading from 1.4.14 to 1.4.16 fixes the persistent location but the sessions made to 1.4.14 were lost with RAM and could not be recovered after a firmware upgrade.
Upgrading from 1.4.3 to 1.4.16 should maintain the session information
from the previous version. End-device with unique appkeys registered through ‘lora-query -a’ command will be saved to /home/root/whitelist.jsonlines. They will not be able to join the network until the list is imported into the API.See Upgrade Guide
April 9, 2018 at 7:40 am in reply to: What is the new lora-query command for adding nodes in MTCAP #23047KeymasterDelete by array index is supported
$ curl 127.0.0.1/api/loraNetwork/whitelist/devices/0 -X DELETE –data “”KeymasterOnly one downlink will be sent in either window. In LoRaWAN there is only one pending uplink or downlink frame.
April 6, 2018 at 4:18 pm in reply to: What is the new lora-query command for adding nodes in MTCAP #23037KeymasterRestart is only needed after all keys have been added.
You will also want persist the keys over reset.Issues API save
$ curl 127.0.0.1/api/command/save -X POST –data “”April 6, 2018 at 10:42 am in reply to: What is the new lora-query command for adding nodes in MTCAP #23033KeymasterThe LoRaWAN > Key Management page can be use to enter end-devices and appkeys.
AppKeys are longer stored in the network-server database so the lora-query cannot be used to add them.
They can be added to the API on AEP or the lora-network-server.conf file for mLinux.
The network-server must be restarted after keys have been added to take affect.
The OTA device will not appear in the device list until it has joined the Conduit.
KeymasterIt doesn’t translate to a time. There should be a time field in the packets received by node red.
The recent packets table is a list of packets received by the radio.
Since the may be garbage CRC error packets no processing is done at the network server to add a timestamp. The packet forwarder may attach a timestamp in some configurations with GPS, then it will be included.The packets table at the top has datetime for authenticated packets. The tmst is included with packets at this table. It could be cross referenced to get the tmst -> time conversion in an app.
KeymasterIt’s a MTAC card internal clock time in microseconds.
There are some message field definitions at the bottom of this page. They should be consistent with lora-query output.
KeymasterAre you following these instructions?
Sounds like you are trying to copy the source tarball instead of the pre-built image files.
KeymasterWhat version of mlinux is being used? 3.3.22 is the latest.
Do you have logging enabled in the network server conf?
Check the logs for received packets.If 3.3.22 is installed
> lora-query -x help
> lora-query -x packet recent join
KeymasterDo you see the missing packets in the table on LoRaWAN > Packets page?
An MQTT input node could be used to check if there are packets reported to the lora/+/up topic. This should match what is reported by the lora-in node.
KeymasterRobert,
Please contact support.multitech.com for help with this issue.
KeymasterNode-RED 0.15.3 in AEP 1.4.14 available on the Downloads page.
-
AuthorPosts