Machine learning model transmission using BLE

Hi, everyone! I am about to do research on Federated learning with TinyML. Although it is possible to send tiny volumes of data from a master to the slave using BLE, I'm not sure if you can transfer data such as a machine learning model using BLE. Is it possible to send such data (weights/biases) using BLE? Some of these models usually range between a few to at most 200kb.

Any type of data can be sent. It is up to you to format the data for transmission, and check for transmission errors.

Understood, Also is it possible for me to create a wrapper for BLE to provide custom functionality? As in, is the BLE protocol manipulatable based on TTL in hops, when to switch to idle/power up (maybe based on network activity?)

That is not how BLE works now. Bluetooth SiG has created a mesh networking standard but that is not supported. The standard is still young and likely suffered some slowdown in the last two years like many other things. Then there are other protocols that like to occupy that space e.g., Zigbee, WiFi, Thread ... as well.

Currently you can create peripheral and central devices using GATT. You have full control over the services and characteristics. The ArduinoBLE library is easy to use a comes with a couple of examples for both peripheral and central device.

I recommend starting with a peripheral device example e.g., BatteryMonitor and a generic BLE app like BLE Scanner, nRF Connect, EFR Connect. There are plenty more for iOS and Android.

As jremington stated, you can transmit any type of data. You will have to split your model into packets and need to verify and re-transmit them on the application layer.

Oh you mean the mesh standard isn't supported by Arduino boards just yet?

Yes, and there is no strong reason that they need to. Most sensors will not need to support mesh ever. Mesh will require a node to have power to allow it to be active all the time. Most sensor on the other hand should run on coin cells. That is when wireless connectivity is the most useful. So, low power nodes will work as they do now, they sleep most of the time and only activate every now and then when the application requires it e.g., to send a new sensor value.
The mesh functionality will be supported by a few special nodes that will require power anyways e.g., office or home lighting. All other nodes will not even know that they are part of a BLE mesh network.

I do not speak for the Arduino team, but realistically I do not see a lot of value for the Arduino team to support BLE mesh. It will require some serious engineering resources for little gain. And the devices will likely be more expensive because they need more memory and most user will not need the functionality.

Understood, so in that case if I were to create a mesh, the best bet would be alternatively switching the roles M/S to transfer data to one another. Yes?

Did you already start working with the devices? I would expect the TinyML part to be much more challenging then the BLE part.
How you design the data transfer may be a matter of taste for now. You could have a peripheral/server that provides a new model to every client that connects. Or in the opposite case, you could have a client that stores a new model onto every peripheral it finds. Or as we discussed in the other thread when you have a collection of peripherals, each of them changes it role to a client in slightly random intervals. This would not be a mesh, but the nodes would talk to each other from time to time and update everyone to the latest model.

Yes, I have started implementation on it, And found a few research papers that demonstrate an on-device learning model. Although I have yet to figure out if I can completely update/remove an old model with a new one.

I've actually scoped down my research to create framework for distributed federated learning (i.e. BLE based transfering of models from a phone/laptop (that will aggregate the model from the cloud) to a central MCU to peripheral MCU upon close proximity). Given that I will still have to demonstrate that it is practically feasible to transfer models using BLE. For that I thought of having a model underfitted model in a peripheral and have another well trained model in a central and depending on the model version, transfer the model to the outdated device.

And yes, what I plan on doing is somewhere within the lines of what you said.

One question I need answers to is, to know whether it is possible to replace/update a model in such a device after all the packets have been sent

I have not worked with any of the model software packets. I suspect the model is a structure in RAM. As such it can be overwritten at any time.

The next part is the how and when. From what I read about models they seem to require lots of RAM (depending on the complexity). So, you may need to replace the model on the fly. When your model is small enough to fit two of them inside the available RAM, you can first collect all packets, verify the model is complete and then overwrite the model you have.

When you require the model to survive total power loss you will need to investigate storing the model in non-volatile memory.

True, I myself am not sure if it stores the weight's and biases in the flash storage. Need to checkup on that

That is possible but not likely. Flash memory is slower and that would be significant for an application that needs to access these values millions of times. Of course the values are part of the flash image to initialize the values in RAM.

Yep, so in that scenario, every time there is a need for me to update the model, I will have to do some updating and restart the device if possible that is. Do you know if it is possible for me to update the data in the flash storage? Went through a few threads which require me to reset the flash storage. I saw Pete warden repository, and have yet to run the project

Give the example from Pete a try. It looks promising.

Edit: Just tested it on my Arduino and the example works as you would expect.

Perfect! Thank you @Klaus_K . That means I can partition the flash and have a particular segment of it for storing the new model, correct?

Yes.