Let's say that 6V is borderline: it's barely above the ability of the Netduino regulator. By the way, +12V isn't too much, unless you pull too much current from the Netduino regulator.

I personally suggest any good (linear) regulator which outputs from 7.5 to 12V. However, 9V is perfect.

I'm not going to lie, GHI has a much better community. Why?

1. Trained experts supporting new comers VERY well.
2. A very reliable Gadgeteer production.
3. Many members can show their custom made parts.
4. Their "Codeshare" is a brillient place for Drivers.
5. Though not as open source, good structure and gameplan.

I hope we can all learn from this.

What should we learn?

It seems to me that, especially on the "hot" Netduino era, this forum was plenty of enthusiast people. Also many of them were experiencing the Netduino forum as a "big family", full of warmful users.

Gadgeteer, in my mind, is a flop. Nothing more than a flop.

My philosophy endorses the KISS principle: http://en.wikipedia..../KISS_principle

The Arduino board boomed because its simplicity, as the same was for Netduino...

Many projects created on Netduino are still alive and used even on other platforms: why do you say the users "didn't show their parts"?

If you mean about hardware, I may agree, but it's not because the forum, but because the users. Honestly speaking I often see users refusing to learn a bit of electronics...what else?

The problem isn't Netduino, but MS which almost dropped the MF project. That's a big blame, at least in my opinion.

Also an over enthusiastic admin who deletes posts and has an interesting marketing perspective....

Uh? Could you explain?

 

Please be careful - mains voltages can and do kill people!

...

 

Have (safe) fun - Paul

Hence the famous words: "make love, don't make war, and play with mains responsibly"...

If the characters arrive with a relative "distance" (in terms of time) each other, the original snippet should be good. I wondering how could happen whenever a long stream of bytes arrive at once.

At this point, where's the problem on inserting the I/O control inside the loop?

BTW, I believe the Netduino could be a bit touchy: remove the "until the end of the Universe" comment, then re-run the program...that might yield a way better result.

Cheers

Hello Who.

Instead of using the event, fire a thread endlessly running which consumes the bytes incoming (basically the event handler content).

I think should be more reliable as timing, because the events are dispatched sequentially, but there's no guarantee of accuracy and you may experience a messy stream...

Anyway, I'm not sure to understand what you want to do.

Do you want the Netduino:

1. receive a message from the serial, then
2. process the message by de/activating one or more I/Os, then
3. send an answer out on the same serial

Is that what you want?

...just forget...

MF does have sense...if MS will *SERIOUSLY* develop it...otherwise I totally agree that PI or whatever else board will replace it.

I wouldn't open my Champagne bottle....yet.

R-Pi is much a muscle-toy than a reliable board: consider it has no flash on board. The Netduino has its own limits, but it's way more reliable than R-Pi. Whenever someone will talk about BeagleBone, that would be another story.

Anyone reminds the "revolutionary" Galileo and Edison? Anyone could point a decent support for them?

Honestly, I still haven't see anything "revolutionary" in the MS world. Maybe the most awaited thing they SHOULD publish is the ability to natively compile the C# code, and (for the MF world) the ability to create native drivers without recompile the whole framework.

In my drawer there are a BeagleBone and an Intel Edison still waiting, but on my breadboard there's a Netduino working.

RPi is a proven device, also available in an embedded format (compute board).  They probably sold more today in 11 seconds than all others combined forever. It's barely second all time to Arduino, which IS a prototype platform like the Netduino.   If the hype to open source .Net to linux et al ever happens, it's just 1 more thing on a successful product regardless, but certainly not a dependency.

They sold thousands of boards for true, but the quantity does not make the hardware more reliable over another one.

Again, the board ships with *no* flash, so you must connect a SD. Would you rely on a SD connector durability (dust, oxidation, etc) along 1+ years in a normal city climate?

Have a look at some comparisons between the PI1 and the BBB:

http://makezine.com/...aglebone-black/

I can flash an app to a Netduino/Arduino and forget it for years (possibly avoiding the pins connection as well).

When you can get a PI for $35.00 why would you spend $60.00 on a Netduino 3. Especially since Windows 10 is going to run on Pi 2.

 

https://dev.windows....Program-for-IoT

Again, I'd wait for "singing in the rain" until some concrete signals are coming...

I've heard the Galileo and the Edison support, but nothing concrete. There's also a Compact porting for the BBB, but without much support.

By the way, the current Netduino and a "bigger bro" will have several differences, that you can't wipe off with a bunch of bucks less.

Here are some:

• power consumption
• power-up time
• hardware support (I mean *how* to write your own driver, *how* to port your own board, etc)
• NVRAM support
• software stability (I mean porting support)
• actual processing speed (the MF is way lighter and OS-less than a regular Windows)
• licensing price?...this is unclear.

Somebody says it's free, but WEC 2013 is also "free" unless you use for commercial applications (i.e. not hobby/prototyping)...

I want to see some real-life app, both headless and UI, then I'll decide whether that's a good news or not.

A diode is a semiconductor component which allows the current flowing only to one direction:

• when drawn as a symbol, the arrow indicates the direction
• when a real component, there's a striped which indicates the outgoing lead.

However, when the current is flowing there's a small voltage drop across the leads, roughly 0.6V (it's an exponential formula, though).

About what you want to do, consider the internal point where the power is needed: this point is Vin.

Suppose to feed the power through the barrel. Let's say exactly 10V, but there's a diode on the board (D_board), so the Vreg is expected to 10-0.6 = 9.4V. Everything's working fine.

There's a 9V battery connected with a diode (D_bat) to the same Vin point. Now, the voltage on the positive lead is 9V MINUS the voltage on the Vin is 9.4V, yields -0.4V which is lesser than the minimum required for the D_bat to allow the current flowing. That is, under these conditions the battery can't feed any energy, and all the power is given by the barrel.

Now detach the power barrel.

The voltage on the Vin pin WOULD drop to zero, but AS SOON the point falls below 9-0.6=8.4V, the D_bat begins to allow the current flowing. The battery now is the only one feeding energy.

Why 9-0.6=8.4? Because 9V is the battery voltage (on the positive lead) and 0.6V is the drop of the D_bat diode.

NOTE: I used 10V as the barrel voltage to emphasize the circuit's behavior. However, 10V is not a standard voltage for an adapter. If you have a common 9V adapter, you'll experience kinda "challenge" between the adapter and the battery: the one having the highest voltage will actually feed the board. Bear in mind that a new battery has typically a voltage slightly higher than the nominal, but decreases also easily.

I suggest to make some experiment, but if you want to be super-guaranteed there's no "challenges" anytime, just use TWO diodes in series for the battery. At this point the drop is 0.6+0.6=1.2 and the barrel should "win" all the times!

The short answer to the first question is: yes, but...

The long answer is: there is the "Vin" pin on the header which is basically the same as the power barrel pin. However, you can't wire a battery directly to the Vin pin, but you must add a diode in series to the positive lead. The ground of the Netduino should be connected to the negative lead.

The second question leads to a simpler answer.

The current required by a Netduino may span from 50mA to 200mA: it depends on the model, on the state, on the hardware connected.

Then, check the nominal capacity for a 9V battery here: http://en.wikipedia....ne-volt_battery

Finally, divide the capacity by the current flowing.

Let's say you have a Zinc-Carbon battery (400mAh) and the average current for the Netduino is 100mA. You'll have 400mAh / 100mA = 4 hours.

Bear in mind that a more practical result would lead to the time halved or a bit more.

Good luck.

Very nice, but you'd to file this post under the "Projects showcase" category for better visibility.

Thanks for sharing.

They are a polish team, and I think their bot is C++ based on a homegrown PCB. They have two microcontrollers onboard. One exclusively for sensors, and one for motors.

 

It's just a matter of time: C# will definitely beat C++, and the world will be a nice place to live...(and programming machines will be feasible without brain transplant)
 

In april there'll be a couple hundred robots in Wien for an annual competition. Robotchallenge.org. I haven't been there yet, but can hopefully go next year. 

 

April in Wien? Really? Do you mean this year (2015)? At the end of April I should travel very close to Wien: let me know the details...

Amazing! Very nice indeed...

I know it's a dumb question, but...why they run so fast?

Just another question...who's "Enova"? I mean, which kind of "brain" powers it?

It's on the 11th and 12th of april this year.

See http://www.robotchallenge.org

I won't be able to go this year, but hopefully next year.

Oh!...My chance would be near the end of April, not before.

Definitely better the next year, so I'll take the chance to visit the city once again (really worthwhile).

Cheers

Hi Mario

I set up a modbus TCP client, but I'd need to send registers in string format. Could it be done?

 

Thanks

Alessandro

Ciao Alessandro.

If you mean Modbus ASCII, then the answer is "no". However, you may create your own codec for such a standard. Have a look at the RTU codecs, and the design is easy enough.

Riciao

Create a Microsoft Azure application that unlocks the true power behind embedded and connected devices: the web services and applications that actually connect those devices.

Sponsored By

You could use Azure and the CodeProject API to create a mobile web app to keep track of your CodeProject rep points from your phone, or build a webservice that allows a LED on your Netduino board to blink when you get a new message. What about constructing an IoT-powered robot, automating your home or creating a dashboard that connects to your Fitbit to track your fitness? The sky's the limit - suprise and impress us!

Submit an article outlining how you built your Azure IoT app (with code snippets and screenshots) and complete tasks and missions for your chance at loads of cash prizes.

Read here:

http://www.codeproje...oT-Contest.aspx

Good luck to everyone!

Please Chris, make this post as sticky.

Sorry for being in late.

The boost library leverages its performance by a hardware trick: you must use it, otherwise the library not only won't help you, but even won't work at all.

The Stefan's library is more intuitive and maybe more straightforward to wire, but you can't get it faster because the interpreted framework. That's because I used a hardware solution as a workaround.

From your photo I realize that you already finalized the hardware. I believe there's no clues for pushing the speed greater...

Cheers

First off, thanks Mark for pointing the article: I missed it although I check Hackaday daily.

Secondly, I'm happy twice, because it is rare to see something about on Netduino (NETMF in general) on Hackaday.

Will be that kinda "divine-sign" that something is gonna changing?

Have a nice weekend everybody!

Here is my (modest) contribution...

I believe that iced98lx answered mostly fine, although I never liked Go! nor Gadgeteer.

Netduino Plus 2 is a very nice board, which *never* leave you disappointed, except when...you'll enjoy so much, that you wanna have more, and...there's NO more than a Netduino.

This is the biggest fault, IMHO.

Please, don't mind my signature comment, because derived from the huge blackout in NYC some year ago...keep it likely as a "too deep dependency of the humans from the energy"

BTW, I really endorse Spiked. Maybe he's very "direct", but...it's just what I've written above: the real problem is "behind" the Net MF project, and MS in general. Many, many, many announces, but nothing concrete. We use to say "lot of smoke and no roast".

I wouldn't bet a single cent on what will be the future, but it's also evident the dramatic change that MS shown after the Nadella leading.

Technically speaking, the Arduino board is not "much" different from the Netduino: they both have a microcontroller (MCU), they both have I/O ports, they both have their own features, limitations, etc.

What's *really* different is the firmware inside, or "what the programmer sees". Arduino offers a minimal 8-bits MCU, with few resources (RAM, flash, speed), thus there's *NO* alternative other than "the programmer must help the machine" (C language or so). Netduino leverages its super-powerful 32-bit ARM core to simplify *A LOT* the development, the debugging and many other things.

A frequent surprise is about the "port toggling frequency": whereas an Arduino can toggle an output in the MHz-order, the Netduino barely performs 100 times lower...and it's a 180MHz CPU!

The most straightful answer should be: write a complete HTTP app (for instance), then let's remake the "comparison".

They DO NOT compare: they're two different approaches, which also may interact.

The Go! idea was nice: use the C#+.NetMF power for the higher level "app", then leave the lowest "physical" level task to a small, inexpensive chip. That's the right way. What I don't like is the "plug-and-play" way of doing that: the hardware is maybe the hardest thing to standardize, and most of the times, as soon you do it, it's already legacy.

However, many users like this way of "glueing" hardware: don't follow my words much, I love hacking hardware.

I don't know much about R-Pi or Galileo, but I think they're different beasts.

Have a look at my blog, there are many examples of Netduino exchanging data with serial, TCP, and to the Azure cloud.

http://highfieldtales.wordpress.com/

Good luck.

The Thread.Sleep(500) at the beginning looks useless. Rather, add a Thread.Sleep(100) inside the while.

Moreover, inside the same "while" you're creating a new byte-array object on every cycle: that's causes an unnecessary yet expensive memory management. Create it once outside the "while": there's no need to create a new one all the times.

Finally, instead of reading always a lot of useless bytes (256), consider asking the stream how many are still to pull off, and use that value in the "Read" method.

Another way is the following:

https://github.com/h...erviceClient.cs

Good luck.

I may put my modest contribution to the project, although I'd have a couple of questions...

1. coding the stack as managed code, would offer a decent performance yet reliability? From the experience I've collected with N+/N+2, the low-level layer are the most critical section, and coding them as managed unfortunately yields to a mediocre result.
2. is there anything "interesting" at the horizon, like...for instance...ability to compile a C# app natively?

Chris, I know that you won't disclose anything, even under heavy torture...but could you justify a bit more this decision of porting the stack on C# (apart the bugs)?

Cheers

Hey Paolo,

With a native-compiled proof of concept like Llilum, you still have real-world issues like garbage collectors to deal with. There is a possibility that a GC-less application could be built, and there is a possibility that a GC which honors determinism around interrupts is possible. But to be clear none of these are announced features--or necessarily on the roadmap. It's all very early still, and we're just super-excited for the new bits.

Chris

I think none would need (strictly-speaking) a Real-Time-Netduino, otherwise you'd opt for a different beast, and -yes- maybe programming in some native language.

Instead, I believe the typical req' of the Netduino user is the ability to interface with some I/O: that is, bit-banging, hi-res capture, etc.

So, all the Netduino would need is some hacky-ability to plug a native-coded section. Let's say the "Go" idea, but full-software solved.

I remember an user of this forum, who was very smart, and created kinda "hook" so that the regular C#-managed code ran together with machine-language bits of program.

I always thought that was the right direction although his own solution was actually too cumbersome to use.

Just think to an Arduino-sketch (better: template) against a bunch of Netduino APIs, and the result should be linked to the main app. Although a static linking would require way less resources, I'd rather look in the dynamic one: paying more, but the benefits are satisfying.

Maybe a tiny-tiny Windows COM interface or so...

My two cents...

This would support dynamic loading and also component evolution in a very clean and neat way, with relatively little overhead. But on the other hand, if a static system is accepted, still a lot of overhead can be shifted to build time, thereby allowing to reach much smaller microcontrollers than the one of a Netduino - and this approach would create less confusion regarding the positioning of NETMF versus the IoT version of Windows.

 

A COM-based evolution of NETMF was actually considered for the future of NETMF. But the focus for Llilum is to reach smaller microcontrollers. It should also allow for a high degree of hackability, without the need to combine different languages.

Of course a static binding would be simpler, but...bah...I don't know pros/cons...maybe it's me having an obsessive eye toward the pluggability.

What do you mean about "less confusion" between NETMF and Win-IoT?

Really was considered a COM interface for MF?

Finally, I agree on the "high-degree of hackability", but whenever you need some hires capture/reproduce signal, the GC makes all that unreliable. IMHO, it should be designed some "sandboxed" section dedicated to the RT drivers: a very specific extension with RT capabilities.

Whether the code is interpreted or compiled, should not matter: the sandboxed code has to behave always the same.

Cheers

I don't think you'll get decent (i.e. accurate) results with a simple oscillator: the capacitance is pretty small and also spans along a short range. Moreover, as you correctly pointed out, the Netduino itself won't be able to capture a so high frequency, although I believe you'd have hard time to read it with an Arduino-like board.

Such a sensor is surely cheap but much reliable: it's just a comb-shaped pair of plates, which offers a different electrostatic behavior upon the quantity of water on it...

Water? how this water is composed? what if the rain is mixed with sand, since often we experience red-rains due the African desert wind?

I don't know if that might help you, but we faced the generic "weather" station a while ago, for real cases, not just hobby/home purposes. We've a complete set of sensors for accurate telemetry, even without TCP/IP layer and for pretty long distances (up to some km).

Have a look  here, just for your information...

http://www.cet-elect...ti/sensors.html

Cheers