[Ajay K]

Any thoughts multitech engineering team?

[Ajay K]

just wanted to follow up, what is the difference between the US915_old and US915? Should we be even using US915_old or AU915_old?

Thanks,
Ajay

[Ajay K]

Thanks Jason for taking the time to respond. Do you have an estimated timeline as to when the libmDot-dev changes would make it to the production version?

Also Is this frequency band: “lora::ChannelPlan::US915_OLD” for US still valid.

Thanks,
Ajay

[Ajay K]

Any thoughts multitech team?

[Ajay K]

Any thoughts Jason/Multitech team on why the registers have a loss of data on a FOTA upgrade?

Thanks,
Ajay

[Ajay K]

Hi Jason,

Thanks for taking the time to respond.

We are using all the 10 user backup registers provided for MDOT. However in all the scenarios i.e. when we reset the MDOT via the resetCpu() method in the MDOT Class or when we press the reset button on the board, the register stays intact. However only during the FOTA upgrade the Register values don’t have the values stored before the mdot was reset by the underlying MDOT class library after the FOTA file has been transferred successfully.

we are on mdot library 4.0.0 which I believe is the latest version.

Thanks,
Ajay

[Ajay K]

Any thoughts multitech dev team?

[Ajay K]

any thoughts multitech team?

[Ajay K]

I had to add component “FlashIAP” and also device has “Flash” capability in mbed_app.json in order to even attempt to use the FlashIAP Driver. However I ran into error when compiling the “flash_api.c” under the folder “\mbed-os\targets\TARGET_STM\TARGET_STM32F4”. Its looking for a header file called “flash_data.h”, which is present under the “TARGET_MTS_DRAGONFLY_F411RE” target, but not present for the target “TARGET_MTS_MDOT_F411RE”. So the contents of the file flash_data.h is as given below. How do I modify this file to work for the MDot target?

#ifndef MBED_FLASH_DATA_H
#define MBED_FLASH_DATA_H

#include "device.h"
#include <stdint.h>

#if DEVICE_FLASH

/* Exported types ------------------------------------------------------------*/
/* Exported constants --------------------------------------------------------*/
/* Exported macro ------------------------------------------------------------*/
/* FLASH SIZE */
#define FLASH_SIZE      (uint32_t) 0x80000

/* Base address of the Flash sectors Bank 1 */
#define ADDR_FLASH_SECTOR_0     ((uint32_t)0x08000000) /* Base @ of Sector 0, 16 Kbytes */
#define ADDR_FLASH_SECTOR_1     ((uint32_t)0x08004000) /* Base @ of Sector 1, 16 Kbytes */
#define ADDR_FLASH_SECTOR_2     ((uint32_t)0x08008000) /* Base @ of Sector 2, 16 Kbytes */
#define ADDR_FLASH_SECTOR_3     ((uint32_t)0x0800C000) /* Base @ of Sector 3, 16 Kbytes */
#define ADDR_FLASH_SECTOR_4     ((uint32_t)0x08010000) /* Base @ of Sector 4, 64 Kbytes */
#define ADDR_FLASH_SECTOR_5     ((uint32_t)0x08020000) /* Base @ of Sector 5, 128 Kbytes */
#define ADDR_FLASH_SECTOR_6     ((uint32_t)0x08040000) /* Base @ of Sector 6, 128 Kbytes */
#define ADDR_FLASH_SECTOR_7     ((uint32_t)0x08060000) /* Base @ of Sector 7, 128 Kbytes */

#endif
#endif

Thanks,
Ajay

[Ajay K]

Thanks Jason for taking the time to respond. I was wondering if you can let me know the address range of the flash, where the data can be written?

Also I know the MBED FlashIAP object provides the size of the data in bytes that can be written at any given time and also the sector size while erasing data. if already have that information can you provide that?

Thanks,
Ajay

[Ajay K]

It could be an empty array, but the web page needs the ability to handle the scenario where the array is set to null and not error out like it is currently. The only thing missing in the above scenario is a valid list of EUI’s for that particular group. the web page should display every other device group that is in the list and not be blank page like it is currently. So it would be great eventually if not in 5.2.5 patch release, some other release this is addressed.

Thanks,
Ajay.

[Ajay K]

So the groups page completely errors out or is blank if the deveuis is set to null via code. An example JSON for which the UX is completely broken is as shown below and I see the following error in the browser console.

vendor.7e69a35f0ea1812ae2da.js:1 TypeError: Cannot read property ‘length’ of null
at 60.cfe321709b14c865ceb5.js:1
at a.kt [as _l] (vendor.7e69a35f0ea1812ae2da.js:1)
at a.render (60.cfe321709b14c865ceb5.js:1)
at a.t._render (vendor.7e69a35f0ea1812ae2da.js:6)
at a.r (vendor.7e69a35f0ea1812ae2da.js:1)
at za.get (vendor.7e69a35f0ea1812ae2da.js:6)
at za.run (vendor.7e69a35f0ea1812ae2da.js:6)
at Ee (vendor.7e69a35f0ea1812ae2da.js:1)
at Array.<anonymous> (vendor.7e69a35f0ea1812ae2da.js:1)
at ct (vendor.7e69a35f0ea1812ae2da.js:1)

{
   "code" : 200,
   "result" : {
      "lora_groups" : [
         {
            "deveuis" : [ "00:80:00:00:00:01:96:cd" ],
            "groupeui" : "00-80-00-88-21-09-23-24",
            "groupname" : "FOTA_HIGHER_DR"
         },
         {
            "deveuis" : null,
            "groupeui" : "00-80-00-bb-cf-fe-6f-83",
            "groupname" : "FOTA_LOWER_DR"
         }
      ]
   },
   "status" : "success"
}

Thanks,
Ajay.

[Ajay K]

I tried calling the post method repeatedly and couldn’t create duplicates. However I see the UX i.e. https://<conduit-ip>/lora/device-groups, seems to be completely un-synchronized with the changes. I am guessing the duplicate issues occurring in reality is an UX bug, rather than an API issue. I even used fiddler to see what the API was returning for the device groups calls and its returning no duplicates, however the UX at times doesn’t display the device groups at all even though there are devices in the device groups or shows them as duplicates.

I think the UX team needs to address this issue, when they get a chance. Its easy to reproduce this issue.

Thanks,
Ajay.

[Ajay K]

Thanks Jason, However I am not just updating a single EUI. The example above shows just adding a new EUI to an empty list, over time the list will have more devices added and the deveuis array in the payload would have all the device eui’s that need to be in the group, not the one I am attempting to add or remove.

However I am wondering if the post request is causing the group to be re-created? Since I end up seeing duplicate groups in the device group screen. Also in your example you seem to be sending the data via the url, I send it via the body, hopefully that doesn’t make a difference?

Should I be using the PUT method to indicate that its an update, not creating a new group?

Thanks,
Ajay

[Ajay K]

Any thoughts Multitech team?

Thanks,
Ajay

[Ajay K]

Thanks Jason for the detailed explanation. Actually we were looking to send a maximum of 200 bytes in a single downlink packet in class C Mode. Since you mentioned Class C Mode uses RX2 data rate, what would be the Ideal setting in the conduit to achieve this data length and reliability of transmitting a packet of this size , even with MDOT’s are further away in excess of say 1-1.5 miles?

Also we only switch to Class C mode when we are doing large configuration changes to a particular MDOT. So it would be in Class C Mode for not more than a few minutes and it will switch back to Class A. We could use the Lorawan->Operations->Messaging mechanism to transmit as well, however we want this more automated and so we are looking to implement this without using the Operations screen.

Thanks,
Ajay

[Ajay K]

Thanks Jason for taking the time to respond. Just curious if you were able to view the image? Thanks for providing the link for examples as well.

THanks,
Ajay

[Ajay K]

I did find a way to determine the end time that is received based on the packet type described below received on Port 200. However I was wondering is the mDot just going to sit there in class C mode for let’s say best case 1 hr when the FOTA transfer fails? Which is what is happening in our case and since we can not enter sleep during class C, it will burn thru’ a lot of power. Any suggestions as to figure out when we can definitely say that there is no more FOTA Packets arriving after all the parity frames have been received and we can go to sleep even though we are in Class C Mode?

MC Class C Session Req
MC Index Start Time Timeout Freq DR
04 00 11a2a84c 0f 68e28c 0a

Thanks,
Ajay

[Ajay K]

Any thoughts Multitech team on this question? We are trying to figure out if we can use the Multitool to upgrade our firmwares instead of using ymodem mechanism to break into the bootloader and flash it via tera term.

Thanks,
Ajay

[Ajay K]

Thanks Jason for the explanation. Is there a way to get access to this end time via any of the API calls either using the FOTA api or the mDot API? we currently use the timeToStart() method on the Fota Class to determine if FOTA is about to begin or is in progress. However I was wondering if there is a way to look at when the estimated end time would be, basically get access to the value being logged in this case 4131 seconds?

Thanks,
Ajay.

[Ajay K]

Thanks Jason for the explanation and I will review the document you have provided via the link. However I am just curious regarding the log entry which calls out the end time as 4131 (which I am assuming is in seconds). So what does that time represent? Is that when the mdot eventually switches back to a non FOTA mode, once the FOTA process has started?

Thanks,
Ajay.

[Ajay K]

Hi Jason,

Thanks for taking the time to respond. I was looking at the API list, based on the link below and couldn’t find any of the API’s that were related to the FOTA operations, unless I am looking at the wrong API list.

http://www.multitech.net/developer/software/mtr-software/mtr-api-reference/

I am sure I can look at the debug window in the browser and try figuring out, but I was hoping I can refer to something that is clearly documented?

Thanks,
Ajay

[Ajay K]

Any thoughts multitech team?

[Ajay K]

Any thoughts Multitech team?

[Ajay K]

I fixed this issue, I wasn’t initializing the fota instance with the mdot instance and this resolved it. I am running into other fota issues, I will open a ticket instead of waiting for someone to respond to my forum questions.

Thanks,
Ajay

[Ajay K]

Thanks Jason for taking the time to respond. Other then calling the getNextTxMs() method to determine the next available transmission window, do we need to do anything else to handle out installations in Europe?

Thanks,
Ajay

[Ajay K]

Thanks Jason for taking the time to respond. I meant in the current supported sleep mode in mDot, which is not deep sleep mode would the LowPowerTimeout attached method get invoked even when the mDot has entered the supported sleep mode. If so I am guessing it would break the mDot out of its current supported sleep mode?

Thanks,
Ajay

[Ajay K]

Amy thoughts multitech team?

[Ajay K]

Thanks Taylor for taking the time to respond and for the clarifications provided. Have a great day!

Thanks,
Ajay

[Ajay K]

Any thoughts Multitech team as to how I can intercept these packets definitively?

[Author]

Posts