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"));
        }
    }
}

Here's what I would do. I am not an expert on anything so... you're on your own.

Looking at the below diagram, look at the circuit on the right, since a motor is an inductive load. I would skip RC, because I am hardcore. RB i would start with a 1k Ohm. I would use just about any NPN resistor, RadioShack should definitely have them, I think they sell a 10 count variety pack. For such a small motor almost any diode would do, something like this should be fine: http://www.radioshac...oductId=2036269

Is it safe to assume you understand the symbols in the diagram for the diode, transistor, etc?

Yeah, that diagram is the same basically as the right side of what I posted.

Vbe is the base to emmitter voltage.
Vce is the collector to emmiter voltage.
Ib is the current to base
Ic is the current through the collector
RC is the resistor to the collector <--i just edited this, i had it wrong!

Since you're just going to be using the transistor as a switch, you really don't need to worry so much about any of those to get started. They will be whatever they are. All you need to really worry about is RB and maybe the diode. Starting with an RB of 1k is a good starting point.

If you want to think of the transistor as something more than a switch (because they are so much more) in this case, think of the transistor as a current multiplier. Different transistors have different multiplication factors (the real name of which escapes me...) .. so, if you put in say 1ma into the base (Ib), that will allow say 100x (which is typical of common transistors at radioshack) the current to move from the collector to the emmiter (Ic). If you use a 1k resistor for RB, that gives you .0005 amps for Ib, which should multiply to .5 amps Ic, which should be enough to drive your motor.

Some transistors:
http://www.radioshac...oductId=2062586

do you have or can you get at least a transistor and some resistors? I think you risk hurting your netduino hooking it up directly.

I'm pretty sure you're going to need at least a transistor and a diode to drive a motor -- i don't think the netduino (or most microcontrollers for that matter) can safely drive a motor.

Ballpark, how much $$ are we talking about?

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

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....

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.

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

Have you tried using a pull down resistor? Quickly looking at all the example circuits on the datasheet for the LM35, it looks to me like they have some kind of path to ground. Also, according to the neduino processor datasheet, only AD0-3 have pull up resistors, A4-7 do not?

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.

LOL i was going to link to the previous thread about the LM35 in case there were some hints ... but it's your other thread...

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());
            }

        }

    }
}

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.

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);
            }

        }

    }
}

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.

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.

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 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

The LM35 seems to have given folks some trouble... I don't have one so I don't know how to fix it. Marius: what if you used a fairly high ohm pull-down resistor? It almost seems like very small output current of the LM35 has nowhere to go. Instead of the cpu acting like it has a pull up resistor, it simply has too high of a resistance to sink the current away. This is all wild guessing on my part.

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.

Check the actual voltage on the aref. If you're running only off USB, I have found that it could be off a significant amount if your usb voltage is low for whatever reason.

You can also use the .SetRange(0, 3300) on your pin method to get the millivolt conversion "for free". I'm guessing if your aref is actual at 3.26 or something you could do .SetRange(0,3260)...

Also check this thread on the LM35

I'd be curious to know about fluctuations in your readings, which I have been struggling with:

Analog Input Fluctuations

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

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.