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

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

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

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

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?

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.

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.

Can't wait!

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

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.

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.

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!

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.

Pretty interesting reading let slip from Fabien on Twitter.

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

Heh been there done that

You failed to mention whether you acquired the t-shirt.

If you want to use the go!bus compatibility logo, you'll need to use go!bus IO virtualization firmware on your chip (STM8S and STM32 supported soon, AVR and others hopefully supported in the future). It does fun things like let us know how much power you need and lets you build a super-low-cost-module with both tons of intelligence and plug and play ease.

BTW, the STM8S chips are thirty-something-cents in reels. I kid you not.


The on-module processor is there to speak the go!bus protocol and virtualize your IOs. So that your driver on the Netduino Go mainboard sees its IOs, SPI bus, I2C bus, UARTs, PWMs, ADCs, etc. as its own. We can take a small number of developers into our module builder's group for the next few months...once we feel that everything is ready for widespread module building we'll open it up to everyone. 100% cross-board compatibility is our utmost concern.

Will there be a module development board making its way out of that builder's group? I think it'd be good for developers to have a standardized module for creating their go!bus compatible modules. Sure we could use the shield base but that will be flashed specifically for the shield. Would a board with the micro, a go!bus socket, maybe some DIP switches for any configurable settings (power requirements you mentioned...?) and breakouts of pins from the micro be feasible and more useful than the shield base itself?

Heck, this might even be easier for creating limited run modules for special purposes if you offered some cases that fit around the module with a hole for the bus cable. It'd be a heck of a lot easier than designing the PCB, sources the electronics (without bulk pricing! oh noes!) etc. Then if it turns into something people want en masse, the work to turn it into a real and true module could be done at that time.

Is there already an offering or alternative I've failed to consider?

I'm a little confused on what you're trying to accomplish (I don't know the other thread to which CW2 referred).
Looking at your post, this is what I understand you're asking for - please correct me if this is wrong.

[==T1==>]
        [==T2==>]
        [==T3=>]|
        [==T4=>]|
        [=T5=>] V
                [==T6=>]
                [========T7=======>]
                                   [====T8====>]

Or is this more accurate?

[==================T1==================>]
 [==T2==>]                              |
 [==T3=>]|                              |
 [==T4=>]|                              |
 [=T5=>] V                              | 
         [==T6=>]                       |
         [========T7=======>]           V
                            [====T8====>]

If your methods are timed correctly and you don't want to adjust your logic, I'd just create a helper function that takes an array of delegates (VoidAction delegate?)
and runs them each in a new thread using a ManualResetEvent and a counter to track when each finish and only mre.Set when they've all completed. This would
make your helper function become a blocking call which starts and tracks the completion of multiple threads at once.

public delegate void VoidAction();

void AwaitCompletionOf(VoidAction[] actions);

For the first timing diagram, your code would be as simple as the pseudo-code below:

loop:
Thread_1(); // This is call to method directly so it blocks
AwaitCompletionOf(new VoidAction[] {Thread_2, Thread_3, Thread_4, Thread_5}); //Executing parallel; group blocks
AwaitCompletionOf(new VoidAction[] {Thread_6, Thread_7}); //Same as previous
Thread_8();

The second timing diagram would require a bit more work to synchronize the 1st and 8th methods while running the middle threads in waiting parallel groups.

For inspiration, you can look at the beta (but works!) version of a ParallelForEach extension I'd written for NETMF awhile back. It was refined with feedback from Corey Kosak here on the Netduino boards.

Some good approaches and advice in that very long thread. As soon as my eyes uncross I could try giving it another pass.

Hi Jackie,

I think this sounds like an amazing first project!

Guido's advice about breaking down the tasks is essential. Without it you might start to feel overwhelmed at what you've taken on and I really don't want that to happen - I'd love to see what you design!

First I'd identify what are the 'must have' features. These will be your baseline for accomplishment. The remaining features can then become additional upgrades you can make or can be brought in if you're already nearing completion of your core features before you've reached any limit on time, budget, patience, etc.

In your case, you already have a motor but that would have been one of the first things I would have suggested researching. Since others might follow your journey, the way I'd approach it is to:
1. Identify the power capability of the environment. How will this be powered?
> In your case, you've chosen a 120V motor so I'll assume from here on out you're using standard US AC power socket. Have you checked to ensure the motor is AC rather than DC input?

2. Identify the components that are critical to the function of your project. What do you need to make it work?
> In your case, you've identified (and sourced) a motor and presumably the plant stand. In your 'nice to have' features, you will need a moisture sensor and possibly a water drip source.

3. Refine your static design. Where do all the parts go?
> In your case, the only thing that stands out is that the plant appears to have multiple independent soil containers. Soil not exposed to direct light will not dry as fast - and won't need as much water - as soil that is in the light. If you water all the plants equally when a single sensor detects dryness, you could be over or under watering plants. Is this a problem? Should you use multiple sensors?

4. Identify your intended location of the project. Where will it go?
> In your case, will the plant have enough room to rotate? Will the plant brush against any objects that could tip over? What other environmental factors (curious cat) could impact the rotation?

5. Figure out which environmental factors pose a risk you need to account for in your design.
> Your project could involve electricity and unattended watering. What safety mechanism(s) do you have to prevent water from overflowing the stand?

If you take a look at these questions, your initial scope (create a rotating stand) is much less difficult than when you factor in your additional features of being able to detect soil dryness and water the plants. This is why it's good to separate out the features that aren't critical to completing your project and getting satisfaction! Besides, you can always go back and tinker, tweak, add, edit, etc.

So, now that we know at a minimum we will be working with:

Powered Motor capable of spinning a 10lbs load.
Linkage to a platform which will hold the stand that needs to be rotated.
Light sensor to power down in the evening to save power; not rotate unnecessarily.
Microcontroller with the logic.
Interfacing components.

The interfacing components get a bit tricky. While there are parts to do pretty much anything you want available quite readily, it can be a bit daunting trying to find the /right/ components for what you're trying to accomplish. 'Should I use relays? What about a transistor? MOSFET? Why is isolation of power so important?'

For powering the motor from AC (if this was a correct assumption) you have a couple options and your initial thought of a relay is what I would have thought as well. There are a couple options in this arena though. You could use some screw terminals and strip an extension cable to plug into the outlet and run through the relay. I tend not to like this approach only because I'm skittish around mains. I've been looking at the Powerswitch Tail (Adafruit) which is the same thing as using a relay but it's already wired and sealed. As long as your motor doesn't require more than 15A (also check the 'stall current' spec on the motor in case it gets stuck. This is the amount of current the motor will draw while attempting to force the rotation). The only exposure points are where you'd plug in the signal leads. Bonus: the work to prevent feedback on the signal lines when he coil is discharging is done for you and you don't need to worry about this at all! Since the board does act as an LED, I believe you should put a small resistor on the line. Some of the other people here who are stronger in hardware could weigh in on this. Using the Powerswitch Tail contrasts what you'd do if you use your own relay as you'll have put in your own protection to prevent your microcontroller from getting fried. This has been discussed previously and isn't anything new that you'd have to solve on your own should you chose to go that route. In fact there are probably more than a few compatible Relay Shield modules which have done this work for you as well.

How will you power the microcontroller? Since the board can be fully powered from either USB or a barrel jack and you'll already need access to your mains for the motor, you can easily use either a plug-in USB charger or a wall wart adapter providing the right power. These requirements are documented.


So now what do we have?

Given my preferences for non-cut/spliced mains wires, the design looks like it'd be a Powerswitch Tail and a DC adapter plugged into a power strip. The microcontroller would send signal to the tail and run the timer to kick off spinning based on light readings and possibly other factors. Since the cord and micro will be connected and both are powered from the wall mains, the micro can't live on the spinning platter in order to keep the wires from tangling unless you used a servo or stepper that could be reversed. That's no problem here, unless you want the moisture sensor... (See what I mean about pre-defining your musts?)

What's left?

Figuring out how to pair the motor to a drive on the plant stand, timing the rotation to ensure you get the right turn radius per cycle and figuring out how to keep the lighting evenly distributed in order to keep soil moisture levels fairly consistent. Figure out how to connect a moisture sensor without tangling wires!

Alternatives?

While looking up the spec for the Powerswitch Tail, I noticed a new product - the Smart Cord! It's essentially the same as the Powerswitch Tail but with a 10A capacity and Bluetooth control! This means no wires from the micro to the power tail (but requires the addition of a Bluetooth module, figuring out the protocol, etc.) Using this, your micro is no longer required to be directly connected to control the motor. Now the micro /could/ be mounted on the spinning tray and be attached to moisture sensor(s) and whatever else you would like to have. But - there's a new issue of how to power the board since plugging into the power strip would bring us back to twisted cords. If you're okay with changing a battery from time to time, there are some very powerful LiPoly rechargeable batteries available from various sources which I think would fit the bill though you might need a boost circuit to get the required voltage for the board. Going down this road, you can have an LED on your micro light up to warn you when the moisture level is too low. Getting two batteries would be great as you can have one charging (there are simple USB chargers for them) while the other is running the micro. If you wanted to get super fancy, you could probably find a battery gauge circuit for your batteries which would trigger when the power was getting too low and then light up another LED.


I'd say, just to get started and get that rush of accomplishment, look at just doing the motor and interfacing to spin the plant. Get it revolving and marvel in figuring it out and getting the linkage of the motor to the platter working correctly. Then think about possible ways of adding sensors for feedback. I don't think I'd go down the road of automatic watering of a spinning plant source - it just seems to easy to make a mistake and end up with flowing water and dirt out of the stand. I reserve water pumping for static projects that don't move and have sufficient drainage (usually a closed-loop using the same water unless the drainage is, say, a whole yard which won't flood from an outside water source getting stuck open).


I know this is a super long post but that's because I think this is an awesome project and I'd love to see how it comes out! Just know the community will be here to help you along the way if you need it.


Happy making!

You could put a strain gauge under one corner of the base so that as it rotates you can tell which side of the plant is heaviest. As long as the plant was balanced on the base to start with, you could use the heaviest side to tell which side is growing the most and give that side less time in the sun.

That IS a crazy (awesome) idea! Do the herbs grow at different rates/weight though? Maybe the same idea would work as a relative wetness indicator though. You could spin the platter and store the readings as a benchmark (with all the soils appropriately watered first) and then as it rotates, it could indicate when one side has less water than the rest. Maybe spend less time with this section in the direct light until it gets watered again. It's less accurate than a (set of) moisture sensors but it could help keep a neglected plant from becoming too dry (an unexpectedly warm/bright day in the window while away). Otherwise it will spin on schedule. It could also warn if the weight seems to be getting too light in general (all the soils are getting too dry).

I am eagerly awaiting my LCD module! In fact, I just got an email from my apartment building saying I have a UPS package waiting for me when I get home. I have a couple things on order and the tracking info only shows me from where the package was shipped. The anticipation is killing me! It could be my order from [nwazet or fancy shampoo! Edit: Looks like it's the LCD module (and sundry)! But now I need more cables...

This is what you'll see if you don't have a proper static main() method to start/run your project. Did something happen to it?

Hey everyone - I want to say I spoke to Antti directly and worked out the language difference. I can say with absolute confidence the initial communication was just a misunderstanding but there was some escalation after that point with the frustration. From Antti's point of view there was some sense of being attacked where I can see the remaining members were probably being defensive to what they sensed was an antagonistic contact. Please take my word that this was just a misunderstanding. Antti's use of the English language seems so complete it's easy to overlook that he's not a native speaker and is from a different cultural background. The way the language is learned varies greatly around the world and leads to misunderstandings like this when people don't realize they're speaking with someone with such a different background. I hope everyone involved can stop and reset their perception of each other from this first impression! Antti: While I do not speak for Secret Labs or the talented people involved in the Netduino Go project, I can say with confidence the source will be forthcoming. It's important to understand the resources involved in this project are quite small given the scope. Due to this a lot of things slipped through the cracks. I can say I'm never as good with documentation as I am with getting to the 90% point of a project. This is not an excuse. The open source hardware, in fact open source in general, has a difficult time with the last details of a project. Please don't think this means something strange is going on. Secret Labs has committed quite deeply to the open source hardware and software communities. From what I can tell, without passionate people external to Secret Labs, the Netduino Go would not be where it is today. Because of this immense accomplishment, despite the remaining community member's desire to have the SDK completely finished and released, we are very tolerant. This is a brand new product. This is a new league of device. It will take some time for everything to come together. Please also keep in mind the Netduino Go is not even finished being made yet! The same limited resources that rushed to get this amazing hardware to us are still working on refining the SDK to get the most stable and best performing firmware and libraries out to those of us on the bleeding edge who wanted to get our hands on this project early. They are still working on stabilizing the Shield Base module and preparing the switch over to faster bus access for it. They are working with a small group of extremely dedicated and passionate people who want to start creating go!bus compatible modules right now. It's important they pursue these goals now while the community is at the height of their excitement or they might lose the momentum and struggle later to get people interested again. This is important to us in the community because we need those passionate people to struggle through the rough ground and cut a path for us! We need them to shake out the problems and establish a common, workable way of creating modules. In short, please allow for some delinquency in the schedule. It was very ambitious of them and things slid. Updating a web page to reflect this was clearly an oversight. As Secret Labs people can't possibly monitor the forum so frequently to see that this is an issue and correct it immediately, it will take a little time for this to shake out. If it is acceptable, please just consider the date "pending" but know that it will be as soon as is responsible. In my time here I have grown to understand Secret Labs to be full of wonderful, passionate and very smart people who will help in any way possible. They are committed to delivering high quality boards. If you look at the schematics and see how well the boards are engineered with respect to signal and input tolerances, the components chosen for the manufacture, and with the Netduino Go the commitment to using easily recycled parts to lessen their environmental impact, I hope you will come to see them as I do: a truly great, caring company. My best, -Erik

Looking at the third picture on a site that sells them, it looks to me like maybe the connector is set up as |- DET +| when the jumper pins are to the left and the connector is on the bottom of the board facing you.
http://www.geeetech....odule-p-70.html

But otherwise I too can't find any documentation about the module in my, admittedly short, search. At least this suggests there IS a silkscreen on the board. Unless my eyes are really that bad!