Wireless Sensor Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

WSN Sampling

Hi WSN users,

 

I'm trying to determine what speeds I can acquire reliably with my 3202 programable node. According to the datasheet, if the node is not transmitting, it can acquire 35 samples a second on 1 channel, but what will happen to my sampling rate when I transmit?

 

I have a sensor attached to count objects, so with 35 samples a sec, I should reliably be able to count 17 objects passing the sensor a second and keep the count value at the node, but I want to transmit the count value every minute or so... I'm guessing that my sampling rate will reduce when I transmit, so I'm worried I may not count reliably during the short period the node is transmitting.

 

Anyone got some knowledge to share with me about this.

 

Thanks, 

Jevon

0 Kudos
Message 1 of 10
(10,361 Views)

Hi JChen,

 

Is your sensor connected to a digital input or an analog input? If you are using a digital input, you can use the 'DIO Notification' feature that will run the corresponding case whenever there is a value change.

 

You can use a shift register to increment a counter each time the code executes.

 

Then, once a minute or so, you can use the 'Sample' case to transmit the current value. It is possible that you would miss a count during transmission, but not likely. You would have to receive multiple value changes during the transmission to actually miss one. 

 

If you have not read this white paper, I highly recommend you do in order to understand the operation of LabVIEW WSN: LabVIEW WSN Under the Hood.

 

 

Now, if you don't have a digital sensor and are using your analog input, you will need to architect it quite differently and you will definitely miss counts. Let me know if this is the case and I will explain.

 

thanks,

Kurt 

 

 

LabVIEW WSN Benchmarks:

http://zone.ni.com/devzone/cda/tut/p/id/9365 

Message 2 of 10
(10,359 Views)

Hi Kurt,

 

Thanks for the response. My code is doing pretty much what you've explained and I am using a digital input. I'm incrementing a counter on a value change and once a minute, it transmits the data from within the sample case. All seems to run well with that; having no problems... only worried about losing a count during transmission.

I shall read the white paper, haven't seen this one before, so thanks for that. The questions I really need answers for is how long does the node transmit for and how does this effect my sampling rate. Its highly unlikely I will have more than 15 counts a second, but without transmitting, this number is already close on the limit of the node.

To be honest, these are not set specifications for a project, I'm simply seeing the limitations of my wireless devices for future applications.

 

Hopefully the white paper answers some of my questions. 

 

Thanks,

Jevon

Message Edited by JChec on 12-15-2009 10:01 AM
0 Kudos
Message 3 of 10
(10,346 Views)

Hey Jevon,

 

Ah, I see your concern about counting using the DIO at rates approaching 35 samples/sec. However, the 35 samples/sec is only max. sample rate for the analog input.

 

The digital inputs can read at almost 1kHz and with the DIO Notification feature, we have had customers counting at a few hundred Hz. 

 

The benchmarks I linked in the previous post contain the digital acquisition rates, although we have not benchmarked counting with DIO Notifications.

 

Even if a value change occurs during your transmission, I believe you won't miss it. An interrupt is set when the value change occurs, so that event can be handled when the processor is free. So, if more than one value change occurs, you will miss the additional counts, because the interrupt is already set.  

 

I would set up a test to send a known amount of pulses to your node at 15Hz, and then compare that to your node's count data.

 

 

I don't know the time it takes to transmit off the top of my head, but will try to get someone who does know to post.

 

You also asked about how transmission affects your sample rate. This will make more sense once you read the 'Under the Hood' paper linked in the previous post that explains the LabVIEW WSN state machine execution model. You can think of "Sample rate" two different ways with LabVIEW WSN.

 

 

  1. Acquiring a sample AND transmitting it over the air to the gateway, then repeat - this is the default model if you are not programming your nodes and this is limited to 1 sample/second 
  2. Acquiring many samples on the node WITHOUT transmitting - this method allows you to acquire many samples in a while loop, without ever taking the time to power up the radio and transmit data. For analog inputs, this method allows you to sample at 35 samples/sec by default or you can get close to 200 with a little extra coding (see benchmark doc). For digital inputs you can get close to 1kHz.
Counting with the DIO Notification event really does not map to either of those models. With the DIO event, the node is sleeping until the DIO value change occurs, then it wakes up and executes the LabVIEW code in the DIO Notification case. Then the node goes back to sleep. This repeats very quickly if you are continually changing the DIO value. If the sample interval timer expires, the node will wake up and run the sample case and then return to just running the DIO Notification case.
 
Hope this all makes sense 🙂
 
Kurt 

 

 

 

Message Edited by jkurtw on 12-15-2009 10:28 AM
Message 4 of 10
(10,341 Views)

Hey JChen,

 

Time to tranmit is vague statistic, because it depends on network conditions.  When the node wakes up, the radio will quickly sample the medium to determine if it is clear to transfer.  If it is, it will send the data.  If not, it will wait its turn.  This all happens extremely fast (on the order of milliseconds). For a 15 hz pulse, a transmit would have to take ~130 ms to miss a pulse count.  I don't expect a transmit to ever approach taking that long.

 

Kevin

National Instruments
WSN/Wireless DAQ Product Support Engineer
Message 5 of 10
(10,333 Views)

Hi Kurt and Kevin,

 

Thanks for the informative responses, you've understood my problem completely. I apologise for the delayed reply as I was not in the office yesterday. 

 

I think any of the problems I thought I may have had, are gone now that I know the 35 samples/sec only refers to the analog input. 1000hz for 1 channel or 255 for 4 channels is more than ample for my digital inputs. I would suggest that some information on the digital input rates is put into the specification overview or in the datasheet.

 

I will do some of my own benchmarking tests on counting at a few hundred Hz and transmitting when I return from the xmas break.

 

Thanks again for the help.

Jevon

0 Kudos
Message 6 of 10
(10,311 Views)

So I've done the tests I wanted to and said I'd post back. The tests were to see at what rate I could reliably count at using the programmable 3202.

 

I used a crio and a ni 9624 and programmed the fpga to output an accurate enough squarewave at a frequency I specify. The code would generate the squarewave long enough to produce exactly 5000 rising edges and hence I programmed the 3202 to generate notifications on rising edges.

 

Once the squarewave has finished running, I'd request the count from the 3202 and hope for 5000. I found I would not miss a count when using a 25Hz squarewave... anything above that and I would (not always) lose 2 or 3 counts from the 5000. At 100Hz I would usually lose around 3 or 4. Not a lot, but nevertheless I lost counts.

 

The next test was to see if transmitting the data would effect the counting. I would generate the same signal as above by transmitting the count when it got to 1000 and then once the squarewave was finished running, I'd request the count to see if it was short of 5000. That way I'd know if the transmitting of Data would effect the counting.

 

I used the 25Hz signal for this and ran the test 10 times. On 4 occassions I lost counts. My final counts were 4994, 4998, 4999 and 4999 on those occassions. I found if I reduced the signal to 20Hz, I never lost a count. This is enough for my application so that's great!

 

Regards,

Jevon

Message Edited by JChec on 01-19-2010 02:29 PM
0 Kudos
Message 7 of 10
(10,109 Views)

Great information! Thanks for the testing and post.

 

I am glad to hear that the digital events are fast enough for your application.

 

Also, we are always excited to hear what people are doing with our products. If you are able to, let us know what your are counting. I am curious now 🙂

 

thanks,

Kurt 

0 Kudos
Message 8 of 10
(10,094 Views)

Hi Kurt

 

Sorry for my slow response. I'm just counting parts on a production line, 5 samples a second would be probably the max I'll be needing. Just wanted to test the node's limits in case I come across a suitable application that requires slightly faster sampling.

 

Thanks,

Jevon

0 Kudos
Message 9 of 10
(10,065 Views)

Hi Kurt,

 

Hope you are doing well. I would like to know that in the labview WSN 3202 benchmark whitepaper it is illustrated that we can acquire 37.23 Samples/sec.

so to achieve this what i need to configure or set the parameters on the node. I just want to acquire 37.23 S/s using a single channnel of programmable node 3202 node.

 

I am awaiting a positive reply from your side.

 

Thanks.

0 Kudos
Message 10 of 10
(7,384 Views)