Wireless sensor network

I am trying to build a simple wireless sensor network..my intention is as follows

  1. sensing data and transmit through XBee wireless module (series-1) to a remote XBee wireless module with time stamp
  2. retrieve data from the remote module using desktop or laptop and time stamp when the data received
  3. calculate latency how much time it takes to send the data from the sensing module to the receiving module.

My problem is that how can I add time information at transmission end (may be any micro-controller such as arduino can do it though I have no idea) and retrieve the data with the sending time and receiving time at the receiving end using a computer.

Please help me..with knowledge and what hardware do I need to build this network.

You have to have a time reference, the PC almost certainly have one for the Arduino you have to add one. If it has to be precise enough to measure transmission latency you cannot use the usual DS1307, a DS3231 is minimally required.

Why don't you calculate the latency once (I doubt it will change notably over time) and take that value? What do you need the latency for?

Knowing what time, to the millisecond, that XBee one sent data, and what time XBee two received it, are useless bits of information, unless the two time frames are identical. The only realistic way for this to be the case is for each XBee to be connected to the same device that can provide a time signal. If this is the case, then the XBee has no role anymore.

I hope that you are not expecting the latency to provide a measure of distance. for the distances that the XBee can transmit, the latency as can be determined given the accuracy of an Arduino will be either 0 or 4 microseconds, since the micros function is limited to +/- 4 microseconds of accuracy.

Neither 0 or 4 will tell you anything.

I tried to do the same thing with one base and 4 remote sensor with XBee on all of them, with no common clock signal. I got all of the nodes talking to one another and all was happy on the network. My times were not making sense and one of the reasons was that the packets coming out from the XBee is not deterministic and that makes the latency different with each event from the sensors. I found that I could get time resolution of maybe 0.050 seconds but would be happier saying it is 0.10 seconds.

My timing resolution needed to be about a millisecond so I needed some kind of time base that was common to all nodes and the base so the remote sensors could report the time of the event referenced to that common time base. The time base I am implementing now is using the pulse per second (PPS) signal coming out of the GPS, the PPS signal is attached to an interrupt, the attached ISR sets the MCU timer to zero and records the time stamp from the GPS. When an event occurs the remote nodes send a message that such and such happened at so many clock cycles from the time stamp reported.

When the message gets to the base it can store it and time correlate to all other messages. This should give me time resolution to about a microsecond with no problems.


The time base I am implementing now is using the pulse per second (PPS) signal coming out of the GPS, the PPS signal is attached to an interrupt, the attached ISR sets the MCU timer to zero and records the time stamp from the GPS.

Are you assuming that all the GPSs will be pulsing at the same time? Is that a reasonable assumption?

No guarantee that they all pulse at the "same" time but the spec says that iff all have 4 or more sats they will all receive a PPS pulse within +/1 10's of ns. With the sensitivities and out of band rejection available on modern GPS receivers 4 sat fixes are easy today. If one of the remote sensor nodes only has a lock on one sat the math says the error on the PPS pulse goes up to +/- 100 ns.

When I quoted a resulting timing resolution in the microseconds that assumed 4 or more sat fixes. When one of more node had less than 4 sats I would assign a resolution probably in the neighborhood of 10's of microseconds, I have not worked up the math entirely for that statement so it is a little back of the envelope as even 10's of microseconds is good enough for my current needs of sound millisecond resolution.

Short story long: no they do not all arrive at the "same" time, that you can not guarantee for any system there will always be some uncertainty you just have to make the decision is that level of uncertainty small enough for the measurement being made. That is the same thing that is done anytime you make measurements, we get away in a lot of cases today because the instruments available for small amounts of money are usually orders of magnitude better than what we need so the instrument uncertainty gets swept under the rug.

The PPS signal is used quite a bit as a means of data synching if the sites do not have internet connectivity or do not want to, or cannot, rely on internet connectivity.

This can be done reasonably well with XBee ZBs (S2) in API mode. After a module completes a transmission request, it sends a TX Status frame which indicates success or failure of the transmission.

I think the XBee 802.15.4 (S1) modules operate very similarly, but I've only used this with S2.

Not sure why it's important to you, but for short payloads, I typically see 25-30ms if just a single hop is involved.

Interesting discussion. By coincidence I am looking into using exactly this technique to check/calibrate an OXCO regulated clock I am making. Indeed I stumbled on this thread whilst searching for information on how accurate the pps signals are on GPS modules generally.

@wwbrown: May I ask what GPS you are using. I have a GlobalSat EM-406a, but I can't find any specific information on the pps in the copy of the datasheet I have available. I am also looking at a Fastrax UP501 where the datasheet, somewhat blithely, simply states +/-50ns.

@PaulS: Thanks for the information on the accuracy of the micros function. Just out of interest is that documented anywhere? I'm guessing the best (only?) way of improving on that would be to use an assembler level timer ISR? (And keep in mind the accuracy of the system clock, of course.)

I am using the Maestro 1035 http://www.mouser.com/ProductDetail/Maestro-Wireless-Solutions/A1035-H/?qs=sGAEpiMZZMsa9w4dmI1JYEv5hDt7Ew5Y and the 2035 http://www.mouser.com/ProductDetail/Maestro-Wireless-Solutions/A2035-H/?qs=sGAEpiMZZMsozux2%2FwCmWzf0tcKPfaAL, as I mentioned in an earlier post some GPS units do not support PPS output and that may be why your datasheet does not mention. I have yo admit that the PPS signal is probably useless to all but a very small percentage of the users.

I have some 1035's in hand otherwise I would only have the 2035's as they have better performance a few bucks cheaper. For either of these modules a breakout board is required and I could not find one on the 'net so I designed one myself, but the design is not ready for primetime right now.

The +/- 50ns is probably correct given 4 or more sats, and you have to ask yourself is that good enough and I am pretty sure the clock speeds on the ATMEL 8-bits MCUs is such that the MCU timing will add more uncertainty than the PPS signal. The GPS units process the data from the sats in pretty much the same way so the PPS signal from one GPS is good as any. When I contacted Maestro with a technical questions re: the PPS Larry responded to me that they did not recommend using that signal for timing and I was a little confused. I emailed Larry back and asked him why and he stated the PPS signal was not exact and it could 50 ns off. I knew for my apps that level of uncertainty was fine, but everyone has to ask themselves the same question but I imagine that is fine for most users here also.


I am working with time critical systems where latency of the WSN is greatly important for controlling and I am trying to build a simple one.Once test successful then I'll go for the complete WSN in large scale.I can start this way

  1. Each sensor node associated with XBee module and send data to the local XBee with arduino
  2. local arduino can be set for time stamping and one Xbee for routing data to the centralized PC/Laptop
  3. the centralized PC/Laptop will receive data through an XBee module
    and the Xbee module need to be series-2
    Is it correct correct approach?

What clock source are you using for the time stamping?

@wwbrown: isnt it possible to use RTC of the Arduino? if possible..would you please give me the code for collecting RS-232 data with time stamp (when data is being collected from the sensor).

I am working with time critical systems where latency of the WSN is greatly important for controlling

You're working with time critical systems and wanna introduce twice the latency by using two XBee transfers on your route from the sensor to the controlling PC? And if your timestamping on the Arduino, what's with the latency introduced by the XBee transfer from the sensor to the Arduino?
How critical are your systems? Is it in the seconds, the milliseconds or the microseconds?

@pylon: actual WSN works this way....data needs to travel multiple hop while you are managing a large WSNs,right? If you have any code how to use RTC in arduino for collecting data with real time stamp (milisecond,second,minute,day,month and year)..please help me with that.

Even with an RTC you don't get a millisecond resolution without effort. The DS3232 has a programmable square wave output with 1Hz that you can use as an external interrupt trigger. Within the interrupt handler you can save the micros() value. Now if you need a timestamp read the RTC registers to get the day, hour, minute and second, then read the micros() and subtract the save value of the last interrupt call and divide by 1000 to get the milliseconds.