Find content
Not Telling
What about 5V and Ground pins? Are they were at the same place as on Netduino itself?
5v, 3.3V and GND remain in the same place.
- PShchegolevatykh likes this
#57929 Using Seeed GPRS Shield with PIR motion sensor
Posted by
on 04 May 2014 - 10:19 AM
5v, 3.3V and GND remain in the same place.
#57911 Using Seeed GPRS Shield with PIR motion sensor
Posted by
on 03 May 2014 - 02:52 PM
You'll need to pick different pins for the signal lines - by plugging the PIR into another digital input (say D8) and adjusting your code.
You should be able to share power and ground for these devices but the Neduino doesn't supply a lot of power so external supplies are sometimes required. Remember to connect the Ground (GND) of the external supply to the Ground of the Netduino otherwise you'll have problems. Also if you have devices with high current needs (e.g. motors) you will need an external supply.
I2C devices (I don't think that either of yours are) can be tricky - you'll need to add resistors to the various signal lines.
FYI - I'm a beginner too. It can be really frustrating... but great when you make some progress.
Jack
You should be able to share power and ground for these devices but the Neduino doesn't supply a lot of power so external supplies are sometimes required. Remember to connect the Ground (GND) of the external supply to the Ground of the Netduino otherwise you'll have problems. Also if you have devices with high current needs (e.g. motors) you will need an external supply.
I2C devices (I don't think that either of yours are) can be tricky - you'll need to add resistors to the various signal lines.
FYI - I'm a beginner too. It can be really frustrating... but great when you make some progress.
Jack
- PShchegolevatykh likes this
#47923 Help for an engineer with severe ADD
Posted by
on 02 April 2013 - 09:00 AM
You are not alone: I have been investigating this too. See below for my collected thoughts. Of course, I am certain that I will have misunderstood some things. I am equally sure that the community has the skill to correct me.
There is no standard firmware yet and the outlook is (realistically) summer this year. It will land on the STM32 architecture first: the Ethernet module, SD and Shieldbase. See Chris' reply here: http://forums.netdui...tate-of-the-go/ "This is where we're at now...getting the GoBus 1.5 firmware for STM32 ready for primetime"
You'll see my questions about module development at the bottom of this thread: http://forums.netdui...or-netduino-go/
Basically, all of the activity today is around firmware development: native C coding and protocol implementation (http://forums.netdui...ucing-gobus-15/). Nevyn's and Matt's http://komodex.com/b...ction-to-gobus/ blogs are the most informative on the subject of firmware development. I find all of this stuff interesting but not practical, for me, because I don't have the skill to develop either firmware or an implementation of GoBus. I would love to see GoBus on the Arduino though: think of all the modules and, potential, code reuse.
My current thinking about adding hardware - a sensor for example - to a Netduino Go is to use the shieldbase. I have just invested in some more shieldbases for this reason. This will be the first "end user" usable implementation of the firmware. In the meantime you'll be able to do the C# code development against the beta firmware. Hardware development can be partially done on top of the shieldbase and then moved onto a target board. The critical decisions about what chip to use (STM8S, STM32F0, STM32F2 or STMF4) will have to wait. My guess is that the STM32F0 - used in a discovery board, nwazet's DAQ and the upcoming Ethernet module - will be the most popular choice.
GoBus and .net Microframework 4.3 provide a consistent way to use IO. That helps a lot.
Everyone that has developed modules so far (Kodomex, nwazet, Variable Labs, etc) has built their own custom firmware and has implemented GoBus 1.0.
The firmware & GoBus are worth waiting for. There is a massive community of C# & VB developers. What is needed is a way to allow these people to, more easily, get closer to the hardware. That is what GoBus is all about. The fact that a non developer, like me, is looking at this is testament to the promise of this technology.
While we wait for the firmware, we can use the shieldbase. Any work done with that will not be wasted effort: on the contrary, it will move development forward. Once the firmware is released, you'll be able to turn these hardware prototypes into "real" modules, complete with the funky connectors. Or just stick with the shieldbases - an easier but (slightly) more expensive option.
Jack
#47468 Netduino Saves Marriage - fixes hot water
Posted by
on 22 March 2013 - 12:05 PM
Ah, there are so many impressive people and projects here. What I have done is neither but it is why I love these devices: I used them to do a simple ugly hack to fix the hot water in my house. I have extended my computer skills into the real world. Amazing.
Background
I have a combination gas boiler in my home. Owing to some manufacturing or design defect, every couple of years the hot water breaks down. This is because the internal switch for DWH (Direct Hot Water) fails. I’ve tried everything in the past but the only reliable fix is to replace a fairly substantial assembly costing over £100.
It not the money, the scraped fingers, the swearing, the tears (mine) whilst replacing it. It’s the business critically of the service. When the thing breaks, the hot water suddenly goes cold when my wife is in the shower.
So I put together the ugliest of ugly hacks with a Netduino, a water flow sensor (http://proto-pic.co....er-flow-sensor/), a simple relay and a bunch of plumbing items.
Oh, and this code.
Can you tell that I don’t do this for a living?
using System;using System.Net;using System.Net.Sockets;using System.Threading;using Microsoft.SPOT;using Microsoft.SPOT.Hardware;using SecretLabs.NETMF.Hardware;using SecretLabs.NETMF.Hardware.NetduinoPlus;namespace NPlus_Water{ public class Program { static long pulsebuffer = 0; public static long totalPulse = 0; const int samplingPeriod = 500; // 1 second public static void Main() { InterruptPort FlowMeterPulse = new InterruptPort(Pins.GPIO_PIN_D7, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeHigh); FlowMeterPulse.OnInterrupt += new NativeEventHandler(FlowMeterPulse_OnInterrupt); bool flowLastPeriod = false; bool flowThisPeriod = false; OutputPort hotWater = new OutputPort(Pins.GPIO_PIN_D13, false); while (true) { WaitUntilNextPeriod(samplingPeriod); if (pulsebuffer > 10) { flowThisPeriod = true; } else { flowThisPeriod = false; } if (flowThisPeriod && flowLastPeriod) { hotWater.Write(true); } else if (!flowThisPeriod && !flowLastPeriod) { hotWater.Write(false); } flowLastPeriod = flowThisPeriod; Debug.Print("Pulses: " + pulsebuffer.ToString()); totalPulse += pulsebuffer; pulsebuffer = 0; } } public static void FlowMeterPulse_OnInterrupt(uint data1, uint data2, DateTime time) { pulsebuffer++; } static void WaitUntilNextPeriod(int period) { long now = DateTime.Now.Ticks / TimeSpan.TicksPerMillisecond; var offset = (int)(now % period); int delay = period - offset; Debug.Print("sleep for " + delay + " msrn"); Thread.Sleep(delay); } }}
Here’s the thing. It has worked without a hitch and was a lot less expensive than the commercial part. And I did it myself with the support of this community: the various posts, the books, the inspiration (Cuno’s code).
Of course, I don’t let the wife see how appalling and flimsy the whole arrangement is.
Two pictures - One is where "the brains" plugs into the boiler instead of the old DHW switch. The other is "the brains": Neduino, flow meter, switch, etc.
Attached Files
-
IMG_1066.jpg 37.41KB
69 downloads
-
IMG_1069.jpg 128.75KB
81 downloads
- Paul Newton likes this
