At 06:15 PM 1/24/2008, James Newton wrote: >If you send out status data in a serial stream fast enough and continuously, >it should look more or less consistent when used to light the power on LED >on the widget you are making. I would have to give Robert Rolf credit for the original inspiration. I'm not sure if he would even remember it, but we built a project many (15?) years ago that was essentially a large "guess the magic number" contest for a radio station promotion. It made use of large LED-based displays that lived over top of a clear plexi-glass case containing a prize. Each lucky contestant would enter their guess on a simple keypad. A correct guess caused the case to open, allowing the prize to be retrieved. Robert suggested that I have the LED displays encode the correct answer as a serial bitstream so that he could win the prize should he become one of the lucky contestants . . . I didn't take him up on his request at that time - it just wouldn't have been right . I've received a lot of email on this issue - I can't share code but I can certainly tell you what I did. 1) Idle condition (that is: "Disconnected Idle" condition) is that a particular LED is transmitting (0x00 0x00 pause) whenever it is lit. A logical zero = LED on - that means that the LED is running at about 80% brightness. 2) I'm using super-bright T1 red LED as the indicator / transmit LED. 3) The receiver is a Industrial Fiber Optics IF-D92 photo transistor with a short length of 1mm jacketed plastic fiber. The free end of the fiber has a Hellerman sleeve glued such that the sleeve will fit over the T1 LED and hold the end of the fiber in contact with the LED. For those who aren't familiar with Hellerman sleeves, they are an alternative to heat shrink tubing (probably pre-date heat shrink tubing). They are made from a super-elastic neoprene rubber and can be stretched to 5 or 10 times their collapsed diameter using a special tool. In this case, no stretching required. The sleeves are about 1mm or so inside diameter, about 20mm (3/4") long. I simply slide the sleeve onto the free end of the jacketed fiber, then glue it so that it doesn't slide around. The sleeve grips the body of the T1 LED tightly when pushed on. How it works: The LED normally blinks. Each blink transmits the "disconnected idle" token (0x00). When the fiber is pushed onto the LED, the display system detects the token (0x00, 0x00) and prompts the user to press and hold both buttons. After a 2 second or so delay, a different token is transmitted. That causes the display to prompt the user to release button #1. Shortly after button 1 has been released (but button 2 is still pressed), the LED transmits the next token. The display prompts the user to release the 2nd button. If the buttons are released at the correct times, the controller is pretty sure that the display is connected and working. It transmits its "connected idle" token to the display, which causes the display to present the highest menu level. From this point on, you can do whatever you like using the interactive display and 2 buttons. If no button is pressed after an appropriate idle time, the controller reverts back to "dumb blinky LED" mode and transmits the "disconnected idle" token during blinks again. Notes: 1) the hand-held display unit contains all the text strings needed for the product. The token sent by the controller simply selects the appropriate string(s) for display. 2) All data needed for specific fields on the display are transmitted along with the appropriate token for that menu level. 3) I've been using standard 8n1 serial up to this point (bit-banged on a 12F675 or 12CE671). I'm considering changing my next project using this system to encode the data with Manchester or MFM encoding. The 12CE671-based systems used a resonator but I've been lucky enough that the internal RC clock in the 12F675 has been adequately accurate for reliable communications. FWIW - the early units used a modestly self-correcting serial receive routine that I've posted previously. This receive routine is based upon John Payson's 40 bit long serial receive buffer, where an entire character is sampled at 3 times the baud rate and stored in a 40 bit long shift register. The character is decoded when the start bit reaches the end of the register - one can then examine the bit transitions and make a "best guess" as to the location of each bit. Sounds complicated but its not too bad. Isochronous code at its best . The MFM modulation I mention above is a primitive 25% / 75% duty cycle modulation that I've been using for at least 20 years. Its charm is that its extremely easy to generate in hardware and very easy to decode. That, plus the ability to maintain accurate communications over the range of about 60% through 170% baud rate variation. The downside is a 2 times drop in effective data rate compared to Manchester encoding (it requires 4 bit slices compared to Manchester's 2 bit slices). Other notes: I'll sometimes set the card up so that it always powers up in smart (interactive) mode for the first 2 or 3 power-up cycles. That makes production testing easier. It stores how many times its been powered up in eeprom - then stops counting after the appropriate number has been reached. I've been asked if this has been patented. Quite frankly, I considered it to be an obvious technique and thus in the public domain. I certainly hope that it remains in the public domain. dwayne -- Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax www.trinity-electronics.com Custom Electronics Design and Manufacturing -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist