This is an interesting idea! Even if all we did was turn on an LED, and pass it around (Jonny sends a signal to my ND+ which turns on an LED, and I send a signal to Omar's which turns on his LED, etc), and captured it on video, it would be VERY interesting.

This is simple and doable. Sign me up. Pick a date!

@bill.french: To access a Netduino behind a firewall check out http://yaler.org/

That is cool -- i think for this project, that might be cheating -- I think we'd need to get an ND+ playing the role of Yaler.

I have'mentioned in the my previous reply, we can get the led params from the link. So why do we even need the firewall stuff??
I am realy busy this week so I guess I'll have to wait couple of days more to get hands on..

Vincent

My concern with your link is that it involves using an extra server to store and pass data that is not an netduino -- i think we should keep it as purely about the netduino plus as possible.

my point is that I think an ND+ could (should?) play the role of the server. I do agree that most of the ND+ should be as bare bones as possible, so blinking an LED is a great starting point.

If it's worth anything, after doing everything under the sun i could think of (caps, resistors, chokes, inductors) to quiet the power supply, the aref, the supply to the thermistor, and showed it to gray beard ( ) who teaches microcontroller programming at Rutgers, using an oscilloscope, he was surprised at how quiet i got the power, but we still could not eliminate the fluctuations. Even with just a simple voltage divider -- no thermistor involved. The voltage was solid on the oscilloscope, but the analog readings were wild by as many as 4 bits, occasionally more -- even after averaging 100 readings. Mine was *way* worse using an external power supply -- even a battery.

I had similar issues dealing with a thermistor:

http://forums.netdui...ch__1#entry3556

I even went so far as to get an external ADC (MCP3204) and still couldn't get it to work well. I came to the conclusion that something about the netduino is too noisy, or analog circuits are too hard.

That's when I switched to the DS18B20 digital temp sensor.

Wow, Corey, that's amazing. So many potential uses!

You must have something already, but in case it somehow helps you even a little bit with making an 'offline' compiler, I wrote a simple function (wrapped in a console app for testing) that takes in a short[] and outputs text that can be easily cut and pasted into VS. It was fun for me to write, regardless.

using System;
using System.Text;

namespace ArrayOfShortsToText
{
    class Program
    {
        public static string AOStoText(short[] aos, string name = "compiledCode")
        {
            string nl = Environment.NewLine;
            string result = @"private static readonly short[] " + name + "=unchecked(new[] {" + nl;
            int count = 0;
            foreach (short i in aos)
            {
                result += @"(short)0x" + i.ToString("X4");
                count++;
                if (count < aos.Length)
                {
                    result += ", ";
                    if ((count % 5) == 0)
                    {
                        result += nl;
                    }
                }

            }

            result += nl + @"});" + nl;
            return result;
        }

        static void Main(string[] args)
        {

            short[] compiledCode = unchecked(new[] {
                (short)0xB5F0, (short)0xB086, (short)0x9005, (short)0x9104, (short)0x9E13, (short)0x9603, (short)0x9E17, (short)0x9602,
                (short)0x2600, (short)0x9601, (short)0xE027, (short)0x9801, (short)0x1E40, (short)0x9E01, (short)0x4046, (short)0x9600,
                (short)0x9901, (short)0x2200, (short)0xE019, (short)0x9E00, (short)0x2701, (short)0x1C33, (short)0x403B, (short)0x2B00,
                (short)0xD00E, (short)0x2701, (short)0x1C0B, (short)0x403B, (short)0x9E02, (short)0x6874, (short)0xB44F, (short)0x9802,
                (short)0x0080, (short)0x9E08, (short)0x5830, (short)0x9903, (short)0xF000, (short)0xF815, (short)0x1C07, (short)0xBC4F,
                (short)0x9E00, (short)0x1076, (short)0x9600, (short)0x1049, (short)0x1C52, (short)0x9F05, (short)0x42BA, (short)0xDBE2,
                (short)0x9E01, (short)0x1C76, (short)0x9601, (short)0x9E01, (short)0x9F04, (short)0x42BE, (short)0xDBD3, (short)0xB006,
                (short)0xBCF0, (short)0xBC02, (short)0x4708, (short)0x4720
              });
            Console.WriteLine();
            Console.Write(AOStoText(compiledCode, "TEST"));
        }
    }
}

Yes, blinky deploys multiple times, deploying the pushbutton/led app (using either d0 or the onboard button) fails after the first deployment. I used fully patched windows XP and whatever version of VS is linked in the download section, 2010 express. I've tried it on several computers now, including a Sony vaio, a dell netbook, a dell optiplex, and vm under fusion on a macbook pro. I've even tried it with and without a usb hub involved.

Yes, I have the same issue with the button app. I can deploy it once. Then I cannot deploy it again without erasing.

I've also tried the below code, which uses D0 for the button, instead, so I could still have access to the reset. Reset has no effect on how visual studio acts, however. I can see that the board resets (the net leds and the blue led cycle and then my code resumes) but visual studio is uneffected.

Once VS is stuck, i can only unstick it by unplugging the netduino, plugging it back it, waiting for it to boot, then unplugging it again. My code never stops running except during netduino boot up.

I've tried every combo i can think of involving resetting, power cycling, and deploying to get it to work without erasing. No luck.

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace NetduinoApplication1
{
    public class Program
    {
        public static void Main()
        {
            // write your code here
            OutputPort led = new OutputPort(Pins.ONBOARD_LED, false);
            InputPort button = new InputPort(Pins.GPIO_PIN_D0, false, ResistorModes.PullUp);

            while (true)
            {
                led.Write(!button.Read());
            }

        }

    }
}

Could Windows 7 work better? It's also not isolated to the built on button; i wired up an external button to d0 with the same results.

I followed those instructions, then loaded the new firmware on the unit and I am back up and running.

What new firmware did you install? I thought the firmware that came with the netduino plus was the latest available?

I am having the exact same problem.

To reproduce it, I followed the "pushing the button" demo exactly. Deploy the project, and it works: the led turns on when I press the button. Then, I change led.Write(!buttonstate) to led.Write(buttonstate) -- removing the !, just to get it so the light turns off when you press the button, and I go to redeploy and is gets stuck on "preparing...". It's done it every time. The circles I'm referring to is: once I'm stuck, I have to kill visual studio, erase the app using MFDeploy, going back into visual studio, loading the project (hopefully I've saved it before trying to deploy!) and trying to deploy again. I believe once I'm stuck I can also unplug the netduino, wait a little while, and visual studio will eventually say the deployment failed, and at least I can save my work. Now I try and save before I deploy, which is probably not a bad practice, anyway.

I assume if I upgrade the firmware to the one in that thread, I'll lose the networking components? That's fine as I continue to get warmed up to the netduino, but obviously not a long-term solution. I chuckle as I type: the networking part is kind of important to me. Still hopeful, --Bill

Great, thank you for the update, I have verified adding "Thread.Sleep(1);" to the demo works!

Let me start off by saying that I had never heard of arduino or netduino or maker faire until about noon yesterday when I read the engadget article on the netduino plus, and I nearly fell out of my chair. Ethernet? C#? $60??? So I packed my three little kids in the car and headed to Queens. I was so excited about the netduino plus, that I completely forgot to check out the 3d printer corral. Anyway, I'm having trouble!! I'm getting stuck on "preparing to deploy". I did just as the OP did, once I sent the button/led demo, I was unable to further deploy using VS. I've used two totally different computers now, both running fully patched x86 XP. I am able to erase using mfdeploy by holding the button and plugging it in, but obviously it's a bummer dealing with VS crashing and going in circles to deploy very simple programs. The demo and other code does work once I have loaded it. Any suggestions would be greatly appreciated.

I am able to deploy the below code multiple times. Thanks for you help with this. --Bill

namespace NetduinoApplication1
{
    public class Program
    {
        public static void Main()
        {
            // write your code here
            OutputPort led = new OutputPort(Pins.ONBOARD_LED, false);
            bool b = false;
            while (true)
            {
                b = !b;
                led.Write(B);
                Thread.Sleep(50);
            }

        }

    }
}

1. The LCD you listed, two members are working on it and have it functioning, minimally (i just ordered mine this week)
2. Config storage: this is a little mysterious right now
3. Thermal sensor: I like the DS18B20 but then you'll need a onewire controller - and then you can read 6 sensors easily, here's a thread about it
4. You can always etch your own PCB -- it's pretty easy

The one wire controller acts like a bridge connecting onewire stuff to serial. It's pretty straight-forward, a couple folks (including myself) here have gotten it working. You can get it from here: http://www.phanderso...mp/onewire.html

I like this project. Tell me if I'm understanding correctly, based on what you said and my imagination: A. The Goals: 1. While away from the cottage, run the heat at very minimal levels to prevent pipes from freezing 2. Turn on the heat to warm the cottage up before you arrive 3. Monitor and report problems remotely B. The Risks: 1. The heat never comes on and the pipes freeze 2. The heat never shuts off and you get a big heating bill, wreck the furnace, or burn the place down In the US, every "heating only" thermostat I've ever seen only have two wires, that when connected (via a relay or other mechanical connection to complete a circuit) tells the furnace to operate. The furnace itself has some sort of electronics to fire itself up, turn on pumps on and off at the right times, etc. Maybe the netduino's role could be limited to reporting back temperatures, and allowing you to remotely switch between two thermostats via a relay? One thermostat could be a cheap programmable one set to normal temperatures, and the other a very basic unit that is set to somewhere above freezing to keep the pipes intact. This way, if the netduino (or, much more likely, your code fails) the fallback mode is just a regular thermostat.

I've got my netduino plus talking to a windows forms application over the network, so that this code:

        public static void Main()
        {
            NetLog log1 = new NetLog();

            log1.Host = "192.168.1.12";
            log1.Port = 8000;

            log1.Print("100");
            Thread.Sleep(500);
            log1.Print("400");
            Thread.Sleep(500);
            log1.Print("200");
            Thread.Sleep(500);
            log1.Print("500");
            Thread.Sleep(500);
            log1.Print("300");
        }

...using the Microsoft Charting stuff, produces this graph:


Which makes me happy!

What is weird though is that sometimes, and only from initial boot or by pressing play is VS, the netduino never makes it past sending the first "100" and throws an exception for each of the subsequent sends:

#### Exception System.Net.Sockets.SocketException - CLR_E_FAIL (1) ####
    #### Message: 
    #### Microsoft.SPOT.Net.SocketNative::connect [IP: 0000] ####
    #### System.Net.Sockets.Socket::Connect [IP: 001d] ####
    #### NetLogger.NetLog::Print [IP: 0042] ####
    #### NDP_SocketSender1.Program::Main [IP: 002d] ####
    #### SocketException ErrorCode = 10053
    #### SocketException ErrorCode = 10053
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in Microsoft.SPOT.Net.dll
    #### SocketException ErrorCode = 10053
    #### SocketException ErrorCode = 10053

When the netduino is unable to connect to the forms app, I am able still able to connect to my forms application using telnet, so I know it's still responding. I am on the latest posted firmware.

I'm sure my code is a train wreck, so any advice would be very much appreciated. I don't doubt I'm doing something fundamentally wrong. My next step is to have the act of sending the data spun off into it's own thread. Here are my solution files:

• The Forms application
• The Netduino solution

I've been working up the nerve to take a stab at this for a while, eventually to start graphing data from the analog inputs. I was motivated to action after seeing Corey's 2d motion tracker w/ excel graphs using data cut/pasted from the debugger output... I was hoping I'd end up with something slightly useful for his Avatar motion project!

Thanks! --Bill

You know, I have not had the problem, since, so I have not turned my attention back to it. I really, really, want to get my head around sockets and threads in .net. I used to have a handle of it under Java, but that was too long ago. Are you having the issue with my code, or your own?

Hello! Both the computer and the ND+ are plugged into switchports on my FiOS actiontel router. The netduino is also plugged in and powered via usb. It mostly works, but when it fails, it's almost always under these scenarios, after opening my forms application: 1. Pressing "play" in VS, which reboots and deploys 2. Unplugging the ND+ and plugging it in My forms app receives the 100, and then the netduino throws exceptions for each of the subsequent transmissions (which I catch and send to output), after the timeout for each one. I know my forms app is still responding, as I can telnet into it and send data while the ND is waiting to time out. But, sometimes it works in #1 and #2. And, it always works when I hit the reset button.

If you had two netduinos in very close proximity, what protocol would you use to connect them? SPI, uart, I2C? Something else? Why? I guess I'm looking for what would be the easiest way to do it, and would tie up the least valuable resources.

Very close distance. Serial is definately easy. I guess my one concern with serial is that there's only two uarts, and point-to-point, so they are kind of "precious". Hmmm....

It sounds like you got it working, but you mention earlier that you're running the sensor off of 3.3v, the LM35 spec says: - Operates from 4 to 30 volts So perhaps that is an issue? You do need to be careful not put put more than 3.3v to the analog input, but from what I gather about the LM35 (10mV/degree C) that should not be an issue.