[Ajay K]

Thanks Jason for taking the time to respond. So bottom line I would need to override both the methods to support FOTA implementation, is that assumption correct?

Thanks,
Ajay

[Ajay K]

Any thoughts Multitech team?

[Ajay K]

Awesome, Thanks a lot for the clarification!

[Ajay K]

What version of the conduit firmware are you on? Also the is intention to install the custom app on an SD card or on the local file system?

Currently my custom app is on 5.2.1 conduit firmware version and I am not sure what else the install-to-conduit.sh is doing. In my case I generate the tar.gz file and save it in in /var/tmp folder. Also before I generate the tar.gz file I ensure Install and Start file have the execute permissions provided as well.

I then open up the command terminal and I use the following command below to install my custom app.

sudo app-manager --command local --appfile TestApp.tar.gz --appname "TestApp"

Thanks,
Ajay

[Ajay K]

Thanks Leon for taking the time to respond and for the clarification. I have one other question, should the GPU continue to drive it high or should it be driven low once the reset is complete? I am wondering what state the GPU needs to be so it doesn’t keep resetting the mDot module.

Thanks,
Ajay

[Ajay K]

Any thoughts multitech team?

[Ajay K]

Hi Jeff,

Thanks for your response. Below are the model#’s on the conduits that are currently in use and the firmware version of the conduits is mostly 5.2.1 and some may be on 5.1.6.

Model Number MTCDT-LVW2-246A
Manufacturer Telit
Model LE910-SVG
Firmware Version 17.01.571

Model Number MTCDT-L4N1-246A
Manufacturer Telit
Model LE910C4-NF
Firmware Version M0F.660006

MTCDT-LAP3-246A
Manufacturer Telit
Model LE910C1-AP
Firmware Version 25.26.255

Let me know if there is any other information I can provide to help you better in identifying the difference on calling a reset command as opposed to a complete conduit restart.

Thanks,
Ajay

[Ajay K]

Thanks so much Jeff for your response and the script. I was going to use the ping command that is available via the conduit api mentioned in the command table. However I see it takes a json object for the IP Address or URL, not sure what the actual json object this command expects. Can you point me to an example?

Meanwhile I will give the attached script a shot to see if it does work?

Thanks,
Ajay

[Ajay K]

With 5.2.1 firmware I think you won’t be able to run the commands directly, I believe you will need to prepend your commands with “sudo“.

for example “sudo ifconfig”

Thanks,
Ajay

[Ajay K]

Thanks Heath for taking the time to respond and for your valuable inputs. I will give that a shot and see how the ping command works?

Thanks,
Ajay

[Ajay K]

Thanks Jeff for taking the time to respond. Does the conduit API expose a ping call or is there a way to make a ping request using node js. Also the server we would be hitting does support an ICMP ping. The ICMP check the cellular management admin screen, does it use native linux calls to make the ping request? Also what is typical payload size of request and response for a ICMP ping request?

Thanks,
Ajay

[Ajay K]

Just wanted to some confirmation from Multitech team, does the article regarding best practices, sound accurate, is it something we need to handle in our custom firmware or does the mDot library manage this for us internally such as varying the data rates and frequency?

Thanks,
Ajay

[Ajay K]

Thanks Jason, I will try the API out and see what the max timeout is?

[Ajay K]

Thanks Jason for taking the time to respond. I was wondering if we set the watchdog timer to timeout at a larger timeout say several minutes or a longer interval, so that the mdot doesn’t get reset and during each wake cycle, the first thing we do is kick the watchdog? Is increasing the timeout of the watchdog timer to a larger interval, usually not the best practice?

Thanks,
Ajay

[Ajay K]

Any thoughts multitech team?

[Ajay K]

Any thoughts multitech team?

[Ajay K]

Any thoughts on this issue?

Thanks,
Ajay

[Ajay K]

Hi Balamurugan,

I have never successfully installed a custom app via the Conduit UI. I usually install winscp on my local machine or you could use putty. Then connect to the conduit and copy over the tar.gz fie you downloaded to the /var/tmp directory and install it by running the app-manager. for example:

sudo app-manager --command local --appfile express-hello-world-1.4.tar.gz --appname "express-hello-world"

Hope that helps? As far as the Conduit UI throwing the error, may be some one from Multitech can chime in. Meanwhile you could try via the command line to install the app.

Thanks,
Ajay

[Ajay K]

Awesome thanks for the clarification.

Thanks,
Ajay

[Ajay K]

Thanks so much for taking the time to respond. Just was wondering what happens from a conduits perspective if we queue a payload size in the downlink queue greater than the maximum permissible payload size for a given data rate?

Thanks,
Ajay

[Ajay K]

That’s awesome Jason! I was not aware that the new bootloader supported differential updates. I will play around with the differential updates and see if I have any further questions.

Have a great weekend!.

Thanks,
Ajay.

[Ajay K]

I agree thanks for your inputs Jason. I guess we can run it as a batch script, post compilation.

Thanks,
Ajay

[Ajay K]

Any thoughts how this can be achieved, as I am guessing this was done for mbed-cli prior to the 4.0 library?

Thanks,
Ajay

[Ajay K]

Thanks Jason for taking the time to respond. We will stay with the 5.2.1 version for now given the improvements are on the mDot 4.0 which we are already using currently.

Thanks,
Ajay

[Ajay K]

Any thoughts or suggestions, if it is a good idea to skip to version 5.3.0 instead of 5.2.1 from a FOTA perspective?

Thanks,
Ajay.

[Ajay K]

Thanks Jason for confirming. Also can mbed studio be used to build MDot custom firmware? I am guessing you need a license to compile using ARMC6 with mbed cli?

Thanks,
Ajay

[Ajay K]

Any thoughts on my query?

Thanks,
Ajay

[Ajay K]

Thanks Jason for pointing me out to the relevant github page. I will go thru’ the documents specified on that page. However I was looking at the mdot examples especially around the fota example. Especially around the code base below in the RadioEvent.h.

`virtual void PacketRx(uint8_t port, uint8_t *payload, uint16_t size, int16_t rssi, int16_t snr, lora::DownlinkControl ctrl, uint8_t slot, uint8_t retries, uint32_t address, bool dupRx) {
mDotEvent::PacketRx(port, payload, size, rssi, snr, ctrl, slot, retries, address, dupRx);

#if ACTIVE_EXAMPLE == FOTA_EXAMPLE
if(port == 200 || port == 201 || port == 202) {
Fota::getInstance()->processCmd(payload, port, size);
}
#endif
}`

I was wondering if we know the firmware being transmitted to the end device is intended for the other Module on our custom board and not the mDot, Can we ignore calling the FOTA:: processCmd, instead use the inbound payload to construct the firmware for the other module on our custom board and eventually flash the new firmware?

Does the Fota::processCmd do any housekeeping items on the mDot and/or report to the Conduit regarding the status of the multicast or fragmentation session or regarding the payload it just received? If so how easy or hard would it to mimic what the fota instance does under the hood to complete the firmware transfer successfully? Is it possible to override the fota class to achieve the same?

Thanks,
Ajay

[Ajay K]

Any thoughts on my query?

Thanks,
Ajay

[Ajay K]

I did try printing them separately and the same result as described earlier. However is the length of the variable name a factor here? I have practically written a sentence for my variable name :).

Thanks,
Ajay

[Author]

Posts