Yes. There is no limitation on how many nodes you can update at the same time, as long as they are being updated with the same application. There will probably be some retransmissions, but that is fine, and it is handled in the Mesh stack, so nothing you need to implement manually.
I've read that firmware updates over BLE Mesh typically take longer compared to Zigbee or Thread, especially in networks with around 100 nodes. In practical scenarios, how much time does it usually take to update a 1 MB binary file across 100 nodes using BLE Mesh?
I would not say it is slower than Zigbee or Thread, but it is significantly slower than (standard) Bluetooth Low Energy, and so is Zigbee/Thread.
I don't know how long it takes. You will have to test. But it is roughly the same as with a smaller network consisting of only two nodes. It will take a bit longer in a larger network, because there are more nodes that can drop packets, so some more will have to be retransmitted, but I don't think this is significant.
I would not say it is slower than Zigbee or Thread, but it is significantly slower than (standard) Bluetooth Low Energy, and so is Zigbee/Thread.
I don't know how long it takes. You will have to test. But it is roughly the same as with a smaller network consisting of only two nodes. It will take a bit longer in a larger network, because there are more nodes that can drop packets, so some more will have to be retransmitted, but I don't think this is significant.
I would like to know the data transmission speeds in kbps for DFU (firmware update) and regular message communication in BLE Mesh, Zigbee, and Thread. Do you have those figures?
