Home    Bloggers    Messages    Resources
Tw  |  Fb  |  In  |  Rss
Comments
Oldest First   Newest First   Threaded View
Page 1 / 2   >   >>
Rich Quinnell
Rich Quinnell
4/13/2012 7:34:04 PM
User Rank
Blogger
In with the old, to help out the new
Curt, very clever use of an old but reliable technology. I would never have thought of using Morse Code to communicate to an MCU.

I was looking forward to having my son learn Morse in Scouts, but it seems that they dropped that and semaphor some years back. Guess BSA figured that with cellphones so widespread there was no need to learn another form of long-distance communications. Sigh.

I once adapted older technology for a new purpose back in the 70's. I needed a high speed digital recorder but the wideband multi-channel analog recorders available to capture high-speed parallel digital signals were not rugged enough to survive use in a submarine (which is where the data needed capturing). I created an interface that allowed a VHS recorder to capture the digital signals onto videotape, then created a playback decoder that would recover them (this was streaming data; I didn't need to worry too much about occassional loss). I then told the submarine personnel that they could use the VHS to play their own tapes if they wished when it was not being used to capture data. They handled it much more carefully than they did the fancy equipment.

50%
50%
antedeluvian
antedeluvian
4/13/2012 8:47:34 PM
User Rank
Blogger
RAM for PROM
Years ago, when the microcontroller firmament was still being formed (1978), I had to develop a low power micro based project. We had CMOS processors (RCA 1802 and Intersil IM6100), but no CMOS (E)PROM of any type. We only had 256x4 CMOS RAMs and newly out, 1Kx8 bipolar PROMs. There were MOS EPROMs, but they were multi voltage and so, unsuitable. My solution was to use the same approach used in core memory of the mainframes of the day. The code was partitioned into blocks. The PROM would be powered up, a block of code was shifted into RAM, the PROM turned off and then the code in RAM was executed while all the power stuff was turned off. When there was a transition in the system process, another block would be loaded.

Apropos of the thread on development kits- we actually had to build the PROM programmer using logic. The micro had been hand coded in assembler and loaded byte by byte in hex into the (self made) development facility. Once finalised the program had to be re-entered byte by byte into the programmer and then the device programmed. Obviously we never had the algorithm set up properly because under temperature testing one of the fuses in the PROM regrew and the unit stopped operating correctly. That was kind of difficult to resolve!

50%
50%
antedeluvian
antedeluvian
4/14/2012 6:51:29 PM
User Rank
Blogger
Books
I have just read two books that dealt with Morse and telegraphs.

The first was "The Victorian Internet" by Tom Standage and covered the whole telegraph age. I found it good, if a little shallow.

The second was called "Degrees Kelvin" by David Linley which dealt with the life of Sir William Thomson, Lord Kelvin. In describing his extensive efforts in the telegraph field it also covered most of the ground in "the Victorian Internet". Kelvin was involved in far more than just the telegraph though and so this is a far more detailed book, one one that was more to my taste.

Both however, are reccomended.

50%
50%
Curt Carpenter
Curt Carpenter
4/15/2012 11:27:51 AM
User Rank
Blogger
Re: Books
Thanks for the titles Aubrey -- I've noted them in my diary for future reading.  Right now (for reasons that are a little mystifying even to me) I've been really busy and have been investing my reading time in "Urban Planning" material:  what makes a city "alive?"   It seems there's something of a revolution going on in this field, with old models giving way to some new (and pretty radical) ideas.  A question in the back of my mind is "what might our new technologies contribute to this New Wave?"

 

50%
50%
MicroPower
MicroPower
4/15/2012 8:02:22 PM
User Rank
Program Manager
Morse project
This reminds me of an earlier project I did quite sometimes ago in college. Out of curiosity, I tried to create a Morse code generator that transmitted Morse codes using a simple push button. In order to prove it worked, I used one of the local radio station frequency then listened to that same radio station. And it worked, even though I don't know how far it transmitted and gave annoyances to other listeners since I believe mine is not a strong transmitter after all. But it was only used a couple times since I don't want to be bothered by the FCC for any reason :)

However, SFB Morse did have a quite amazing idea that was quite useful in the 20th Century. I wonder if it can be kept useful during this 21st Century with all these new gadgets based on powerful MCU.

Nevertheless, I also wish Mr SFB Morse a Happy Birthday.

50%
50%
Curt Carpenter
Curt Carpenter
4/16/2012 10:20:26 AM
User Rank
Blogger
Re: Another Morse project
That reminds me of a story...

Years ago, I was working with a team that was developing a family of high-speed CMOS logic.  CMOS logic at the time was (and probably still is) notorious for generating BIG Vdd power transients each time it makes a 0 ->1 or 1 -> 0 transition. 

To try to convince the design guys that this was a problem, I took a hex inverter and connected it up as a simple, pretty high frequency ring oscillator.  Instead of the usual decoupling capacitor from Vdd to ground, I cut a quarter-wave whip antenna (about 10cm long) out of some hook-up wire and soldered it to the Vdd pin of the inverter package.  I cut another whip the same lenght and connected it to a scope probe located at the other end of our building.  This was a dandy transmitter that did a nice job of sending Morse over about 100 meters with no difficulty :-)  (The FCC did not seem to notice, but might have if we'd made a few hundred thousand of these transmitters -- which we sort of did, now that I think about it -- but never mind.)

I'm convinced that Morse's invention is still relevant, even in today's technology, as a man- and machine-compatible communications protocol that a) can be implemented for less that fifteen cents on any MCU, b) using just one I/O bit, and c) can give you a fully-capable human command and control interface with a very small memory footprint.

(I did know a guy once that could listen to his telephone modem and "read" what was being sent -- but that's another story...)

Cheers!

Curt

50%
50%
Jim Turley
Jim Turley
4/16/2012 1:40:03 PM
User Rank
Blogger
Re: Books
Coincidentally, I just started reading "The Victorian Internet" last night. Very readable.

50%
50%
Nemos
Nemos
4/16/2012 6:20:35 PM
User Rank
System supervisor
OMG
I am totally impressed for your idea ... I never expected to hear again about the morse code.

50%
50%
Curt Carpenter
Curt Carpenter
4/17/2012 1:48:41 PM
User Rank
Blogger
Re: OMG
Well Nemos, using Morse as a machine- and man-readable MCU interface is certainly not a new idea.  I'm pretty sure I remember seeing its application maybe 30 years ago in a BYTE magazine article.  It does offer a lot of advantages though.  The "dot-dash" code for any character -- numbers and punctuation included -- fit nicely into one byte in a look-up table, for example.  But you really only need the twenty six alphabetic characters to handle every command&control interface I've ever built, and most commands can be expressed in four characters at most (since the context that you're communicating in is very narrow).

The key to making the command part of the interface work reliably is to adopt a simple "command & confirm" protocol.  You send a command using the key, the MCU plays the command back to you, and if it's correct you confirm it by sending a "foolproof" confirmation character ("T" or "E" work well!).

Writing all this in assembly is a great way to teach kids the joys of programming.

100%
0%
paulyvee
paulyvee
4/26/2012 2:01:32 PM
User Rank
Bit twiddler
Re: In with the old, to help out the new
I had to develop an indicator unit from a number of lecture rooms to a kitchen facility so that attendees in the rooms could request coffee/tea. We are talking 30 odd years ago and the only technology at that time was a single channel hand held remote transmitter/receiver and programmable gate arrays. I used a similar two bit code to identify each room remote to a receiver in the corridor and then decoded it via the PGA to the indicator - verrrry crude by today's standards but that was all we had.

By the way - it would appear that Mr. Morse did not actually invent the code. he was not so much an inventor as an entraprenour. The code was invented by his lab tech - but developed by Morse following experiments that "showed" that communication was not possible over long distances because of cable losses.

His lab tech (I can't remember the guy's name) disproved the range limitations and invented/developed a very sensitive receiver and while doing this invented the code as a test medium.

Morse then apparently took his experiments and developed the code from this.

However don't ask me where I got this info - I only remember it from discussions with my Morse trainer many many many - and more - years ago.

Paulyvee

 

50%
50%
Page 1 / 2   >   >>


latest blogs
Your test bench needs to be thorough in its coverage to avoid costly production problems.
Regardless of language, the way you name your variables will have a significant impact on your code's quality.
New MCC blogger Adam Carlson talks about ECAD tools for those coming to MCU design from other fields.
In the third of four parts, Aubrey talks about semiconductor sensors and software issues.
In the latest issue of this ARM-centric magazine, topics ranging from Android apps to digital cows.
flash poll
MC on twitter
like us on facebook
Microcontroller Central    About Us     Contact Us     Help     Register     Twitter     Facebook     RSS