Printable View
I am looking for transmitter/ receiver or tranceiver hardware recommendation.
I would like to learn how to wirelessly collect about 6 different analog sensor locations into a pic.
Range (distance) would be up to 100 to 200ft max. Update rate 6 readings/ second (all 6 sensors in 1 second).
Thanks,
Mark
I would recommend anything from here.
http://www.rentron.com/PicBasic/RemoteControl.htm
The TWS-434A and RWS-434 is what I would try from your project description.
To receive data from different transmitters into one receiver, each transmitter could have a unique value in the checksum. Then the receiver MCU will know where the data came from. Lots of possibilities here.
Thanks Dave for the recomendation. The Rentron parts look perfect. I'm not sure how to deal with multiple remote transmitters trying to send data at the same time. I'm thinking transceivers might be easier, I can request data from the selected remote.
Mark
If the remotes are constantly sending data then you should be good with sending an ID.Quote:
I'm not sure how to deal with multiple remote transmitters trying to send data at the same time
What you basically do is treat the ID like a checksum. If the checksum is correct the data is saved/used. Same with an ID. If ID=r1 then data is from remote #1.
Dave, in that case wouldnt there be constant collisions in the incoming packets, affecting the validity of the actual data seen by the receiver?Quote:
Originally Posted by mackrackit
Anand
Receivers are constantly being flooded with noise from everywhere. That is why the checksum or some other way of knowing if the signal being received is good or data we are after. If the ID is part of that then we know the data is good and where it came from.Quote:
Originally Posted by ardhuru
No, thats not what I meant; if all transmitters are transmitting together, wont the receiver ALWAYS see a 'composite' signal thats actually a mix of more than one signal?
Anand
It's not likely that all transmitters are transmitting all the time. Most jurisdictions have rules limiting such transmissions to intermittent transmissions spaced well apart.
In that scenario, building in both an ID byte and error checking is sufficient. The NEC protocol (used by X10 for ~40 years) works quite well. There's a PBP example at http://davehouston.org/PIC-RX-TX.TXT. If you need to send more than 2 payload bytes, you can extend this.
Transceivers that transmit only when queried also work quite well but at large increase in cost. The simple transmitter and receiver like those Bruce sells are inexpensive and available from many sources worldwide. http://davehouston.org/modules.htm
I think Anand has raised an important issue with uni-directional data transmissions.
As he has mentioned, there may be no way to synchronize multiple independent transmitters. This leads to a situation where 2 or more transmitters may offload their payload over the air simultaneously. This will most certainly result in loss of information at the receive end.
To overcome this, there are a few possible approaches.
1) Send the same payload a minimum of 2 times or more spaced randomly in time so the chances of the receiver catching the un-polluted packet is better.
2) Use a 2 way link in which you implement CSMA/CD protocol.
3) Use modules that have built-in CSMA/CD protocol.
The last 2 are more expensive to implement in terms of hardware and firmware.
CSMA/CD = collision sensing multiple access with collision detection
Regards
That is the point.Quote:
Originally Posted by dhouston
When the random simultaneous transmitter trigger happens data will be lost. Again, this happens all of the time, only in this case we know some of the sources of the "jamming" transmissions. Good question to raise though.
One place where this type of thing happens often is with ham radio, and APRS. Yes, the radios used here are transceivers and if one radio hears a transmission in progress then it is supposed to wait to send. Many times the radios sending data can not hear each other so the receiver has to sort things out.
Then it's almost certainly illegal.Quote:
Originally Posted by mackrackit
Unsupervised transmissions such as these are restricted. They cannot transmit continuously but for a limited time-slice out of every x number of seconds. It is detailed in FCC Part 15 regulations. It's been too long since I worked on this specifically and the recent loss of a HDD took my code and notes but I designed just this type of system a few years ago using battery operated transmitters as shown at...http://davehouston.org/adc.htm. I very recently discussed the choice of batteries and measuring battery charge in http://www.picbasic.co.uk/forum/show...9263#post99263.
In N. America most of the spectrum from ~300-500MHz can be used for this type of project but off the shelf transmitters/receivers are generally only available for 315MHz, 418MHz & 433.92MHz although other frequencies are available for volume orders. Most top shelf RF remotes (e.g. Philips Pronto) use 418MHz here.
In Europe, 433.92MHz is used for everything, fancy remotes, RF controlled lighting, RF controlled thermostats, RF controlled ceiling fans and much, much more.
Interference is not much of a problem because of the restricted time-slices and because the limited range of these low power devices. The FCC power limits are much lower than CE limits so that out-of-the-box commercial devices usually have only 30-40' range. It's quite easy (and legal) to improve the receiving side with a preamp and better antenna to extend this to hundreds of feet. It is not legal to mess with the transmitter side.
There are links to the FCC and other pertinent sites on my web page. http://davehouston.org/
.
Continuous was a poor choice of words on my part. The OP wants to send data once per second, so continuous meaning once per second or so.
The OP needs to read what the FCC says about this in 15.231 Periodic operation in the band 40.66–40.70 MHz and above 70 MHz....Quote:
Originally Posted by mackrackit
I cannot imagine what kind of data needs to be measured this often.Quote:
In addition, devices operated under the provisions of this paragraph shall be provided with a means for automatically limiting operation so that the duration of each transmission shall not be greater than one second and the silent period between transmissions shall be at least 30 times the duration of the transmission but in no case less than 10 seconds.
EDIT: I went back to the original post...and I'm not sure I agree that he wants to send all data every second or whether he wants one second bursts at unspecified intervals. It would help to know where he is located and exactly what the sensors are measuring as well as how often he wants an update.Quote:
Update rate 6 readings/ second (all 6 sensors in 1 second).
That sounds like all six in one second.....Quote:
Originally Posted by markedwards
One of the XBee modules like this: http://www.sparkfun.com/products/8664
fits the distance, legalities, and timing specs. It's only $19.00 at DigiKey.com, and is highly configurable.
Attachment 5181
If it is a 1 second burst containing all 6 sensors, I agree - this is ideal.Quote:
Originally Posted by scalerobotics
I appreciate all your insight. I work on equipment installations and it always seems like the sensors are spread out in multiple locations. Example a cooling tower has 2 or 3 temperatures, water level pressure and flow. Down a flight of stairs to the pump room, then up the ladder to the roof...
I was hoping to install a few diagnostic transmitters to temporarily monitor operating conditions.
The Xbee looks reasonably priced.
Thanks,
Ed
But it seems that you need multiple transmitters to avoid running wires up and down the stairs.Quote:
Originally Posted by markedwards
Can you be a bit more explicit about sensor locations and whether you want continuous or periodic operation?
Yes absolutely!Quote:
Originally Posted by dhouston
I was thinking real time data w/ 1 reading per second per each sensor (6 readings per second) would be goodQuote:
Can you be a bit more explicit about sensor locations and whether you want continuous or periodic operation?
Some systems operating conditions can ramp up and shut down in a matter of seconds others rarely change. I have experienced an intermittent high pressure switch
that caused rubber hoses to ocassionally fail.
I have never had an opportunity to work with radio communication and thought this would be a good project to learn.
It does sound like a good placed to learn. You will also get to see how motors and other equipment, along with reinforced walls and such interferes with the signal.Quote:
I have never had an opportunity to work with radio communication and thought this would be a good project to learn.
The FCC limits this type of transmission...Quote:
Originally Posted by markedwards
Quote:
In addition, devices operated under the provisions of this paragraph shall be provided with a means for automatically limiting operation so that the duration of each transmission shall not be greater than one second and the silent period between transmissions shall be at least 30 times the duration of the transmission but in no case less than 10 seconds.
Thanks Dave.Quote:
Originally Posted by dhouston
I read the considerations for operating in the 260 to 470Mhz frequency band and it would not allow my desired update rate.
I started researching the zigbee/ xbee modules.
Mark
Mark,
Sorry I was a bit late as I was back in the hospital for most of this week.
I'm not as familiar with XBee as I am with the lower frequencies subject to FCC Part 15 Regulations but I believe it will be a better fit for what you want to do.
1. It's pre-approved by the FCC. Getting Part 15 approval can cost several thousands of dollars. There's a loophole for "homebuilt" designs but your application sounds too commercial to fit the loophole.
2. There's much more spectrum and frequency hopping is automagically included so I suspect you can meet your desired schedule. If not, since they are all transceivers, you can do a query/response schedule from a master unit which will be simpler to manage than random transmissions from multiple transmitters.
Good luck and keep us updated - this is likely to interest many others.