First of all, thanks for incredible effort put in this project and creating this community. Started exploring the code and conversations here. Important improvements and features on the way, will try to catch up and contribute.
While porting SW update code (in Android) to swift 5 for a dummy iOS client (not an iOS developer at all), noticed that update progress on app side and device side is different. App sends all chunks in a while loop and continue running following lines. It seems it finished on the device side (heltec wifi lora 32 v2) as well, but that is not the case. In serial monitor, it continues processing chunks (MTU: 512, firmware size: ~1MB). Is this how it works at the moment or sth not working as expected on the iOS client?
If this is how it works at the moment:
Guessing that it’s because of not waiting for ack of each chunk ( write with response ) and keep sending next one. If next chunk is sent after receiving notify event, this would keep progress on both side in sync which requires PROPERTY_NOTIFY BLE characteristic for CRC32 in device code.
So, update progress on both side is supposed to be almost equal all the time. If it is true, can above be a way to improve or what would be the recommended ways?
hmm - the update process works basically okay on the android version. Can you point me at your iOS code so I can take a look? Is your plan to make this an iOS client for meshtastic (which would be awesome) or are you just wanting to use the update code for your own ESP32 project? (also fine - as long as you obey the GPL license)
If you are trying to make a meshtastic client, I’d recommend getting basic message comms going before dealing with the software update API I created. They are both completely independent. In fact, someday I’d like to split the software update function out as a library and put it on platformio (because there seems to be no other working open-source ESP32 solution I could find)
wrt the SW update API
Each write in the android version is waiting for the write to reach the device before it continues to the next 512ish byte block. The android BLE implementation is generally considered less good than the Apple version - so I wouldn’t be surprised if the apple version doesn’t progress as synchronously. I would recommend that you force the write to be synchronous by wrapping it in a beginReliableWrite()/executeReliableWirte(). Alas, those are standard terms from the BLE spec, but I don’t know what the Apple API calls them.
This dummy iOS client is not started for meshtastic in the first place because:
In the links above, the direction is towards cross platform mobile app (flutter, react, ionic)
Also, I’m in the learning phase for own project. That’s why I preferred starting with something working instead of own design
And, I’m not sure if this amateur work would be preferred by any seekers
not comfortable with how meshtastic work yet
well, may sound like complaining but it’s not
Anyhow, will share the app in a few days and let’s see where it goes. It basically has bluetooth connectivity and sw update buttons. I will add messaging. I see that jeksys has interest and iOS skills, there may be others as well to contribute and polish.
wrt the SW update:
ReliableWrite seems .withResponse option in swift which is already used as I mentioned: peripheral.writeValue(value, for: characteristic, type: .withResponse)
but will point the code and wait for your comment before making a change.
Agree about the iOS vs Android BLE implementation. That’s also a reason for me thinking cross platform meshtastic client may functionally (BLE) be limited at some point.
One last thing:
Using meshtastic as a library would be great, but I am not sure if it is doable at the moment. Need time to go through topics here and github repositories. If you have timeframe and quick response to share about using meshtastic as library, it would be very helpful about design decisions of my eventual project.
