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.

Stefan W.

Member Since 19 Jun 2011
Offline Last Active May 30 2012 02:30 PM
-----

#27445 Electronics 101 book recommendation

Posted by Stefan W. on 17 April 2012 - 09:10 AM

Also not a book, but for me, when I started with electronics, a simulator like LTSpice has been invaluable - you can try stuff without frying things ;) i.e. test if your transistor switch works and how much current is drawn from the microcontroller etc. But that's just in addition to a book, it obviously does not teach you physics :)


#21406 Forum topics color

Posted by Stefan W. on 06 December 2011 - 08:41 PM

Well, colors are not absolute, especially on LCD screens colors depend a lot on the screen - the links are readable for me (although i'll say that the choice is suboptimal and a darker color would be better)


#19940 Code fails when battery powered.

Posted by Stefan W. on 28 October 2011 - 09:24 PM

7.2V is below the specs - the netduino asks for at least 7.5V as unregulated input (which means in case of battery you should aim for more since the voltage drops as the battery discharges). This might be the cause for your stability issues ...


#18740 i2c voltage

Posted by Stefan W. on 04 October 2011 - 07:23 AM

You have only three choices:
make all the devices working under the same supply;
use two different I2C buses for each supply;
insert a double bidi-level adapter to decouple the different supplies.
Of course, I suggest to follow the first one, which is the simplest.


I disagree here, it's not the simplest simply because there are devices which do use different supplies ... but a bidirectional level adapter is pretty simple, have a look at the tx line from http://www.sparkfun....nverter-v10.pdf - two resistors, one mosfet, and you're done (note the resistors act as pullups, so if you already have pullups on both sides - as you have - you can ditch them, so your level converter becomes a single transistor.
  • CW2 likes this


#18240 High resolution light measurement

Posted by Stefan W. on 20 September 2011 - 01:11 PM

No, the custom firmware just increases clock resolution, it does not make code run magically faster. Seriously, you are wasting your time. I don't get why you think this is a reasonable goal ... you will not be able to count pulses coming in at 1mhz in managed code. Why are you so fixated on directly interfacing this sensor with the netduino? As was already suggested in the beginning: Use another sensor, e.g. with a phototransistor or photoresistor (it does not get much cheaper or easier than this) or use another MCU to do the counting for you.
  • CW2 likes this


#18224 High resolution light measurement

Posted by Stefan W. on 20 September 2011 - 05:35 AM

Not wanting to spoil something, but be careful. It's not "so close to working" - you are still more than an order of magnitude away from your target (500khz). The trick from CW2 is an interesting one, but as you've seen there are limitations - it builds on disabling the interrupt handler before the queue fills up, which it can't if the frequency is very high (as you've seen) and which gets also harder should the GC decide to kick in before the handler start and the removal of the handler. Also, a limitation of that approach is that you only sample for a short time, so you're susceptible to "noisy light" (if the sensor is fast enough for that, didn't check that).
  • CW2 likes this


#17364 Input Debounce

Posted by Stefan W. on 31 August 2011 - 10:32 PM

In case someone is searching for this in the future, this is the very simple software glitch filter i talked about:
    public class Program
    {
        private static readonly InterruptPort Button1 = new InterruptPort(Pins.GPIO_PIN_D0, false, Port.ResistorMode.PullUp,
                                                                Port.InterruptMode.InterruptEdgeLow);
        private static DateTime Button1LastPushed;

        public static void Main()
        {
            Button1.OnInterrupt += Button1_OnInterrupt;
            // ... main loop
        }
        private static void Button1_OnInterrupt(uint data1, uint data2, DateTime time)
        {
            // glitch filter. events within 50 milliseconds of the first event are discarded
            if (Button1LastPushed.AddMilliseconds(50) > time)
                return;
 //         Debug.Print("Button 1 Interrupt");
            Button1LastPushed = time;
            // actions on interrupt here
        }
    }

Also, Mario, i definitively did read an application note for a microswitch that strongly advised against putting a "naked" capacitor across a switch because of damaging effects. If i can turn it up again (I don't recall where I found it ...) i'll link it here.

Also for the record, if someone wants to do the hardware debouncing "cleanly" it should be probably done like in this article (german text, the schematic should be understandable though) using a RC filter with a schmitt trigger. However, as software debouncing is so easy and doesn't require additional components, i just do that :) Another useful bit of information in that (german) article is that switches usually bounce for up to 10ms, so the time constants for the debouncing (software or hardware) should be chosing according to that (and no human operates a switch 100 times a second anyway)


#17284 Input Debounce

Posted by Stefan W. on 30 August 2011 - 06:45 PM

A capacitor across the switch works, however keep in mind that this means that by pressing the switch you are shortening the capacitor, which can lead to high currents through the switch. This effect can (does not have to) lead to damaged (stuck in "on" position) switches (won't likely happen the first time you try it, however if this is something that should live a long time, you might see this), you can prevent that by putting a resistor in series to the capacitor to limit the current (100 ohm should do fine). A software filter is what i'm using - i store date of the last edge, and if the timespan between the last date or the current date is too low, i discard the event. What the glitch filter does is polling multiple times, i don't know over which time domain, maybe it's too short.


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.