Fred

Let's not forget that with a lot of hobby projects it's the journey not the destination that's the important bit. Maybe Aaron and Dan aren't making the protomodule because it fills a gap that other existing tools don't support, but because they want to and are having fun.

So - who here is pretty sure that they'll be ordering one no matter what it turns out to be? Probably quite a few of us.

#1 thing you'll need is an idea for a project. It doesn't have to be anything complex (and probably best it isn't) and will give you a focus and a clearer idea of what you'll need.

I have to disagree on the oscilloscope. It's a great bit of kit but not cheap and you may never need it. Buy one if you find you need one, not before. A logic analyser is cheaper and more likely to be used, but also not essential to start.

I'd say the starter kit would be:

• Breadboard
• Assorted wires (any single-core wire in a few colours will do, but a bundle would be ideal)
• Some LEDs
• Selection pack of resistors (e.g. current limiting for the LEDs)
• Some small NPN transistors (and maybe PNP too) for stuff like LEDs
• Something to interface to (e.g. serial GPS or LCD display). Maybe pick something that someone here's already got working.

Then just start tinkering. Get an external LED under Netduino control (via a transistor and current limiting resistor). Get some device working - a serial LCD display might be easiest. And just keep going from there.

Well, I finally completed my first Netduino Mini project - a GPS-based puzzle box for my nephew's 8th birthday. It's inspired by a couple of project I'd seen - a reverse geocache box and a steampunk compass. I'd also done a standard netduino based box similar to the reverse geocache for a friend, but I wanted to do a little better and the Mini was just perfect for it.

The plan was to take my nephew via a few locations and perhaps involve a bit more than just the GPS. In the end he had to do 6 challenges. The first 5 were to find a certain point. He had a descriptive clue and sometimes wither a distance countdown or an arrow pointing in the right direction. The final challenge was to find some magnetic ball bearings and put them on the lid, operating a reed switch and unlocking it. It all went well with only a couple of minor hitches.


Some photos










Link to full size ones.

Source code
Attached as ZIP.

The components

• A Netduino Mini - running 4.1.1 alpha 7 firmware so that I could use an SD card to store the data.
• An EM406 GPS unit (serial TTL) to track where it was
• A HM6352 compass (I2C) for orientation
• A µSD breakout board (SPI)
• A 4D systems µOLED-128-G1 1.5" display (serial TTL)
• 2 x Hitec HS-55 servos (one for the lock, one for the direction arrow)
• Cogs from a clock I picked up from a charity shop. You should have seen it. It was hideous. I've done the world a favour chopping it up.
• 3 x 9v batteries.

Things that worked well

• You may notice that I'm using two serial TTL devices (GPS and display) but the Mini has only one TTL COM port. I used both at the same baud rate and had no problems using the TX line for the display and the RX for the GPS. As far as the Netduino was concerned it was an odd hybrid device that was told to display some text and responded with incessant NMEA chatter. 4800 baud was the easiest to get them sharing. It was quick enough.

Things I'd do differently if I did it again

• Consumer 9v batteries are rubbish. They'll power the Mini but as soon as you have a couple of servos moving it all goes wrong. I was approaching a deadline so just wired 3 alkaline batteries in parallel. A better solution would be a decent LiPo battery.
• The compass didn't seem great. Continuous reading mode seemed flaky and even in query mode the reading jumped around. Having some Neodymium magnets in my pocket may not have helped!

Things I would have improved given more time

• The OLED display is a great little device. It can display images and video. It has inbuilt µSD storage that I could have used instead of a breakout. It does sound. I ran out of time to do any of this. On the negative side, readability in sunlight wasn't great - especially red text.
• Kept the servos a bit further from the compass. The magnets in the motors may not have helped with the accuracy.
• Spent more time on the wooden box. It's balsa wood stained brown and looks OK but could be better. Inside was hastily done using off-cuts and araldite.

The result
It worked really well. As his favourite thing at the moment is the film "How to train your dragon" it had a Viking theme. He pretty soon sussed out that I'd made the box and it hadn't been "left with me by some Viking who'd knocked at the door", but he played along.

The arrow went crazy at one point and pointed completely the wrong direction. Probably a bug in my code, but was conveniently blamed on crafty dragons that were trying to fool him. I wish I could use that sort of excuse at work! The second coordinate where the arrow was used it worked fine.

All up, it was weeks of effort and a far more expensive than the present it contained, but great fun to do.

Debounce is a very common problem when dealing with the switches. Here's some code I used recently that does a couple of things.
1. Debounces by ignoring any further interrupts within 500ms. (Tune this if you need to catch quicker presses.)
2. Adds two events OnPress and OnLongPress. For long press it checks every 500ms and if the button's still down after 3s it fires OnLongPress.

using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using System.Threading;

namespace Fred.Useful
{
    /// <summary>
    /// A debounced button wired to an input pin.

    /// </summary>
    /// <remarks>
    /// Ignores clicks within 200ms
    /// Has simple OnPress and OnLongPress events (3s)
    /// /// </remarks>
    public class DebouncedButton
    {
        const int DEBOUNCE_TIME = 200;

        const int HOLD_SAMPLE_TIME = 500;
        const int HOLD_COUNT = 6;

        InterruptPort _button;
        DateTime _lastButtonPress = DateTime.Now;
        Timer _timer;
        public delegate void PressedDelegate();
        int _holdCounter;

        public DebouncedButton(Cpu.Pin pin)
        {
            _button = new InterruptPort(pin, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);
            _button.OnInterrupt += button_Pressed;

            _timer = new Timer(timer_Fired, null, Timeout.Infinite, Timeout.Infinite);
        }

        public PressedDelegate OnPress;
        public PressedDelegate OnLongPress;

        private void button_Pressed(uint data1, uint data2, DateTime time)
        {
            // Debounce - ignore multiple presses within 200ms
            if (time < _lastButtonPress.AddMilliseconds(DEBOUNCE_TIME)) return;
            _lastButtonPress = time;
            _holdCounter = 0;

            // Set up timer for OnLongPress
            if (OnLongPress != null)
                _timer.Change(HOLD_SAMPLE_TIME, HOLD_SAMPLE_TIME);

            // Fire event
            if (OnPress != null)
                OnPress();

        }

        /// <summary>
        /// Check whether the button's still being held down
        /// </summary>
        /// <param name="state"></param>
        public void timer_Fired(object state)
        {
            if (_button.Read())
            {
                // Button released
                _timer.Change(Timeout.Infinite, Timeout.Infinite);
                return;
            }

            Debug.Print("Holding x" + _holdCounter.ToString());

            // Keep sampling. Button's not been held downlong enough

            if (++_holdCounter < HOLD_COUNT) return;

            // Fire event
            if (OnLongPress != null)
                OnLongPress();

            // Stop timer
            _timer.Change(Timeout.Infinite, Timeout.Infinite);
        }
    }
}

I just happen to have a Sony Ericsson lying around, so may well look at doing this sort of thing when I get a chance.

A quick google around suggests that the communication with the phone could be either 0-3.3V or 0-5V (depending on model) rather that +/-12V RS232 levels. You may find the SE data cable is dropping the +/-12V from the PC down to these levels at the phone end. If you investigate a bit further it might be possible to avoid the need for a RS232 shield. I could well be wrong though.

Option 3 sounds good. If you could allocate some of that 8K block to the user and allow easy C# access I'm sure it would be really useful. Anything more than that really should be on an SD card or EEPROM, but when you just need somewhere to stick a few bytes of config that seems like overkill.

A little bit of digging on this forum and it seems EWR is not supported on the Netduino range as it would take up 16KB of valuable code space. In my case I could probably spare the space, but quite understand that Secret Labs are putting effort into supporting more useful stuff that creating a seperate firmware build that includes EWR.

http://forums.netdui...reference-work/

I'll post the code later in the weekend but I'm so excited I had to let you know that I've now got the Netduino Plus webserver handing out files from the SD card. To be honest it isn't tricky, just a File.Exists() and a looped FileStream.Read / Socket.Send. However, there is something magical about seeing XML, XSL, CSS and JPG files being dished out by this tiny device and forming a (small) working web application. My home automation project now had a very basic HTML front end to let me truns a few lights on and open a garage door. Unfortunately I did this to postpone writing an Android front end, not realising that the Android webkit browser can't do client XSL transforms. Cool that it works in IE and Firefox though. Anyway, it's Saturday night so I've got to head out. Lucky I'm not a single man or I'd probably be trying to impress the ladies with talk of .NET microframework web servers and failing miserably. My wife tried her best, but she had to confess to notgetting what's I find so amazing about it.

An updated simple web server for the Netduino Plus. Obviously based on the SocketServer .NET framework example and code posted here by oz-solutions and hari. Some slight tweaks to headers should help prevent lost requests when using IE9 beta. Has a Request object to help with parsing the incoming request. Threaded so your code can get on with whatever it's doing and still respond to a http request. [30/11/2010 - project updated]

They are available from the UK now.
Be quick as we have only received a small number of boards.

Ordered.

I'm interested in a completely autonomous robot that can go to the kitchen, open the refrigerator, and bring me a beer.

I got one of those. Voice controlled too. Works really well, but she does make me put up shelves and dispose of spiders.

Maybe I missed it, but is there a list of Arduino shields that have been verified as compatable? If not, can I suggest one of the forum moderators adds one (and makes it a sticky). Not got a Netduino yet, but I'm probably about to jump in - just checking a few things like this out first.