Hi,

I'm pretty new to electronics and microcontrollers, and I've gotten a netduino because I wanted to get into this topic, and so after a few starting excercises (like blinking leds, using shift registers with SPI, using LDRs as sensors and so on) I think about setting off to my first "real" project: a small lego robot (built with old parts that I used to play with a long time ago ). There are, at this moment, two things unclear to me yet though, so if anybody could clear those up for me that would be great:

• I'm going to run this robot on batteries, and i'm wondering if directly plugging in a 9v battery to Vin/Ground (maybe with a rectifying diode to prevent wrong polarization) will be fine, or if i need a supply with a regulated voltage (which would probably need a bigger voltage on the battery, which i'd like to avoid - i'm already going to have to use 8 AA batteries to power the motors).
• In which state are the netduino pins when the netduino turns on? Or, to be more direct: Can I damage the netduino when I connect a pin to the netduinos 3.3V on startup? (If it's going to be used as an input with ResistorMode.PullUp later).

Thanks for your help, and for a great product

Stefan

Hi Stefan,

You can supply 7.5V-12VDC to the VIN pin, unregulated. A 9V battery will work fine. In fact, we do that frequently with the Netduino Minis.

As for startup--the pins are set as inputs with pull-ups enabled by the micro at boot. This may cause attached devices to see a bit of a "logic high" during boot, but you should haven't to worry about damaging the Netduino itself during boot unless you're trying to draw/supply large amounts of current.

For your motors and such, your best bet is to use a separate power supply.

Chris

Yes, I planned to use a seperate block of batteries for the motors, using an H-Bridge, i got as much from the web. Thanks to you and Stefan for the information!

Just a question Stefan W...
What kind of motors are you using with the lego? the originals ones?
If so, how do you solved the wiring of them (the plain special connectors I mean)?
Cheers

I did not yet, but I planned on cutting a lego cable open (i have a damaged one anyway) and soldering it to hookup wire. When i'm done, i'll report on how it worked out - and yes, original lego motors (the ones that i have now are the old ungeared ones, i ordered some newer ones from ebay).

I used such a bridge for my robot, see this thread for more. Perhaps the code could be of use for you?

I'll have a look into it when I run into trouble, but for now this is my learn-as-you-go project - thanks though

Hi, I just got something like this (for a further range), and was wondering a bit - you're putting the sensor out from the sharp sensor directly into the analog input, which is fine for "usual" readings, but I'm gathering from the datasheet in the "absolute maximum ratings" that the output might get as high as V_CC (maybe during the initial unstable readings?) - or does that just mean that one can apply this voltage to the output port (for whatever reason?)

Hi,

I'm running into the same issue now (I need to generate a pulse on a port to trigger the measurement, and then want to use interrupts on it) with the same sensor. Basically, as I see it, there are two choices: use two ports (one outputport and an iterruptport, left in the image) or use an external circuit to generate the triggering pulse and an interruptport (right). (sensor works like this: you send a pulse over the signal line, and then after a delay it sends a pulse back, and the length of the pulse translates to the distance).



However, as I'm an electronics newbie, I'd like to clear up some issues first:

I weakly recall that somewhere here in the forum someone said never to connect one output and one input port, because that can/will lead to frying the pin. I don't quite get this, because the input port should be high impedance, so currents between them should be low, right?

However, this also means that the output port can sink current when the sensor sends its pulse back. this i can imagine as a problem, both because that might disrupt the measurement on the input port and because there's no current-limiting factor there. I'm reluctant to add a diode there, because the voltage drop of e.g. a 1n4148 combined with the netduinos 3.3v output levels could mean that the neccessary pulse height isn't reached to trigger the measurement. Should I simply add a resistor there? What would be a good value for that?

A similar problem exists for the external circuit, a bit less because the circuit has higher output levels and so there is no problem with adding a diode, i think ...

Can someone clear my doubts for me? Thanks!

How did you wire the button to the netduino? (well, since you "only" get glitching, i guess you've done it right - using some external pullup or pulldown). A simple solution for human-operated switches would be to block events from being triggered if they have been triggered in the last 50 ms or so - so, inside the interrupt handler, check if the last event was within 50 ms, if yes, discard the event, if no, update the time on the last event and do the action.

That depends on your LEDs and your wiring. A stock alkaline 9V battery provides 400mAh or something, so for a really simple circuit, with resistors and "standard" 20mA LEDs, a 9v battery will light 10 LEDs for 2 hours. For low-power 2mA LEDs you'd get 20 hours. By pulsing the current you could lengthen the span also ... if you're looking for battery life, use 6 AA batteries instead of one 9v batteries. They last far longer ... And also, yes, it makes sense that a portable usb battery is no good power source - they usually don't deliver a regulated voltage like a computer does, which is usually fine for charging e.g. mobile phones, but the netduino might not like what it gets.

Bummer! How many mAh do six 1.5volt batteries have?

Since you put them in series, you want to know how much one has, and you can find that out at http://en.wikipedia....wiki/AA_battery.

Hi,

I wrote some netduino plus "driver" for ultrasonic rangefinder. It is rather simple, it uses interruptions, from the 0->1 timestamp to the 1->0 timestamp. It works only when network cable is not plugged in. When the cable is in, the output is allmost allways wrong - it tells that there is something in 150 cm ( instead of 400 cm which is mesure when cable is not plugged in ).

Are there some changes in timings/ frequency / latency when the cable is in?

Is there some kind of workaronds, as I bought the plus version so I could send measured data over LAN...

I recall a post in this forum that the analog inputs behave oddly when the network cable is plugged in ... do you have the input on an analog input port of the netduino plus?

Cheers,
Stefan

I'm very happy to report that we are now shipping the FPGA shield, with a new name: ÜberShield. Boards are in stock at Amazon.com, and more information can be found at the product website http://ubershield.com and in our forums at http://forums.ubershield.com. The final product specs are essentially the same as above, although the 50 MHz clock oscillator has been replaced with a 25 MHz model.

Just in case you know - what is the reason amazon rejects overseas shipping (to Germany)?

You need to look at Fritzing. The Netduino parts are on the forums here.
Regards,
Mark

The netduino parts ship with the current version of Fritzing, no need to manually add them anymore

Regards,
Stefan

You should NOT supply the current for the motors over the netduino (e.g. by using connecting V_M to VIn), as Mario stated. One (the most important) reason is that Motors usually need more current than the netduino can safely supply (read: you can burn out your netduino), another reason is that motors produce glitches in the power that the netduino won't like. You should use a seperate power supply (a seperate battery pack) for the motor and the netduino - connect the motor battery pack to VM and one GND port of the breakout board, connect 3.3V (netduino) to VCC (board), connect GND (netduino) to another GND on the breakout board. (on a side note - you don't need to connect GND on the netduino to GND on the board 3 times ...) You probably should also add filtering capacitors across VM + GND and VCC + GND.

Edit: It seems that the driver already has builtin filtering capacitors, so you can ignore that bit.

The picture looks like you connected 5V to VCC/STBY instead of 3.3V. As Mario said,

consider to power the chip (Vcc) with +3.3V instead of +5V. This allow much more compatibility for the input levels. If you take a look at the chip specs, they show as +3.5V (min) for the high-level, when powered at +5V. Since Netduino cannot reach output levels over +3.3V, that would be at limit. Another way is keep Vcc=+5V, and configure the Netduino outputs as open-drain.

What is the PWM frequency you are using?

Hey everyone, thanks for the great information. Based on what I read, I went ahead and wired everything up with a single power source, running from the 2A source. I tried it in a few configurations, and sure enough I was able to power everything without a problem. The one concern I ran into is that if I plug in the USB, but not the primary power source going into the 5V pin, it will power the LEDs off of the USB power. Since the LEDs have a much higher draw than should be provided through the USB input, I can't imagine this would be good for the N+. Should I worry about this? I would like to be able to program the N+ without worrying about plugging in the lights, so if I could restrict the power to the LEDs when it is only powered by USB. From what I remember in my Physics class back in college, that's the purpose of diodes. If I insert a diode between the power supply and the LEDs, could that cause a problem? I know that diodes have a bit of leakage, so it wouldn't be a perfect isolation, which is fine. I just don't want the LEDs putting too much strain on the N+.

The problem with a diode is that they have a forward voltage drop, the netduino won't get 5V if you simply add one before the netduino +5V pin. How much current do the LEDs draw?

A capacitor across the switch works, however keep in mind that this means that by pressing the switch you are shortening the capacitor, which can lead to high currents through the switch. This effect can (does not have to) lead to damaged (stuck in "on" position) switches (won't likely happen the first time you try it, however if this is something that should live a long time, you might see this), you can prevent that by putting a resistor in series to the capacitor to limit the current (100 ohm should do fine). A software filter is what i'm using - i store date of the last edge, and if the timespan between the last date or the current date is too low, i discard the event. What the glitch filter does is polling multiple times, i don't know over which time domain, maybe it's too short.

In case someone is searching for this in the future, this is the very simple software glitch filter i talked about:

    public class Program
    {
        private static readonly InterruptPort Button1 = new InterruptPort(Pins.GPIO_PIN_D0, false, Port.ResistorMode.PullUp,
                                                                Port.InterruptMode.InterruptEdgeLow);
        private static DateTime Button1LastPushed;

        public static void Main()
        {
            Button1.OnInterrupt += Button1_OnInterrupt;
            // ... main loop
        }
        private static void Button1_OnInterrupt(uint data1, uint data2, DateTime time)
        {
            // glitch filter. events within 50 milliseconds of the first event are discarded
            if (Button1LastPushed.AddMilliseconds(50) > time)
                return;
 //         Debug.Print("Button 1 Interrupt");
            Button1LastPushed = time;
            // actions on interrupt here
        }
    }

Also, Mario, i definitively did read an application note for a microswitch that strongly advised against putting a "naked" capacitor across a switch because of damaging effects. If i can turn it up again (I don't recall where I found it ...) i'll link it here.

Also for the record, if someone wants to do the hardware debouncing "cleanly" it should be probably done like in this article (german text, the schematic should be understandable though) using a RC filter with a schmitt trigger. However, as software debouncing is so easy and doesn't require additional components, i just do that Another useful bit of information in that (german) article is that switches usually bounce for up to 10ms, so the time constants for the debouncing (software or hardware) should be chosing according to that (and no human operates a switch 100 times a second anyway)

Hi everybody

I've got a question about Serial port communication using the netduino. This is the first time I've built something like this - my first week with a Netduino - but I hope this isn't a dumb question!!!.

Where I've got to so far:

I'm using a barebone FTDI USB to Serial mini adapter - I open COM1 at 115200, and repeatedly send a byte array (each packet being 16 bytes long) from my netduino.

I also have a C# client application which reads from the com port at 115200, and successfully sees the stream of bytes that I'm sending from the netduino. So far so good.

Where I'm hitting the problem:

The client application isn't able to determine where my packets of 16 bytes start and end. I mean if I tell the my client app to read 16 bytes from the port, I find that it's possible it'll pick up the last 7 bytes of one packet and then the first 9 bytes of the second.

I think this is probably expected behaviour.

My current workaround is a bit of code that looks for a certain byte pattern in what comes in from COM1 - when it finds that, then read the next 16 bytes of data and assume it's a valid packet of my data - and I just repeat that.

But do you guys know if there's a more elegant or robust solution to my problem, or if there's a protocol I should look into using to tokenise my data stream?

Thanks in advance for any help!
Jeremy

One general solution to this kind of problem is using a Self-Synchronizing code, another one is using markers to delimit token boundaries. How I would design the protocol specifically is dependant on the exact setting. If there's a byte (sequence) that will never appear in the datastream, you can use it between every N tokens (low N -> fast synchronization, high overhead, high N -> slower synchronization, lower overhead) to mark a boundary.

There's also nothing stopping you from adding another microcontroller to your project that handles timing-critical stuff and communicates with your netduino e.g. using SPI. That way, you can use c# for the high-level stuff and have exact timings for the time-critical stuff.

Instead saying "nothing is stopping you", it would be better to say "the only way to solve this"...

Well, what I was trying to say that you don't need to give up on the netduino completely

Hi,
I am using a N+ to do a variety of tasks (including a threaded process using sockets). Watching the debugger after a while it slows down and grinds to a halt with no exceptions.

I have tried using Debug.EnableGCMessages(true)-
at start - bytes used 30888 available 20088,
when it stops bytes used 31872, available 19104

I am using build 4.1.0.6 N+

regards
Eric

You'll need to post more information (e.g. source code) if you want useful help - also, trying to build a minimal testcase often identifies the problem (trying to remove as much from the code as possible while keeping the bug alive).

Regards,
Stefan

depending on space/weight constraints, you could also use "normal" batteries - i currently use a 9v battery or 6xAA battery holder for the netduino and another battery holder (8xAA) for the motors, but that does take up some weight and space

Hi, I remember someone saying here that the analog input pins of the N+ are unreliable if there's an ethernet cable plugged in - to what extend does that happen and what are the symptoms (loss of a few bits of precision, or mostly right readings and some completely bogus ones, or ...) and is that valid for all the analog pins? Is it also valid if the pins are not used in analog mode (but for e.g. I2C)? Also, is the 3.3V limit on the analog ports valid if they are in analog mode or also when they are used for other purposes (e.g. I2C), as is my guess? Regards, Stefan

No, the ADC was for an hypothetical analog sensor. If you're hooking your sensor to an arduino, you can directly count the pulses with it and then send that number to your netduino. However, using an arduino is overkill for that, you could just use a "naked" microcontroller (e.g. an atmega168 or similar - also overkill for this, but a lot cheaper than a "full" arduino - that is, if you already have a programmer/are planning to buy one anyway).

Just browsing the code and they use a NativeEventHandler - wondering if this is helping with the speed of the interrupts?

Regards,
Mark

No, that part of the code is redundant.

The method will also work on the netduino, as long as the frequencies don't get too high. From the datasheet you can see that the frequency can go up to at least 500khz (they don't provide an absolute upper limit, but a graph in it goes up to 1mhz) which means that there's one pulse every 2 µs, and that is too fast (i don't have absolute timings, but i recall interrupts taking at least 20µs).