PIC wireless (RF) monitoring

[grom]

PIC wireless (RF) sensing

I've done a PIC16F877A project which can find the temperature using a sensor connected to the ADC of the pic and subsequently finding the digital value and displaying it on an LCD.
As an improvement, I'm planning to make a network of sensors(substations) which transmit the digital temperature value to a main station which displays which sensor is sending what value.
Here RF transmission and reception has to be used.
The main prob I'm encountering is : HOW TO DISTINGUISH BETWEEN THE SENSORS??
ideas anyone??

 

[LTX71CM]

Add a sensor ID to each data packet as it's sent. If you're generating the data and gathering the temp data with a uC it would be trivial to add such functionality.

 

[grom]

but then since each sensor would be continuously sending data wouldnt they? wouldnt the data sent by one sensor be mixed up with data from the other sensors?

 

[LTX71CM]

but then since each sensor would be continuously sending data wouldnt they?

Only if that's what you program them to do. Packet collisions and distinguishing between two different sensors are entirely different problems.

wouldnt the data sent by one sensor be mixed up with data from the other sensors?

No, that's why you use tagging.

 

[(*steve*)]

Do you have two separate transimitters, each sending 1 sensor 's data, or 1 transmitter sending 2 sensors' data?

If the second case is true, do you ever intend to have more than 1 transmitter?

 

[grom]

I have one sensor connected to one transmitter that sends data to a reciever(Main station) i want to get data from each sensor at the press of a pushbutton or something... Eg. pressing button1 will give sensor1's data and pressing button2 will give sensor2's data on main station's LCD.

are you saying that if i assign particular start bits and stop bits to each sensor for distinction, packet collisions wont occur?

suppose sensor1 sends: 1110010<data>10011
& sensor2 sends: 1110111<data>01001

i'll be able to distinguish between them?

 

[LTX71CM]

are you saying that if i assign particular start bits and stop bits to each sensor for distinction, packet collisions wont occur?

No, I said that was a different issue altogether.

suppose sensor1 sends: 1110010<data>10011
& sensor2 sends: 1110111<data>01001

i'll be able to distinguish between them?

Yes, make the first or last few bits serve as an ID. You'd have to know which ID goes with what sensor but that would allow the base station to track where the data is coming from.

On the remote sensors you could use DIP switches to set the ID so you can easily, add, remove or change IDs as needed.

If you want to prompt a transmission from the sensors you'll need transceivers. If that's the case the requesting packets can be tagged with the ID of the sensor you want to hear from then your base station can make sure it got the right response by checking that packet return has the corresponding ID.

If you only want to view the data but when it arrived isn't important you can have the sensors transmit on a schedule and if you lose a reading here or there it's not a problem (presuming extremely accurate and timely readings aren't that important to you). If the base just stores the last valid transmission of each sensor it can display it upon request but it won't be "real time". You should use some form of error checking like a parity bit. Using only parity isn't robust but it's cheap and easy to implement. A checksum would be better and the next step would error checking with error method that allows for error correction.

 

[(*steve*)]

You can have the transmissions spaced so that they will very rarely overlap, and just live with that overlap when it happens -- so have one transmitting every 9.7 seconds, and the other every 6.1 seconds (97 and 61 are prime numbers). Even in the worst case and assuming transmission took a full 0.1 second, they would only overlap every couple of minutes. As long at you really only need 1 reading every 20 seconds or so, the missed readings could be ignored.

Another way of ensuring you data gets there without corruption is to employ redundancy. Send the same data 2 or more times. Considering that you tend to need a fairly significant lead-in to your data on most transmitters, sending the data 3 times may not even noticeably add to the transmission time.. If both (or all) copies don't match, you have a problem. If you send the data more than twice, you can use a "majority rules" method of figuring what the real data was. It may be easier to code for this than for a checksum, especially where the data is itself very short.

 

[grom]

to make this clear,
LTX71CM, you are saying that for overlap not to occur, I should send a signal(with an ID of certain bits) from main station to the receiver (of say sensor1) to make the sensor1 transmit the data to main station while sensor2 remains idle and send data only when requested by main station?


and Steve, you are trying to say that if i use only transmitters in the sub stations, i could go for scheduled transmissions to avoid signal overlap?and how much time does transmission of say 20 bits take?is it feasible to go for the schedule if i need a fairly fast reading of say max 3 sec?

 

[(*steve*)]

and Steve, you are trying to say that if i use only transmitters in the sub stations, i could go for scheduled transmissions to avoid signal overlap?and how much time does transmission of say 20 bits take?is it feasible to go for the schedule if i need a fairly fast reading of say max 3 sec?

You need to determine some of that yourself.

Let's say your data is 16 bits, and that you're (somehow) sending RS232 to the transmitter.

You might send UUUUUUUU1XX1XX1XX, where U us hex $55 and serves well as a preamble character, followed by the character 1 (meaning the first sensor) followed by XX being the 16 bit data. The data packet is then repeated 3 times.

That's 17 characters. Let's suppose we send that as 1200 baud with 1 start and 1 stop bits, that's 17/120 of a second (let's call it 1/6 of a second.

If you send one sensor every 1.4 seconds, and the other every 0.9 seconds, you would expect a collision every three to four seconds, but you would also be guaranteed to get at least one good reading in every 3 second window.

Reducing the preamble, or increasing the baud rate would reduce the chance of collisions too. Some of this stuff you'd have to determine experimentally. It may even be possible to eliminate the preamble.