Gather Data from Multiple Devices in Close Proximity Wirelessly

I need to gather data from no more than 200 devices wirelessly, all within 50 meter radius. The data is simply one ascii text character string (not more than 20 characters) and two numeric numbers (each, not more than 7 decimal places) per device. The cost must be as low as possible.

I need to create one module for each device, and have a single PC able to receive the data from each individually addressable device within the radius.

Please suggest wireless protocol, devices, off the shelf solution would be preferable. Cost target is 15$ per module (with quantities of 1000)

Thanks for any help.

* What is the sample rate?
* Is timing important
-- Do you need to know when the data was sent (to what precision)?
-- Do the data nodes have to follow a schedule, or can they transmit asynchronously?
* Can any further data be added to the stream without violating the specifications? i.e. a unique code for each of the data nodes--so the receiver can tell where the data came from?
* What region are you in -- this impinges on frequency selection -- i.e. what frequencies are legally open for this kind of communication -- with or without a license, etc.

This could be done with 200 separate frequencies, but that would make the receiver rather complex and require transmitters that can be set to different frequencies. Or, it could be done on all one frequency, and each transmitter/data node would have a unique code that it would transmit along with the data (or is it important to know where the data came from?).

BUT, there needs to be a way to coordinate the transmissions so they don't overlap. There are numerous methods, but selection of a method is contingent on the answers to the above questions.

BTW: I have some experience with this, but I'm in no way an authority -- so anyone else who wants to chime in...

Hi ( Just in from work 01:22 and dead tired )

Use a raspberry pi then write a sever application using what ever language you choose Think along the lines of a chat application each of your raspberry pi's will act as a client sending a request to the server (Your PC running lets say for example a java server application with JDBC connectivity " or if you want to a C sharp application using a thread pool to manage your threads spawned on each connection servicing each thread with its relevant Io stream , data input data output streams , IO stream ) populating a database recording the IP addresses as they connect to server plus relevant information

You could even use a web server to do this and send an html or php request something like apache will service up to 100 simultaneous connections quite easily within a 50 meter radius

In fact come to this the raspberry pi will handle all data via the onboard serial ports , io ports for data acquisition


Summing up this suggestion you create a Server class which waits for incoming connections
On receiving a connection it creates a new thread and new connection object

The connection object will have its own independent Io streams for reading / writing data

A thread pool class which handles all new threads and iterates through each thread servicing each connection objects streams


All you have to do is write the software

Hope that suggestion helps



Mark

Or, how about something as simple as a DHCP server running on a data collection RaspberryPi, that serves IP addresses to the "RasberryPi data pods" based on their MAC address. Then the data collector, running a local application, polls the data pods using file sharing. The data pods would collect their data from whatever sensors they are running and save is as a file which the data collection pi will read during its polling.

But, that's all contingent on things like, sample rate, and power demands. A RaspberryPi is fairly power hungry, so may not be a solution if the data pods will be running off battery power.

So, add that to my questions:

* What are the power requirements.
* Also, what are the size and weight restrictions.

That could work too or if you know anything about paradox and ( Pal paradox application language )Paradox 9 incorporates a ready made server which allows you to take web requests and populate a table based on information appended to the URL when a post operation occurs

You can write a post operation using plain ordinary java or C++ or C sharp or VB.net using a socket connection or Winsock controls and append this information to an html stream for example in java see below

[code lang="java"]

String html = "";
String postUrl = "http://www.example.com/login.jsp";
String data = "x=10&y=20";

URL url = new URL(postUrl);
URLConnection urlConnection = url.openConnection();

// Posting the content
urlConnection.setDoOutput(true);
OutputStreamWriter wr = new OutputStreamWriter(urlConnection.getOutputStream());
wr.write(data);
wr.flush();
[/code]

You can also post data doing this as well and send this to a server
(Your URL of web server ) ?kwds=Celine_Dion
Append property = value

Good:
TI has an interesting thing with its MSP430 line.
i got one of these back in 2009 at ESC in San Jose.
Nice radio interface between basestation and remote. Which is the same hardware with different software running on it. line of site transmission/reception was well over 50 meters, something in the way and it dropped real fast.
I really liked the hardware. it could work with your project, if we knew more about it.
skip to the links below, if you do not want to know about the Bad and Ugly.

Bad:
The TI website has stuff all over the place. Bloat, non intuitive. Hard to find or search or read.

Ugly:
When you want to find something on the TI site, good luck. it is very difficult to narrow down what you want. The names of things change. The name of document you have a pdf copy of can not be found. it can be a real time waster.
i bought some back then for $50 for the kit (basestation and remote) and $20 for extra remote units.
i tried to find out what they hand and got lost in the never ending links to never land.
Now your mileage may vary with the TI site.

LINKS:
With that said check out these two links.

http://www.ti.com/tool/ez430-rf2500t
http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=slaa378d&fileType=pdf

-sample rate is one shot (weekly, manually triggered).
-Timing is irrelevant.
-USA-east coast.

I have been thinking 433MHz (cheapo xmitter modules), small (but bigger than the 8 pin ones) pic or similar. one eeprom to hold the data, and a small analog RF receiver/detector circuit tuned to receive a long trigger pulse.

So, there would be multiple devices of this nature, where in each had a numeric ID within its firmware, this ID serves to identify the module physically, but also to specify a variable (in mS, for sake of explanation) which equates to a delay before enableing transmitter and sending data at a fixed, (and slow) rate.

My thinking is that they all just sit there recording occasional clicks (as long as power is applied), and incrementing the variables, then when they all receive the trigger pulse simultaneously, they should wait the appropriate # of ms (that is their "ID") before going to transmit mode and sending the data.

The data consisting of the text character tag (held by eeprom), and the two 7digit variables that are of interest that occasionally increment. (never more than once or twice a min, so no worries about ever crashing with a pulse during transmit. that level of error is acceptable).

I know I will either need to implement either an off the shelf library, or implement my own protocol for "noisy RF enviornment" situations with the cheapo 433MHz modules.

Any thoughts?

Thank you very much for your input.

:)

Thanks Mark! While an elegant solution, it is somewhat outside the cost/complexity of what I was seeking. I will refer back to it for sure, if I need to go with more intelligent devices as a solution. Thanks again.

(Copied from earlier reply):

I have been thinking 433MHz (cheapo xmitter modules), small (but bigger than the 8 pin ones) pic or similar. one eeprom to hold the data, and a small analog RF receiver/detector circuit tuned to receive a long trigger pulse.

So, there would be multiple devices of this nature, where in each had a numeric ID within its firmware, this ID serves to identify the module physically, but also to specify a variable (in mS, for sake of explanation) which equates to a delay before enableing transmitter and sending data at a fixed, (and slow) rate.

My thinking is that they all just sit there recording occasional clicks (as long as power is applied), and incrementing the variables, then when they all receive the trigger pulse simultaneously, they should wait the appropriate # of ms (that is their “ID”) before going to transmit mode and sending the data.

The data consisting of the text character tag (held by eeprom), and the two 7digit variables that are of interest that occasionally increment. (never more than once or twice a min, so no worries about ever crashing with a pulse during transmit. that level of error is acceptable).

I know I will either need to implement either an off the shelf library, or implement my own protocol for “noisy RF enviornment” situations with the cheapo 433MHz modules.

I was thinking along the IP based identifier solution at first, then I thought I could just do a PC keyboard interface box, open notepad, then hit a button on that box to start data collection, and then a string of text and numbers (followed by a hard return to separate each piece), until all the devices that "heard" the trigger request responded. (I have a specific need to do this in text pad, and not a more intelligent software solution at this time.)

Very cool! thank you. I will look at that closely. (Yeah, TI merging fairly recently with so many, does not suprise me that its in a bit of turmoil. Hopefully it will get sorted out in a few years.

You can do it that way for a far simpler solution but how will you handle the different transmitters and also possible errors I can see that this may not be too important but for acurate results you would want two way commmunication (Full duplex/ half duplex)

Might be a modem that you want as opposed to 433mhz el cheapo solution also you might still need to implement TDM ( Not that easy)

http://www.cis.temple.edu/~giorgio/cis307/readings/datatrans.html

programming wise you would have to push your tansmissions or recieved bytes onto a stack implemented in your PC sofwtare and create a message cue

If you are just using 433mhz yes in theory you could use ID with transmission making up your own protocol but you would also need CRC Check for correct data included in your packet transmission

Zigbee could be your answer to some of this

By having a timing frame - like once a minute, then from that mark, each transmitter would have a unique delay, like Enyaw said. That would require the ability to sync all of the transmitters to the mark. One way to do that would be to have a receiver on each transmitter that would receive the mark signal. Or, they could all be powered up at the same time. OR, they could each have something like a Real Time module that would be set on each transmitter. Maybe the transmitters could all be plugged into a base that would both charge their internal battery AND set their internal clock--i.e. sync it to the mark.

Like that approach steve good thinking

Well, I can't take all of the credit -- I basically elaborated on Enyaw's idea ;)

bq). So, there would be multiple devices of this nature, where in each had a numeric ID within its firmware, this ID serves to identify the module physically, but also to specify a variable (in mS, for sake of explanation) which equates to a delay before enableing transmitter and sending data at a fixed, (and slow) rate.

Here is also a datasheet that will be of further interest to you