PiCow - the Raspberry Pi Computer Originated World

There I was, minding my own business, when the lovely owner of Radios-TV.co.uk commented on my PiPatGen thread.....

Dammit! I was supposed to be tidying the workshop (in all fairness, some tidying occurred!)

A PiCow ... why not ?!?? (if you don't know what C.O.W. is ... look here.)

So I did a spot of research into video playback, and found a brilliant video playback program called hello_video designed for continuously looping video for use on advertising hoardings and art installations.

Excellent.

Some footage was conjured up, and exported from my video editing software (Kdenlive) as an .mp4

hello_video needs a .h264 fileformat to work, so I used ffmpeg to create a raw stream. 

ffmpeg -i input_file.avi -vcodec copy -an -bsf:v h264_mp4toannexb output_file.h264

Brilliant.

I created a COW directory and placed the .h264 file in the directory using scp from my main linux PC.

Issuing the command

hello_video.bin --loop  ~/COW/cow.h264

created a wonderful display! It looped seamlessly!

The command was written into the .bashrc file, so it would start up on boot.

The shutdown scripts were added, in a manner identical to the PiPatGen.

I wanted something a little better to shut down the Pi, rather than having to push a toggle button. 

A small timer was conjured up

5V comes into our circuit, and is used to power up a 4049 inverter IC. There's also a feed to a relay coil, and it's normally open contact. SW1 is a normal DPDT ON-ON toggle. On one switch, the normally closed switch is connected to pins 6 & 12 of the raspberry pi's IO's. The NO contacts on the other pole, are connected to +5V via D1 (actually, D1 is a throwback to an earlier iteration, you can just couple the switch straight to +5V!). This is the power switch. When it's operated, pins 6 & 12 are disconnected, and C1 is rapidly charged up to 5V, which switches on U1A, taking the output of U1A low, this in turn feeds U1B, inverting the signal again, and turns on Q1, which energises the relay and supplies power to the raspberry pi.

When the power switch is turned off, pins 6 & 12 are connected, which initiates the pi shutdown script. C1 is still charged up, and starts to slowly discharge through R2. When it gets to about 50% of it's voltage level, the logic does it's thing, and switches off Q1, removing power from the pi. 

R1 is made adjustable, as the time to shutdown a pi varies on which version of the pi you have and the speed of the SD card. When building the device, manually shut down the pi by shorting pins 6 & 12, and set a timer to see how long the pi takes to completely shut down (you can tell as the SD card access LED stops flashing), then set R1 to allow the relay to switch off in a little longer than the Pi takes to shut down, to allow for a bit of a safety margin. My Pi Zero W takes about 9 seconds to shut down, so I set my timer to keep power connected for ~15 seconds. I used a 10-turn pot to make setting a little easier. (Incidentally, the Pi model B takes about 15 seconds, with the same image)

The 4049 is there just as a buffer. I could have used a FET to switch the relay, as that has a very high impedance gate, and eliminated the logic all together, but I didn't!

If your Pi takes longer than the maximum time, make the value of C1 bigger. 

The circuit was built up on a piece of perf-board.
This hardware also works great on PiPatGen, which would eliminate the shutdown pushbutton.

I did try the image on my PiPatGen's hardware, and even on my resource-shy Pi B, the output was smooth. 

Onto making another case!

The PiPatGen's front panel was modified, and despite my Pi Zero having no audio output, I left the audio jack in place, as I can feed some audio into the front panel if required. 

Clearly no shutdown button is now required. 

Another PlayStation modulator was procured from eBay, another case from eBay seller seemoreitems, and a simplified 3D printed front panel was made.

If you're not using an earlier Pi with a video output socket, you'll need to add a couple of header pins, and connect to that... this is the location of the port on my Pi Zero W. The port is marked up "TV" on this Pi Zero W. Check your Pi is capable of a video output before buying, as the newest models seem to have lost this (certainly the 400) 

The image file for the project can be downloaded from 

https://www.mediafire.com/file/sg4pyh07waam1cf/PiCow.img.gz/file

Here's the obligatory YouTube video ...

PiPatGen - The Raspberry Pi Television Pattern Generator.

Recently I came by an old Model B Raspberry Pi, whilst once the cutting edge of single board computing, is now showing it's age a bit.

So what projects can we create today with it?

How about a pattern generator for our vintage analogue TV sets?

It's got suitable composite video output (I *think* even the current Pi's (although sadly not the 400) have this (if you can find one)), so this project *may* work fine on something newer.

Here's the plan:

Have a set of test patterns available, that we can select, say Test Card F, Test Card C, a PM5544 type, maybe the "Native American" pattern, a grey scale, colour bars, SMPTE, cross hatch for setting up convergence... all running straight at boot, selected by switches on the front panel, and a button to safely shut it down.

The latest version of Raspberry Pi OS lite is downloaded and written to an SD card, we don't want (or need) the additional hassle of running a resource hungry desktop GUI.

The system is booted, with a keyboard and monitor attached.

Using raspi-config, the system was set up with SSH enabled, auto-login at boot, composite output enabled etc etc ... 

I installed the FBI (Frame buffer imageviewer), and wrote a bit of python to act conditionally on the position of a 10-way rotary switch in an attempt to display 10 different pictures. 

Whilst FBI does a wonderful job of displaying the images in the console, no way could I persuade it to act on the position of my switch, unless I issued an ESC or CTRL-C between changes on the keyboard. Even using the signals library and attempting to send a killall would work. Once FBI is running, it grabs hold of the keyboard interface and refuses to allow any changes until ESC or CTRL-C is issued on the physical keyboard. Googling the problem shows I'm not alone in my quest.

So, what else can I do? I tried a package called FIM (FBI improved), which performed no differently. 

I could get FBI to scroll through all the images one at a time, by pressing J to step back and K to step forward in the image sequence. This would work, except I didn't want a keyboard attached. I needed a method of generating a "J" and a "K" and getting it into the USB interface as if it were a keyboard. I did contemplate using an Arduino as an HDI (human device interface, that's a keyboard (or mouse) to you and I!) , there's code that I could implement to do this freely available.

Instead I asked on our street's whatsapp group to see if anyone had an old USB keyboard that they were going to get rid of, and someone did!

Excellent. A Dell keyboard duly showed up at the front door, an ideal candidate. The keyboard was quickly disassembled and the keyboard driver PCB extracted... 

Keyboards are generally wired in a matrix, each key connecting an X and a Y (or rows and columns if you like) , and each switch closes one of the X and one of the Y, giving a unique coordinate for each switch, a bit like this...

In this fictitious example above, we can see that J (SW15) puts a short between X7 and Y2, and K (SW16) puts a short between X8 and Y2. All we need to do if discover what connections are made for J and K on our scrap keyboard, and make connections to the encoder board to a couple of push buttons, to make a keyboard with just J & K on it... simple...

The keyboard matrix consists of three layers of plastic film, the top one contains all our "Y" traces, there's an insulating layer with no traces (just some holes that allow the keys to press through and complete the circuit) and a third bottom layer that contains the "X" traces. 

Identifying the two J & K keys, and their contacts is easy enough, and the traces are discovered by testing with a multimeter for continuity. 

Once these are discovered, it's just a matter if wiring up out two push buttons to the appropriate contacts on the USB encoder PCB. My PCB had a layer of black conductive material deposited on the contacts, to facilitate a reliable connection with the plastic traces on the original matrix. This was removed with a fibreglass abrasive pencil, to reveal the copper traces underneath, so they would take solder. 

Now I had a method of skipping forward and backwards through patterns as required.

Next a shutdown button was implemented using a python script in an identical manner to the hospital radio streaming  codec and monitor. Thankfully FBI didn't interfere with the operation of this. The shutdown button connects between pins 6 & 12 on the Pi's GPIO header.

Now, what about some audio. I created a stereo 44.1KHz wav file in audacity and placed some music on one channel (left), and a continuous 1KHz tone on the other (right), this is set to play using the aplay function on boot. I tried using an MP3 player, but it's glitchy with this resource-shy pi.

Next, everything is set to run on boot, and it all works nicely.

As most of my TVs don't have a video input, I'll need to create a UHF output. This is achieved using a redundant PlayStation modulator, purchased for little money on eBay. The modulator case is opened up to save space, and the small RF metal enclosure mounted inside a clamshell case, along with the Pi. Note the european modulator has a setting for I & G, this is for 6 MHz (I) or 5.5 MHz (G) sound carrier settings. Sadly the PI won't output SECAM. American users wishing NTSC output may wish to use a VHF modulator. 

Note on PlayStation modulator wiring:-

White is video in

Yellow is +5V

Red is audio in

Black is Ground. 

The audio is switched between left and right channels of the Pi's 3.5mm audio jack to select tone or music with a simple SPDT toggle switch. 

A front panel was 3D Printed with the holes in it to accommodate all the required functions. The RF is leaving on the rear of the case, via the coax already attached to the modulator. Power is supplied from a USB lead, via a switch, to the Pi and the modulator. Audio from the Pi is switched between L & R channels, and sent to the modulator, and a front panel RCA socket. Composite video is also made available to the front panel.

A front panel legend is created in inkscape, and printed out and laminated. This is then stuck to the front panel. 

I've made an image of the OS etc, which you're free to download and modify here:

https://www.mediafire.com/file/487gmshuabp0qul/pipatgen180624.zip/file

Write the image to a card using Raspberry Pi Imager or Belena Etcher etc ..

It will run straight out of the box in PAL, if you need to modify any settings, see below...

CTRL-C or escape will quit FBI (although the music will still be playing in the background!) ...

It may be wise to change the default password (DTW) at this stage, if you're connecting your Pi to the outside world. 

sudo raspi-config 

whilst you're in there , press 1 , and expand the filesystem to make use of all the space on your card.

sudo reboot

If you need to change the overscan settings or change to NTSC, you'll need to edit the boot config file

sudo nano /boot/config.txt

and edit the overscan lines. Note this is in pixels. 

overscan_left=10

overscan_right=10

overscan_top=15

overscan_bottom=15

and then reboot

sudo reboot

For NTSC change:

sdtv_mode=2

to 

sdtv_mode=0

There's 3 images and a 1K/ Music file loaded, you can change these to suit. Images are found in ~/doz/TestPatterns/ and images should be PNG or JPG format. These are cycled through in alphabetical order. To display correctly, images should be 720*576 for PAL, or 720*480 for NTSC.

The music file can be found in ~/doz/Music/ and must be called TCM.wav 

You can use WinSCP on windows to change these via the network, or copy them straight to the card if you run a linux distro (or use the SCP command in a terminal)

Pye 169 revisited.

Remember the Pye 169 back here?

 
Well... it's been acting up. Rather than the usual write-up, here's a bit of video entertainment, also ideal as a cure for insomnia...

 

Enjoy ... ! 

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" 😁

Video rack repairs and new video multiplexer upgrade!

5 years ago, I built a rack to house the standards converter and video source equipment in the workshop (you can see that post here)... it's time for a few repairs and a refresh.

It's got a few niggling faults.

1. The DVD player no longer ejects, and sometimes doesn't want to play.
2. There's a couple of channels which no longer work
3. There's quite a lot of crosstalk between channels.

Let's address a few of these...

1) The DVD ...

First off some disassembly of the rack case, which allows the DVD player to be removed.











Powering the player up, and there's nothing on it's output... until after a few minutes the unit powers up, and reports "Bad disc" on it's on-screen display...


A few screws later, and the lid's off, the tray front removed and the trapped disc released.











A known good DVD is inserted. At this point it's obvious why the thing won't eject. I suspected a failed tray belt, but that wasn't it... the tray is catching on the front escutcheon. I'll deal with that later. The disc attempts to spin up, fails miserably to get to speed, and then "Bad disc" appears once more.. On the second attempt the player seems to re-start it's firmware...

I check the outputs from the power supply with my multimeter... +5, -12 and +12.. +12 is varying between about 10.5 to 12.5, which may be acceptable. I switch to the 'scope and check the +5V again....

Woah! That's awful - 40V pk-pk of 50Hz crap riding on the output !












The power supply is removed, and a blanket change of all the electrolytic capacitors is performed, to ensure reliability.










The power supply is replaced, and on powering up, the disc spins up rapidly, and then reports "No Disc" ... hmmm ...











The laser pick up is given a gentle clean with some window cleaner (Don't use IPA on any CD or DVD, it damages the coating on the lens), and ....



Bingo, the test pattern DVD fires right up!





The guilty parties....

The sticking front tray is resolved by relieving the front a touch with a file... I suspect it's got distorted by the shelf above it in the rack for all those years...

Good, one fault fixed ... on with the next...

2 & 3 - Channels not working and crosstalk.

This is being caused by the mechanical switches failing on the front panel, there was always a bit of cross-talk (one channel seeming to "float" behind the video of another) as the switch does not provide any correct loading, or buffering between channels... 

What's needed is a proper video (and, of course audio) multiplexer.

I designed this a while ago in Eagle... thankfully Kicad reads eagle files :) KiCad, the gift that keeps giving :)

There are 8 audio and video inputs. 

Each video input is loaded by a 75 ohm resistor, and fed to two MAX4312ESE multiplexing ICs. One outputs the video to a UHF modulator, and one outputs the video to a 625/405 line standards converter. So, under the control of my favourite flavour of microcontroller, the ATMEGA328P, any of the video sources can be sent to either 625 or 405 sources.

The select line of the video multiplexer also feeds two ADG1408Y multiplexers, which switch the audio through to the relevant output device in the same manner. There's a 5532 buffer on the audio output, as there's none in the audio mux, unlike the video mux.

The audio mux requires a negative supply rail, and this is supplied from the microcontroller. A continuous squarewave is output on pin 5 of the micro, is floated by C9, and rectified by the double diode D1 (BAT54S) to provide a "-5V" supply, in reality it's more like -4V. 

The micro is controlled by a front panel , which has two push buttons, and a small OLED display.

A PCB was created... not modelled as it was Eagle, but Kicad has a go at it!

When Kicad imports an Eagle creation, it doesn't seem to cope with the ground plane or component models, but you get the idea... 

... anyway, the real thing turns up from PCBWay.

... and duly stuffed. I'll clean that flux up later ;)

The front panel was also designed. Simple.

and again, built up... not quite so simple though, as my new display has the power and ground pins reversed from the one I modelled :(

... so a minor bodge is deployed...













The software is very straight-forward. It acts conditionally on the actions of the select switches on the front panel to increment the channel address selected, and update the display. I used the U8glib library this time out, as it's got some nice fonts, and is quick, if a bit bulky.

The software can be downloaded from my git. https://github.com/andydoswell/video-rack

It will be noted that the hardware supports 8 inputs, and two outputs, but the software doesn't support that many, as I don't need them all! It's a simple task to enable more, if you wish.


Nice font...












So, back to the rack.



Out with the old...











Tidy up the RF wiring a bit. The black box in the bottom is the Aurora 405 line standards converter. The loop of co-ax you can see is a stub filter, as the output from the aurora is very harmonically rich, and the filter eliminates aome of the patterning caused by the harmonics effecting the UHF. What I really need is a low pass filter .... one day.






The UHF modulator (modified to run on DC, see here) is once again disassembled, so I can adjust the channel and sound carrier spacing via two buttons on the front panel. I've just soldered some wires on the existing switches, and made them available to the front panel.








The Cyclone media player, and HDMI converter are mounted on the shelf, and the multiplexer PCB behind that.


The power supply is a salvage 12V 5A supply. This feeds the multiplexer, and the aurora. It also feeds the modulator via a 42 ohm resistor (to give about 8V) , and an eBay 5V buck regulator, which feeds the Cyclone and HDMI converter.











The front panel is marked out...












... and the holes chewed out with my teeth. I do wish my metalwork was better, anyway, it's only for my own consumption!










And it's all wired up ... what a rat's nest!


















The back's fitted, and it's all powered up and tested - No cross talk, all the inputs work - oh bliss!










Now, there's a rake of telly's here need fixing ....