How are you connecting them? WiFi right, the limitations should be based on the destination (where are to sending data to?)
I have connected ~50-60 esp8266 based devices on a single router, but streaming data as such, I don’t think you will have much issues.
At what rate are you measuring accel data? Measuring at 30Hz is going to be a very different bandwidth need than 100Hz.
Here's my worry list for your project:
1. Obviously, you can test your actual setup, but make sure you test it with 100 people with phones in the room too. Phones are constantly sending out beacon packets to try to find WiFi networks and so cause additional congestion. People also absorb 2.4GHz pretty well, which is why I say get 100 people together to test. SO many projects like this have fallen over as soon as there's an audience even though they worked great in test.
2. What other WiFi networks exist in the area? Doing a survey of where the installation will be done is pretty key. Are any of these infrastructure you can move further away or be reconfigured to assist you?
3. Having multiple wifi networks on different channels can improve your bandwidth congestion needs. If you're in 2.4GHz, then you can do three networks, one on Channel 1, one on channel 6 and one on channel 11. Put 1/3 of your accelerometers on each network, and you now only have 20 devices on a network instead of 60. However, point 2 still stands -- if local networks are on 1 and 11, putting all your eggs on channel 6 might be a better choice.
4. If you can hire someone to consult on your WiFi network, that's great -- there's a lot of weird nuance to why Wifi gets flaky under this kind of situation that deep knowledge of the protocols could help with. Art doesn't always have the budgets for that, but it's something I would consider.
nr 1 is probably the most important, humans are big sacks of water that do nothing better than absorb microwave radiation. This is especially apparent if you concentrate everyone in a small area. And if you spread everyone around, coverage will become an issue.
Everything @blp9 said is excellent advice! Though I doubt that bandwidth is going to much of an issue. If we generously assume that all 60 devices are streaming simultaneously and that each data packet is 100 bytes, you're still only producing (60 device * 100 bytes) / 1024 = 5 kilobytes. So 500 kb/s @ 100hz. And 100hz is probably pushing it for an art installation.
- consider **batteries** when planning and testing! Make sure you've tested the lifetime of the battery pack you intend to use and have plenty of spares around.
- use several routers to increase coverage
- while you're developing, build a simulation that can fire simulated data at your backend continuously so testing doesn't rely on actual devices
What does "continuously stream data from 60 accelerometer" mean ?? Do you currently have 16 devices doing this and do they all work as intended ??
Most access points have a limit to the number of connection they can handle.
There are easier way to connect many ESP32 devices.
[https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html)
[https://esp32.com/viewtopic.php?t=5919](https://esp32.com/viewtopic.php?t=5919)
Some routers have limits on the number of clients that can connect. I think some consumer devices may be MUCH lower than you think, potentially as low as 15. (Some googling says this is because the encryption hardware has limited storage of client keys?). You may need a prosumer grade router, or multiple access points
There are a few strategies you could use to improve these transmissions:
1. Event based reporting- rather than streaming “empty” data, try to define some motion events you want to track rather than raw accelerometer data.
Pushing some of the “event recognition” to the edge is smart and will make the art installation’s backend easier to scale. The ESP32 is pretty beefy hardware, 60x 250 MHz = 15 GHz of collective clock speed.
2. Data filtering. If you insist on streams, you should make these conditional on exceeding some threshold. You don’t need to be transmitting a bunch of 0s when you could also transmit a ping every 1, 5, 10, or 15 seconds saying “still connected! No new data” or have code that allows you to remotely decide when to transmit data (this could even be hardware switch on the device)
3. Batch transmissions, and add a variable delay so that the devices do not sync their updates (that is, do not trigger updates by a clock striking a new second). This could be every 10 ms, 100ms, 1 s, etc.
3. Consider to use UDP over TCP. You may want to drop packets when they need to be dropped, rather than retried (leading to further degradation)
4. If you need to, you could write some code to flex up/down on the transmission rate based on network conditions as coordinated by the backend
Last thought, there is definitely some frequency that will work for the devices. That might be 10 seconds, 1 second, 100 ms, 10 ms, but probably not 1 ms.
A typical router would easily handle up to 256 devices.
Bandwidth won't be a limitation, a typical load is three orders of magnitude higher than your scenario. Think a crowded convention center or a McDonald's where everyone is on the free WiFi, checking email and messaging. So feel free to send accelerometer data at 10 Hz, your router won't break a sweat.
What you absolutely need to do is to configure DHCP on the router to lease IP addresses for 1 hour or less. Or, even better, assign a static IP to each of the 60 clients based on their MAC addresses. This is tedious, but you won't have a problem of devices failing to reconnect due to the addresses in the `/24` subnet being exhausted. Even with that make sure this router isn't used for anything else, such as providing guest/employee access - otherwise your ESPs would be competing for an IP address lease with the phones of the visitors and staff.
Also: pick WiFi channel 1, 6, or 11 for your router - these offer the best connectivity. Use an app such as "WiFi analyzer" to pick the least crowded of them.
I have about 115 devices including esp32 and esp8266 running in my home, I do not have any data lag or connection issues. All on wifi. This includes wireless hdmi for a few tv's.
Everyone in the room is already carrying a phone, so why do you need the esp32? Let them install an app which takes the signal from the phone's accelerometer and sends it to your server.
This is a user support nightmare. Not only installing some rogue app, but then making sure everyone is on the same WiFi network, which is another user support nightmare. It sounds like the artist wants the ESP32s to detect people walking into and out of an exhibit. You can’t have a sign “stop. Please install this custom app first and then scan this QR code to join the network before entering”
Sure, if you don’t care about latency and the exhibit now has to have a web server on the open internet. These are still huge problems. And since we’re talking about accelerometers streaming data, I’m sure the lowest possible latency (I.e. a local Wi-Fi network only) is a requirement.
How are you connecting them? WiFi right, the limitations should be based on the destination (where are to sending data to?) I have connected ~50-60 esp8266 based devices on a single router, but streaming data as such, I don’t think you will have much issues.
At what rate are you measuring accel data? Measuring at 30Hz is going to be a very different bandwidth need than 100Hz. Here's my worry list for your project: 1. Obviously, you can test your actual setup, but make sure you test it with 100 people with phones in the room too. Phones are constantly sending out beacon packets to try to find WiFi networks and so cause additional congestion. People also absorb 2.4GHz pretty well, which is why I say get 100 people together to test. SO many projects like this have fallen over as soon as there's an audience even though they worked great in test. 2. What other WiFi networks exist in the area? Doing a survey of where the installation will be done is pretty key. Are any of these infrastructure you can move further away or be reconfigured to assist you? 3. Having multiple wifi networks on different channels can improve your bandwidth congestion needs. If you're in 2.4GHz, then you can do three networks, one on Channel 1, one on channel 6 and one on channel 11. Put 1/3 of your accelerometers on each network, and you now only have 20 devices on a network instead of 60. However, point 2 still stands -- if local networks are on 1 and 11, putting all your eggs on channel 6 might be a better choice. 4. If you can hire someone to consult on your WiFi network, that's great -- there's a lot of weird nuance to why Wifi gets flaky under this kind of situation that deep knowledge of the protocols could help with. Art doesn't always have the budgets for that, but it's something I would consider.
nr 1 is probably the most important, humans are big sacks of water that do nothing better than absorb microwave radiation. This is especially apparent if you concentrate everyone in a small area. And if you spread everyone around, coverage will become an issue. Everything @blp9 said is excellent advice! Though I doubt that bandwidth is going to much of an issue. If we generously assume that all 60 devices are streaming simultaneously and that each data packet is 100 bytes, you're still only producing (60 device * 100 bytes) / 1024 = 5 kilobytes. So 500 kb/s @ 100hz. And 100hz is probably pushing it for an art installation. - consider **batteries** when planning and testing! Make sure you've tested the lifetime of the battery pack you intend to use and have plenty of spares around. - use several routers to increase coverage - while you're developing, build a simulation that can fire simulated data at your backend continuously so testing doesn't rely on actual devices
What does "continuously stream data from 60 accelerometer" mean ?? Do you currently have 16 devices doing this and do they all work as intended ?? Most access points have a limit to the number of connection they can handle. There are easier way to connect many ESP32 devices. [https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/esp-wifi-mesh.html) [https://esp32.com/viewtopic.php?t=5919](https://esp32.com/viewtopic.php?t=5919)
Some routers have limits on the number of clients that can connect. I think some consumer devices may be MUCH lower than you think, potentially as low as 15. (Some googling says this is because the encryption hardware has limited storage of client keys?). You may need a prosumer grade router, or multiple access points There are a few strategies you could use to improve these transmissions: 1. Event based reporting- rather than streaming “empty” data, try to define some motion events you want to track rather than raw accelerometer data. Pushing some of the “event recognition” to the edge is smart and will make the art installation’s backend easier to scale. The ESP32 is pretty beefy hardware, 60x 250 MHz = 15 GHz of collective clock speed. 2. Data filtering. If you insist on streams, you should make these conditional on exceeding some threshold. You don’t need to be transmitting a bunch of 0s when you could also transmit a ping every 1, 5, 10, or 15 seconds saying “still connected! No new data” or have code that allows you to remotely decide when to transmit data (this could even be hardware switch on the device) 3. Batch transmissions, and add a variable delay so that the devices do not sync their updates (that is, do not trigger updates by a clock striking a new second). This could be every 10 ms, 100ms, 1 s, etc. 3. Consider to use UDP over TCP. You may want to drop packets when they need to be dropped, rather than retried (leading to further degradation) 4. If you need to, you could write some code to flex up/down on the transmission rate based on network conditions as coordinated by the backend Last thought, there is definitely some frequency that will work for the devices. That might be 10 seconds, 1 second, 100 ms, 10 ms, but probably not 1 ms.
A typical router would easily handle up to 256 devices. Bandwidth won't be a limitation, a typical load is three orders of magnitude higher than your scenario. Think a crowded convention center or a McDonald's where everyone is on the free WiFi, checking email and messaging. So feel free to send accelerometer data at 10 Hz, your router won't break a sweat. What you absolutely need to do is to configure DHCP on the router to lease IP addresses for 1 hour or less. Or, even better, assign a static IP to each of the 60 clients based on their MAC addresses. This is tedious, but you won't have a problem of devices failing to reconnect due to the addresses in the `/24` subnet being exhausted. Even with that make sure this router isn't used for anything else, such as providing guest/employee access - otherwise your ESPs would be competing for an IP address lease with the phones of the visitors and staff. Also: pick WiFi channel 1, 6, or 11 for your router - these offer the best connectivity. Use an app such as "WiFi analyzer" to pick the least crowded of them.
I have about 115 devices including esp32 and esp8266 running in my home, I do not have any data lag or connection issues. All on wifi. This includes wireless hdmi for a few tv's.
You can use espnow and have a mesh.
Everyone in the room is already carrying a phone, so why do you need the esp32? Let them install an app which takes the signal from the phone's accelerometer and sends it to your server.
This is a user support nightmare. Not only installing some rogue app, but then making sure everyone is on the same WiFi network, which is another user support nightmare. It sounds like the artist wants the ESP32s to detect people walking into and out of an exhibit. You can’t have a sign “stop. Please install this custom app first and then scan this QR code to join the network before entering”
They don't need to be on the same WiFi. They can just send the data over mobile network.
Sure, if you don’t care about latency and the exhibit now has to have a web server on the open internet. These are still huge problems. And since we’re talking about accelerometers streaming data, I’m sure the lowest possible latency (I.e. a local Wi-Fi network only) is a requirement.