Dash-cam irritation avoidance circuit (How to use a sledgehammer to crack a nut). A guaranteed supply.

My dash-cam has a irritating issue. If I stop at the traffic lights, and switch the engine off in the car to save a little fuel, and hopefully reduce my environmental impact, when I restart the engine, sometimes (most times) the camera hangs up and stops recording. It's powered from a 12V to 5V USB adaptor plugged into the accessory socket. What's probably happening is the supply is momentarily dipping and the micro inside the camera is "browning" out, despite having an internal battery. No messing about with the camera's settings or firmware have solved this issue. 

What we need to do is make a little circuit that ensures the power supplied is OK. 

My idea is, if the main supply dips or even switches off completely, the supply is temporarily held up by a small LiPo cell for 3 minutes. After the that, power is removed, unless the 12V is restored within that time. This should be long enough if I'm sat in traffic, even if I've switched the accessory socket off. 

Here's the schematic:

12V arrives to one of those small buck converters (from eBay/Aliexpress etc) .. and is used to provide a 5.7V regulated supply via one half of D1 to supply the 5V for our camera and the ATTiny85 microcontroller. It's also feeding one of those small PSU boards for charging a LiPo cell & boosting it's output that I used in the Geiger counter project (albeit modified). This board is unmodified, and is adjusted to provide 5.2V output. 

Once the microcontroller has started up, it takes PB0 High, biases on Q1 via R2, and energises the relay. This connects the LiPo cell to the charger/boost controller. The 5.2V output is then connected to the other half of D1, which is currently reversed biased, and does nothing. The output from the 5.7V converter is monitored by the microcontroller PB1, via D2.

In the event of the 12V supply failing, PB1 will be pulled low by R3, as the 5.7V supply is removed, and a timer is started. 5V supply is now maintained, as the output from our 5.2V Lipo boost converter now feeds the 5V supply, as the second schottky diode in D1 is now forward biased. Once the 3 minute timer has elapsed, PB0 is taken low, which kills the LiPo supply by opening the relay, and, as there's no power supply anymore everything stays off, until the 12V supply is restored. 

R1, D4 and C3 form a reset delay circuit. C1& C2 provide some power supply filtration & decoupling. D3 prevents the back-EMF from the relay coil destroying Q1. 

The principal is the same as the circuit I used to write the mileage to the EEPROM on the Mini speedo project.

The code is simplicity itself, and is uploaded to an ATTINY85, set for a 1MHz internal clock.

# define OUTPUT_PIN 0

# define SUPPLY_OK 1

unsigned long timer;

void setup() {

  pinMode (OUTPUT_PIN, OUTPUT);

  pinMode (SUPPLY_OK, INPUT);

  digitalWrite (OUTPUT_PIN, HIGH);

}

void loop() {

  if (digitalRead (SUPPLY_OK)) {

    timer = millis ();

  }

  if (millis() > timer + 180000) {

    digitalWrite (OUTPUT_PIN, LOW);

  }

}

Possibly (!) far too complicated. I could simply use a high side drive FET circuit to drive the output, and use a simple RC time constant to drive the FET, but I suspect the actual parts cost would be about the same, and I don't have a suitable FET in the junque box!

Right, down to construction...

Having got a bunch of parts from the junque box, the circuit is constructed on a bit of perf-board.  

I added an LED across the 5V output, just so I could see what was going on during testing.

All mounted up in a *slightly* too big box, and I could have used a smaller relay (had the junque box provided one) . Input lead is connected to an accessory plug, and output via a USB socket. 

And finally put into the clutter box in the car, and connected up. It performs faultlessly ...

Which is a good job, because this is the state of the wiring on the old USB supply I'd just removed 😬

The ESP32 Analog (Analogue!) Clock

As promised, here's the new stupid analogue clock. 

It consists of two 270 degree analogue meters, thoughtfully calibrated 0-70V and 0-300A, kindly donated by Andy from North Hill Audio in Malvern, and an ESP32 with it's nice in-built RTC, wifi etc etc...

The idea is almost identical to the previously stupid analogue clock, found here. This time, we will use the ESP32's built in wifi to connect to the internet, and pick up the time from an NTP server, and set the ESP32's inbuilt RTC. There's an example in the ESP32's arduino library to do this, and utilises the standard time.h library to maintain the clock. I'll set a random time to refresh the RTC randomly between 12 and 24 hours, I don't want to keep bothering the NTP server. I can then output hours and minutes using PWM to drive the meter movements. 

First off we're going to need to do something about the scaling on our meter movements, as I can't easily drive 0-70 volts, nor 0-300 amps! 

Examining the meters shows the 0-300A meter is actually a 75mV full scale deflection meter (FSD), designed to be used with an external shunt of 0.025 ohms (or does it ... read on), this is good, as we can easily drive that.

The 0-70 volt meter reads directly. Disassembling it shows it has a "multiplier" resistor (actually 3 resistors in series, one adjustable) with the earthy end of the movement. 

Shorting out the multiplier gives us a meter with about 200mV FSD, perfect. The meters are dated 1972.

Both meters pull a fair amount of current ... 

A schematic is conjured up. There's not much too it.

As ESP32 has no native support for analogWrite, but we can use the ledc function. I don't care it's not driving an LED, and neither should you 😉. Each output pin, feeds the base of BC547 NPN transistor which is driving the meter. There's a 1K pot in the emitter to allow FSD for the meters to be set accurately. The venerable 7805 regulator supplies our +5V to the ESP32 and meters. 

There's an output on IO18 for a PM indicator LED, and an output on IO15, which I'm going to use to drive a relay, to give the clock a ticking sound ...

The script has some differences to the original ATMEGA328P script, as there's no 409Hz interrupt timing required, as the RTC is doing that job for us, and the code to receive the 433MHz timing signal has now gone, as that's now taken over by NTP. There's a section to extract the individual hours, minutes and seconds from the RTC, and load them into separate variables that we can manipulate. There's also no "smooth" function, as both hours and minutes are smooth, and there's no 400Hz interrupt timer to give us 1/409th of a second to drive a "smooth" seconds meter, and there isn't one anyway! The clock is also permanently set to 12 hour mode, with a PM indicator on pin XX. I've retained the fabulous "IsBST" routine. It just works. If you're outside of the UK, you'll need to modify the code to suit your timezone.

The software can be found on my github page at https://github.com/andydoswell/ESP_32_analogue_clock

The electronics is mounted up on perf board.

So that's the electronics and software sorted. 

I ordered a wooden craft box from eBay to mount it all in.

A couple of stains and finishing oil are tried out on the inside... 

.. and while they dry, I use libre cad to make a cutting plan for the front. 

The template is printed out , and taped to the box.

The two holes are cut out for the meters

The box given many coats of finishing oil to bring out the grain, and give it some shine.

I had to get a bit creative when  mounting the meters, as I didn't have the original mounting hardware..

I added some redundant 19" rack handles as a stand. I'm pleased with the results.

There, and goodnight, it's 250 amps past 51 volts!

I notice there's a kickstarter, where you can now buy something very similar. 

Pyers read this last night, and has pointed out the value of the shunt is wrong. I simply glanced at the back of the 300A meter, and mis-read it... I had wrongly assumed 0.025ohms was the value of the shunt... But 75mV across 0.025 ohms only gives us 3A... not 300.

Reading the label correctly, it simply states "Use with external shunt" , and the 0.025ohms is "lead resistance". The shunt should be 0.00025 ohms for a full scale deflection of 300A. 

Moving on up from ATMEGA328 & Arduino. The ESP32 "Mexican wave" light chaser.

I've recently been looking at other microcontroller options for some upcoming projects. Arduino and the ATMEGA328 have been wonderful devices, but it's getting on a bit now. 

I've played with the very powerful Teensy range of controllers a little bit, and they're great, just, well, a bit pricey .... The audio functions they perform are, however, wonderful. Probably great "bang for the buck" ... I just really don't need that much bang!

A while ago, I visited the USA, and one guy there gave me a "Blue Pill" , a fast, 32 bit microcontroller, with plenty of IO. Sadly not much in the way of RAM, and support for libraries seems a bit lacking. It is, however, stupid cheap.

I seen & read a bit on the ESP32. Looks good, and is cheaply priced. I've bought a couple. The one thing that (sort of) lets it down is the absence of a simple analogWrite function to control it's myriad of PWM outputs. It does have 2 proper DAC's though. Thankfully there's a function called ledc, which is largely similar, but operates at a higher (5KHz) PWM frequency than Arduino uno (nano etc) 490Hz, which makes filtration a bit easier. It's got wifi, bluetooth, a magnetic hall sensor (why??), and a built in RTC, and probably much more!

A while back I built the Arduino analogue clock , and always intended  to incorporate two large 270 degree meters. I never got round to it. My intention is to modify the code to use the in-built RTC, synchronised by NTP via Wifi, and use that to drive the meters. Seems easy enough, and will be a good project to cut my teeth on. 

In the meantime, I've been playing with ledc to make a mexican-wave style LED chaser, to get the hang of things a bit. It's based on adding more channels to the example supplied in the Arduino IDE for ESP32.

Hang some LED's off the pins as listed in the code, with appropriate current limiting resistors (220Ohm), and enjoy.

/*

  LEDC Software Mexican wave

  

*/

// use first 8 channels of 16 channels

#define LEDC_CHANNEL_0     0

#define LEDC_CHANNEL_1     1

#define LEDC_CHANNEL_2     2

#define LEDC_CHANNEL_3     3

#define LEDC_CHANNEL_4     4

#define LEDC_CHANNEL_5     5

#define LEDC_CHANNEL_6     6

#define LEDC_CHANNEL_7     7

// use 13 bit precission for LEDC timer

#define LEDC_TIMER_13_BIT  13

// use 5000 Hz as a LEDC base frequency

#define LEDC_BASE_FREQ     5000

// fade LED PIN (replace with LED_BUILTIN constant for built-in LED)

#define LED_PIN_0      23

#define LED_PIN_1      22

#define LED_PIN_2      21

#define LED_PIN_3      19

#define LED_PIN_4      18

#define LED_PIN_5      17

#define LED_PIN_6      16

#define LED_PIN_7      15

int brightness [] = {0, 32, 64, 96, 128, 160, 192, 244, 255}; // how bright the LED is

int fadeAmount[] = {1,1,1,1,1,1,1,1}; // how many points to fade the LED by

// Arduino like analogWrite

// value has to be between 0 and valueMax

void ledcAnalogWrite(uint8_t channel, uint32_t value, uint32_t valueMax = 255) {

  // calculate duty, 8191 from 2 ^ 13 - 1

  uint32_t duty = (8191 / valueMax) * min(value, valueMax);

  // write duty to LEDC

  ledcWrite(channel, duty);

}

void setup() {

  // Setup timer and attach timer to a led pin

  ledcSetup(LEDC_CHANNEL_0, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_0, LEDC_CHANNEL_0);

  ledcSetup(LEDC_CHANNEL_1, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_1, LEDC_CHANNEL_1);

  ledcSetup(LEDC_CHANNEL_0, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_2, LEDC_CHANNEL_2);

  ledcSetup(LEDC_CHANNEL_3, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_3, LEDC_CHANNEL_3);

  ledcSetup(LEDC_CHANNEL_4, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_4, LEDC_CHANNEL_4);

  ledcSetup(LEDC_CHANNEL_5, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_5, LEDC_CHANNEL_5);

  ledcSetup(LEDC_CHANNEL_6, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_6, LEDC_CHANNEL_6);

  ledcSetup(LEDC_CHANNEL_7, LEDC_BASE_FREQ, LEDC_TIMER_13_BIT);

  ledcAttachPin(LED_PIN_7, LEDC_CHANNEL_7);

}

void loop() {

  for (int i = 0; i <= 7; i++) {

    ledcAnalogWrite(i, brightness[i]); // set the brightness of each led in the array

    brightness[i] = brightness[i] + fadeAmount[i]; // increase the brightness of each led

    if (brightness[i] <= 0 || brightness[i] >= 255) { // until it gets to 255, then reverse the direction of fade, until it gets to 0, and reverse again

      fadeAmount[i] = -fadeAmount [i];

    }

    delay (1);

  }

}

Arduino Audio Compressor.

As part of an upcoming project, I need to compress some audio a bit. 

Now there's plenty of analogue compressor schematics on the web, but a lot require obsolete FETs or odd ball lamps, shining on an LDR (the optical compressor). I fancied a different approach.

Here's the plan, audio comes in to the "top" of a digital pot (also known as an R-DAC), the pot is controlled by the arduino. The wiper of the pot is connected to out audio output. That way, we can use the arduino to effectively wind our pot up and down to control the level of the audio. 

The wiper of the pot also feeds a rectifier, and the resultant level sampled by one of the Arduino's analogue ports, and that value is processed to provide the control signal to the pot.

A schematic is scratched out...

Audio comes in on J1, C3 is a DC blocking cap as the audio is biassed to half of the 5v supply by R1 & R2. The audio then feed the top of our digital pot, U2, on pin 5. Pin 7 of our pot is the bottom of our pot, and is connected to GND. Audio emerges from the wiper of out pot on pin 6, there's another coupling cap, C9, and the audio is then biassed to half our 12V rail by R14 & R16. It feeds a buffer amp, U1B and is output via R15 & C11, and is referenced to gnd by R17.The audio also feed U1A, which has a gain of about 14, and boosts the audio up to a sensible 10 volts pk-pk or so. This is coupled via C8 to our rectifier (D1 and a small filter cap of 10nF. This then drives the ADC of the arduino on pin A0. I haven't really shown the power supply, but it's just a single 12V supply, the 5V being derived from the arduino's on board regulator.

The software, can be found on my github page, as usual  https://github.com/andydoswell/audio-compressor

There are some variables to play with, being Target, Avg, Attack and Decay. Play around with the values and get a feel for it.

One other thing I played with, was feeding U1A from the incoming audio, rather than the devices own output. It was possible to get the software to lose control and end up with no audio coming out, but it could be tamed.. I think this type is called a "feed forward" compressor, and again, worth some experimentation. 

Here it is lashed on a bit of breadboard. It performed surprisingly well, and quiet too.

Strathclyde STD 305D Display fault

Remember the Strathclyde STD 305D I built a supply for here? Well, it ran for a while then the display started to play up .... 

It stopped indicating the correct speed. Ugh.

I got it back into the workshop, and poked around the board. 

The vacuum fluorescent display is driven by a long obsolete counter, a Plessey ZN1040. The good news is, it's actually counting. The bad news is that's all it does. The way it indicates RPM is it counts some pulses derived from the motor's tachometer , and a reset pulse comes along and resets the count. The display is then updated on reset, so 33 pulses per "reset" indicates 33 RPM on the display ... A prod round with the 'scope shows the reset pulse is missing. The pulse is generated from a Plessey ZN1034 precision timer IC, again long since obsolete. Damn. 

It's a bit like a posh 555 IC.. It's simply configured as a bistable. Replacements appear to be available on eBay, but are of questionable parentage. (You can't tell me that when this thing went obsolete in the early 80's, China had massive stocks of them).

We need to find another solution. 

This is a quick sketch of the relevant bit of the STD305D's schematic. 

As shown here, it's the Q output that feeds the reset pin of the counter. The complimentary output (not Q) of the ZN1035 timer is also feeding something, so we'll need to implement that also ..

 

The power supply available is 5V, so that's easy. How about an ATTINY85 ? Perfect. Two pins connected for both outputs, Q and not Q. Should be easy enough, and be easy to fit. Good, a plan. 

The program is simple enough ... 

#include <avr/io.h>

int timing = 1000;

void setup() {

  // PB 3 and 4 to output

  DDRB |= (1 << PB3);

  DDRB |= (1 << PB4);

}

void loop()

{

  //set PB3 , unset PB4

  PORTB = 0b001000;

  delay (timing);

  // set PB4, unset PB3

  PORTB = 0b010000;

  delay (timing);

}

I've used direct port manipulation to minimise the overlap between Q and not Q. digitalWrite takes longer to change the state of the port. I don't know whether that would be an issue in this application, but it's best practice. We can tweak the timing variable to suit.

The ATTINY85 is loaded into an adaptor and programmed using my ISP programmer. 

As power consumption isn't an issue, the micro is set to run at 16MHZ internal clock. 

The ATTINY85 is pressed into service, and produces odd results. The reset line still isn't resetting the ZN1040 counter. Checking through, I connect it directly to the reset line of the ZN1040 ... not a good idea, as this instantly kills the output pin on the TINY. :(

Liberating the ZN1040 pin from the board, the pin on the IC measures a few ohms to ground. Not only is our ZN1034 dead, but so is the ZN1040.... What's common here? Ugh , the +5V rail. 

I measure the 5V rail ... it's 5.1V , close enough.... hang on 5.2 .... 5.3 ... it ends up at 6V , the regulator on the power supply board is shot. It's a simple enough Zener diode and transistor affair... I sack it off, remove the BD239 pass transistor, and fit a 7805 on a heatsink. It's all a bit too late for our poor ZN1034 and 1040 though. 

So what to do? Obviously remove both IC's. Feed the pulses from the tacho into an arduino, calculate the speed, and output it over the existing discreet transistor drive circuitry to the display. Works for me. 

Studying the datasheet for the ZN1040 , gives us all the info we need... 

OK, so this is shown for LED displays, but the principle will be identical. Four lines switch on the supply to select which digit MSD (Most significant) to LSD (Least significant), only three are connected in our application ... We'll need to multiplex these, and the actual segment drives (A-G) need to be pulled low to illuminate the display. 

First up, is go get our arduino to read the pulses from the tacho. 

They should be arriving at pin 22...

... and, sure enough there's a nice negative going pulse train arriving, and it varies with the speed control. Great. 

We'll drop these pulses into INT0 on our arduino, and trigger an interrupt on a falling edge.

 

A quick piece of code is conjured up to read RPM and output over the serial interface. It's uncalibrated at present, but is near enough , reading 33, 45 and 78 RPMish...

Excellent, we can return to calibration later (the turntable is currently upside down with no platter on it).

Now to deal with driving the existing display. The ZN7040 is capable of muliplexing a 4 digit display. In this application only three digits are used. A quick bit of reverse engineering shows those digits are the 3 most significant digits. These are coupled to  our arduino on pins A1- A3 and set to digital outputs. Each of these pins feeds a grid, and taking this high allows the display to function.

Arduino pins 3 to 9 are connected to the segments drives for A through to G. These are used to individually control each segment's anode. Pulling the pin low, switches on the anode, and illuminates the segment. 

Bingo, a muliplexed display. Now to couple the two parts together...

And finally to reassemble and calibrate ...

Nice!

I will NOT be beaten by mere machinery!!

The software is available as usual from my github.

And another saved from landfill, these really are a stunning deck. 

An experimental Arduino VU meter (and why it's no good)

 In an upcoming project (that is, as usual, taking far too long) requires some indication of audio input level.

So the plan is to have a meter, only this time drive it using an arduino PWM output. Seems like a good plan, as I already use said Arduino to perform one task on start-up, and it's sat there doing nothing most of the time.

So here's the simple input stage. It's job is to take our audio, and amplifying it, so it swings the whole range of our 5V rail, using a rail-to-rail opamp, and centering it on 2.5V, so it doesn't go negative. This is then fed into A0 of our arduino.

Now I need a peak value of our audio, so the usual trick is to rectify it. Rather than implementing this as , say a precision full wave rectifier, I thought I'd have a go in software.

Now the software reads the ADC, and if the result is greater than 512, the result stands and has 512 subrtracted from it. If the result is 511 or less, it's inverted and the result stands, IE is the ADC returns 0, it's inverted to 511, if it's 511, it's inverted to 0. That way, if our peaks are positive or negative, we're measuring a peak. It's a software rectifier.

And that's about all we care about. the output is divided by two and sent as a PWM to the meter. There's a bit in the software to decay the pointer.

At first glance, it appears to work well, given the limitations of the ATMEGA328's A/D ... but it's frequency response is awful...

The problem is with aliasing. Mr Nyquist tells us that we need to sample at least twice as fast as our highest frequency. The software may be going as fast as it can (albeit I haven't employed any techniques to optimise it) , but it's frequency response is poor, and unpredictable (or is it?)

Here's a quick video to show the issue... 

So it is predictable, and poor. Because we are sampling at a constant rate, at anything but that frequency, we will not be sampling the same point of our sinewave, let alone the peak, we could be sampling on the slope, or even at the central crossing point, and giving false readings. We can also see the frequency response improving at the higher frequencies. This is called "spectral folding" , and you can learn more about it here.

So there it is ... it might be OK to give a sort of visual response to some music, but it's woefully inadequate for my purposes. I could use a faster micro (and a better A/D), but that's overkill for this project. I've going back to doing this in good old fashioned analogue!

Here's the code if you fancy playing with it...

int LPeak;

int LoopCounter;

void setup()

{

  pinMode (5, OUTPUT);

  pinMode (3, OUTPUT);

  analogWrite(3, 255);

  delay (1000);

  analogWrite(3, 0);

}

void loop() {

  unsigned int Raw = 0;

  for (int i = 1; i <= 5; i++) {

    Raw += analogRead(A0);

  }

  Raw = Raw / 5;

  int LVal = Raw;

  if (LVal >= 513) {

    LVal = LVal - 512;

  }

  else {

    LVal = map(LVal, 0, 512, 512, 0);

  }

  LVal = (LVal / 2) - 1;

 if (LVal <= 35) {

    LVal =0;

  }

    //LVal =  (106* log10 (abs(LVal)));

  //Serial.println (LVal);

  if (LVal > LPeak) {

    LPeak = LVal;

  }

  if (LPeak >= 210) {

    digitalWrite(LED_BUILTIN, HIGH);

  }

  else {

    digitalWrite(LED_BUILTIN, LOW);

  }

  if (LPeak >= 229) {

    digitalWrite(12, HIGH);

  }

  else {

    digitalWrite(12, LOW);

  }

  if (LPeak <= 32) {

    LPeak =0;

  }

  analogWrite (3, LPeak);

  if (LoopCounter >= 1) {

    LPeak -= 1;

    LoopCounter = 0;

  }

  if (LPeak < 0) {

    LPeak = 0;

  }

  LoopCounter ++;

}

Arduino TV clock with vintage clock source (or another stupid Arduino clock, or "The Ping-Pong Clock")

A while back, the boss presented me with a gift ...

"Found this, I thought you'd like it"

It's a pair of 460KHz Crystals in a standard B7G glass valve envelope. Pretty.












It's sat on my desk for months ... I keep looking at it, and wondering what to do with it...

About the same time, my mate Alan gave me a small CRT video monitor.













I think it's come from a reversing camera from a lorry...










After working out the power pins on the rear, it springs into life, and a stupid plan is hatched....

Take the crystal, and build a CD 4060 oscillator/ripple counter, divide the output down to produce ~28Hz (460000/16384). Feed the 28Hz into an Arduino interrupt pin, and get it to run a clock. Run the TV out library as well, and produce an image on the screen. Brilliant. Stupid. All in one go.

Now, with a crystal oscillator, we need to know the crystal's "load" capacitance. This is formed by the two capacitors off each crystal leg to ground. Every crystal needs these. Get it wrong, and it's unlikely to reliably oscillate (if it does at all). For example, the usual Arduino crystal of 16MHz needs about 22pF on each leg to reliably start up. We'll also need to bias the 4060 so it always starts. Regular readers of this blog will know I used to include a 1 megohm resistor (unnecessarily) across the arduino crystal in my stand-alone designs. We'll need this in our oscillator. (We didn't in the ATMega328 because the bias is supplied by the IC). We'll also need a load resistor. The load resistor is there to make sure there's a voltage on the crystal with which to start the oscillation.

The issue we have is we have no idea of the load capacitance required, or it's required load resistor. There's a rule of thumb about load resistors. 1mm thickness of crystal = 1K ... our crystal is a little over 1mm thick, let's opt for 2.2K. Capacitance? No such rule of thumb. I was going to put 2 adjustable 100pF capacitors in each leg, and twiddle until it would reliably start. Sadly, I could only find one 100pF capacitor... so that went in one leg, and a 22pF fixed capacitor on the other.

Result? Nothing. No amount of twiddling of the 100pF capacitor helped. OK, add another 22pF capacitor to the circuit to give 44pF ... and it's oscillating, but it frequency isn't stable. Remove the two 22pF capacitors and replace with 100pF ....


... and bingo! ... 28.061 Hz pops out of the Q14 pin. It's reliable and steady as a rock. It's a shade off frequency, but crystals do tend to drfit with age, and I doubt my load capacitance quite meets the original spec. It should be 28.076171875Hz.. (460000/16384)








It's all built "fugly" style on a bit of perf board.



























Here's the circuit

The pulses are fed into an Arduino Uno which allows a bit of development to go on, and a discovery is made (should have read the read.me!) .... you can't use an interrupt when using the TVout library, as the interrupts are being used to generate the timing need for video ... no problem, we'll use another arduino to generate the video and pass the data to it over a serial interface..

Now Arduino no1 is just doing the final bit of dividing down and outputting seconds over it's hardware serial interface, it's given it's own 16MHz crystal and mounted on the perfboard along with a 7805 to provide the 5V. The Arduino Uno is now used to develop the video software.







Before long, we have a rather nice clock display running.... (The photo doesn't do it justice, this is the tiny colour monitor I use in the workshop, and the photograph has artifacts..) . There's still plenty of memory left though ....








How about an animated "Pong" (Copyright Atari, the dawn of time) clock? Oh this is getting silly... Yeah, OK...

There appears a number of Arduino "pong" clones on the web, that will (allegedly) sit happily with TVout. After trying, I can't find one that works properly. Shoddy ball/bat collision (it's at best hit and miss 🤣), the ball flying right through the bat half the time.. we don't want that, so I re-engineered the code to suit.

Next thing... We don't want the monitor on all the time, consuming power and wearing the CRT cathode out. So some means of switching on the monitor when someone maybe looking at it. I did contemplate using a passive infrared sensor (PIR), but that's overkill. A simple sound detector will do. We can implement this on Arduino 1. 

A small electret microphone is amplified using an op-amp, and the output fed to Arduino 1's A0 pin.
This input is measured a few times, averaged, and compared to a value. There's an interesting bit of code here, whereby the audio is "rectified" in software, this means any negative audio is "flipped" over,  and a negative peak has the same value as a positive one (I've got a cunning plan for this bit of code, watch this space...). Anyway if this level increases above a certain point, there's some noise about, and we can switch our monitor on.

The output pin feeds a BC547 transistor, which in turn switches on a P-channel FET as a high-side driver, which supplies 12V to the monitor. A minimum on time is specified, as the monitor takes 8 seconds for the CRT cathode to warm. Even with the monitor off, Arduino 2 is still doing it's thing and creating the video waveforms and dealing with time.  

A temperature sensor is added to display the temperature as well... 

This is connected to A0 of Arduino 2. It's just a cheap 10K NTC thermistor. 

Meanwhile, we need a method for setting the clock. 3 push buttons are added, one for hours, one for mins and one for set, and connected to Arduino 2. When Arduino 2 starts up, it automatically enters this screen, and the hours and minutes can be set with the buttons. Once the set button is pressed, a reset pulse is sent to Arduino 1, and it's restarted, setting the seconds back to zero.

I also added a bit of code to enable easy calibration of the clock. Grounding pin D6 (pin 12 on the actual microcontroller) puts Arduino 1 into a calibration mode, whereby it outputs minutes elapsed since start-up and seconds over the serial interface. Disconnect Arduino 2, and connect Arduino 1 to an FTDI converter and monitor the serial output. Open the arduino monitor , and enable time stamp. Write down the time the sketch started, and the difference between that and the current elapsed time. Leave it for hours, then calculate how far it's drifted and use this value to alter the calibration value in Arduino 1 (old cal factor * ( number of seconds expected / number of seconds counted) . Excellent, it now keeps good time.

Excellent ... what about a chime?

I don't want just a beep or something from the micro... I'd like a proper chime.

(It's at this point, it begins to dawn on me I may have taken leave of my senses...)

A small solenoid is purchased from eBay... 

...and a bicycle bell...

.. all conjured up into a chiming assembly! 

... and a driver circuit created to be driven from Arduino 2.

So the final thing looks like this ...

The vintage crystal is top left, with the 14 bit ripple counter to it's right, and the 7805 voltage regaultor to the right of that.  The horizontal ATMEGA328P is our seconds generator, and controls the power to the monitor, the microphone and amplifier can be seen just below it. The high side FET is there too, and runs very cool, as the monitor draws about ~520mA when running. The vertical ATMEGA is creating the video, and also drives the chime, via the low side FET under the stripey ribbon cable, which leads off to the three push buttons, hours, minutes and set. Video is connected to the monitor via the small coax just above the ATMEGA.

The final schematic.

The clock display itself has three modes.


Clock ...












... pong ...












 ... and 3D cube ...

The software can be found, as usual, on my github page https://github.com/andydoswell/stupid-video-clock , and I've included the TV out library as well, as I've modified it so it compiles without issue, has a "degrees" symbol and tweaked the timing a shade. 

Now, I'd better start thinking about a case for it... some sort of perspex thing?

My colleague , Alan, has given it a good name... "Well, it goes "ping", and plays "pong" ... it's the ping-pong clock" 😁