RuggedCircuits

We've released a new shield, the Quick Shield, which is similar to the Screwshield but uses spring-clamp terminals that do not require any tools like screw terminals do. Fits very nicely on a Netduino, and we even have a picture!



Here is the product page

Question... What do you suggest I do to protect the light sensor from the rgb light's awesome brightness? It isn't too bad but the less interference the better.

The plane of the RGB emitter is higher than that of the light sensor so any interference will probably be mostly due to reflection from whatever is above the shield. Try to keep reflective objects away, or if that doesn't work perhaps glue in some cardstock around the LED or light sensor.

The SecretLabs.Hardware.PWM class gives you two methods: SetDutyCycle and SetPulse. If you create a PWM object using one of the Netduino PWM Pins, you can use SetDutyCycle to change the duty cycle from 0-100%.

OK, asking in a purely informational way, how would someone that just purchased a Netduino know this?

We are working on an "Introduction to Netduino" text... Should we make an online (HTML in addition to PDF) version as well?

Forget the text, start putting it online as you write it, print it off when it's done. Just 1 suggestion....

Hmm, could you tell me more of what you're looking at?

Would a C# wrapper around the InterruptPort give you what you needed? Basically, the wrapper would just take readings from the InterruptPort's event handler and build them into an Array of timings...

Here's the RC6 decoder by community member Phil... What do you need in addition to the timestamps he's using?
http://forums.netdui...-decoder-class/

Chris

See, this is where knowing more about the .NET code would have made me look a lot smarter I didn't realize that interrupts came with timestamps. Phil's code that you referenced above should work perfectly well on a Gadget Shield and no wrapper is needed.

However, my guess is that interrupts come with timestamps because the event handler, after some latency, takes a snapshot of the system time (stabbing in the dark here but that sounds reasonable to me). That should work perfectly fine for decoding IR transmissions where sub-microsecond resolution is fine, but an InputCapture class with single-cycle resolution (what is used on the Arduino for IR decoding) would be useful for other applications like accurate frequency counting. Certain sensors (I'm thinking light-to-frequency sensors like the TAOS series) encode their sensed values in frequency thus accurate frequency measurement is important, at higher resolution than event timestamps. Not important for the Gadget Shield, but something to keep in mind maybe for future development The more of the underlying hardware features of the AT91SAM7X512 you can expose, the more applications will be enabled.

Hmm, let me get more details on what you need here...

For the RGB LED, it looks like you're using digital pins 5, 6, and 10. The PWM on the Netduino drives all four of these--and then PWM feature to drive duty cycle is already in the firmware. What additional functionality do you need? The ability to change the frequency?

Where in the firmware? I looked for PWM code samples and didn't find any. Microsoft's .NET documentation site linked from your home page has no mention of PWM. Searching for PWM in your forums fails because search terms less than 4 characters are rejected. I looked in the source and all the PWM functions seemed to be stubs. I apologize but coming from the Arduino world the C#/.NET model is still very foreign. Please please PLEASE come up with something like this to help us Ardufolks out:

http://arduino.cc/en...erence/HomePage

And code samples wouldn't hurt either Not in the forums...on the web site.

As for the IR transmitter, the upcoming v4.1.1 release will allow you to set the low-level PWM frequency (based on a standard divisor of the 48MHz MCU clock speed) and then set custom intervals/periods for PWM square waves. Is this enough for what you need to do--or do you need something where you can submit a byte array and then have a sequence of pulses sent with different periods? A constant 38 KHz signal with 50% duty cycle will be easy with 4.1.1 -- but I want to see what else you might need here...

Chris

Well, the more functionality the better (the byte array thing would be cool!) but simply being able to generate 38 kHz 50% duty cycle pulses is enough. IR transmitters don't change state faster than a couple of hundreds of microseconds so low-level hardware support isn't necessary for state changes, just 38 kHz square wave generation. Looks like 4.1.1 will at least make IR detection/generation possible using interrupts instead of input capture (crossing my fingers...as I'm not sure what the resolution and/or latency of DateTime is compared to actually reading a hardware timer/counter).