Also true. I'd thought about that this morning. I tend to over-complicate things I guess.

Ah, I misunderstood. I thought you were trying to achieve the CW2's second timing diagram.

You can't do this with a single thread. You'll need to use 2 threads (and probably want to synchronize them in case one rushes the other by a little bit; otherwise the time difference could grow greater and greater with each loop.) I'd do it like this: MainThread: Prepare things [PWM ports, semaphore or reset events for synchronization] Create 2 threads; one to execute the dimming of LED 1, one to execute the dimming of LED 2 (possibly the same method but with invert parameter?) Methods loop forever just changing brightness of their LED. Start both threads. Thread.Sleep(Infinity); To prevent their timing from drifting use thread signaling. Have each thread block and wait at the end of their loop until the other thread also reaches their end before letting the loop restart. You could use two autoresetevents - one for each thread? I'm not sure if there's a potential for deadlock but I can't see how (assuming you call Set before Wait) but you could attempt to avoid it with a timeout in the wait.

Sweet! And we tentatively had this for 7 months. I can't wait for then to have already happened!

The recorded session is now available.

Awesome job! Can't wait to get my compilers on it!

Artist? I was thinking about just the logo on the front, maybe on the back, pretty simple

You should consider an easy-to-read/remember shortlink or QR code for those too shy to ask about it. Make it easy for them to see or secretly scan to keep it on record to look up later!

Wish I could be there! I've only been to one so far, NYC last year. And I'll be going again this year. I just think it'd be sweet to see how the west coast Faire differs. EDIT: Awww Man! Adam Savage will be speaking at the Bay Area Faire. /sad_panda

The firmware source patch for GCC-based toolchains will be released soon. Please stay tuned.

Tease.

Here is the Netduino Go firmware.

Version: 4.2.0 (version 4.2.0.0)

Is this what is already flashed on the boards or did they ship with a beta of somesort?

I'm so sorry for not responding sooner! My watch on this thread seems to have gotten lost! I guess this explains why perkunas emailed me directly!

This is the code I provided (the helper function is the main bit) and perkunas was able to integrate it and get it to work but he's seeing some strange behavior on some pins when the board is first turned on that he's still trying to diagnose. I thought it might be normal board behavior but it sounds not quite right. He says it stabilizes after 5 seconds or so. Hopefully someone more knowledgeable of the board can help here.

Before I paste the code - the other approaches are pretty much the same and probably lighter weight than this but since perkunas is actually using this at the moment I include it so everyone can be on the same page (so the hardware guys don't blame the software too soon or unjustly!) Again, the AwaitCompletionOf is an adaptation of a function that was heavily inspired by forum member Corey Kosak.

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



namespace Example
{
  public class Program
  {
      public const int SecondMs = 1000;
      public const int MinuteMs = 60 * SecondMs;
      public const int HourMs = 60 * MinuteMs;
      public const int DayMs = 24 * HourMs;
      public const int WeekMs = 7 * DayMs;

      static OutputPort ph = new OutputPort(Pins.GPIO_PIN_D2, true);
      static OutputPort b = new OutputPort(Pins.GPIO_PIN_D3, true);
      static OutputPort a = new OutputPort(Pins.GPIO_PIN_D4, true);
      static OutputPort drain = new OutputPort(Pins.GPIO_PIN_D5, true);
      static OutputPort solenoid = new OutputPort(Pins.GPIO_PIN_D6, true);
      static OutputPort heater = new OutputPort(Pins.GPIO_PIN_D7, true);
      static OutputPort controller = new OutputPort(Pins.GPIO_PIN_D8, true);


      public delegate void VoidAction();

      public static void Main()
      {
          try
          {
              while (true)
              {
                  Method_1();
                  AwaitCompletionOf(new VoidAction[] { Method_2, Method_3, Method_4, Method_5 });
                  AwaitCompletionOf(new VoidAction[] { Method_6, Method_7 });
                  Method_8();
                  Thread.Sleep(10000);
              }
          }
          catch
          {
              //Something has gone wrong; reset to a safe condition
          }
      }

      void RunTheStuff()
      {
      }

      public static void Method_1()
      {
          drain.Write(false);
          Thread.Sleep(16 * MinuteMs);
          drain.Write(true);
      }
      public static void Method_2()
      {
          solenoid.Write(false);
          Thread.Sleep(16 * MinuteMs);
          solenoid.Write(true);
      }
      public static void Method_3()
      {
          a.Write(false);
          Thread.Sleep(11 * MinuteMs + 7 * SecondMs);
          a.Write(true);
      }
      public static void Method_4()
      {
          b.Write(false);
          Thread.Sleep(6 * MinuteMs + 3 * SecondMs);
          b.Write(true);
      }
      public static void Method_5()
      {
          ph.Write(false);
          Thread.Sleep(3 * SecondMs);
          ph.Write(true);
      }
      public static void Method_6()
      {
          while (true)
          {
              controller.Write(false);
              Thread.Sleep(1 * SecondMs);
              controller.Write(true);
              Thread.Sleep(10 * MinuteMs);
          }
      }
      public static void Method_7()
      {
          heater.Write(false);
          for (int i = 0; i < 14; i++)
          {
              solenoid.Write(false);
              Thread.Sleep(20 * SecondMs);
              solenoid.Write(true);
              Thread.Sleep(1 * DayMs);

          }
          heater.Write(false); // added this
      }
      public static void Method_8()
      {
          drain.Write(false);
          Thread.Sleep(16 * MinuteMs);
          solenoid.Write(false);
          Thread.Sleep(16 * MinuteMs);
          Thread.Sleep(30 * MinuteMs);


      }

      public static void AwaitCompletionOf(VoidAction[] actions, int millsecondsTimeout = -1)
      {
          ManualResetEvent mre = new ManualResetEvent(false);
          Thread t = null;
          int total = 0;
          int target = actions.Length;

          for (int i = 0; i < target; i++)
          {
              if (null != t)
                  t.Start();

              int captured = i;

              t = new Thread(() =>
              {
                  try
                  {
                      actions[captured]();
                  }
                  finally
                  {
                      if (Interlocked.Increment(ref total) == target)
                          mre.Set();
                  }
              });
          }

          if (null != t)
          {
              t.Start();
              mre.WaitOne(millsecondsTimeout, false);
          }
      }
  }
}

Hi x893,

We used RVCT (ARM RVDS 4.1) to compile the Netduino Go firmware.

CW2 did quite a bit of work to get it to compile under GCC (using Yagarto...maybe CodeSourcery) as well. This is not tested, but we do want to make sure that everything compiles under the free GCC compiler as well.

Chris

THANK YOU! I tried compiling 4.1 from the NETMF sources but it was a jumbled mess and I couldn't figure it out. After a couple hours I was like: "I has a sad" and gave up. But I still strongly desire to tinker in the native layer to add in some things I think would be useful for me and test them out. I don't like the idea of asking others to make the change to see what happens and I won't blindly send a pull request or merge source that I can't test myself!

Chris - You're my hero for inspiring such awesome people.
CW2 - I will grant you one wish. Within my power to grant. And if it's not too troublesome or very illegal. Unless I'm incapable of making it work again.

I've always just taken a look at the output directory file sizes. For instance, in a default configuration you'll have a BIN folder with 1 or 2 folders underneat: Debug and Release. Whichever configuration you're building, go into that folder. You should see your DLL (and probably other referenced files, build artifacts, etc.) and 2 more folders: LE and BE (for little endian and big endian builds.) These should be about equivalent but you're likely deploying the LE files. Go into that folder and take a look at the .PE file sizes (I'm pulling from memory - maybe it's not PE?).

Looking further at the board, the output goes high when it detects. Your InterruptPort looks like it might be configured for the opposite...

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!

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

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?

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

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

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!

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

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.

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

Heh been there done that

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