Jason Reiss
Forum Replies Created
-
AuthorPosts
-
Jason Reiss
KeymasterWith ADR enabled the network can increase the datarate when the signal looks good. The end-device will lower the datarate when the signal is bad, realized by periodically missed packets. To enforce a minimum datarate with ADR enabled the end-device application would need to monitor the current datarate of the module. There is no message in the current protocol to control the min datarate the ADR back-off algorithm will reach.
Some application designers may sent different sized packets depending on the available datarate with ADR enabled. Or ADR can be disabled and the device can periodically sent a small 11 byte packet on DR0 and a larger packet on DR1. If the network cannot received the DR1 packet it may still be able to receive the DR0 packet.
January 7, 2021 at 7:59 am in reply to: LoRa Basics Station with USB (MTAC-LORA-1.0) Lora card #31515KeymasterI added a note in the doc.
Here is a link to the Basic Station documentation.
https://doc.sm.tc/station/January 6, 2021 at 8:45 am in reply to: LoRa Basics Station with USB (MTAC-LORA-1.0) Lora card #31504KeymasterThe USB cards are only supported for use with the UDP packet forwarder.
New card designs are using SPI and HAL is only provided for the SPI interface with the latest software from Semtech.
KeymasterI see it referenced in the release notes for mPower 5.1.5
https://www.multitech.com/documents/publications/sales-flyers/PCN%2003092020-001_mPower%20Software%20Release%205.1.5.pdfI agree an official mPower developers guide document would be a great addition to the available resource.
KeymasterThe previous procedure was a work around to get multicast to work.
When creating the multicast session provide this field.
“multicast”: “C”KeymasterSince there is a “joined” message the key must be matching and the Join Request has been validated in order to send a Join Accept.
The question is whether or not the Join Accept is received and if it is received have the keys been generated for the session.
I would expect the Murata firmware to work correctly. If there is no way to enable only the 8 channels supported by the gateway is it possible to take a while for a successful join as the device attempt to join over the 64 channels.
KeymasterFirmware 5.2.1 is the mPower firmware version I was looking for.
Has the end-device firmware changed since it was last working?
Do you have a device that is known to work or a Conduit that is working?What is the JSON of the received and transmitted packets that you see in the MQTT output?
KeymasterWhat is the mPower version installed on the MTCDT?
Is it different from what you have used previously?On the LoRaWAN > Devices page the Session table has a details button for each session. The Session details popup shows the session keys.
What is the RSSI/SNR of the received packets. It is possible to receive packets on adjacent channels when devices are close to the gateway. Then the Conduit may try to respond on the wrong downlink channel.
I will be good to confirm with the device developer which channels are being used.
Can you get the session keys from the device?
Are there packet_recv messages after the packet_sent or is the device sending only Join Requests?
Is the device receiving the Join Accept?KeymasterAre the device and Conduit set to the same Frequency Sub Band?
The Conduit must be using FSB2 since 904.5 was shown as the freq in the rxpk.Can you check that the session keys match those that the end-device is using after the join?
That packet looks to be noise. First the CRC failed (“stat”:-1) and the expected coderate is “4/5 (“codr”:”OFF”).
KeymasterThere has been no change to the path. lora/+/up should be expected.
Perhaps the devices are being joined to another Conduit within range?
If AooEUI and AooKey values are used between Conduits the device could join either. If the session keys do not match then there is no up message shown.
You could check that the DevAddr and session keys of the device match those in the Device session on the Conduit.
December 22, 2020 at 8:14 am in reply to: Using MBED Watchdog Timer API and managing the timer during sleep cycles. #31431KeymasterI believe the maximum IWDG watchdog window is around 30 seconds.
The watchdog class has a get_max_timeout function.
December 21, 2020 at 4:38 pm in reply to: Using MBED Watchdog Timer API and managing the timer during sleep cycles. #31426KeymasterOnce watchdog is enabled it cannot be turned off. That is why stop is not supported. The device must be reset and watchdog not enabled on startup.
So sleeping longer than the ~30 second maximum watchdog window would require resetting the device, not enabling the watchdog and going to sleep for an extended time. Otherwise the application must wake-up every ~30 seconds to kick the watchdog.
Make sense?
KeymasterThe response is a redirect.
Post to HTTPS instead, https://192.168.1.100/api/lora/packet/queue
November 23, 2020 at 1:48 pm in reply to: Maximum Packet size for downlink packets in Class A mode. #31378KeymasterThe packet will wait in the queue until there is a chance to send in a packet at the required datarate.
There is no protocol to allow automatic fragmentation. The application layer could implement a protocol. Still the lowest size is easiest to handle. Or adjusting the Rx2 datarate so max is always available. Still there occasional MAC commands for ADR to consider.
November 23, 2020 at 12:07 pm in reply to: Maximum Packet size for downlink packets in Class A mode. #31376KeymasterWith ADR enabled it may vary. On the Conduit when a packet is queued for Class A it does not know what the datarate of the next uplink will be.
In US915 53 bytes is the allowed packet length for downlink in Rx1 when DR0 is used in the uplink.
Rx2 can be set to DR10 for most use cases and 242 bytes of application payload are allowed. The GW can transmit at a higher power than end-devices so it can reach end-devices easier with higher datarates. Performance may vary per environment of deployment.
The size will depend on the downlink datarates configured for Rx1 and Rx2. Rx1 is dependent on the uplink DR used and the Rx1Offset setting.
https://lora-alliance.org/resource-hub/rp2-102-lorawan-regional-parameters
The N column on page 34 shows the maximum size for each datarate.
November 20, 2020 at 12:23 pm in reply to: Post Build script to set the checksum on the resulting binary using mbed-cli. #31367KeymasterCouldn’t the multitool commands be scripted to run after compile?
Post-build hooks are part of mbed-os, customizations would be lost if you later updated mbed-os.
KeymasterThe Conduit does not know or modify the contents of a package. The support for differential updates is needed by the bootloader and tools to create a package that can be transmitted to the device.
Dot 4.0.0 release has bootloader updates to support compressed and differential updates.
https://os.mbed.com/teams/MultiTech/wiki/Dot-firmware-change-log
Use the multitool to create diff packages.
https://pypi.org/project/mtsmultitool/November 17, 2020 at 12:45 pm in reply to: FOTA: On AEP Firmware version 5.3.0 as opposed to 5.2.1 #31340KeymasterThere is no functional difference in the FOTA processes in mPower 5.2.1 and 5.3.0. The only change was in the algorithm for generating the random Multicast Session keys.
The majority of latest FOTA improvements are implemented in the Dot v4.0.0 firmware and tools.
KeymasterHave you seen these examples?
November 10, 2020 at 2:36 pm in reply to: Reducing the size of overall custom firmware binary. #31327KeymasterRTOS is required. Using ARMC6 to compile reduces the firmware size.
KeymasterWe have made some documentation available here
https://multitechsystems.github.io/The examples are shown in HEX.
October 23, 2020 at 1:20 pm in reply to: FOTA Transfer and Custom board with MDot & Other SOC's. #31254KeymasterWe are trying out github pages. There is relevant doc for multicast/fota here.
https://multitechsystems.github.io/October 15, 2020 at 8:16 am in reply to: Not sure what the issue here is with the time function or some log issue? #31240Keymasterprintf(“time: %” PRId64 “\r\n”, time(NULL));
October 15, 2020 at 8:11 am in reply to: Not sure what the issue here is with the time function or some log issue? #31239KeymasterDo you get the same results if you use one logDebug per variable?
I have seen issues in the past when too many variables are provided to the print format statements. It seemed to be more prevalent when printing large numbers.KeymasterAT+RSSI is the preferred method to retrieve RSSI of the last received packet using Dot AT Firmware. It will work in LoRaWAN and P2P modes.
October 9, 2020 at 3:49 pm in reply to: MDot 4.0.1 library compilation warning in mDotEvent.h #31234KeymasterHow about this, the read_ms function will return milliseconds time until it is removed from the mbed-os API. At that point this code will not compile. That is why it is marked deprecated.
October 8, 2020 at 1:34 pm in reply to: MDot 4.0.1 library compilation warning in mDotEvent.h #31231KeymasterIt is a warning that this may not be supported in a future release but still appears to work as is.
KeymasterThis will compile out the logTrace and logDebug when NDEBUG is defined. If you do not see logTrace or logDebug messages then your build has NDEBUG defined.
#ifndef NDEBUGSince NDEBUG is defined you could change this to an #ifdef to include logDebug and logTrace instead. Or this line and to corresponding #endif line can be removed.
KeymasterChange MTSLog.h to include logTrace and logDebug.
KeymasterLogging was reduced in this release to reduce firmware size on xDot for new functionality. FOTA support was added for xDot if an external flash is attached.
The library has this enabled by default. It can be changed in the MTSLog.h file where #ifndef NDEBUG occurs.
https://github.com/MultiTechSystems/libmDot/blob/master/MTS-Lora/vendor/multitech/MTS-Utils/MTSLog.h
-
AuthorPosts