Jason Reiss
Forum Replies Created
-
AuthorPosts
-
Jason Reiss
Keymasterhttps://github.com/srned/baselib/blob/master/crc64.c
const std::string name = "NETWORKID"; uint64_t crc = 0; crc = crc64(crc, (const uint8_t*) name.c_str(), name.size());https://github.com/nullptr0807/aes128_cmac
const std::string passphrase = "NETWORKPASSPHRASE"; uint8_t key[KEY_LENGTH]; AES_CMAC_CTX ctx; AES_CMAC_Init(&ctx); // default session key is 2b.7e.15.16.28.ae.d2.a6.ab.f7.15.88.09.cf.4f.3c AES_CMAC_SetKey(&ctx, LoRaConfig::defaultNetworkSessionKey); AES_CMAC_Update(&ctx, (uint8_t*) passphrase.c_str(), passphrase.size() & 0xFF); AES_CMAC_Final(key, &ctx);KeymasterWhy would the generated values be better than using the appeui and appkey generated by chirpstack?
January 10, 2022 at 12:36 pm in reply to: After FOTA Firmware Upgrade, MDOT User Register values are lost #32293KeymasterWe will need some time to analyze the issue.
https://os.mbed.com/questions/62192/What-might-cause-RTC-Backup-Domain-Reset/
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/rtc_api.c
KeymasterThe sleep interval is converted to us in libmDot.
An issue was found where this value was not cast to a 64-bit value which caused the value to be truncated.There is a fix in the libmDot-dev repo that has not been pushed to a release.
https://github.com/MultiTechSystems/libmDot-devJanuary 10, 2022 at 7:56 am in reply to: How does Deduplication work with LENS and Local Network Settings ON #32288KeymasterHello Simon, your situation sounds like a good fit for LENS.
Please open a support case at support.multitech.com to discuss further with the LENS team.January 7, 2022 at 4:33 pm in reply to: After FOTA Firmware Upgrade, MDOT User Register values are lost #32285KeymasterWe have not heard of any issues with the RTC backup registers before.
Behind the scene we are making calls to the RTC library.
__PWR_CLK_ENABLE();
HAL_PWR_EnableBkUpAccess();RTC_ReadBackupRegister
RTC_WriteBackupRegisterHow many are you using and how many are getting corrupted?
January 6, 2022 at 8:45 am in reply to: How does Deduplication work with LENS and Local Network Settings ON #32277KeymasterCould you use different APP EUI/KEY per customer for each set of Conduits?
Best practice is to use unique AppKeys per device.
LENS could be used although there would be additional cost involved.
When using the Network Server on Conduit a device should join and get a session to only one Conduit. Without LENS multiple Conduits that know the DevEUI/AppKey could respond to the Join Request.
December 29, 2021 at 9:21 am in reply to: Storing Data on mDot Internal Flash using MBED Flash API. #32270KeymasterOnce the firmware is programmed into the internal flash it will not be modified by libmDot during normal operation. During FOTA the image will be overwritten of course.
Writing to the end of flash should be possible, we have done this on another system where there was no external NVM to save configurations.
December 20, 2021 at 8:58 am in reply to: Can't set the application port to run LoRaWAN certification tests #32258KeymasterlibmDot v4.0.1 did not allow the port to be set using setAppPort.
The AT firmware v4.0.5 release uses a v4.0.5 libmDot, it looks like this version did not make it to the release repo.
Here is the commit on the dev repo.
https://github.com/MultiTechSystems/libmDot-dev/commit/f150bb9d4eafe3e0be73c8348a34aeaf4379a9d3KeymasterDoes the JSON list of devices match what you see when you add devices through the UI?
Please open a support case to share screen shots and API call details so we can try to reproduce.
support.multitech.com
December 20, 2021 at 8:04 am in reply to: Can't set the application port to run LoRaWAN certification tests #32255KeymasterAT Firmware v4.1.2 should pass the latest LCTT tests, at least it did when it was released. v4.0.1 did pass the tests when it was released but the LCTT has since changed, perhaps it was 3.0.0-R1 for LCTT.
See handleTestModePacket for details of the test mode implementation.
December 1, 2021 at 9:21 am in reply to: Sending captured packets over MQTT or HTTPS from gateway? #32242KeymasterGlad you were able to get the system setup.
Did you use the MQTTS or HTTPS to connect to your back-end?
November 29, 2021 at 8:49 am in reply to: Sending captured packets over MQTT or HTTPS from gateway? #32239KeymasterThere is a Default App installed in mPower 5.3 and can be enabled on the LoRaWAN > Network Settings page.
The API is described here.
https://multitechsystems.github.io/lorawan-app-connectOtherwise a custom app can be installed to connect to your back-end. The Default App python script could be used as a starting point.
KeymasterThe fota functionality is not included in the mLinux images.
There are IPK files available to download to install into mLinux. See LoRaWAN FUOTA.
It is better/easier to use the UI/API in mPower firmware.
KeymasterOnly /var/config/ and /var/oem will survive a firmware upgrade.
You will need to test if either will work for your requirements.KeymasterHow much space do you need?
The /var/oem partition is 8MB and survives reboot and firmware upgrades.
It is only used if you back-up settings to be used as custom factory default settings.Only /var/config/ and /var/oem will survive a firmware upgrade.
KeymasterWhen a device uses OTAA it will send an EUI in the Join Request, this EUI is saved on Conduit as the Join EUI. This is saved into the session record but never used after the Join.
The App EUI may be different than the configured Join EUI the end-device sends up. The DevEUI is used by Conduit or Lens to match the App Key to the device. The end-device may assigned to a different application network after it has been deployed. This App EUI is attached to each uplink JSON record.
For an ABP device, since the Join Request never occurs, these field must be provided manually.
A session is needed to authenticate the sensor uplinks and create downlinks.
KeymasterSupport is available at support.multitech.com
mDot firmware 2.1.2 implements LoRaWAN 1.0.2
KeymasterThis is the AppEUI sent in the Join Request.
Network ID: 70:b3:d5:7e:d0:00:fe:5c
KeymasterHere are some options for open-source lorawan servers.
https://www.chirpstack.io/
https://github.com/TheThingsNetwork/lorawan-stack
https://github.com/gotthardp/lorawan-serverKeymasterThe SPI resource can only be controlled by one process, so this will limit you to one packet forwarder.
I suggest creating a program, like the chirpstack-gateway-bridge, that listens locally for UDP messages and sends them over each backhaul in separate sockets.
There are no utilities already available to achieve this non-standard use, it will need to be a custom application.The UDP protocol is similar to the following protocol for the v1.5, the JSON message will differ but since you are only passing messages through you should only be interested in the socket connections.
https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXTLet us know if you have more questions.
KeymasterI do not think this is possible with the v2.1 hardware. The Sx1301 array is accessed through an FGPA, all SPI calls are multiplexed through a single SPI interface.
The packet forwarder global_conf.json file configures both Sx1301 chips.
A gateway with two MTAC-LORA-1.5 cards can run with a packet forwarder process for each card.
What is the premise of the experiment that would require two packet forwarders?
Perhaps a process that receives the UDP data from one packet forwarder could mimic the connects to a network server that two packet forwarders would make?
KeymasterSure we can handle the null value, but what is the reason to create a group with no devices?
KeymasterWhy null and not [] for empty array?
KeymasterOnly GET, POST, DELETE calls are handled by the UI
There is no PUT handler to add a single EUI.Providing the data in the body or URL should have the same effect.
Sending a POST with a groupeui will overwrite the group. Without an groupeui an new group will be created.
The API accesses the /var/config/lora/.groups folder containing the group lists.
These files can be modified locally to append devices to a group.KeymasterIf I post a group with updated devices it will overwrite the group.
There is no call to add a single device, the entire group of euis must be provided.https://10.17.100.146/api/lora/groups?method=POST&data={%22deveuis%22:[%2200-80-00-00-00-01-58-34%22,%2212-31-23-23-12-31-23-23%22,%2212-31-23-23-12-31-23-25%22],%22groupeui%22:%2200-80-00-70-30-f8-ec-da%22,%22groupname%22:%22123123213%22}
KeymasterI will need to verify if/when there will be support for v2.1 in Basic Station.
No the v1.5 version will not work with the v2.1 gateway.
Only UDP LoRa Packet Forwarder is supported.
KeymasterA Basic Station forwarder for the v2.1 geolocation gateways is not provided in mLinux or mPower releases at this time.
KeymasterPlease refer to the mbed-os site for information regarding firmware development using the mDot platform.
https://os.mbed.com/platforms/mts-mdot-f411/If you have specific questions you can ask on the mbed forum or return here for more help.
KeymasterSee similar forum topic.
https://www.multitech.net/developer/forums/topic/how-to-downgrade-to-1-6-4/ -
AuthorPosts