Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

12 water flow sensors 160ft away from N+2

water flow sensor distant

  • Please log in to reply
10 replies to this topic

#1 Emilio Pastore

Emilio Pastore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationSo Paulo, Brasil

Posted 03 March 2015 - 03:09 AM

Hi guys. I plan to start monitoring the water consumption in my entire building floor.

 

There are 12 apartments, and I don't really know much about electronics. Since I have to power each water flow sensor with +5V and ground, I guess the best option would be to put one 5V power supply for each 6 sensors and place the N+2 midway to try and keep yellow signal cables to a minimum lenght -which would vary around 160ft. Would you take a look at the attached sketch and tell me what you think ? Would it work at all ?

 

And... Would a N+2 reliably handle 12 interrupts ?

 

Thanks, Emilio

 

 

Attached Files



#2 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 03 March 2015 - 05:37 AM

Not clear the cable length...supposed a midway N, each yellow wire could span around 60m?...or 60m is the total cable length to reach *all* the sensors?

 

In general, it's difficult to grant a reliable connection (both in terms of supply and sensor signal) over a so long cable length, especially when there are *many* "branches".

  • If I had to create something similar for my condo, I'd follow those guidelines:
  • The wiring should be "chained" and not "starred", unless the branches are driven independently. That's because the length of the cable can produce standing waves, which scramble the signal (or cancel it at all). Of course, a chained connection might be unpractical, thus the hardware by the N gets more complex.
  • Since the cable length is pretty relevant, the voltage supply should be higher than required. That's for both voltage drop along the cable and noise injected. For instance, using a normal 12V DC (or AC) PS, then a small regulator by each sensor (e.g. 78L05): http://www.ti.com/li...ink/lm78l05.pdf
  • The cable should be (read as: must be) shielded. For simplicity, a two-cored (signal+power) and the shield as ground.
  • Supposing the water sensor as a simple on/off switch, feeding this signal as-is isn't reliable, because any spurious noise injected can toggle the N input easily. A more reliable way to "send" the on/off is using the current loop, but is a little more complex than a simple connection.

 

HOWEVER, In general, over a long cable, especially with branches/intermediate nodes, the power supply isn't carried (unless special "power" circuitry) and the signals are modulated over a carrier, so that the bandwidth is narrow and pretty immune to external noise injection.

 

My suggestion is to dramatically change the way to connect the sensors as follows:

  • Search in the Internet a decent RF transmitter (lo power, due legal restrictions), possibly one with some encoding logic so that you can "recognize" each one, when it sends a message. There are some with a small MCU Arduino-like, which is easy to program by yourself. Also favor the ones which offer kinda "idle" state (microamps current when doing nothing). You'll have to buy as many transmitters as the sensors are.
  • Grab ONE related receiver to place close to the N.
  • Place the N+receiver in a smart position so that the signals of all the sensors reach the receiver without criticity.
  • Consider to power each sensor+transmitter with a battery (suggested) or a PS.

 

You don't need a real-time monitoring, and the sensor MCU could collect the signal then send the result sometimes only (e.g. once a day). Tricks like this one can last the battery very long yielding the sensor hardware relatively simple.

 

Hope it helps.


Biggest fault of Netduino? It runs by electricity.

#3 Emilio Pastore

Emilio Pastore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationSo Paulo, Brasil

Posted 03 March 2015 - 10:15 AM

Thanks very much, Mario. I expected not to add more elements so that the cost and points of possible failure would be kept to a minimum. Let's assume each yellow cable is 30m (100ft), would this 5V PS to each group of 6 FS300A G3/4" sensors suffice ? And how about the 10k ohm resistor between +5V and yellow signal cable near each sensor ? I suspect there is a calculation to be made in order to adjust these numbers, right ? Thanks !

#4 Emilio Pastore

Emilio Pastore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationSo Paulo, Brasil

Posted 03 March 2015 - 10:25 AM

Ops, I was not as clear as I should have been. Since some of these apartments are far from one another, I imagined putting the N+2 somewhere in the middle, not using the Netduino +5V and ground, instead putting a separate PS for each group of 6 sensors, but the yellow signal lenght would have to reach each sensor from the central Netduino.

#5 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 04 March 2015 - 05:40 AM

First off, your dog looks awesome!

 

Secondly...OK, I didn't read about the sensor and its specs.

If you want to stay stuck with cables and a cheap solution, I'd suggest to walk the project step-by-step, together with tests and measurements. In general, a long-cabled solution requires relatively complex approaches. In your case, you may follow a custom-made yet -tailored solution, which hopefully will yield decent results.

 

Here is how I'd do...

  • As you wish, the topology will be the N somewhere in the middle, then a "starred" cabling from the N to each sensor, possibly optimizing the cable length (also due its cost), but also avoiding to run it close to appliances which may create noise (pumps, electric cabins, etc)
  • The cable will be a twin-cored shielded cable. An audio (600 Ohms impedance) cable should fit fine, but there are also cables designed for alarm systems: they're multi-cored and shielded, but they might be cheaper than the audio one. Consider the robustness, endurance and even the flexibility. Although you may smile, often we consider the "taste" because mice and other rodents seem liking to eat cables...no dogs so far, though!
  • The cable, by the sensor side, should be connected to the sensor itself and nowhere else. I mean the shield won't be connected to any ground, than the black wire of the sensor. On the N side, instead, the shield (together with the N ground) will be grounded as well as possible.
  • Consider to enclose the N in a waterproof (plastic) box. Its resistence to the water/dust/etc should be the better the worse is its final position. If you'll place in a protected room, that will be better, of course. Take care if you must wire mains in a very wet position, instead. In such a cases, PLEASE ask an electrician or someone certified!
  • Since the sensors are able to accept up to 24VDC, I'll take advantage to use a higher voltage than 5V. A good 24VDC PS should be fine, but maybe keeping a bit far from the max level would be even safer. Are able to find a 18-20VDC PS? The required current is below 1A for sure, so its price shouldn't be a problem. FAVOR an "old-style" PS, than a switching one because the noise it produces. An old PS "wastes" a bit more of energy, but in your case I believe is better.
  • Of course you can't connect the yellow wire directly to an input, because the too high voltage. The voltage adapter could be solved with a simple diode (for each input), but I STRONGLY suggest to create a more sophisticated interface. The reason is right to the N safety: without some kind of robust "shield", an hazard (even electrostatic or a lightning falling in the nearby) may enter up to the MCU and blow it. In my opinion, despite the bit more hardware required, it's worthwhile...and way cheaper than a brand new N.

 

Let me some time to draw you a small sketch to interface the sensors by the N side.

Let me know what you think, in the meantime...


Biggest fault of Netduino? It runs by electricity.

#6 Emilio Pastore

Emilio Pastore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationSo Paulo, Brasil

Posted 04 March 2015 - 01:06 PM

Hey Mario, you killed it. I mean, sound advice all the way, thank YOU !

 

Nina, the dog, she's my loving companion. It's a shame I can't introduce you to her !

 

Now to your comments.

  • The topology, yes, center the N to try and keep all cables about the same lenght and as short as possible. Nice.
  • Cable, would RG59 coax do it ? http://media.extron....spec_062409.pdf Nina will never reach the roof, no worries. And I'll taste it before purchasing, well noted lol
  • Should I A) connect the core of the cable to the N Dx input and the shield to the N ground, and on the sensor side only the core to the yellow cable directly ? Or should I also B) connect the cable shield to the black sensor cable too, and then this cable to the ground of the remote PS ? Only A), right ?
  • The enclosure will be a nice IP55 plastic box, tight cable holes accessing from below. I guess it'll do it nicely
  • Now the 'remote' PSs : Would it make any sense at all to put, instead of the 18+ PSs you mentioned, for instance, 6V or 9V units and then do the math and define a minimum cable lenght, so that the N does not receive more than 5V without any other attenuating circuitry ? If this does make sense, what would the equation be (PS specs / cable attenuation / cable lenght) ?

 

Again, thanks Mario !

 

- Emilio



#7 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 05 March 2015 - 05:50 AM

Emilio, my suggestions come for a price: you must take a picture of Nina and post somewhere, so that I can admire her. I'll post a picture of my cat as well (if you've a Facebook account, we might get in touch and the photos are already visible).

 

I forgot the very most important thing to the list of tasks: create a prototype with 1-2 sensors in order to refine, adjust and possibly change something not working fine. This is, IMHO, a mandatory step for any decent project, but many people don't like it and prefer to go straight to the final stage. Although we may think and think again, there's no better way than make a reduced test and see what's going on...

So, please, grab a small breadboard like this one, and follow the prototyping approach first.

https://www.sparkfun.com/products/112

 

NOTE: I'll show you Sparkfun links just because it's a worldwide commonly known shop, but of course you may search for something equivalent/better. I mean that I have no reason to sponsor this or that Company.

 

Well, I though a little more about the wiring and how to reliably interface and it came in my mind a pretty simple, safe yet cheap way to connect them all: optocouplers.

I'd pick a couple of those for a test, just to understand pros and cons:

https://www.sparkfun.com/products/9118

You could also grab this one, which is quad and cheaper, but comes without PCB. If you aren't scared to put your hands on resistors and so, favor this one!

https://www.sparkfun.com/products/784

 

The optocoupler is kinda Columbus' egg: it allows to use a normal PS for the sensor side, but completely insulate the N side. Even in case of an hazard or so, the N will be safe. The cable is also a simpler choice: a RG59 is too much. Just search for a decent alarm cable (I don't know the price), because you need THREE wires: ground (the shield), +V and output.

An example: http://img.diytrade....Alarm_cable.jpg

 

At this point, the PS could be a normal +12VDC (rated for 1-3 Amps) or, if you like, you may also grab an old laptop PS, which should be a 19VDC 3A or so. Don't get crazy for searching something more complex.

Upon the chosen PS, the optocoupler's resistor will be calculated accordingly, otherwise the embedded LED will fry.

 

Once you have an optocoupler (=OC) as insulator, the N side is a walk in the park.

The OC output is just a transistor which "shorts" upon the paired LED will light. You could wire the OC's emitter to the ground, and the collector directly to any N input. Bear in mind that you need a pull-up resistor, otherwise there would be no activity.

 

Here is the trickiest part...

The sensor's specs say that it toggles the output at a rate of up 60Hz (i.e. about 17ms). The problem is that you'll have 12 sensors, which asynchronically feed pulses tot he same N. Now, although 60Hz is perhaps an exaggerated value, you should consider a pessimistic context: let's say ALL the sensors at 20-30Hz. I found that a normal shower takes 15-20 liters/min. Think 8AM, when almost all the apts are taking showers.

So, the N will face an equivalent pulse rate of 200-300Hz, that is an interrupt every 3-5ms. And probably it has to manage other things...

 

That's because I though there would be a "software" problem more important than the hardware one.

My suggestion (just brainstorming, as I were doing that for my condo) is using an "Arduino" pre-stage for the dirty work. In other words, the Arduino (any flavor you like) should be the real board facing the OCs, so counting all the pulses. Since its native elaboration, it won't have any problem on reliably counting all the pulses. Then, supposed the N for doing something smarter (such a web or so), the N could pull the data out the A via UART for example, which is trivial.

A bonus coming for free in this scenario is the relative reliability of the system in case of power failure. Of course there are no more pulses incoming, but it would be a dumb project if the counter values were lost due no-persistent storage. So, you might: back-up just the A with a small battery, or (easier IMHO) simply write the counter values in the EEPROM of the A. In the latter option, you should avoid to write the EE often, but it's no hard to add a small "voltage level detector" so that you'll write the data upon the power supply is dropping.

 

I'd say that it's possible that you need some small capacitor as well, but that's part of the prototyping.

 
Let me know what you think...

Biggest fault of Netduino? It runs by electricity.

#8 baxter

baxter

    Advanced Member

  • Members
  • PipPipPip
  • 415 posts

Posted 05 March 2015 - 07:32 AM

The ESP8266 WiFi modules might be a nice fit for your project.  When using the nodeMCU Lua firmware they basically become programmable wireless access points. The ESP-01 costs about $3 and exposes 2 GPIOs. The modules operate as a TCP client or server or both. Out of the box firmware uses an AT command set, but the Lua firmware offers much more and is very stable. They require about 240 ma when talking on the network and 70 ma when not. They are also 3.3V and not 5V tolerant. The disadvantage is that one needs to learn a bit of Lua, but there are plenty of examples in the nodeMCU forum link below.

 

GPIO2 supports an interrupt to count pulses for your sensor and the latest version of Lua has floating point math so you could directly compute the flow rate on each ESP module. Each ESP module also has its own MAC address and a chipID for identification, accessable via Lua functions. There is also a Lua repeatable timer alarm  with a callback function. This is where you could do your calculations and send the flow rate with an ID every X seconds via TCP or UDP.

 

The range in open air has been reported as 366 meters with the PCB antenna. This, however, is optimistic in the real world. I have an ASUS RT-n66U router and about 40 feet away from it, through 2 walls and a floor, a laptop shows 5 bars for the network SSID. For an ESP under the same conditions, the ESP broadcast SSID shows 2 bars signal strength. Given your longer distances, you might need to add a wireless extender to the mix.

 

If you use them behind a wireless router, each of the modules can obtain an IPaddress with with Lua code like the following: (Lua has a file system and a file is executed with dofile("myfile.lua")


-- File name: init.lua
print("set up wifi mode") 
--this is sent back to serial terminal if connected, otherwise does nothing
wifi.setmode(wifi.STATIONAP)
wifi.sta.config("ret13x","XXXXXXXXX")
 --here SSID and PassWord should be modified according your wireless router
wifi.sta.connect()
tmr.alarm(1, 1000, 1, function() -- repeat function every 1000 ms
    if wifi.sta.getip()== nil then 
    	print("IP unavaiable, Waiting...") 
    else 
    	tmr.stop(1)
    	print("Config done, IP is "..wifi.sta.getip())
    	--dofile("yourfile.lua")
    end -- if
 end) -- function

The init code will run on a powercycle or soft restart. The dofile("yourfile.lua") above will run once an IPaddress has been obtained and this is where you could put your flowmeter stuff.

 

here are some links,

 

ebay seller (USA fast shipping)

http://www.ebay.com/...html?rmvSB=true

 

nodeMCU forum:
http://www.esp8266.c...wforum.php?f=17

 

nodeMCU firmware(see pre_build) :
https://github.com/n...odemcu-firmware

 

API instruction set:

https://github.com/n.../nodemcu_api_en

 

For development, I use LuaLoader and a PC console TCP client for testing networking:
http://benlo.com/esp....html#LuaLoader



#9 Emilio Pastore

Emilio Pastore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationSo Paulo, Brasil

Posted 09 March 2015 - 08:26 PM

Hey Mario !

 

Thanks for all the detailed considerations ! I've read it half a dozen times, and as I understood it, you suggested that we use Arduinos to fetch every... say, 4 apts, and then upload water consumption to the N, and then N sends it over the network. Did I get it right ? If so, summing up -and considering Ns are not that more expensive than Arduinos, what if we reduced from 6 to 3 or 4 apts for every N ? I would rather have a more... unified solution, you know ? Let's say, one N for every 4 apts, that way would each N be able to handle the worst scenario ? And then, maybe we could employ normal cabling and use N's own +5V and ground for each sensor...

 

Never suspected OCs such as this existed !

 

Are you building such a solution yourself ? Get in touch on FB, I'm "Emilio Pastore Jr" !

 

Baxter, man, thanks ! I'll check how this ESP8266 works, for sure. Thanks !

 

- Emilio



#10 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 10 March 2015 - 05:18 AM

Emilio, just got in touch with you on FB....

 

The Baxter suggestion is valuable, and follows the first one I gave you (scroll to the top). I don't know these ESP boards, so if I were in you I'd grab a couple in order to put my hands on. The price is almost irrelevant, and even in the worst case you may use them for another project.

The only problem is that the N has not a wifi shield, and you must add an external router, as Baxter pointed out.

That in case the wireless solution is acceptable.

 

If you want to pursue the wired solution, you'd need just ONE Arduino for all the apts.

All the 12 cables head to an OC, each one. The Arduino will face all the 12 OCs, then it exchanges data (e.g. via UART) with the N. Most likely, will be the N querying data to the Arduino, and not vice versa...that's for sake of simplicity.

 

Emilio, I believe it's up to you evaluate what's better for your condo.

Again, if I were in you, before starting with a very well defined solution, I'd make more than experiment. That without purchasing too much (useless) material.

 

Good luck!


Biggest fault of Netduino? It runs by electricity.

#11 Emilio Pastore

Emilio Pastore

    Member

  • Members
  • PipPip
  • 12 posts
  • LocationSo Paulo, Brasil

Posted 11 March 2015 - 02:37 AM

Thanks, Mario ! I'll purchase items to experiment with all these variations, and will report along the way.

 

Cheers !







Also tagged with one or more of these keywords: water, flow, sensor, distant

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.