4

The company I work for is developing a sensor network that will require roughly 1 sensor per every 6 m2 or about 160 sensors for a 10,000 sq ft building.

They need to synchronize them by sending a sync signal to each one every second. They are arranged in groups of 4, so 40 sensors will be activated by the first signal, another 40 by the second and so on.

They want to use wifi to generate the sync signals so the router(s) will see 160 devices in addition to the general wifi traffic in an office building. The overall bandwidth will be small, but the number of devices is large and they will need to be continuously pinged. Accurate timing is not a problem, latency of signals can be 200%.

Is this a good idea? Will this significantly affect wifi traffic or present potential configuration problems?

Improve this question
3
  • 1
    Wi-Fi is a bidirectional protocol, and only one device can transmit at a time on any given channel (devices cannot both send and receive at the same time, and the WAP will need to send back to the STAs). You will probably impact the normal business traffic. You should perform a wireless site survey in light of all the STAs and projected traffic. That will tell you the number of WAPs, the WAP placement, the radios channels, the radio power, etc..
    – Ron Maupin ♦
    Feb 20, 2019 at 5:28
  • 2
    I would look at LORA or LORAWAN gateways rather than WiFi. Please check for more details : thethingsnetwork.org
    – Datagram.Network
    Feb 20, 2019 at 10:16
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin ♦
    Jan 5, 2021 at 18:13

1 Answer 1

Reset to default
4

In principle it can be a good idea. Whether it suits your situation depends on a lot of things, and here are few that you might consider to find your answer.

  1. What kind of protocol is the sync signal? The network behaviour is going to be quite different for UDP, TCP and other protocols. It's going to be very different for unicast, multicast, and broadcast. Remember you lose a lot of control over timing with TCP.

  2. What happens if you drop a packet? This is probably the most important question. If it doesn't matter much that helps a lot. If it matters a lot, don't do it with radio of any kind.

  3. Is it viable to put in a separate SSID or even entirely new wifi on a different channel or frequency?

  4. It's not clear from your description whether the 160 devices send replies. It sounds a little like you're sending the same signal to lots of devices at once, somewhat like SNTP in broadcast mode (RFC 1769).

  5. Can you design or choose the protocols? Does it have to be 1 per second? If at all possible use an existing protocol. If you can't, consider a very-partially implemented or greatly adapted standard protocol. For example, single-OID SNMP, or Time Protocol (RFC 868) with non-time values.

  6. Does the polling system have to be connected by wifi, or can this device be wired?

I do a lot of telemetry work. When I get the choice, I choose UDP broadcasts from the server with randomised-delay UDP unicast replies; ideally I like to do this kind of polling each minute, and I like it to not matter at all if a given device doesn't answer. These are just preferences picked up from the field: very often there's no choice, and you have to do TCP once a second for example in Modbus/TCP.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.