ErikN

I am actually going to disagree with this one. There is a lot of value to this being discussed on an open thread. Most likely there are other devs that can learn from it and avoiding having the same issues in something they are working on.

tt.

I'm going to disagree with your disagreement.
This discussion isn't really for devs - it's for module developers. There is a different effort being made on establishing best practices and, I think, write up a Module Builders Guide which would benefit from anything learned during this process.

This particular discussion is just noise on the original question now.

Ulrik,

I felt that your reaction was offensive and unfair. I'm only interested in one thing: getting our users unblocked asap and for issues such as this one to never repeat themselves in the future.

Aside from how you perceived his words, it sounds like we had an easy, quick answer to unblock your users. Don't upgrade to 4.2.1 until this bug is worked out. Bugs happen. In all industries. This is not unexpected and to continue to claim this is errant behavior is disingenuous.

Software releases generally follow a process which involves regression testing to mitigate potential user impact when changes are introduced. It's a reasonable thing to ask if regression-testing occurred because it is a standard best practice in our industry. No one should be offended by that and I am confused as to why anyone would perceive my question to be a wrongful attempt at keeping anyone waiting.

It sounds like they did do quite a bit of work to ensure the update did not change the way the spec was designed. From my observation it looks as though the driver were written in such a way that it happened to work through a bug or fluke. It is out of spec. Of course it could break as the spec evolves if it isn't conformant. Please don't put the weight of, what appears to be, a poor implementation of the spec on the designers of said spec. It's just divisive and won't win you any favors in trying to get problems resolved.

This has moved well beyond anything of benefit of the average user at this point. I'm sorry you feel as though you're going to have to move mountains to make your driver work as it should but it's just a bit of software. And there's time - there's no absolute need for your users to move to 4.2.1 immediately. They're in good hands while this gets worked out. Take the time to analyze what went wrong, read over the spec and recommendations on how to implement and mull over how your interactions could change in the future to be more conducive to problem solving and be just all around a bit more civil.

Bon chance!

Ok - so back to the clues.
People have figured out the gobbledygook was a date.
It's assumed the FRA... is a pointer to Daft Punk Harder, Better, Faster, Stronger.
And the latest: Faster than a speeding bullet.* And a date.

So, what could the asterisk signify? Internet telephony? Is it to denote something shady like when a record holder was found to be doping?
Better, Faster I'm on board with. Those seem straight forward. Harder? Like - more difficult? This is less awesome. Or is it milled from a solid block of aluminum like MacBooks? Those are pretty awesome and would meet with Stronger too.

Put it all together and ... Holy Crap You Guys - Netduino Phone!*
*Not a real phone.

There are more differences than raw clock speed. The Atmel chip on the Netduino Plus executes code in Thumb mode (for code space optimization). In this way the DMIPS for that chip is 0.9/MHz. I believe the Go can use Thumb2 code which is more efficient for execution while still having a smaller code footprint. I believe the DMIPS rating is 1.25/MHz. If the Go is still running Thumb code then it will have the same DMIPS as the Netduino and in this case it's a simple matter of increased clock speed. If your program is purely computational (CPU bound) then the time to execute should decrease directly proportional to the instruction set efficiency and speed increase. Exceptions would be any situation you're waiting on threads to switch since I believe the time slices in the NETMF are set at 20ms. If you're not using all the time you are given for your time slice, you could be wasting cycles and you won't see as much of a speed increase. Bottom line is it's really hard to figure out performance difference from a pure math perspective. You'll really just need to benchmark your application.

I was at the booth for a short time yesterday and from overhearing just a few people it was clear people were very happy to know they could use just one board and the hub to use all the modules. It would seem there was some frustration with the number of choices out there. The dilema of choice. I'm incredibly excited to see a unifying solution! I really think this will be overall a very good thing for users. Kudos.

I think you could pull off the dark wizard look quite easily! I'm interested to see what you come up with. I've seen the "Blade Runner" style umbrellas before but they've always seemed too weak to use in any sort of ambient light. As further ideas, I think having a button to immediately switch to a red and orange swirling pattern would be useful to you. When you get angry you can hold the button down and switch into this mode to look extra menacing. When you've calmed you can release and let the colors go back to swirling through a fuller range of color.

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

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

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!

hi there, starting my journey with netduino and as I always expected its the electronics side of it that is going to cause me the problems rather than the .net side!!

I'm building a basic intervalometer for a Canon 350d ("rebel" range in the US) which to trigger taking the picture simply "shorts" two of the three wires which plug intot he camera - http://www.diyphotog..._for_canon_dslr

my previous electrical experiences is very basic car electrics so this would suggest a relay can be used but I'm not sure on what kind of relay, or can this be done without a relay? Is it possible to "connect" two pins together eg plug wire 1 into "pin X" and wire 2 into "pin Y" and the chip cmakes the circuit complete when required?

I've done something similar with Radio Shack Voice Recorder modules. The playback button is just a piece of metal that, when depressed, contacts two PCB traces. For my purposes I removed the button, soldered wires to each of the traces and placed them across a Reed Relay. To control the relay, you can tie one side to Vcc (through a resistor) and put the other to a digital pin on the microcontroller. When you want to trigger the relay, set the micro pin low. Otherwise leave it high. This requires an additional piece of equipment (the relay) but uses only 1 digital pin on your micro. Be sure you get a relay that will operate at the correct voltage. Since the Netduino works on 3.3V logic, you will want to use a relay that can reliably trigger when the difference over the coil is close to that.

I'm sure others have different suggestions. I'd be interested to see what others have done.

-Erik