Main Site Documentation

FEZ- Panda Real World Application released today!


#1

Hi everybody.

We are very proud to introduce the release of our brand new “Quarry Access Control” project entirely developed on FEZ-Panda devices.

It seems that it is actually one of the first real world app developed on .NET MF, at least here in Italy.

You can take a look to devices we developed at http://dl.dropbox.com/u/7414592/Embedded/BOX_1_2_small.jpg and http://dl.dropbox.com/u/7414592/Embedded/Interno_1.jpg

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.


#2

That looks great!! we do have many customers with real life applications based on NETMF :wink: NETMF has been out for a while now.


#3

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.

http://ec.europa.eu/enterprise/sectors/mechanical/documents/guidance/atex/application/introduction/index_en.htm

What IP does you product case have ? Also does Panda board meet all electrical requirements ? (electromagnetic compatibility, galvanic isolation)


#4

Looks awesome! Congratulations!


#5

:clap:


#6

Maybe this is enough to gain some more points and succeed in download SDK beta?

We’re impatient to try new RLP on EMX and USBizi… :smiley:


#7

Please email us a request for the beta SDK.


#8

If you post the zigbee driver on fezzer.com you will earn enough points to be a junior then you can download the beta SDK.

I have the Xbee unit with the zigbee stack but I’m still using AT mode!!

Cheers Ian


#9

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


#10

Sigh! We’ve just published our XBee Device API wrapper for MFToolkit but…no exp points!

Thanks Mike: I just submitted a request through GHI site form.


#11

Gralin:

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.


#12

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.


#13

So you are using two XBee modules from Digi. Which ones? Are they configured as coordinator and router or some other configuration?


#14

Gralin,

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).


#15

Gralin,

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.


#16

@ Mike. I think that post requires 250 points don’t you.

Cheers Innovactive excellent driver…

As soon as mine is up and running I’ll post mine aswell.

Cheers Ian


#17

Why would you want that? I rather do not want my device check the serial port every 100ms


#18

You’re absolutely right.

Nevertheless I cannot blame Micheal Schwartz since on most scenarios it works very well as is.

I think (and hope) that someone will try to change library implementation sooner or later.

After all it is on codeplex for that reason.


#19

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.


#20

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.