Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at 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-October 20)

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 40C, 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!


#64472 How to interface and measure a capacitive sensor?

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


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.


#64465 How to interface and measure a capacitive sensor?

Posted by Mario Vernari on 09 November 2015 - 08:27 AM in General Discussion

I don't think you'll get decent (i.e. accurate) results with a simple oscillator: the capacitance is pretty small and also spans along a short range. Moreover, as you correctly pointed out, the Netduino itself won't be able to capture a so high frequency, although I believe you'd have hard time to read it with an Arduino-like board.

Such a sensor is surely cheap but much reliable: it's just a comb-shaped pair of plates, which offers a different electrostatic behavior upon the quantity of water on it...

Water? how this water is composed? what if the rain is mixed with sand, since often we experience red-rains due the African desert wind?


I don't know if that might help you, but we faced the generic "weather" station a while ago, for real cases, not just hobby/home purposes. We've a complete set of sensors for accurate telemetry, even without TCP/IP layer and for pretty long distances (up to some km).

Have a look  here, just for your information...




#64340 LCD-Boost library for Netduino

Posted by Mario Vernari on 20 October 2015 - 12:00 PM in Project Showcase

Sorry for being in late.

The boost library leverages its performance by a hardware trick: you must use it, otherwise the library not only won't help you, but even won't work at all.

The Stefan's library is more intuitive and maybe more straightforward to wire, but you can't get it faster because the interpreted framework. That's because I used a hardware solution as a workaround.


From your photo I realize that you already finalized the hardware. I believe there's no clues for pushing the speed greater...


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

#63471 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Mario Vernari on 13 July 2015 - 04:25 AM in General Discussion

This would support dynamic loading and also component evolution in a very clean and neat way, with relatively little overhead. But on the other hand, if a static system is accepted, still a lot of overhead can be shifted to build time, thereby allowing to reach much smaller microcontrollers than the one of a Netduino - and this approach would create less confusion regarding the positioning of NETMF versus the IoT version of Windows.


A COM-based evolution of NETMF was actually considered for the future of NETMF. But the focus for Llilum is to reach smaller microcontrollers. It should also allow for a high degree of hackability, without the need to combine different languages.


Of course a static binding would be simpler, but...bah...I don't know pros/cons...maybe it's me having an obsessive eye toward the pluggability.

What do you mean about "less confusion" between NETMF and Win-IoT?


Really was considered a COM interface for MF?


Finally, I agree on the "high-degree of hackability", but whenever you need some hires capture/reproduce signal, the GC makes all that unreliable. IMHO, it should be designed some "sandboxed" section dedicated to the RT drivers: a very specific extension with RT capabilities.

Whether the code is interpreted or compiled, should not matter: the sandboxed code has to behave always the same.



#63460 Introducing Llilum, the native-compiled (NETMF) proof of concept

Posted by Mario Vernari on 12 July 2015 - 10:50 AM in General Discussion

Hey Paolo,

With a native-compiled proof of concept like Llilum, you still have real-world issues like garbage collectors to deal with. There is a possibility that a GC-less application could be built, and there is a possibility that a GC which honors determinism around interrupts is possible. But to be clear none of these are announced features--or necessarily on the roadmap. It's all very early still, and we're just super-excited for the new bits.



I think none would need (strictly-speaking) a Real-Time-Netduino, otherwise you'd opt for a different beast, and -yes- maybe programming in some native language.

Instead, I believe the typical req' of the Netduino user is the ability to interface with some I/O: that is, bit-banging, hi-res capture, etc.


So, all the Netduino would need is some hacky-ability to plug a native-coded section. Let's say the "Go" idea, but full-software solved.

I remember an user of this forum, who was very smart, and created kinda "hook" so that the regular C#-managed code ran together with machine-language bits of program.

I always thought that was the right direction although his own solution was actually too cumbersome to use.


Just think to an Arduino-sketch (better: template) against a bunch of Netduino APIs, and the result should be linked to the main app. Although a static linking would require way less resources, I'd rather look in the dynamic one: paying more, but the benefits are satisfying.

Maybe a tiny-tiny Windows COM interface or so...


My two cents...

#62468 Power Questions

Posted by Mario Vernari on 06 May 2015 - 04:06 AM in General Discussion

A diode is a semiconductor component which allows the current flowing only to one direction:

  • when drawn as a symbol, the arrow indicates the direction
  • when a real component, there's a striped which indicates the outgoing lead.

However, when the current is flowing there's a small voltage drop across the leads, roughly 0.6V (it's an exponential formula, though).


About what you want to do, consider the internal point where the power is needed: this point is Vin.


Suppose to feed the power through the barrel. Let's say exactly 10V, but there's a diode on the board (D_board), so the Vreg is expected to 10-0.6 = 9.4V. Everything's working fine.

There's a 9V battery connected with a diode (D_bat) to the same Vin point. Now, the voltage on the positive lead is 9V MINUS the voltage on the Vin is 9.4V, yields -0.4V which is lesser than the minimum required for the D_bat to allow the current flowing. That is, under these conditions the battery can't feed any energy, and all the power is given by the barrel.


Now detach the power barrel.

The voltage on the Vin pin WOULD drop to zero, but AS SOON the point falls below 9-0.6=8.4V, the D_bat begins to allow the current flowing. The battery now is the only one feeding energy.

Why 9-0.6=8.4? Because 9V is the battery voltage (on the positive lead) and 0.6V is the drop of the D_bat diode.


NOTE: I used 10V as the barrel voltage to emphasize the circuit's behavior. However, 10V is not a standard voltage for an adapter. If you have a common 9V adapter, you'll experience kinda "challenge" between the adapter and the battery: the one having the highest voltage will actually feed the board. Bear in mind that a new battery has typically a voltage slightly higher than the nominal, but decreases also easily.

I suggest to make some experiment, but if you want to be super-guaranteed there's no "challenges" anytime, just use TWO diodes in series for the battery. At this point the drop is 0.6+0.6=1.2 and the barrel should "win" all the times!


#62444 Power Questions

Posted by Mario Vernari on 05 May 2015 - 04:21 PM in General Discussion

The short answer to the first question is: yes, but...

The long answer is: there is the "Vin" pin on the header which is basically the same as the power barrel pin. However, you can't wire a battery directly to the Vin pin, but you must add a diode in series to the positive lead. The ground of the Netduino should be connected to the negative lead.


The second question leads to a simpler answer.

The current required by a Netduino may span from 50mA to 200mA: it depends on the model, on the state, on the hardware connected.

Then, check the nominal capacity for a 9V battery here:

Finally, divide the capacity by the current flowing.

Let's say you have a Zinc-Carbon battery (400mAh) and the average current for the Netduino is 100mA. You'll have 400mAh / 100mA = 4 hours.

Bear in mind that a more practical result would lead to the time halved or a bit more.


Good luck.

#62172 C# help

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


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.



#62169 Keypad Wiki Article Mentioned on Hackaday

Posted by Mario Vernari on 17 April 2015 - 11:40 AM in General Discussion

First off, thanks Mark for pointing the article: I missed it although I check Hackaday daily.

Secondly, I'm happy twice, because it is rare to see something about on Netduino (NETMF in general) on Hackaday.

Will be that kinda "divine-sign" that something is gonna changing?


Have a nice weekend everybody!

#62067 Will this power supply work?

Posted by Mario Vernari on 09 April 2015 - 05:46 AM in Netduino Plus 2 (and Netduino Plus 1)

Let's say that 6V is borderline: it's barely above the ability of the Netduino regulator. By the way, +12V isn't too much, unless you pull too much current from the Netduino regulator.

I personally suggest any good (linear) regulator which outputs from 7.5 to 12V. However, 9V is perfect.

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

#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!

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

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





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!

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


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:

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!


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

#61772 3V3 to 5V SPI link

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


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.

#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):
  • 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.

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

#61707 Serial ports and Bluetooth I/O and GPIO output

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

If the characters arrive with a relative "distance" (in terms of time) each other, the original snippet should be good. I wondering how could happen whenever a long stream of bytes arrive at once.


At this point, where's the problem on inserting the I/O control inside the loop?


BTW, I believe the Netduino could be a bit touchy: remove the "until the end of the Universe" comment, then re-run the program...that might yield a way better result.



#61705 Serial ports and Bluetooth I/O and GPIO output

Posted by Mario Vernari on 24 February 2015 - 04:50 AM in Netduino 2 (and Netduino 1)

Hello Who.

Instead of using the event, fire a thread endlessly running which consumes the bytes incoming (basically the event handler content).

I think should be more reliable as timing, because the events are dispatched sequentially, but there's no guarantee of accuracy and you may experience a messy stream...


Anyway, I'm not sure to understand what you want to do.

Do you want the Netduino:

  1. receive a message from the serial, then
  2. process the message by de/activating one or more I/Os, then
  3. send an answer out on the same serial

Is that what you want?

#61690 Netduino MiniSumo robot

Posted by Mario Vernari on 22 February 2015 - 04:54 AM in Project Showcase

It's on the 11th and 12th of april this year.


I won't be able to go this year, but hopefully next year.


Oh!...My chance would be near the end of April, not before.

Definitely better the next year, so I'll take the chance to visit the city once again (really worthwhile).


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.