2013-09-21

Video on oscilloscope

My friend sent me this video a few days ago:



And I immediately wanted to do the same, but it's a huge project if done properly. It has a ILDA interface/driver, high-speed custom DACs, etc.
So I tried a simple alternative - creating a raster monitor from oscilloscope.

Here is the idea:
  • Put oscilloscope to the X-Y mode
  • Take a standard composite video (from DVD player in my case)
  • Separate horizontal and vertical sync signals from the composite video
  • Use these sync signals to generate two saw-tooth signals for raster. Vertical sawtooth (frame signal) scans top-bottom and horizontal sawtooth (line signal) scans left-right.
  • With these two signals I should get a raster/white screen on the scope
  • Assuming that I'll be fine without gray shades, just black and white image
  • Keep a raster running all the time, but when the beam is supposed to be passing over the black area then quickly change the horizontal (or vertical?) signal to the constant voltage. But choose this voltage to cause the beam to jump to the outside of the scope screen. This would form a dark spot.

This sound simple and could be done without microcontrollers, but using just a handful of analog ICs.
The only tricky part could be to separate sync signals from the composite video. I used to repair TVs a long time ago and vaguely remembered that it used to be a specialized IC to do exactly that. Sure enough google remembers it better than me: LM1881 Video Sync Separator

Here is the adapter schematic:


Horizontal sawtooth signal generated by R1, D1, C2 and buffed by the U1. The signal turned on/off by the analog switch U2A.
Vertical sawtooth signal is generated by the R6, D2, C5. It is inverted by the U2B, so it actually becomes an inverted sawtooth. This is because in the oscilloscope world higher voltage causes beam to move up, but TV scans top-bottom.
U4 is a comparator to decide when it is time to turn the beam off (based on the brightness). Actually it's not a "turning the beam off", but instead it disconnects the horizontal sawtooth signal from the scope input, which is equivalent to applying 0V to the input. This causes the beam to move to the left, beyond the scope screen, so the beam is not visible.
The alternative solution would be to use scope's blanking input (z-axis) to turn the beam off, but I thought that it'll be too much like a standard TV.

А few pictures/oscillograms to illustrate how it works. The source video were paused at this frame:


Below I am displaying both channels in standard scope mode (not X-Y).
The bottom sawtooth is vertical channel. I am triggering on the falling edge of this signal (vertical retrace).
The lame picture above the vertical signal is my horizontal trace.
The bright line just above the vertical trace signal is where my horizontal trace parks for the "beam off" period.



The same as above, just zoomed into the highlighted area (head).



And this is the result, playing the same video as the original project (touhou - "bad apple"):



Note: it looks like the video is losing frames around 0:30, but this is from the original video and have nothing to do with my adapter.

Rotary Dial for digital age

As I remember good-old rotary dial phones have been around since forever. And it is used to be a part of the everyday life, like dragons during medieval period. But like dragons, all of a sudden all these marvelous ancient devices just disappeared one day. I was lucky to find one of these dinosaurs at the local flea market:


I was eager to try it out, but unfortunately I don't have a home phone line anymore. I hook it up to my Voice Over IP (VoIP) adapter that I haven't used in years. And it almost worked! Well, it rings like it is supposed to - waking up dogs and babies in a 2 block radius and I could have a pleasant conversation over it, but I can't dial out. I hear a dial tone, but it ignores the number I was trying to dial.

The problem actually is not a phone - there is nothing could go wrong with it, ever. It's probably bullet-proof and could easily survive a minor nuclear apocalypses (haven't tried it, it is in my todo list). The problem is in my Voice Over IP adapter, it's not compatible with "ancient" rotary-dial phones. It designed to work only with (well, also vintage) push-button phones.

Ironically, rotary dial (or pulse-dial) is actually digital protocol, and is supposed to be closer relative to VoIP than "modern" push-buttons phones. The later ones were using analog encoding to transmit digits. This process has a fancy name: Dual-Tone Multi-Frequency Signaling (DTMF).
And the rotary dial is pure digital - transmitting numbers as a sequence of on/off pulses. One pulse correspond to digit "1", two pulse - digit "2", etc; Ten pulses represent digit "0".

Of course I could get another VoIP adapter that supports pulse dialing, but this would be too easy.
Instead I decided to make my own pulse-to-DTMF converter.

I had a few Atmel AVR microcontrollers lying around and using them to generate DTMF signal should be trivial. Obviously, it's been done before and I found Atmel application note to do exactly that. There is nothing special there, just using a PWM (the same method I used to play audio on the TI Launchpad) to generate analog signal. The only difference is that I am not using any external memory here. DTMF consists of just two sinusoidal waves, so we have to store one period of the sin wave and it is small enough to easily fit to the microcontroller's internal memory.

As I mentioned before, reading pulses from the phone is very simple, it's already digital, just count them up - and bam you get your digit.

Here is a a test setup with my adapter still on the breadboard



From left to right:
  1. WiFi to Ethernet converter. Just because my VoIP adapter doesn't have a WiFi and I don't like having Etherent cables everywhere
  2. VoIP adapter. I had the old Cisco/Linksys PAP2
  3. Phone (kinda obvious)
  4. Breadboard. Schematic below:

Phone line voltage in the "on-hook" state (confusing term? it seems to be originated when you are supposed to keep the earpiece on the hook and "off-hook" it in order to answer the call).

Back to the voltage,  so the "on-hook" voltage is quite high, around 48V DC and even higher (around 90V AC) during the ring. I decided to connect my board after the phone switch, so I am getting the power only when the phone is in the "off-hook" state (means handset is not on the phone).

In the "off-hook" state, line voltage is supposed to drop down to around 5V DC, which is perfect for my AVR, but I still added a 5.1V zener diode D1 just in case.

Rotary dial module is disconnected from the phone circuit and connected to my adapter only. The purpose of the connection between pins F and RR is to make phone think that the dial is still connected.

I am generating DTMF/PWM signal on the AVR pin 5 and feeding it to the emitter follower Q1 via the low-pass filter (C1, R3).

If you are curios, you can grab an AVR source code here.

Here is the video testing the adapter

During the test I ran into into the interesting issue. I noticed that AVR power consumption at the power-down mode is much higher than I anticipated (~500uA instead of ~10uA). After poking around I traced the issue to the debugWIRE interface. I were using debugWIRE to download and debug code on the AVR. But apparently debugWIRE draws a lot of current (~500uA). Disabling debugWIRE via fuses and using ISP instead solved the problem.

Last steps were to wire adapter on the perforated board.




And mount it inside the phone (thank you again, hot glue)



Done! Just put the cover on. Obviously it looks exactly the same as before modifications.


Next steps. I guess there is none. Well, maybe to record how this phone rings and use it as a ringtone.