LabVIEW Wireless Sensor Network (WSN) Module Beta

[Robert_Jackson]

Welcome to the LabVIEW Wireless Sensor Network (WSN) Module Beta project. This thread is intended to foster discussion about the project, so please post your questions, suggestions and applications here.  Our team including R&D, marketing, and support will be actively monitoring this discussion. The LabVIEW Wireless Sensor Network (WSN) Module allows you to deploy LabVIEW code to the programmable NI-WSN measurement nodes.  With the programming capabilities of LabVIEW on the WSN node you can extend battery life, perform custom analysis, build custom interfaces to sensors and control power provided to sensors.  We are excited to bring graphical programming to the Wireless Sensor Network marketplace through the ability to program NI WSN hardware. 

Sincerely,

The National Instruments WSN Team

Robert Jackson - Senior Product Manager

Kurt Williams - LabVIEW WSN Product Manager

Jaidev Amrite - Product Support Engineer

Message Edited by Robert Jackson on 06-30-2009 05:47 PM

Message Edited by Robert Jackson on 06-30-2009 05:47 PM

[muks]

can this be readily coupled to line scan camera for vision applications?

[Jaidev]

Hi Muks,

Although the NI WSN Nodes can do some digital I/O, it is really not meant for vision applications. To see the applications that WSN technology is best suited for, I recommend taking a look at this short webcast. It provides a good overview of the technology and intended applications.

Wireless Sensor Networks – An Introduction to Technologies and Architectures

(http://zone.ni.com/wv/app/doc/p/id/wv-1017)

Thank you,

Jaidev Amrite 

[muks]

Jaidev,

Thanks for the links.

[bnadeau]

Can you run a PID loop on a programmable node?

[jkurtw]

Hi bnadeau,

You can perform simple On/Off control using the digital outputs to implement something like a thermastat.

However, deterministic closed-loop control is not an application that these nodes have been designed for.

Two main reasons: 

1. There are no analog outputs on the nodes

2. You cannot be certain that the code will run deterministically because the node goes to sleep and wakes up between sample intervals 

Hope this helps.

Kurt 

[b1]

In regards to the limitations of the node programming in Labview:

Is it possible to access the routing control and monitor router status at the node via embedded Labview code?

Is it possible to have a counter counting clock ticks?

Are Timed Loops available in the embedded code? 

Where can I find detailed information on the operation of the node and what constraints exists?

Thanks

[jkurtw]

Is it possible to access the routing control and monitor router status at the node via embedded Labview code?

No, currently you don't have insight into the routing behaviour. How would you use this functionality? 

Is it possible to have a counter counting clock ticks?

You have 4 digital I/O lines that can be used as software timed counters, meaning you can either poll the input for edge changes, or you can configure the node to wakeup on rising/falling edges to make it event based and increment a variable each time.

If you meant count the processor clock ticks, no you cannot. 

Are Timed Loops available in the embedded code? 

Timed loops are not available, but you have the standard while loop and basic timing functions. It is important to note that the embedded WSN code execute sequentially in a single thread, so if you have multiple loops, the first has to completely finish before another will start (parallel loops don't run concurrently). This allows us to further optimize your code for density and extend battery life into the multi-year time frame.

Check out the LabVIEW WSN Under the Hood paper and let me know if you have any questions: 

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

Also, if you would like to download and evaluate the LabVIEW 2009 WSN Module, you can get it here:

https://lumen.ni.com/nicif/us/evaltlktindctrl/content.xhtml and follow this tutorial to get started.

You won't be able to deploy but you can check out the function palettes etc.

Kurt 

Message Edited by jkurtw on 09-25-2009 08:07 AM

[b1]

 

Kurt

Thanks for the reply and the links.

The current configuration for the WSN system is 36 recommended nodes per gateway (How many gateways per controller???) and My understanding is that only 50 nodes are allowed in MAX (Is that the limit in total per controller or per gateway???).  So even if you are acquiring lets say 250bits of data per 5 min you can still only have 36 nodes to work with even though your bandwidth demands are low at 250kbits per second throughput you could theoretically have up to 3000 nodes operating on a single gateway from a bandwidth point of view (assuming that 250kbits.sec is the DATA throughput with overhead already accounted for ???).   My understanding is that the lack of determinism prevents the system from doing more.  So I would bypass MAX and the automatic mesh comm handling supplied by the existing hardware/software altogether in order to get the node count up to what is inline with the  250kbit throughput capability.  I would develop an algorithm to create some 'fuzzy determinism' and Administrator comm path controls (eliminating true mesh capabilities while allowing for at least 1 redundant comm path at each hop to and from the controller/nodes).

If I had control over routing and access to a hardware counter counting node clock ticks then I would set up forced data path mapping for data from nodes to host controller with A(rx) and B(rx) comm paths for each hop where A(rx) is taken unless unavailable then B(rx) is taken.  For comm from host controller to Nodes I would broadcast data with address at a defined time for each node.  To get some 'fuzzy determinism' I would do the following as a periodic (maybe twice every 5 minutes) fuzzy determinism cal routine.

Determine the clock jitter and drift, and comm latency for every combination of comm paths established by the administrator and send this information back to the host controller in order for the controller to create a time map of the complete system and assigned times for the node to 'look' for data from the controller (the address attached with data gives a check to make sure the data is for the intended node) and assign times for node to send data back to the controller.  This essentially makes a EtherCAT type protocol based on calibrated and tracked time differences between nodes and overall comm latency. If the A and B paths where stored and handled at the node but set by the controller then I would only need to have 2 nodes configured in MAX and the rest I handle.  This would give me the ability to max out the number of units per gateway according to bandwidth minus the extra overhead.  Also, if the data coming to the host controller has to take path B at any hop then this could be attached and sent with data to inform the host that the node X is down.  Also, by having controlled comm paths from nodes to the controller then return data bandwidth could be higher because multiple return paths could be setup in each network capable of carrying the full 250kbits/sec each. 

If NI limits the number of nodes to 36 then something is limiting the expansion capability and I would like to know exactly what it is. I was told it is "both hardware and software" but that doesn't tell me anything.  These units would be great for an application I have but the 36 (50 in MAX) limit causes a whole array of unnecessary costs and integration issues.

[Kevin_H]

Hey :b,

Thanks for the post.  I'll try and address all your questions below:

1. It appears the solution to your application would be simply adding more gateways. 
2. The theoretical max throughput for the network is 250 kbits/second total.  This includes data and overhead.  Since this is an RF system, the rule of thumb is to cut the theoretical max in half to get the real world number (~125 kbits/second). One standard NI-WSN data packet is 80 bytes.  Keep in mind that each time that packet must hop through a node, it essentially doubles the amount of bandwidth it consumes on the overall network.
3. The radio on the nodes and gateway have a very small memeory footprint.  This restricts the size of the routing table each radio can maintain.  There is no way for the user to modify this table, or add additional memory for a larger routing table.
4. The meshing is handling automatically by the radio, and there are no tweaks that can be done by the user.  The radio firmware controls all aspects of this behavior.
5. The maximum number of nodes that can be connected to gateway is 36.  This is limited by the routing table and the radio firmware.  In addition, that will require that some of those nodes also be configured as routers so they can handle part of the overall routing table as well.  There is more information about setting up a large system in the gateway manual.

For a large system, it would make sense to simply add additional gateways.  This gets you the data acquisition functionality with very minimal effort on your part.

Please let me know if I can help with any other questions.

Regards,