Mario Vernari's Content - Netduino Forums - Page 2
   
Netduino home hardware projects downloads community

Jump to content

  2. → Mario Vernari's 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.

Mario Vernari's Content

There have been 49 items by Mario Vernari (Search limited from 17-June 23)


By content type

See this member's


Sort by                Order  

#64492 How to interface and measure a capacitive sensor?

Posted by Mario Vernari on 12 November 2015 - 07:56 AM in General Discussion

I never said the circuit is not working: I've said that's very critical. I mean that if you're going to create more-than-just-one circuit, you'll have to re-tune each one, because the inherent error, tolerance and whatever will lead to (even to) dramatic different results.

 

A typical resistor is given at 5%, but you might find at 1% as well. The capacitance of a comb plate is due to many factors: exposed surface area, dielectric, and distance. Thus, upon a temperature range of, let's say, 0 to 40°C, you'll have a very different C, despite the same rain fall.

 

Have a try, and you'll face the problem. However, if you're going to create a single one, okay, you can tune it perfectly, table its trans-characteristics on software and plot a real behavior upon rain and temperature.

 

I really didn't want to fire discussions: just to alert other readers that the problem isn't simple!

Cheers



#64472 How to interface and measure a capacitive sensor?

Posted by Mario Vernari on 10 November 2015 - 08:11 AM in General Discussion

Fine!

Just a word about the oscillator...

The frequency of that circuit is something like: f=K/(R*C), where K is a constant.

The relevant thing is that a capacitance-delta is behaving in a hyperbolic way to the frequency. That is, even a small fluctuation of the capacitance (or resistance) will actually produce a huge shift of the expected frequency.

You should avoid coupling high R with small C: leave the oscillator running fast and count how many pulses it feeds in some "capture" input. Any cheap *duino is able to count MHz without any problem.

 

We don't use Davis' products. Our rain detector is basically a water flow meter. However, that's *not* a product of our labs: we just use it.

Cheers



#61480 Help me out with SPI Please.

Posted by Mario Vernari on 03 February 2015 - 06:31 AM in Netduino 2 (and Netduino 1)

The Netduino 2 Plus had some issues related to the SPI, and should have been fixed with the latest firmware.

That was sure for the Netduino Plus 2: not sure about the simpler Netduino 2.

 

Those issues were mostly related to the worse SPI hardware logic in the ST chip, than the older Atmel.



#63724 Gameduino 2 For Netduino

Posted by Mario Vernari on 31 July 2015 - 05:47 AM in Project Showcase

Were you able to display images?

I stopped my porting because of that...



#61606 Finding bytes in byte array

Posted by Mario Vernari on 13 February 2015 - 11:31 AM in Visual Studio

Aveiro, Portugal! My wife was there once, and told me it's an awesome city!

 

As far I know, there's no any immediate way to achieve kinda "Array.find", but of course you can create it. If you were using the regular (i.e. desktop) .Net Framework, you could use Linq, which allows to "compose" whatever function you want with ease.

For the Netduino, you can use something like that:

 

                var source = new byte[] { 00, 22, 33, 44, 0x55, 55, 66, 77, 88, 99, 10 };
                var index = Array.IndexOf(source, 0x55);
                var targetLength = source.Length - index - 1;
                var target = new byte[targetLength];
                source.CopyTo(target, index + 1);

Hope it helps.

 

 

 



#61635 Finding bytes in byte array

Posted by Mario Vernari on 17 February 2015 - 05:16 AM in Visual Studio

Hmm...but what do you mean as "the first one"? That is, what's the expect "end of block"?

Looks like you have to deal with a kind of pattern, and you have to extract all its occurrences...

 

Anyway, before knowing what's you answer, you may also consider another way to deal with such a situations. It may sound as an overkill, but when you have to deal with data extraction (in general), composition, and others function to/from a byte array, the below one is maybe very neat.

http://cetdevelop.co...eArrayReader.cs

(and related classes)

 

It's basically a bunch of classes for byte-array manipulation: reader, writer, data extraction and insertion, etc.

Please, note that the library is a bit "aged" (about two years), but should be working fine with the latest firmwares.

Cheers



#61910 External switch

Posted by Mario Vernari on 20 March 2015 - 04:53 AM in Netduino Plus 2 (and Netduino Plus 1)

I just tried for you...

 

explosion-of-fire.jpg

 

 

In theory, your circuit should work, but the problem is that the Netduino does not offer a "pull down" feature.

Simply invert the logic, and wire the button from the input to the ground, then set the "pull up". This is also the preferred way to connect a pushbutton/switch because the ground is everywhere but the +3.3V not.

 

Remember, if you try to register the button activity via interrupt or so, you may easily experience "bounces". That is, when you press the button, you'll see several unexpected "on/off" events, which are undesired. Those bounces are due to the mechanical structure of the button.

There are two ways to solve this problem:

  • add an external capacitor (e.g. 100nF or more, not critical) across the button. This is an "hardware filter".
  • do NOT use the interrupt, and implement a "digital filter" by sampling the state of the input periodically, then detect the stable state. In this case you won't need a capacitor.

Bear in mind, for a quick test on a breadboard, there's no problems at all. Once you'd create a reliable definitive circuit, I'd use both the filter ways: capacitor and sampling. Bullet-proof!

 

Good luck!



#61113 D13 - LED On Screwshield- Issue with SPI?

Posted by Mario Vernari on 01 January 2015 - 10:26 AM in Netduino Plus 2 (and Netduino Plus 1)

Hello Chris, and have a happy new year, as well as your family.

 

The led shouldn't be an issue, because the current flowing is low. I'd recommend to keep the SPI speed relatively low, let's say 1-2 MHz max. Also try to keep the SPI wiring short (6 inches max) and, possibly, of the same length (SCLK, MISO, MOSI, SS).

The general rule is: the slower the signals are, the easier will be everything work fine.

 

Have a nice holidays.

Mario



#61115 D13 - LED On Screwshield- Issue with SPI?

Posted by Mario Vernari on 01 January 2015 - 04:03 PM in Netduino Plus 2 (and Netduino Plus 1)

Very appreciated, thanks.

 

Just a small note more, although maybe you won't face this case.

You know, the SPI must be "opened" (enabled), and of course can be "closed". When it's closed, the D13 pin (as well as the others involved) can be used as a normal I/O. That is, whenever you set that pin as "input-with-pullup", the led+res act instead as a pull-down. Thus, you should "avoid" this (let's call) collision, because the resulting (floating) voltage may be at an intermediate level, which results in an unstable read.

 

Again, just an alert than a concrete issue. However, if the led+res were connected to the I2C pin that would have been a very annoying trouble, because I2C leverage the pull-up resistors.

 

Hope it's clear.

Cheers



#61917 Controlling Multiple I2C devices

Posted by Mario Vernari on 21 March 2015 - 05:16 AM in Netduino Plus 2 (and Netduino Plus 1)

I never tried I2C on Netduino, but it sounds like other ports, which have to be disposed to be reused. This is surely a elegant yet reliable solution, but -agree- not so efficient.

Did you try to swap the configuration instead of creating many instances of I2CDevice?



#61931 Controlling Multiple I2C devices

Posted by Mario Vernari on 23 March 2015 - 08:05 AM in Netduino Plus 2 (and Netduino Plus 1)

Tim, I'm 100% with you, but abstraction comes at a cost and Micro Framework tries to solve high-level problems on (relatively) very poor hardware.

Swapping the config is surely cheap in term of computation, but of course leaks in term of abstraction. However, you might think the I2Device as the "I2C logic driver", and the various configs as "instances" of this driver. Such a viewpoint comes maybe a little closer to the abstract-hardware model.

Good luck!



#62172 C# help

Posted by Mario Vernari on 17 April 2015 - 04:22 PM in Visual Studio

Uhmmm...

The conversion is rather trivial:

ushort zz = (ushort)System.Math.Tan(c1AngleX);

However, I don't think the "ushort" is a convenient way to store the tangent values, unless they fall with a restrict angle interval.

Moreover, the "ushort" isn't a nice (nor common) type: the "unsigned" types lead to mistakes, unless you check for under/overflow.

Why don't you use "float" instead of "ushort"?

 

On the regular .Net (desktop) framework I'd use "double" instead of "float", but here you have a tiny board and the resources (CPU and RAM) are precious. Double takes 8 bytes and Single (float) takes 4. Furthermore, the float math should be natively supported, but the "double" not.

 

Cheers



#60726 Azure Veneziano

Posted by Mario Vernari on 16 November 2014 - 04:11 PM in Project Showcase

Second part is on...(scroll to top)



#60873 Azure Veneziano

Posted by Mario Vernari on 05 December 2014 - 07:52 AM in Project Showcase

Many thanks everybody, but that's only the beginning!

 

I'd like to create something funnier, so I'd invite anyone is interested to join.

I know that many of you like robots, buggies, Legoes and other evil machines. The idea is to "connect" those toys to the cloud (for a limited time), and leave them to interact by themselves.

 

Feel free to suggest what you think and share your opinions.

Have a nice weekend!

Mario



#61093 Azure Veneziano

Posted by Mario Vernari on 29 December 2014 - 10:49 AM in Project Showcase

Seeedstudio LinkIt ONE board porting completed...(scroll to top)



#60860 Azure Veneziano

Posted by Mario Vernari on 04 December 2014 - 08:08 AM in Project Showcase

Third part completed...(scroll to top)



#61613 Another custom PCB based on Netduino Plus 2

Posted by Mario Vernari on 15 February 2015 - 06:33 AM in General Discussion

That's very nice, but...some questions:

  • where are the I/O pins (or else) for sensors and related?
  • the Wi-Fi is an option/alternative to Ethernet, or is unavailable?
  • could you post an image of the bottom view?

Congrats so far, and good luck!



#61772 3V3 to 5V SPI link

Posted by Mario Vernari on 04 March 2015 - 04:27 AM in General Discussion

Fine.

Just forgot:

  • connect the ground between the two boards (EVB and Netduino) before any other wire.
  • keep the wires as shortest as possible.

Have fun.



#61757 3V3 to 5V SPI link

Posted by Mario Vernari on 02 March 2015 - 04:49 AM in General Discussion

1)  What's a good way (following GEP of course) to deal with the 5V / 3V3 difference? 

 

What is "GEP"?

As for what is supplied by the HC11, the Netduino (by means the MCU) is 5V tolerant so there's no problem.

As for what is supplied by the Netduino (3.3V), the "HC" voltage levels (68HC11) are able to recognize the logic high at 3V: again, no problem.

 

2)  Is it true that the nd+2 can't operate as an SPI slave? 

 

Yes, that's true. You can only try using the Netduino as master and the HC11 as slave.

 

3)  Anyone know of a similar project that I can reference?

 

 

I'm not aware about similar projects, but (under the 2' answer context) should be pretty similar as you connect an Arduino.

 

Question: why don't you use the UART? It's much more convenient if you want exchange data between MCUs...



#61828 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 10 March 2015 - 05:18 AM in Netduino Plus 2 (and Netduino Plus 1)

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!



#61778 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 05 March 2015 - 05:50 AM in Netduino Plus 2 (and Netduino Plus 1)

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


#61774 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 04 March 2015 - 05:40 AM in Netduino Plus 2 (and Netduino Plus 1)

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



#61763 12 water flow sensors 160ft away from N+2

Posted by Mario Vernari on 03 March 2015 - 05:37 AM in Netduino Plus 2 (and Netduino Plus 1)

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.



#61937 0-5V input, 0-20mA output via NDP2

Posted by Mario Vernari on 24 March 2015 - 01:10 PM in Netduino Plus 2 (and Netduino Plus 1)

Very nice, congrats!

To who's reading, this circuit may be useful for current-loop circuit, that is "sending" an analog signal over a very long cable. The more straightforward and intuitive voltage-way leads to pretty high errors.

 

You should have to post it in the "showcase" category: it seems more appropriate.




  1. Netduino Forums
  2. → Mario Vernari's Content
  3. Privacy Policy
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.