The systems consist in two outdoor boxes (one placed near the entry of the quarry and one near the exit) that manage RFID tag identification (via iso cards), ZigBee/API communication with the indoor box (connected via USB to a PC that feeds a SQL Server DB), and a Finite State Machine that drives two gates and 4 photocells to implement a procedure that lets only one truck at a time to enter the plant.
Looks nice. This is something i was looking for at Embedded World 2011 - real world examples of NET MF usage. I need this for my master thesis and also to convice my low level hardware fellow employees that NET MF is not a toy (they associate NET MF and GHI products with monkey ???).
Tell me, does your product fill in with all necessery European standards ? I know there is a directive 94/9/EU ATEX95 that devices need to have in order to work in explosion risk environments.
Except points system is broken on Fezzer at the moment. But it will be fixed eventually, so if you have something to share with the community, please do so. We all will appreciate that. ;D
our devices has been released as a custom system, directly following functional requirements coming from project stakeholders, so they haven’t been submitted to any formal check or certification procedure.
Boxes used are standard IP-66 you can find in many DIY shops.
Gus mentioned in one of his posts that it is recommended to subscribe to SerialPort data received event AFTER openning the port. If this is true than it also aplies to Xbee library (that uses SerialPort). You should check it out and maybe correct your code.
event handlers you see in my code are not related to serial port ones.
Inside MFToolkit XBee library (at http:/mftoolkit.codeplex.com) SerialPort DataReceived eventhandlers could be added after actually opening underlying SerialPort, inside XBee.Open() method.
Actually, such library doesn’t use SerialPort DataReceived event at all, since it creates a thread that polls SerialPort for incoming data (take a look at XBee.cs, inside Open() method and ReceiveData() method).
we used 3 XBee PRO Series 2 modules: one coordinator inside a PC connected box (via USB), and 2 end-devices on remote boxes (one located near entry and on exit of the plant).
We used latest DIGI firmware for those modules, i.e. ZIGBEE COORDINATOR API 2170 and ZIGBEE END DEVICE API 2970.
We adopted u.fl version of XBee modules so that we could connect external antennas (via RPSMA/U.FL adapter cable) and avoid risks about signal shielding and bad propagation.
The range is well beyond 1 km. Just for experimentation purposes, we tried to extend signal putting one or more pure routers (ROUTER API, firmware version 2370) among nodes, but we think it’ll be useful only if nodes cannot “see” each other for topological reasons of the plant.
Using API firmware, we could easily acquire remote samples of climatic data such as temperature and humidity (boxes are placed outdoor 24/7 and they’ll have to resist to hot and cold seasons without any additional protection) using only “out-of-band” data messages, i.e. without even “touching” FEZ-Panda firmware.
Serial port over USB doesn’t have the same concept of a interrupt driver, so this polling approach is at least workable in more than one serial scenario.
We are also in the prototype stage of developing a commercial product based on NetMF. Our product is for use in the Marine Electronics industry, and is basically a joystick control system for boats.
NETMF has been out for a while now.
![http://dl.dropbox.com/u/7414592/Embedded/BOX_1_2_small.jpg[/url]](http://dl.dropbox.com/u/7414592/Embedded/BOX_1_2_small.jpg%5B/url%5D){kind=link}
![http://dl.dropbox.com/u/7414592/Embedded/Interno_1.jpg[/url]](http://dl.dropbox.com/u/7414592/Embedded/Interno_1.jpg%5B/url%5D){kind=link}