FOTA Transfer and Custom board with MDot & Other SOC's.

[Ajay K]

I was hoping to get some guidance regarding FOTA transfer and its inner working. We have a custom board, which has the MDot and also another STM32 MCU as well. We are planning to use the FOTA transfer to send firmware updates to the mDot. However we also have the STM32 module also that communicates with the mDot over SPI. I was wondering if there was a way for us to hook onto the LORA FOTA transfer mechanism to send firmware updates over the air to the STM32 module via the mDot? Any guidance you may have would be great!

Also if it is not possible to hook onto the current FOTA process, say we currently operate in Class A mode and is there a way for the mDot using the mDot library to switch to class C when we are ready to perform FOTA transfers for the STM32 Module and also switch the Conduit to Class C and run a multicast to transfer the firmware specific to the STM32 module?

Also I am curious for Motes or edge devices that are really at a great distance from the conduit, under Class C mode are the data transmissions size similar to Class A? For ex; When the node is at a higher distance from the Conduit, we get around 11 bytes per transmission in Class A, is this true for Class C as well?

Thanks,
Ajay.

[Ajay K]

Any thoughts on my query?

Thanks,
Ajay

[Jason Reiss]

We are trying out github pages. There is relevant doc for multicast/fota here.
https://multitechsystems.github.io/

[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

[Author]

Posts