Read through the Wikipedia article on WiFi to get some feel for what it is and isn't.

http://en.wikipedia.org/wiki/Wi-Fi

Getting 300ft may be a challenge for the kind of network you seem to be needing.

One potential problem you are going to have no matter what technology you use is the possibility for interference from other devices.

I don't know what kind of latency you are looking at with Wi-Fi. There is quite a bit of protocol overhead and medium access control overhead, but I don't have any kind of feel for the typical magnitude you might encounter.

 

e.g. do I have to interact with the internet to get it to send my info?

There is an easy but incorrect answer to that and a more detailed but correct answer and it hinges on what you mean by "the internet".

I guess what you mean is "do I have to connect to the 'public' internet" and the answer is no. However the "internet" really refers to Internet Protocol and yes your WiFi shields would be using Internet Protocol. Sorry, my inner nerd just couldn't help itself.

Anyway, the upshot is that if your project was about learning about wireless data comms then I would say build it yourself from the ground up and it would probably be a very steep learning curve. However if you want to implement a working project in a reasonable amount of time then WiFi takes care of all the underlying complexity for you. Basically you would have one device as a a server and the rest as clients. You would assign IP addresses to them and then send data between the clients and server.

Yes you can just do it all using Arduinos and from the point of view of the Arduinos you just open a connection and send data. WiFi range extenders are readily available so you can probably use one of those to get the range you need.

The thing that could be an issue is the cost of wifi modules if you have a lot of these things. So some combination of local comms between the performers using cheaper wireless solution (XBee or whatever) to a master unit and then from the master client to the server using WiFi my be an option.

In terms of latency it does depend how "noisy" the environment is (i.e. if the audience has loads of smart phones with WiFi enabled) but I can stream video over WiFi at home with no stutter.

 

In terms of latency it does depend how "noisy" the environment is (i.e. if the audience has loads of smart phones with WiFi enabled) but I can stream video over WiFi at home with no stutter.

The ability to stream without stutter doesn't sayanything regarding the latency. For instance, I have a satellite connection but, given a data rate that is sufficiently below my achievable data rate (we won't get into that!) then I can stream with no stutter, either. Yet there is over a quarter of a second of latency just due to the signal path length. You could bounce a signal off the moon and achieve stutter-free streaming.

 

OK, fair point I misspoke (or mistyped or whatever) but as I understand it the original requirement is for some sort of performance. So I assume that a smooth sounding performance is more critical than absolute latency, after all the "latency" due to the speed of sound over 300' is getting on for 1/3 of a second.

 

I'm assuming that the performance is light-based. Either that, or any sound is via speakers near the audience. It's more important that light have low latency because it's all coming in through the same sense, whereas people are pretty tolerant of latency mismatches between what they see and what they hear, if for no other reason than that it is a common part of their experience.

 

First of all, there is no need to worry about nerding out. As foreign as some of this stuff is to me, I like knowing the exact nature of what is being discussed, so your clarification only serves to educate me and for that I am grateful.

I'd like to know more about setting up comms, a master unit, a server and assigning IP addresses. How is this accomplished? I'm not sure what you mean about setting up local comms and then having a master unit that interacts with the server. Does that mean one performer would have the master unit and all of the other performers would send data to him or her, which is then transmitted to the server?

300 feet is an absolute maximum. It would be possible to constrain the distance if that's a big issue. I would just need to know what an acceptable working distance would be, and I'll work around that. I couldn't really do anything with 10 feet of range, but if it's closer to 150 feet I can probably make it work. It is critical that none of the data be lost, so whatever I have to do to ensure this needs to be done.

I am concerned about interference, because there is a very strong possibility that the audience will be pretty large (between a couple hundred to a couple thousand people) and most of them will likely have smart phones, and of course I have no way of knowing if they will be using their wifi, but let's just assume that some will.
I don't understand the technology enough to know if it's possible to work around their signals, or what their signals being present means for this application. Is there a possibility they are going to piggy-back on the system I set up and cause a lag? Is there a way to work around the problem the audience presents?

The principle media will be sound, although using light is definitely on the table too (although it's not as intrinsic to the design as sound is at this point and could be disregarded in the immediate), but if we could get the latency comparable (or even exactly) to what it would be if I was using an acoustic instrument from that distance I would consider that a big win. You're right in assuming the speakers would be near the audience, and you're also right in that there is an expected or at least acceptable lag between the moment of signal transmission and when the sound reaches their ears, so having latency below what it would be if the sound were being transmitted acoustically is definitely acceptable, but over that amount would be an issue. I just realized I should have said this from the outset, but I didn't know what my options were and I just figured 'get the latency down as low as possible and work from there'.

edit: clarification

 

I've been doing a little math, and I came up with this: the latency in seconds (at 1 atm 85 degrees F) of the sound is going to be equivalent to 1/(782*1069.34/60/60/n) where n is the distance in meters from the speaker, 782 is speed of sound in mph at that pressure and temperature, 1069.34 is meters per mile and of course sixty seconds per sixty minutes per hour. That means a distance of 10 m will give you about .029 seconds of latency. Does that sound like it's within tolerance to you all?

 

For this kind of figuring, you can use 1100ft/s or 333m/s. The first gives basically 1ft/ms and the second gives 1m/3ms (and these are within back-of-the-envelope agreement). So 10m would be 30ms.

If you can tolerate the kind of latency that an acoustical signal would have from 100ft away, which would be about 0.1s, then you should be able to tolerate the latencies of the RF transmissions without too much problem.

But that's assuming that the signals aren't jammed by all of the noise from all of the gadgets that the audience members have. That would argue for using a technology that the audience is unlikely to be using in any significant numbers. Zigbee might be an option, though I don't know much about it. But there are off-the-shelf solutions that use it.

Concurrent code spread spectrum might be another, but there are NO off-the-shelf solutions for that technology, though if I had the time I would volunteer to implement it for this project just to get the application exposure into the literature.

 

Huh. Well, now I am back to thinking that maybe the best way to do it is to just use regular RF and forget the wifi thing. I looked at ZigBee, and it looks like the right tech, but the cost is pretty high. I am gonna try to build dedicated frequency transmitters by hand and see if I can make it work. I'm sure I will be back here in a few weeks with more questions. Cheers y'all.

 

What time frame are you looking at wanting this system up and operating?

What are your total data traffic needs? By this, I mean how many total bits of information need to be transmitted per second by all of the transmitters in this system? And how many total transmitters are you looking at?

 

I'd like to have it ready by April or May of next year.

I have to speculate on the data rate, but I would think the max rate would be ~10 bit packets at 20 packets per second for each transmitter. Total transmitters would be 20-50, tending to the lower side of that, although having the ability to expand would be very interesting.

 

I'd like to have it ready by April or May of next year.

I have to speculate on the data rate, but I would think the max rate would be ~10 bit packets at 20 packets per second for each transmitter. Total transmitters would be 20-50, tending to the lower side of that, although having the ability to expand would be very interesting.

Hmmm....

Concurrent code spread spectrum might be a viable option.

What's your budget like for the hardware?

 

The magic question. I would like to keep it to within a few hundred bucks, but the truth is I don't have a particular number in mind. It's just when I saw those ZigBee transmitters, plus the add on wireless card for the Arduino, plus the cost of the arduino uno, plus the antenna and sensors, we're talking about some dough, and I know I can save cash if I just build it myself. I think the Arduino is probably a good fit for the receiver(s), but to pay for one for each transmitter seems frivolous.

I read a little bit on the concurrent code spread spectrum and would be interested in using that if it were a viable option. Could you project what kind of expense I might incur if I go that route?

 

The magic question. I would like to keep it to within a few hundred bucks, but the truth is I don't have a particular number in mind. It's just when I saw those ZigBee transmitters, plus the add on wireless card for the Arduino, plus the cost of the arduino uno, plus the antenna and sensors, we're talking about some dough, and I know I can save cash if I just build it myself. I think the Arduino is probably a good fit for the receiver(s), but to pay for one for each transmitter seems frivolous.

I read a little bit on the concurrent code spread spectrum and would be interested in using that if it were a viable option. Could you project what kind of expense I might incur if I go that route?

Unfortunately, I don't have any kind of a feel for that. The good news is that the transmitters can be very simply and need very little processing power. In fact, if each transmitter is only transmitting 10-bit messages, it would not be hard to simply use a look-up table. Hence they can be pretty cheap, although since we are talking custom builds, they aren't going to benefit from the economies of scale that something like key fob transmitters do.

 

I'm not sure what you mean by look up table? I was definitely going to program the pic to send a specific signal for a certain range of voltages, but that's as far as I thought I needed to take it. Is there another layer of abstraction that I am missing?

 

I'm also at a loss as to which pic I should go with. I have looked up some data sheets on some pretty great microcontrollers like this one:

http://www.mouser.com/ds/2/405/swrs033h-267289.pdf

but I have no idea how I would program it, much less solder it into a circuit.

Is there some "rf friendly" pic that I could use a standard pic programmer (like the picKit3) on, that would also not be terribly difficult to solder onto a PCB?

 

I'm not sure what you mean by look up table? I was definitely going to program the pic to send a specific signal for a certain range of voltages, but that's as far as I thought I needed to take it. Is there another layer of abstraction that I am missing?

Yes and no. If by "specific signal" you meant "send 15 if the voltage is between 2.5V and 2.6V", then you are missing that the "15" has to be channel encoded to be consistent with whatever form of spread spectrum you are using. But you can do that encoding ahead of time and load it into the non-volatile memory and go straight to that whenever you see a voltage within that range.

 

You might be able to save money building this yourself but you won't save time. If you roll-your-own you are going to have a significant time in software development.

Something like this
http://www.rfsolutions.co.uk/acatalog/BRAVO_Module.html
or this
http://shop.ciseco.co.uk/rf-module-range/
may be of interest

 

...the "15" has to be channel encoded to be consistent with whatever form of spread spectrum you are using. But you can do that encoding ahead of time and load it into the non-volatile memory and go straight to that whenever you see a voltage within that range.

You're right in assuming that I meant to send some piece of data if/when the voltage is within some range, and actually what I was planning on doing is just dividing the max/min range of voltages into 128 pieces and assigning 7 bits of the transmission for that purpose.

I have no idea how to do channel encoding, and I have a very limited understanding of spread spectrum, so I also have no idea how to make it so the channel encoding is consistent with the spread spectrum. Could you elaborate a little on what that all means? I looked them up on wikipedia, so I get at least some of the theory, but the implementation is definitely beyond me.

I don't know how to do two quotes in one post, so sirch2, thanks for the ideas on hardware. The second one looks like a viable option, and I will buy one and see what I can make work with my Arduino. I'm wondering though, do I need to have a receiver for each transmitter(?), because that would kind of defeat the purpose. I really need to have as few receivers as possible, for both financial and aesthetic reasons. For my initial run at this, I'm going to be working with five transmitters, if that matters.

The other thing I am wondering about with that XRF module is: can I have a bunch of them running at once without them interfering with each other? I have read some stuff on sending a verification code at the beginning of the signal that the receiver will look for, and then only take the data behind the code if the code matches its preset, so I was thinking that might be one way to do it. I figure I can also send a little ID code, so the receiver could figure out from which source the signal was sent. Maybe I could combine the two codes into one that would serve both purposes?