5 replies to this topic

[James Abbott]

Starting a new thread as advised from Aaron Hi, I'm a hobbyist just starting out, but I think my daytime job employer may have a great deal of use for a Netduino/Plus... It's essentially a counting program, which needs to be able to process signals and have a running total for each GPIO - Probably a frequency of about 83 hz - Is this something that a Netduino, or Plus would be capable of achieving? Or should I look to mod the source to be able to get those kind of freqencies? Or will the standard .NET interrupts be able to handle? Also, do you have any info on electrical interference? I'd be looking to deploy the hardware very close to machines with motors that could be powered with hundreds of volts (manufacturing) - are there any limitations, or workarounds that have been found/resolved with netduinos? Any tips or thoughts on the matter are all welcome My employer would probably order somewhere in the region of 1,000 units per year in the first instance, though with a view to increase this should the project be successful. Thanks in advance James.

[gbreder]

Hi James, impulses with a frequency of about 100Hz can most possibly be handled by Netduino. But you can't say exactly when each impulse occured. Each impulse has a time stamp but this stamp is a few micro seconds of because the .NET Framework isn't realtime. Of course first you should build a prototype before ordering 1000units. Regards Guido

[James Abbott]

Hi James,
impulses with a frequency of about 100Hz can most possibly be handled by Netduino. But you can't say exactly when each impulse occured. Each impulse has a time stamp but this stamp is a few micro seconds of because the .NET Framework isn't realtime.

Of course first you should build a prototype before ordering 1000units.

Regards
Guido

Thanks Guido - The timing of the pulse and when it occurred isn't really something I require - I know if I want to calculate speed/frequency I'll have to try and test a stopwatch class and see if it's accurate, if not I can just get a real time clock chip that should suffice (I hope! )

The main issue I believe is just counting the number of pulses, assuming that we don't miss any pulses on a Netduino? (Does this happen ever, if say the board is very busy may the .NET GC kick in and remove stuff from the Interrupt queues?

Is 100hz capabable with .NET interrupts, or would I need to stick some C/C++ Interop in there? Does anyone have any tutorials/links on Micro framework interop??

[gbreder]

Hi James,
sadly I've to pass your question on to someone else...

...assuming that we don't miss any pulses on a Netduino? (Does this happen ever, if say the board is very busy may the .NET GC kick in and remove stuff from the Interrupt queues?

Does anyone have any tutorials/links on Micro framework interop??

But I'm very interested how the questions will be answerd.

Guido

[Mario Vernari]

My cent on your problem.
If the target of the project is near to a "mission critical", or it's important not losing any pulse, I wouldn't rely on the Netduino itself. That especially if there are "noisy" devices or wiring passing close to the board.

Hardware.
If I were asking for a very reliable "box", I'd pick my Netduino, and I'd enclose it in a metallic (i.e. shielded) box. I also would take care about the supply, and the good grounding. Any wire coming out or getting into the box, should have to be well checked, and maybe shielded. All that assuming the wiring (supply included) aren't too long (let's say below one meter). I wouldn't reject an opto-coupling whereas better than avoiding it.
Upon these conditions, the "box" could be considered pretty reliable from the hardware/noisy viewpoint.

Software.
Netduino (as well as the MF) isn't a bullet-proof framework/firmware, and I wouldn't rely on the service 365 days a year. Nor I bet on a prototype not losing any pulse for a whole day. The system is garbage collected, and it's pretty hard to know what's in the pot will boil.
Instead, I'd use an inexpensive hardware counter, such as many RTCs, which have also several advantages:

• an RTC, which can be always useful;
• the counter (only) can be bat/cap-backupped, thus yields a real non-interrupted servicing;
• it's decoupled from the main board, so any soft/hard failure won't lose the ability to count the incoming pulses;
• I'd bet 1000 Euros on a small stupid chip, over a 1 cent on a very complex machine (imagine a health-critical circuit);
• no need to hack the firmware. Also easier to design, 'cos there's no pain.

Hope it helps.
Cheers

PS: if anyone is asking for thousands of boards, just PM me.

[gbreder]

Hi James,
Mario addresses a very important point with the "noise" issue.
I've designed a DCF77 remote controlled clock. Everything was fine until all my devices were connected together. After that my clock received an additional clock impulse from one of the other components every 10 seconds.
I resolved the problem by throwing the remote controlled clock away. A RTC was implemented instead.

My point: Mario is right in all of his points and I myself have made my share of bad experiences in counting/measuring pulses.

Guido