Pretty interesting reading let slip from Fabien on Twitter.

http://fabienroyer.w...or-netduino-go/

Based on some hints I had awhile back, all I can say is: I'm very much excited to hear a formal announcement! I don't think anyone will be upset by it.

The DOD requiurement for the arbitrary maximum is 60K FT Altitude + 1K FtPS Speed. However most manufactures write the firmware code as 60K FT or 1 ftPS instead of 60KFT and 1 ftPS.

My team and I have posted emails to a few of the larger chip makers with what we are trying to do in an effort to get a properly coded GPS Chip that will meet our needs.

Sounds like you've got it covered then!

Is this a good breakdown of what you're asking?

• Can you request a health check from the Netduino?
• Can you extend the program memory size by using an SD card?

For 1, you can do a few things in an attempt to determine if your board is GO/NOGO but I don't know of any single or set of commands you can run to get this answer directly. For instance, I know of no way to say: Check analog pins can input and output relative to Aref correctly, check the onboard LED is functioning, etc. You'd have to identify the components critical to your operation and devise a way to do a system check yourself. When you do this you might find some things can't be tested when the board is connected to your circuit(s) and require a dedicated testing station. You might also find not every test can be run and understood by the board - for instance generating PWM might be hard to measure to ensure you're getting the correct frequencies and you'll need to use an external device to do the proper capture and/or analysis.

As for 2, there are a number of discussions on using the SD card as storage space for DLLs but keep in mind, once you load the DLL into memory, you're using the chip memory. You can't execute program space from the SD card directly. The SD card is primarily used to store log or resource files. I wouldn't count on being able to use this when decided on what boards to evaluate for your needs.

Side note: all consumer GPS receivers (sold in the US? made in the US? required by license?) have an arbitrary maximum operating altitude above which they will be unusable. Just something to be aware of when designing your project.

Just wanted to report that I had my first successful test of my project in the field on an investigation of an old tavern Saturday Night.

Congrats!

This was also my first test of the new LiPo battery circuit and the charger and it worked fine.

I looked over your project site but I didn't see anything specific about this. I'm curious - what are you using? Custom build? I just picked up a couple of these from Adafruit and I've just started testing them. So far with default configuration I was able to charge a LiPoly battery and blind myself with a 1W LED on the circuit output from a MacBook Pro USB port. The board says it can do 1A but I believe the default is 500mA.

I didn't run the LED for very long, I just wanted to test the transition from USB pass-through while charging the LiPoly to running from the LiPoly pack.

I thought this was a known issue. I remember seeing a reference in the latest 4.2 firmware that says ethernet can not be plugged in at any time and is no longer required to be connected at boot-up. If I am remembering correctly, this means the 4.1 releases require the connection at boot time.

EDIT:
Oops, I didn't realize the latest 4.2 was up to RC4 and since I didn't see an explicit version mentioned, I assumed you were using 4.1 - looking at the error more closely I see you are using 4.2.0.0. Looking over the 4.2 RC4 features and sure enough that's where the first mention of plugging in the ethernet at any time is mentioned.

This firmware also includes the following previous updates:
...
5. Network cable may now be plugged in at any time

Can't wait!

Please give it another shot. I think it was blocking all non USA traffic because of some spam I was getting from China a while back.

Ah yes, the sledgehammer approach.

Maybe it'd be a good idea to heat the tube to expel excess moisture in the air and possibly draw a bit of a vacuum when you seal it. That will further reduce the air volume and help eliminate condensation from affecting your board and causing corrosion. Alternatively maybe you could drop in a desiccant packet from a pill bottle if you don't want to heat blast the tube. Either way, I think it's a good idea to remove as much moisture from the sensor area before you seal it.

I think it depends on your purpose. For instance if you're trying to PWM some LEDs, you could use an LED driver chip. Most can be programmed with SPI from what I've seen. The chip would then handle the PWM work. What specific problem are you trying to solve?

Is glass not the best option? I would think it would have low-to-no reaction to the water and - assuming the temperature probe were in direct contract with the glass - it should react fairly quickly to temperature change. Maybe you could just get a long test-tube, affix the sensor to the side near the bottom and submerge. Keep the open end above the water line and cork it. Isn't this how most aquarium heaters are built? For reaction time, I'd try to have the smallest amount of air volume possible - so maybe after affixing the sensor you could use a silicon seal just above the sensor to insulate it from the remaining air column in the tube/vial? This approach should keep everything except the glass completely away from the water for both electronic and fishy health. -Erik

It depends on your need. If you want to wake up from time to time before going back to sleep:

public static void Main()
{
    //Do your event wireup and any other thread work

    //Then, last thing:
    while(true)
    {
        //Do any periodic work you need executed on the main thread for some reason
        Thread.Sleep(10000); // 10 seconds or whatever
    }
}

If you don't ever need the main thread to wake up to do something then you don't need a loop at all and you can put the thread to sleep forever. Your event threads will continue to process; this is just the main thread which you need to keep active so the whole program doesn't terminate.

public static void Main()
{
    //Do your event wireup and any other thread work

    //Then, last thing:
    Thread.Sleep(Timeout.Infinite);
}

Everything you need to know was right there in the first error:

#### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (1) ####
#### Message:
#### System.Delegate::Combine [IP: 0000] ####
#### Microsoft.SPOT.Hardware.NativeEventDispatcher::add_OnInterrupt [IP: 0014] ####
#### NetduinoPlusApplication1.Program::Main [IP: 004a] ####

This is saying in your application NetduinoPlusApplication1 has an object Program with a function Main which has some instruction that is, under the hood, calling NativeEventDispatcher object's add_OnInterrupt method. That is in turn calling Delegate object's Combine method. From experience, I know when you do <event> += <handler> this uses Combine to join your new handler into the pool of handlers that want to be called when this event is fired.

That gives us all the information we need to find the problem. Looking at your code, there's only one place you're doing a handler assignment to an event:

while (true)
{
    button.OnInterrupt += new NativeEventHandler(button_OnInterrupt);
    button.ClearInterrupt();
}

We see this is being done in an infinite loop. Basically you're attaching a copy of your event handler again and again and again until the Netduino runs out of memory space.

You can read up on Event Based Programming but in short to fix your issue, just move your event wire-up above the while loop (which I assume you have just to keep the main thread alive; in which case you should consider adding a sleep call to put the main thread to sleep when it's not needed.)

Hope this helps!

-Erik

night time here in denmark

I'm going to have to start a list of Scandinavian users! Of which I'll only be an honorary member.


-Erik