remotewizard

I'm finally taking Morse Code classes, trying to learn my dits and dahs.  So I naturally poked around the various Morse projects in the forums.  But now I have a more nuts-and-bolts kind of question.

I purchased a nifty antique telegraph sounder (basically a relay, when the clicking and clunking represents Morse dits and dahs).  There are several projects online to interface such a sounder with a *duino or a Raspberry Pi (such as http://sigalonhowtod...since=318825083).  What I'm looking for is the best design that will protect both my Netduino and my antique sounder.

The sounder has a 4-ohm coil, and (according to http://www.morsetele....org/wirechief/) was designed to run off an approximately one volt 'Gravity Cell.'  The same article suggests running the sounder off a D-cell battery (current draw estimated at 200 mA).

As I said, there's a lot of suggestions online for how to connect the sounder.  Most use a simple transistor to switch a 5 volt power supply to energize the sounder's coil.  This seems a bit high to me, but since the sounder is built like a concrete bulldozer, I could risk it.

More to the point, what kind of snubbing configuration would you recommend to protect the Netduino from induced EMF.  Most folks seem to use a simple diode in parallel with the coil (which would shunt the induced current safely to ground).  Some add an LC circuit; a few suggest replacing the simple snubber diode with two Zeners (diodes wired in series, cathode-to-cathode, then attached in parallel with the coil).

Since I don't want to damage my sounder unnecessarily, and it's pretty much equivalent to a big low-voltage relay, I figured I'd ask the experts for the optimal solution.

Sorry to be so long-winded!

Work continues (slowly!) on my Nixie clock project.  Currently, it includes the following parts:

• a conventional Windows service (running on an existing always-on PC) that periodically obtains the local weather forecast from Forecast.io, parses the results, and posts the one-word forecast for the next day to Xively
• one (so far) Electric Imp with an Adafruit AM-2315 I2C temperature/humidity sensor, which will eventually reside outdoors; this periodically posts the current temperature and humidity to Xively
• My Netduino (attached to an Edimax BR-6258n for WiFi access) running an MQTT client, subscribing to the forecast, temperature and humidity info on Xively.  When new data is received, the appropriate global variables are updated and action taken 
• a lookup table on the Netduino that converts the one-word forecast ("snow") to a color ("white"); think the Gulf Building weather beacon in Pittsburgh, where lighting on the the top of the building changes color with the weather forecast.
• currently, a tricolor LED to display the forecast color.  In the future, when I install my four DFRobot Nixie modules, I'll control the background colors of those instead
• a RTC synced to NTP (currently by the Netduino), with an automatic adjustment for Daylight Savings time
• finally, the four Nixie tubes which will display the clock time on request (I'll normally keep the neon part powered off, to increase the tube's lifespan.

It seems like a waste of the Netduino to run as a simple realtime clock, constantly updating the Nixies via SPI; I'd like to eventually add additional functionality to the Netduino (e.g. local room temperature sensor, smoke detectors, etc.) and don't want to burden the Netduino with gruntwork.  Would I be better off to move the strictly clock-related functions off to something like an ATTiny (or dedicated time clock chip), reserving the Netduino for more complex tasks?  Or am I worrying needlessly (as I often do)?

Did any of this make any sense at all?

Sorry if this has been covered before!

Microsoft is rolling out a new 'Intelligent Systems Competency' for partners sometime in Q12014.  From the announcement:

"As an extension of our cloud commitment, the Intelligent Systems Competency will also launch to enable partners to capitalize on the fast growing opportunity related to the "Internet of Things," and other competencies will have requirement updates to account for new exams to ensure you are confident selling and implementing the newest versions of Microsoft products and services. "

Right now, everything points to the Windows Embedded folks. Might there be a role for .NET MicroFramework (and our beloved Netduino) as well?

I have one of the typical cheapo four-module 7219 LED matrices (e.g. four panels of 8x8 each, with power, ground, clock and cs daisy-chained; each module after the first gets it's DIN from the previous DOUT).  I downloaded the current Max72197221.cs from Netduino Helpers, and was able to send letters and patterns to the first module.  So far ,so good.

However, according to the 7219 datasheet, I should be able to address each of the subsequent modules by sending a No-Op after each row of data (the four 7219 chips acting as a shift register) for each module I want to move to the right.  But sending what I think is the right value to the matrix doesn't work.

For example, I changed the original Max72197221.cs code to define SpiBuffer as ushort[2], and modified the Write subroutine as follows:

protected void Write(byte register, byte value) {

SpiBuffer[0] = register;

SpiBuffer[0] <<= 8;

SpiBuffer[0] |= value;

SpiBuffer[1] = (byte)RegisterAddressMap.NoOp;

SpiBuffer[1] <<= 8;

SpiBuffer[1] |= 0;

Spi.Write(SpiBuffer);

}

But the display doesn't - well, display.  It also doesn't work when defining SpiBuffer[1] simply as 0 (without all the bit-shifting nonsense).  Can anyone help me spot the flaw in my logic?