I remember writing as a kid in the mid ’70s to an electronics magazine well-known in Italy, Nuova Elettronica, asking them to publish the project of a device to display music on a TV like on an oscilloscope. They did not reply but eventually they published the project. I’m not sure I’m the one who actually sprung them into designing the circuit but I was nonetheless compelled to build the circuit which of course worked great as expected. In my idea the line would have been horizontal but vertical appeared to be the most natural after reading the article.
The circuit was a clever mixture of triangular wave generators, comparators, monostables and flip-flops plus an RF generator to feed the TV’s antenna input.
Now that circuit is lost and the magazine gone into recycled paper but it remains one of my preferred.
It is now possible to replicate the circuit using a few components. Also, it is now well clear that a regular microcontroller like a PIC or an AVR provide the necessary speed and peripherals to do the job.
The circuit is very simple as this was my main target. I decided I would use one of the smallest AVRs I had, an ATtiny84. Physically small but large in memory : 8k FLASH is way larger than needed as my circuit fits 1/32th of that much. Anyways, just one 20MHz crystal, 5 capacitors, 4 resistors and one VGA connector are sufficient to generate a vertical line on a VGA monitor which swings left to right depending on the voltage at a micro’s input pin. Applying music at the pin the line dances at the music. A little bit kitschy ’70s prop.
This is a picture of the output without any input : a well steady line is displayed, not bad for software timing.
I chose to go on a VGA instead of a regular TV because it is a single standard all over the world (no 60Hz vs 50Hz issue) and it is not interlaced (like TVs) which would have added another layer of difficulty.
This is the circuit. It is not mounted on a PCB : read further.
The code is entirely in assembler and interrupt driven.
Horizontal synchronism is generated by the internal PWM generator at Timer 1. Horizontal Synch is also used as the timebase for Vertical Synchronization. Also, the input voltage coming from the audio input is read by channel 0 of the internal ADC at the beginning of every line, then a new conversion is started over to give the ADC the time of a full Horizontal line to make a new conversion.
Resolution required is low and as few as 7 bits are sufficient to span the monitor horizontally. The overall effect is just fine anyways.
The only tricky part is the interrupt routine called at the start of every horizontal line :
In case it is the last (628th line at 800×600, 60Hz) line, a Vertical sync pulse is started with the aid of a counter. The pulse is stopped after a 4 lines’ duration has passed. This is the Vertical sync pulse wich causes the vertical retrace and during this period no out should be put on the RGB (colour) outputs (the reti instruction).
In case it is not the vertcal sync occurrence, the ADC input value is converted into a delay after that output at the RGB (Red only, actually) is set to VCC for one single instruction cycle. This time is the smallest possible yet a well visible red spot is displayed on the screen.
The schematic is herebelow. Download it in higher resolution clicking on the image to go to Flickr, then select ‘all sizes’.
The input at the ADC must be 0-5Vcc so it is offset at 2.5V with a resistive network. A capacitor cancels the DC component at the input so that audio is converted to an AC offset which adds/subtracts from the 2.5Vcc DC offset.
In case input level is not sufficient I added a simple op-amp preamp suitable for 5V operation. The requirements called for a rail-to-rail op amp that could be powered from as low as 5v and provide an output of 0/5V. Also it had to be powered from one single supply rail. National Semiconductors LMC6462 was my choice. Other components are fine as long as they meet the three requirements above.
The preamp is designed to be driven by an electret microphone of the kind used in cell phones. In case a regular external source like a magnetic microphone or CD player can be connected at the positive lead of C1 and ground. R2 should be removed also.
A filter can be added placing a .1uF to 1uF capacitor in parallel to R5.
I mounted the two circuits on regular perfboard but wanted to add some finesse, so I glued some black and red cardboard on the perfboard (component side, of course!) to hide the holes and just opened the ones I needed with a needle. Next time I’ll print these paper mask adding components references, some logo and legend at the connectors and variable resistor.
This is the circuit completed with the pre amp. Power supply comes from a 5Vcc wall adapter.
Finally a video of the thing in action.
As usual I take the videos with my Olympus camera, probably not the best mean.
The sources I used to understand are endless, probably too many and not always in agreement to each another: probably they all are right as there’s room for tolerance in timing.
I want to mention the most important: Alberto Ricci Bitti whose articles helped to shed some light on VGA with his award winning video projects (www.riccibitti.com), Daniel Ciocea for the same reason (check his VGA monitor tester at http://www.eosystems.ro/deogen/deogen_en.html) and the infinite list of PIC pongs .
Also the reference pages on VGA at http://www.epanorama.net/ was chosen as the standard since same resolutions happen to be given different different parameters on different internet sources.
I was 6 years old when man reached the moon. I barely remind those days : sure they must have been very exciting for those in the age of reason. Today I’m looking back at that accomplishment as the result of spirit of adventure, bravery, stupidity, lack of common sense, careful betting and something more, probably.
I am also thinking not only of those who actually walked on the moon or simply orbited around the satellite. I am also thinking of the men and women who contributed to the travels .
I know of some men and women who also had to be amazed and emotioned at the very moment Eagle landed : they were the people involved in the design of the system like the one to detect that Eagle had actually landed.They had one single lightbulb (two, actually) that had to turn on when the probes would touch the surface. All of the designers, draftmen, wiring technician and so on knew that at that very crucial moment the lightbulb they designed, wired, mounted and verifyied had turned on.
A very simple mechanism but very crucial because the engines had to be turned off immediately after touchdown, not earlier not later or probably the LEM and the men would have gone.
I of course looked for the part related to the Lunar Contact Lights and the logic behind them : of course it could not be one switch and one lamp only.
Lunar Contact Lights (paragraph 2.10.2.2.2) reads “Both LUNAR CONTACT lights (panels 1 and 3) go on when one or more of the three lunar surface sensing probes contacts the lunar surface. When on, the lights advise the crew to shut off the descent engine.“….Makes sense to me !
The paragraph contains the electrical (principle) drawing of the circuit : a number of relays relay the contacts at Eagle’s probes and a few basic techniques are used to reduce the risks of false signalling or no signalling.
The circuit is this one (part II is available also at the NASA Technical Reports Server as Unclassified; No Copyright; Unlimited; Publicly available : I assume that the same applies to part I, if not I apologize and please let me know) , click for a larger image :
The lights are two (top of drawing) on two different panels, namely panel 1 and panel 3. Both lamps light up when at least one of the probes touches the ground. The circuit is powered from two different sources and only when the descent engine is on – relay 3K7 controlled by switch K16B inside dotted square at left. Should the descent relay fail, switches 1K5B and 2K5B (at left) can be used to manually override switches to both supply lines. The two lamps are independently powered from the two power sources.
The circuit is redundant wherein the bulb besides being powered from two separate power sources, are controlled by two circuits. Let’s see :
Each lunar probe has two normally closed switches (n.c.). The double switch configuration at each leg prevents false signalling in case one of the switch mistakenly opens whatever the reason (say, vibrations).
Now consider Lunar Probe +Y. Both switches (bottom, center) must be activated to open the circuit and relase from ground the bases of transistors 1Q1 and 1Q2 which then go into conduction driving the relays 1K2 and 1K3. The path from ground is created through relays’ contacts 1K2A and 1K3A for panel 1’s lamp and contacts 1K2B and 1K3B for panel 3’s lamp.
The same applies for Lunar Probes -Y and -Z except that the parallel circuit at each leg are put in series : the circuit is open only when BOTH switches at EITHER probes are activated (open).
Now, should the circuit related to relay 1K2 or 1K3 or both fail, Lunar Probe +Y would not turn on the lamps, but two more Probes are there and one more driving circuit which mirrors the previous one : Lunar Probes -Z and -Y which drive transitors 2Q1 and 2Q2 and then relays 2K2 and 2K3.
It is important to note that should BOTH relay 1K2 AND 2K3 fail because the coils burns or the armatures lock or the transistors are damaged (a so-called double fault), the circuit would still work because a path to ground for the lamps could still be created through relays 1K3 and 2K2, unless one of these relays or the Probe switches also fail, a very unlucky combination.
Should BOTH relay 1K2 and 2K2’s circuits have failed (or BOTH 1K3 and 2K3) no path to ground could have been created for the lamps that would have stayed off.
A mean to make this latter double failure more unlikely might be to use different makes/models for relays 1K2 and 2K2 (and for relays 1K3 and 2K3). Or use the same high-availability relay from different batches.
Not that simple a circuit for lighting up two bulbs. A good circuit for a giant leap for the human kind.
Today it would probably still be made with discrete devices ( no microcontroller ) : simply the relay would be replaced by small SMD power MOSFETs driving diodes for the and/or logic and LEDs for display.
Not that I’ll read the whole document but those P&IDs (Piping and Instrumentation Diagram like the one depicting the Portable Life Support System at figure 2.11-6, top picture) and schematics are very intriguing. Definitely worth a look.
One final note : the drawing is dated 1 Feb 1970, so probably it is not exactly the same used on Eagle, nonetheless it was probably used on some subsequent mission, not less important than the first one.
Comments are very welcome also if coming from different parts of the handbook.
Most modern energy meter have one or more LEDs which blink at a rate directly related to the energy used. The one above has two of them : one pulses at 1000 pulses per active kWh, the other one pulses at 1000 pulses per reactive kWh. I dealed with the active power only, event though I’m billed partially for reactive power also.
The idea is to collect the blinks of the LEDs in 5 minutes blocks. Twelve groups of 5 minutes-worth counts give an hour, then data are collected around 24 hours.
I used Processing to read to read the LED through a webcam and detect and collect the blinks.
Processing and its video library is the most obvious choice to me as I’m not much of a high-level programmer. Processing is well supported and gives instant gratification. It also runs on a variety of platforms, including my little Acer Aspire One where I managed to have processing run some time ago.
Grabbing the camera image is straighforward with processing : had to install vdig (vs 1.0.1) as instructed in the processing support forum and Apple’s Quicktime 7 which is the essential part to grab the video Everything went smooth, on my desktop at least. I couldn’t have it running on my Aspire One as vdig of course doesn’t run on it, and would have had to use a different library.
That said, I wrote a quick ’sketch’ in Processing to grab the camera, select with the mouse the “hot spot” of the meter (the LED) to minimize interference from the reactive power LED and ambient lights reflection. The code also represents visually the energy used in 5-minutes chucks over the 24 hours.
This is what is seen in Processing through the web cam. The image is upside-down because the camera is. But of course it doesn’t matter.
The LED area is selected clicking and dragging with the mouse. Some sort of dark cloth sleeve is necessary to pretect the camera from glare and reflection which might cause false or missed reading.
The camera view is activated pressing the “v” key on the keyboard. Click and drag a square around the LED. When done press any other key to turn on the count reading window, the one below :
The bars represent the total reading for a 5 minutes slot starting from 0:00 to 23:55 hours. The height of the bar is the reading (in my case 1Wh per pixel) and is incrmented every blink of the LED (1 Wh gone). Hovering the mouse on window (do not click on the window) returns on the top left the reading (kWh) for the time slot on the extreme left. Click on the image above to go to the flickr’s noted version for what the peaks are due to.
On the right of the string is the total reading over the last 24 hours.
A reasonably fast PC is necessary though to catch the quick blinks and evaluate the very frequent counts during peek energy requirements. And I didn’t want to dedicate my main dual core desktop PC to the purpose.
For now I did not design any mean to read remotely the data. Of course it is probably nonsense to keep continuously a fast-power hungry PC for the purpose. The Tweet-a-watt is a better option, with remote reading option also.
But I wanted to try this.
Version 2 !
It would be faster and less processor intensive to use an external event derived from the blinks and input it somewhere into the PC and log it with Processing.
I went for the “recycle way” and took apart an old mouse (well, no so old) and hooked the following circuit to the left mouse button : the light of the LED makes the TIL78-like phototransistor go into conduction which triggers an ever green NE555 (in the shape of a CMOS TLC555). The monostable in turn makes the NPN transistor close the relay which close the left mouse button of the mouse. Simple yet effective.
Side effect : the mouse can’t be used for anything else during count accumulation, otherwise the counts are affected, obvious. A dedicated external USB I/O device would solve the problem but this cost zero.
The purple wires are hooked to the coil of the relay inside the mouse.
The sketch for Processing for photo transistor version is here.
The sketch for Processing for the web cam version is here.
