Delay and data throughput on 802.11b WLAN with 50 nodes

hi,

we have to connect 50 devices with an WLAN. We thought about the Lantronix WiPort which is only a 802.11b device. I wonder how 802.11b handles conflicts. As far as I know it works with an CSMA/CD algorithm. Does anyone have experience with an WLAN with about 50 nodes? For every node we will send about 30 times per second a TCP Packet with 30 bytes user data. So we transmit a total of about

150KByte per second ( Data+TCP/IP Header = 100Byte, 50nodes * 30 packets * 100 bytes). The maximum data throughput on 802.11b is about 600KByte/s, so we only use 1/4 of it. But it's a real-time application and our deadline for delayed packets is about 100ms. Will a 802.11b WLAN be fast enough for such an application. Or can the delay of a packet become too long due to collisions between the nodes?

I am happy for every hint or answer. Thanks a lot.

Regards,

Andreas

Reply to
Andreas
Loading thread data ...

My first reaction is that you don't have a hope in hell. 802.11 is not RT-friendly.

But it really depends on what happens when a packet is missed. Some RT systems cope with a missed data item (or bad data) by substitution (e.g., extrapolation from earlier samples), and carry on; if your transmitters use write-and-run, and your receivers can afford a few missed samples, you may survive. But, if a few missed packets are a disaster, then a shared 802.11 design should and likely will lead to a court case for malpractice.

And, speed is not the only issue here; 802.11 is prone to RFI and retransmit storms and other things that go bump in the night.

Overall, using unsolicited data from unsynchronized transmitters is a likely recipe for RT failure. One possible solution is to have the receiver solicit data from each transmitter, and to never use this 802.11 channel for any traffic other than solicitations and immediate responses; alternatively (for higher bandwidth), use a pair of 802.11 channels -- one for data requests from the receiver and one for responses. Safe RT design probably dictates preventing the data channel(s) from being used for other traffic and, hence, interfering with RT traffic; so, you may need a third channel for non-RT traffic unless you use a RT OS (not WinDuhs) in the transmitters.

Cheap, fast, reliable: pick one.

Reply to
Bob Willard

Hi Bob,

thanks for your answer. we want to do a show with 50 robots. the most important thing is that the robots movement is synchronized (they dance) and it shouldn't be visible that the first robot starts his movement before the last one. we discussed how the robots should be controlled. So as i thought it seems like it's not a good idea to control all functions from a central server.

I think we have to build "intelligent" robots. Then we can send a specific movement code to every robot an then send movement-start messages as a broadcast.

Reply to
Andreas

Andreas,

If your application can tolerate at most a 100ms delay, then IMO you're making a big mistake by choosing to use TCP.

Now, your application as you describe it (modulo your selection of TCP rather than UDP) sounds not unlike G.711 VoIP. I will note that we support at most 7 concurrently active G.711 VoIP calls in an *optimally designed* 802.11b cell. So, to support 50 such calls, one would want to deploy at least 8 APs in your coverage area.

You may find it instructive to consult our _Cisco Wireless IP Phone

7920 Design and Deployment Guide_,
formatting link
gives some idea of what you need to do to support VoIP over a WLAN.

In particular, the section entitled "Maximum Throughput Calculations for 802.11b WLAN" may prove useful.

Hope this helps,

Aaron

Reply to
Aaron Leonard

One of my friends was involved in almost exactly the same scheme for operating indoor race cars and robots via 802.11. It worked just fine with 3-5 robots running simultaneously on one 802.11 channel. However, when we tried it with 15 robots, response time and packet loss rose to unacceptable levels. Unresponsive would be an understatement. Out of control would be closer to the mark.

I got involved and tweaked the access points wireless settings to improve reliability. In general, I enabled CTS/RTS flow control with a very low threshold (about 250-400 bytes) and reduced the fragmentation threshold to about the same value. 802.11b compatibility was disabled (this was an 802.11g system). The controllers were reprogrammed so that they did not require continuous updates and would only transmit when there were changes in position and direction. Control protocols were switched from TCP to UDP which did not require acknowledgements. The walls and ceiling of the room were covered with anti-reflective panels.

That brought the system up to about 30 robots. They only had 30 robots so there was no way to test larger numbers. My guess is that it could have made it to 50. The real trick was the control algorithm being tweaked to reduce wireless traffic by a factor of about 100. The original designers had simply implemented the conventional radio control servo system over 802.11 which transmits continuously.

Even so, the packet loss was relatively high and response time (ping) varied radically with this packet loss. Personally, I think a conventional (non spread spectrum) system using TDMA would be more effective with large numbers of clients, but they wanted to do it off the shelf. This was largely proven when they tried using Karlnet Turbocell and StarOS wireless protocols. These are polling protocols instead of a big free for all, which scales much better than CDMA/CD. However, they were deemed too expensive to require participating robot owners to purchase.

formatting link
formatting link
cost of licensing is not an issue, you might want to look into these.

Anyway, then came the dot com bomb and funding dried up. I have no clue what happened to this project but can find out if necessary.

Reply to
Jeff Liebermann

i think you are forgetting something - TCP requires ACK packets to flow as well - so there are twice as many packets flying around.

so - you are too near the capacity if 802.11b to handle your data requirements (ignoring the other issues which have already been pointed out).

this is no use if each robot is controlled separately, but if you are sending the same commands to multiple devices maybe you could use IP multicast to cut down on the amount of packets needed?

multicast might also relax the timing constraints, since every device would pick up the command at the same time.

you also need to worry about reply traffic (ie. if you need it and what it should be).

Reply to
stephen

hi Jeff,

thanks for your answer. So with an 802.11g it's possible to handle 30 robots. That's a good information. We also want to do it off the shelf, because we haven't enough time. I think we will build "intelligent" robots with implemented collision detection and motor control. In case we send only commands like "go to position X with speed Y". Then we will only need about 2 or 3 Messages per second and robot. Can you rememer what kind of WLAN modules they used? I could only find modules with 802.11b for embedded Systems (we would like to connect them with a serial port). A module with 802.11g would be nice i think. Any suggestions?

Regards,

Andreas

Reply to
Andreas

hi Aaron,

thanks, the link is very helpful.

Regards,

Andreas

Reply to
Andreas

hi stephen,

thanks for your answer. you're right about the ACK. I didn't include it in the calculation because i thought the ACK Packages are very small.

I think we will transmit the commands with TCP and then send a UDP broadcast to start all 50 robots simultaneously. With "intelligent" robots with integrated collision detection i hope we will only need 2 or 3 messages per robot and per second. I hope we will get this through the WLAN.

Is there an important difference between broadcast and IP multicast?

Regards,

Andreas

Reply to
Andreas

That's 10 robots on 3 non-overlapping channels. However, I'm sure it could be done with 50 bots on just one channel using UDP and by limiting transmissions to only those bots that needed an update.

The proposed system was essentially interrupt drive. The speed and direction was sent to the bot. The bot had enough intelligence to point itself in the correct direction and start moving. If it hit anything along the way, it would transmit an interrupt (packet) and the controlling program would need to revise the speed and direction. This drastically reduced the transmission times.

That's fine because you'll have plenty of time to do it over again.

Is this a club, skool, or class project?

formatting link
formatting link
formatting link
one?

That will barely work. That's far too high an update rate.

Since ours was indoors, the designers decided to NOT use a GPS or hyperbolic location system but used an overhead video camera (Global vision) and PC provided the location of each robot. The last version, which was NOT working before the project died, use multiple cameras and parallax location. However, both of these systems had problems with long delay times in locating the bots. 200msec to several seconds was typical. That resulted in failure of simple positioning algorithms such as what you're suggesting. In some cases, the bot would arrive at its destination before the position report arrived resulting in some rather bizarre behavior. It also forced maneuvering to be limited to straight line positioning. The update problem was reduced by limiting position update to only after a collision, where it was imperitive to obtain a corrected position.

Let's run the numbers. 3 position updates per second per bot requires

333msec latency. If a position report is delayed by 333msec, it won't work. However, 50 bots on a channel requires 6.67msec latency, and that's not going to happen in an 802.11g collision infested environment. Even splitting it over 3 channels at 20msec latency is going to be difficult (one channel per team). Fortunately, you don't have to update all 50 robots at one time and will probably be concentrating on a few active players. The active bots can possible do 3 updates per second, but the other will need to wait much longer. I'll leave the algorithmic problem to you, but I suspect that you will need to drastically reduce your transmission rate.

Yes, but it was too long ago to be useful. At the time, all that was available was 802.11b. The SBC (single board computer) were various overpriced PC104 designs (Kontron?) with a mezzanine PCMCIA adapter board and an Orinocco classic silver card. This was not going to be the final production robot, but the company imploded before the cost and configuration could be optimized.

Reply to
Jeff Liebermann

sounds like a scary amount of traffic for this - you are at 150 msg / sec (ignoring ACKs)

not for this, unless you want to use IGMP like suppressed announcements.

Reply to
stephen

Jeff Liebermann schrieb:

It's not a robot-contest. It's just for a exposition. It should combine art with technology. The robots move on 5 railways and build symbols, changing colors, ... .

Also too high? I thought WLAN would be more powerful.

Well, I see. Hmm, then I will try to reduce the traffic to 1 message per second and robot. Unfortunately all robots will move most of the time. So I have to get the data for all 50 robots through the WLAN. I think I will try to transmit several commands in one packet, so the robots run their own timer to execute the sequence of commands. I hope a WLAN can handle 50 packets per second and a few broadcast-messages at the end of the second to start all robots synchron.

Thanks nevertheless. We will use microcontroller (Atmega128) to run our robots. We have to save every cent we can, so we won't be able to buy SBCs.

Thanks a lot for your help.

Regards,

Andreas

Reply to
Andreas

hi stephen,

well I thought WLAN would be more powerful. Seems like I am totally wrong. Well, I hope to get 50 msg/sec through the WLAN. Perhaps on 2 channels, if it's too much for an single channel.

Regards,

Andreas

Reply to
Andreas

Nice idea. Sounds interesting.

Think of 802.11g as a shared bandwidth among all the robots on one channel with a maximum of 3 non-overlapping channels available. That's because exactly only one transmitter can effectively transmit at a time. The total aggregate thruput is about 20Mbits/sec maximum for a

54Mbit/sec connection. Everything that goes wrong (reflections, collisions, interference, microwave ovens, cordless phones, video xmitters) will reduce the aggregate bandwidth. I'm not sure what number to use in the calculations but I'll guess about 10Mbits/sec aggregate thruput for 802.11g and perhaps 2Mbits/sec for 802.11b.

I think they can but you'll probably need to add acknowledgements that the robots have received the command along with some manner of routine for recovering from lost commands, collisions, and position errors. I'm sure 1 message per second will work. However do NOT expect to get low latency or even consistant latency with 50 active radios. The chances of mutual interference and collisions are just too high.

If you're updating all 50 devices all the time, then you might as well go to some type of polling scheme instead of a collision based CSMA/CD system. It's more efficient and offers predictable and fairly consistent latency. Look into Star-OS and Karlnet which unfortunately might be expensive.

I dunno about this...

formatting link
a 16MHz clock, you're going to have some difficulty moving

54Mbits/sec data (plus overhead) through a serial/USB port. It can be done with buffering, but your latency will increase. Using a USB radio, I'm not even sure you can cram motion control and an 802.11 MAC layer into 4KBytes of stored code. You could use a more complex stand alone radio with an RS-232 interface, but that will be expensive.

There are Atmel based wireless sensor nets available:

formatting link
they use 433/900Mhz and at a much slower data rate. However, this might give you some ideas.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.