Insertomatic 6000 Part 4: Finishing up

Summary of the Insertomatic 6000

The Insertomatic 6000 is a device which generates six analogue TV channels for distribution around a domestic tv system, two of which are derived from external sources such as a PVR or digital TV receiver, and four of which are generated by Raspberry Pis. All six channels can carry modern enthusiast teletext services containing a range of artwork and information.

List of hardware features:

• One Raspberry Pi 3 + three Pi Zero 2 Ws fully networked using USB Gadget
• 6 analogue RF channels in total
• ...4 of which are connected directly to the composite video outputs of the Raspberry Pis
• ...2 of which are connected to the two VBIT-Pis, which insert teletext data into the VBI of external composite video sources
• Each VBIT-Pi takes an external composite video source (such as that from a PVR) and adds a teletext service to the vertical blanking interval of the picture; the teletext service can be set independently from the service which is on the corresponding Pi's own output
• A controller board which switches the audio channel of the two VBIT-Pi channels to an auxiliary input when the external video input is switched off, and which allows the three Pi Zero channels to be switched between their own audio and the audio of the Pi 3 under control of each Pi Zero
• Audio selector switches, which select media playback on each of the four Raspberry Pis
• LCD, which displays information about the playing media, and allows the modulator channels to be conveniently changed
• A USB port on the front panel, which makes it possible to take full control of the system and run any program that can run on a Raspberry Pi

A short video demonstrating the TV channels generated by the Insertomatic 6000. Five modern enthusiast teletext services are currently carried. The four Raspberry Pi channels are presently showing slideshows but I hope to add visualisers for the audio in the future.

Safe shutdown

I decided it would be useful to incorporate a shutdown function into the Pi Pico-based controller so that all the Pis could easily be safely shut down without having to log into each Pi in turn and run sudo poweroff as I had been doing so far. I used this Sparkfun example to make the Pis shut down or reboot depending on the length of the pulse received on an input pin, and added some menu options to the controller which enable the user to issue a shutdown or reboot command and holds an output pin low for the correct amount of time.

A DuPont wire harness was made which connected pin 6 on each of the four Pis together and to a single I/O pin on the Pi Pico.

I found a flaw in the Sparkfun code which was that when attempting to issue a shutdown command, execution of the script does not terminate immediately, so if the pin goes high before the script has been terminated by the system shutdown, the restart command will be executed as well, and this overrides the earlier shutdown command, resuting in some of the Pis turning back on. I added a quit command immediately below the call to the shutdown function to resolve this problem.

Noise

My fear with this problem was that the wired construction simply resulted in poor grounds and that there would be no way around it except for creating a massive PCB with everything on it to provide a good ground plane. The fact that adding a single ground wire between a Pi and the modulators made little difference supported this view, but fortunately it wasn't necessary. All the Pis needed individual ground wires to the modulators, and once this was done, the picture quality was improved dramatically to the extent that it was now almost perfect.

Thermals

The Insertomatic 6000 now has a lot of stuff inside a case with very poor airflow, so I was concerned that the Pis would get too hot, especially when used for something more than just internet radio.

A slot was cut in the base acrylic sheet to hold a fan and some holes were drilled in the bottom panel to the left of the Pi 3 to encourage air to flow across the small heatsink on the Pi 3.

The 35mm fan runs at high speed directly from a 5V power supply and makes a lot of noise. Whilst very effective, the noise and the 4W of power consumption were unacceptable, so diodes were added in series until a low level of noise was achieved without affecting its effectiveness very much, and the 2W power consumption was better if still a little disappointing.

Temperature of the Pi 3 measured using vcgencmd measure_temp with all Pis powered up and running the Slideomatic software and internet radio:

• Case closed, no fan: 46.2°C
• Case open, no fan: 44.0°C
• Case closed, fan at full speed: 33.2°C
• Case closed, fan at low speed: 36.5°C

With the Pi 3 running stress for 15 minutes (using the command shown in Part 3) but conditions otherwise the same:

• Case closed, no fan: 72.0°C, soft temperature throttling activated
• Case closed, fan at full speed: 49.9°C
• Case closed, fan at low speed: 49.9°C

vcgencmd get_throttled was added to the for loop from where stress was run to allow monitoring of the throttling status too.

With the Pi 3 under load, the difference between the fan running fast or slow is eliminated which is surprising, but the results at least show that having the fan lowers the temperatures significantly. However, even at the lower speed, the fan is still audible when the room is silent.

I considered adding a simple MOSFET circuit which allows the Raspberry Pi to control the fan via PWM; a Python script could then automatically turn the fan on when a certain temperature is reached or even use PWM to vary the fan speed and possibly drive it at an even lower speed when idle. However, I didn't want to risk introducing another place where noise could get into the pictures, so I decided to keep things relatively simple and add an extra AliExpress buck converter board which would only power the fan; this reduced the fan's impact on mains power consumption to just 0.5W, and the voltage adjustment potentiometer could be used to adjust the voltage to a point where the fan was very quiet but would still reliably start, and this happened to be at 1.82V. The temperature of the Pi 3 running stress was then 55.8°C and idle 38.6°C, a little warmer than when the fan was spinning faster but still much better than no fan at all, so I think it's sufficient to just have the fan running at this speed all the time and not bother adding a speed control.

Keeping all services up to date

The vbit2 package includes a script which keeps the currently enabled service up to date. In the case of the two Pi Zeros which each have a VBIT-Pi, it would be useful if when a different service is inserted using the VBIT-Pi to that inserted in the Pi's own composite video output, it is also kept up to date. The script was modified to update every installed service rather than just the enabled one, which works well. Unused services should be uninstalled to avoid updating unused services.

And that wraps up all the work on the hardware of the Insertomatic 6000. However, it's a project that will never be completely done, because there's always room for future improvements. One idea I'd like to implement at some point is visualisers for the audio playback instead of static images in the slideshow.

Code links

Slideomatic

Pi Pico RF Modulator and LCD controller

Customised version of teletext-update.py

Insertomatic 6000 Part 3: Mechanical and wiring improvements

Mechanical design

The biggest part of this phase would be the mechanical design, as a number of issues had been identified and were to be improved upon.

Depth of the case

The case is slightly too deep to fit in the rack cabinet that I'd like to put it in, and as it should be possible to make everything fit in a shorter case, the case needed to be shortened.

The first step was to deal with the extruded side pieces of the case. Cutting these is easy using the metal bandsaw at the Hackspace, which achieved a perfectly straight cut in seconds. The threads for the screws were then tapped using the correct size taps.

The next step was to cut the top and bottom panels, This was much trickier because the panels wouldn't fit in the metal bandsaw. They can't be cut with the laser cutter either, not even with multiple passes, but the laser cutter can at least cut a line in the paint which serves as a guide for manual hacksawing. This was done, and the results weren't very nice, as just a millimetre of deviation from the line shows up very clearly once the case is assembled, but it's acceptable. A hole was drilled in each panel for the screw which goes into the metal crosspiece near the front of the cabinet.

The internal sheet of acrylic which holds all the PCBs was also redesigned to make the parts fit more efficiently following the decision to mount the Pi Zeros on top of the VBIT-Pis.

Front panel

The design had a few imperfections; the cutout for the pushwheel switches was too big, leaving visible gaps above and below the switches. The cutouts for the three buttons weren't keyed, so the buttons could be rotated. The depth of the front panel made it difficult to plug anything into the USB port. It was also decided that wiring up the LEDs to the activity LEDs on the Pis would be too risky so the arrangement for those was also changed, reducing the number of holes needed. A new front panel was cut with all these changes made.

The LED holders are of a type which are normally secured to the panel using a nut, but in this case the diameter of the holes cut by the CNC were such that it was possible to tap a thread using an M8x0.7mm tap then screw the holders into the panel. This was just as well because the metal and laser cut panels together would have been too deep to get access to the thread of the holders to secure them with nuts.

Electrical wiring

While working on the project, it had become clear that using "DuPont Wire" to connect all the parts together was not so convenient after all. The solution to this problem would come in the form of custom wiring harnesses, which would be assembled from IDC ribbon cable, DuPont-syle housings with the right number of pins for each connector, and proper crimps which would be crimped on by hand. This enabled each cable to be made to the exact length required, making the wiring much neater, and all the connectors being the correct size for their connectors make assembly and disassembly much easier with less chance of error.

Here is one of the wiring harnesses that I made up:

Controller

Channel memory

Obviously it's highly inconvenient for the modulator channels to be forgotten every time the Insertomatic 6000 is turned off, so adding this feature to the Pi Pico-based modulator controller was important.

As is common with these newfangled 32-bit microcontrollers, unlike PICs and AVRs, the Pi Pico doesn't have any EEPROM, and it is necessary to write to the FLASH instead. The main difference is that flash can only be erased a whole sector at a time, which effectively means that all data has to be written in one go rather than updating it whenever each individual setting is changed to avoid making excessive write cycles. This is solved by having a dedicated option in the menu to save the settings when the user is ready. The cycle life is quite high (10,000) and there isn't a need to change the settings often, so it was decided that it would be acceptable to not bother with any wear levelling.

A channel banks feature was added, which makes it possible to save several sets of channels for the modulators and switch between them easily. It could be used to quickly reconfigure the modulator channels when moving the Insertomatic 6000 from where it is normally installed to other places such as teletext exhibitions.

Now Playing info display

I used the Raspberry Pi Foundation's serial PIO example and expanded it to work on four pins on the Pico. I added some code to poll the FIFOs of these PIOs and process the data into some arrays for the cyclic display on the LCD. I then learnt how to control the serial port on the Pi 3 and Zeros so that data could be sent to the Pi Pico; a little bit of code was added to slideomatic.py to process the data returned by the mpc command and send this to the Pico. The data from the Pis is stored and displayed in a cycle.

Power supply

The inductors on the AliExpress buck modules got rather uncomfortably hot even when the Pis were all idle, and the linear regulator the for the modulators also got very hot despite only having a 7V input voltage, and it was decided that this could be detrimental to the long term reliability of the design once the box was closed up. It was decided that a second regulator would be added and each one would only be connected to two of the Pis; the result of this was that the inductors only get slightly warm when the Pis are idle, and only get very warm under a prolonged stress test using the stress command on all the Pis simultaneously. The 7805 regulator was changed to an LDO regulator so the input voltage for that could be reduced to under 6V, and it was mounted on one of the extruded edge pieces of the case for heat sinking, and as a result, this regulator now remains cold.

Power consumption

The following command was used to stress-test the Pis:

for ((i = 0 ; i < 60 ; i++ )); do stress -c 4 -t 60s ; vcgencmd measure_temp ; done

Measured with an inexpensive plug-in power meter, the total power consumption is listed below. From 240V to 5V the power supplies are 75% efficient, which doesn't seem great but as the conversion to 5V is done in two stages, this is still equivalent to 87% per stage. 240V to 5V power supplies tend to be less efficient than those with higher output voltages, so the gain of changing to one of these would not be significant even if that didn't introduce noise issues.

• 15.0W - all Pis idle
• 24.0W - all Pis running the stress test
• 0.1W - when all loads are disconnected from the mains power supply

The power consumption is quite important because the total energy consumption adds up to quite a lot over time when the device is left running 24 hours a day as is the intention. For comparison:

• 4.0W - Single Pi 5 at idle
• 20.0W - Ivy Bridge office desktop at idle with no spinning hard drives
• 7.0W - Ivy Bridge laptop at idle

Next steps

The main part of the project is done, but there's still some work to be done...

The picture quality on some of the channels is still quite disappointing, particularly the channels derived from the external AV inputs. I will experiment with extra ground paths between the modulators and Pis, and find a way to disconnect the +5V power lines between the Pi 3 and three Pi Zeros, which are not helpful when the Pi Zeros have their owm direct connection to the power supply board; this will also enable the second 5V switching supply to be dedicated to the two Pi Zeros with the VBIT-Pis, allowing the lone Pi Zero to be paired with the Pi 3 on the first 5V switching supply.

Hopefully it won't come to the point of having to design a large PCB almost as big as the acrylic sheet to fit all the components and provide a nice ground plane, but at this point this could be done and it wouldn't add a massive amount of cost in the grand scheme of things.

Finally, once the Insertomatic 6000 has been installed in its rack, all that's left is to find some interesting alternative software to run on the Pi 3. It's possible to switch between the Slideomatic screen and the terminal by connecting a USB keyboard and typing Ctrl+Alt+F1 or Ctrl+Alt+F2, so the Pi 3 can be used for other things before being set back to the Slideomatic screen. Perhaps some BBC Micro and ZX Spectrum ROMs for software originally distributed via Telesoftware could be used to create a "Ceefax Game Pass" service!

Insertomatic 6000 Part 1: Assembling some RF modulators into a case and making a controller

The Insertomatic 4000 is a one-off four-channel teletext generator by Alistair Cree designed to feed four different teletext services to a number of TVs. It contains four Raspberry Pi Zeros, four surplus RF modulators, and some switching electronics to allow the audio to be independently switched. My goal is to make an improved version which is tailored to my requirements, with the addition of two external video inputs that would allow two external sources to be turned into RF channels in addition to four channels generated by the Pis. The device will feature some additional controls on the front for RF channel and audio programme selection - the audio programme selection will be used for my device's added focus on internet radio playback.

RF modulators

The RF modulators will be sourced from Sky boxes, as I already know how to use these and it's a fairly abundant source, which means I'll be able to get several identical modulators for the project.

I posted on Freegle and Freecycle to ask for boxes, and this was quite effective.

There were a couple of issues with the Sky boxes though; the first was that the RF modulator had been removed from the later boxes and replaced with a connector for the optional Sky IO Link, but this was a fairly obvious problem and could be avoided once I had learned from reliable sources that the presence of the WPS button on the front can be used to identify the boxes with this feature removed when only a photo of the front was available. The only frustration was that these boxes were super common, as they'd been the standard for over 10 years by this point.

The far less obvious problem was that in the DRX890, Amstrad (who else?) had discovered that they could cut costs by placing all the components for the RF modulator onto the main board instead of having them on a separate module. This meant that it was no longer practical to remove the modulator, as doing so would require the cutting of a multi-layer PCB without shorting any internal layers, then adding wires to tap into the various parts of the circuit, and this would just be too difficult and fragile.

Eventually, I had acquired just enough suitable Sky boxes and removed their modulators. The modulator came out quite easily from the Pace box so that survived, whereas the Amstrad boxes required a lot more heat, presumably because they didn't use thermal reliefs on the internal layers of the main PCB, and were destroyed.

In the past, I turned this Arduino-based modulator project into a more permanent stripboard assembly, but I had been disappointed by the noisy quality of the picture compared to when the modulator was in a Sky box. To address this issue, I bought some tiny 0402 size ferrite beads, and added one inline with the power connection to the modulator. This delivered a significant reduction in noise, so I proceeded to modify all the modulators, opening them up and cutting the track from the +5V pin before adding the ferrite bead inline. With that done, the modulators were then ready for use.

Controller

The controller was to be responsible for programming the frequency of all six modulators and displaying 'now playing' info from each of the Raspberry Pis on a HD44780-compatible LCD which would be fitted to the front panel. Not a huge amount of processing power needed then, but the unusual requirement of controlling six I2C devices with the same address and having four UARTs meant that choosing a microcontroller wouldn't be easy. I decided to go with the Raspberry Pi Pico because its unique PIO feature would allow the implementation of the UARTs. They would also be able to handle the unusual I2C requirement, but I ultimately decided to just use a software bit-banging approach for that since the actual data is very simple and infrequent.

PCB

I used matrix board for the circuit. I fitted two switching regulator boards, one of which would power all the Raspberry Pis, and the other of which would power just the modulators through a separate linear regulator, minimising the possibility of noise entering the modulators from the Pis. I then added the Pi Pico along with headers for connecting the modulators.

The only unusual aspect of the circuit was the addition of a -5V rail. This would allow the HD44780-compatible LCD to operate from the 3.3V supply of the Pi Pico (regulator on board the Pi Pico), which creates a need for a negative voltage to drive the contrast pin. This avoids needing a 5V level shifter for the LCD as would be required if powering it from 5V, and the negative voltage would have been needed anyway since this particular 24x2 character LCD needs about -6V revative to Vdd to get good contrast as it's an extended temperature range LCD.

I2C

Since all six modulators would always be programmed at the same time, I decided that the best approach would be to share the same clock pin for all of them and just have separate data pins, meaning a total I/O requirement of 7 pins.

With AI being the trendiest thing in tech right now, I asked ChatGPT to write a code example for bit-banging the I2C bus for one device. I tested it and it actually worked first time, programming the modulator as expected. I noticed a flaw in the code which was that it drove the pin high and low, rather than only driving the pin low when needed and making it high-Z at other times, which we'd probably get away with since the slave doesn't appear to use clock stretching, but it's not really 'proper'. I pointed out this mistake to ChatGPT and it immediately produced correct code. I expanded the code myself to write different data to each of the modulators, and this also worked as expected.

At this point, I had just a bare minimum demo which proved that the modulators could be programmed and would work as expected. I still needed to add the user interface for programming them, the ability to remember the setting when turned off, and the display of 'now playing' info, but all that could come later.

Testing all the modulators together

I daisy-chained the six modulators, and they all worked as expected. I was aware that these modulators have a little loop-through gain, and with six in series, this could mean quite a significant difference between the strongest and weakest channel. I used an RTL-SDR to measure the strength of each channel, and found that the loop-through gain was exactly 6dB, so a 6dB attenuator would be needed on the input of each modulator to make them all have the same strength. I also decided to split them into two sets of three with a splitter in reverse to combine them, ensuring that the signal wouldn't travel through too many attenuation and amplification cycles before reaching the output.

Mechanical design

The project will ultimately go inside a rack-mount case, but to keep all the components in place, a laser cut panel was made.

A very basic setup was made; the video inputs of the modulators were connected to the Pis but the audio was not. The picture became noisy once the Pi Zeros were powered up; almost certainly due to the setup of the ground paths, which will need to be improved to ensure that the Pis all have a good return path which isn't shared with the modulators.

Next steps

The next steps from a mechanical perspective will be to cut holes for all the connectors and buttons in the front and back panels of the case using the CNC.

From an electrical perspective, the next step to work on is the audio switching. The circuits for this will go in the empty space on the matrix board.

For the controller, the next feature to add is memory for the set channel numbers.

Experimenting with RF modulators part 2: Sky IO Link and control via a Raspberry Pi

Following on from Experimenting with a programmable RF Modulator (making a controller for it and testing harmonics), I have continued my work on this topic with these goals in mind:

• Make a neater VBIT-Pi assembly by integrating the modulator, VBIT-Pi hat and Raspberry Pi into a single unit
• Control a Sky IO Link

Raspberry Pi control

The Raspberry Pi already has I2C support, and it is fairly straightforward to use it from the command line and in a Python script. In my application, the Raspberry Pi is already being used with a VBIT-Pi hat, an open-source hardware teletext generator which adds teletext data to an external video signal, which has two ICs on it connected to the I2C bus. Fortunately, the modulator IC's I2C address is different to the two ICs, so it's simply a case of wiring up the I2C pins to the same pins used on the VBIT-Pi.

The i2cdetect command can be used to test that all the I2C devices are connected:

pi@raspberrypi:~ $ i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- 25 -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- 65 -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

The modulator can then be tested from the command line with a command like this: i2cset -y 1 0x65 0x80 0x10 0x25 0xF4 i (this will set the output to C21)

I modified the VBIT-Pi to remove the composite video output, since that was now wired into the modulator, and add an audio input for the modulator instead. I also added a micro USB port (wired to a GPIO pin via a resistive divider) with the intention of connecting that to the USB port on the set top box that will supply the video signal, so that the modulator is only active when the set top box is on.

I wrote the script to control it in Python. To keep things simple, I only implemented the maths for UHF channels, even though the modulator supports VHF channels.

When pressed into service, the Pi can be set up to run the script at startup. During testing, it can be started from the command line with python3 ./rf-mod.py and terminated with Ctrl+C. If you have no need for the external enable, then all the code concerning the GPIO interrupt can be removed.

# RF modulator example code
# This example controls an MC44BS373CA RF modulator
# from a Raspberry Pi. The GPIO set as an input
# can be used to enable and disable the RF modulator
# on demand, and if connected to the USB port on a
# set top box, will automatically turn the modulator
# on when the set top box is on.

import time

import smbus
# Set I2C bus number (may vary according to the Pi used)
bus = smbus.SMBus(0)

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

# GPIO 23 set up as input.
GPIO.setup(23, GPIO.IN)

device_address = 0x65
# Set desired channel here (UHF only)
desired_channel = 38
# Set to 1 to enable test pattern or 0 for normal behaviour
test_screen_enable = 0
desired_frequency = (desired_channel - 21) * 4 * 8 + 1885
desired_n = (desired_frequency << 2) & 0x3ffc
desired_n_h = (desired_n >> 8) | (test_screen_enable << 6)
desired_n_l = desired_n & 0xff
config_values = [0x80, 0x10, desired_n_h, desired_n_l]

def configureModulator(gpioChannel):
        #gpioChannel only needed for setting up event handler; it doesn't do anything
        try:
                time.sleep(1)
                bus.write_i2c_block_data(device_address, config_values[0], config_values[1:4])
                print("RF Modulator configured: C", desired_channel, " System I")
        except:
                print("I2C Bus Error (Modulator probably not powered)")

#Configure now just in case modulator is already powered
configureModulator(0)

try:
        GPIO.add_event_detect(23, GPIO.RISING, callback=configureModulator, bouncetime=2000)
except KeyboardInterrupt:
        GPIO.cleanup()       # clean up GPIO on CTRL+C exit

#Loop forever - should not be resource intensive
while True:
        time.sleep(1000)

GPIO.cleanup()           # clean up GPIO on normal exit

This works very well and reliably. The output of the modulator is fed into the house AV distribution system, making it available at every TV point in the house. In retrospect, it may be more useful to use the set top box signal to control a multiplexer which switches the video input between the set top box and Raspberry Pi's composite video out, instead of turning the modulator off. The Pi could then be used to display an "in vision" service or other video content when the set top box is turned off.

Sky IO Link

The Sky IO Link is an RF modulator in a small box which was introduced alongside later Sky+HD boxes where the built-in modulator was removed to reduce costs. This modulator is still made today (2022) by various manufacturers and sold at a low price (~£10), which makes it a great choice for any project requiring a modulator.

The modulator is similar to the ones that were previously built into the Sky boxes, but with an Abilis modulator IC rather than the Freescale one used previously, but the IC claims to be a drop-in replacement, so it should work with the code I've already developed.

The short cable is terminated with a 10-way mini DIN connector, and probing around suggests the following pinout: (wire colours on my unit shown)

The VBIT-Pi's open-source PCB layout could be modified to include the mating connector, which would allow neat and tidy integration with the Pi.

For testing, I wired the connector up to the Pi's GPIO header and connected the video input to the Pi's video output:

• 4 (Power supply) - 2 (5V)
• 5 (GND) - 9 (GND)
• 6 (SCL) - 5 (GPIO 1 / SCL 0)
• 7 (SDA) - 3 (GPIO 0 / SDA 0)

The SCL and SDA pins require pull-up resistors, and should be pulled up to 3.3V (not 5V as shown in my photo, but I got away with that bodge).

I ran my Python script from earlier (changing the SMBUS port to 0 for the original Pi in use here) and it worked perfectly.

Experimenting with a programmable RF Modulator (making a controller for it and testing harmonics)

I was scavenging two old Sky boxes for parts, and although the very large scale integration of the mid-noughties set-top boxes meant there was very little worth removing, I did extract two of these RF modulators.

RF Modulators convert composite video and audio into an analogue TV channel that can be received on any television set and combines it with the signal from the RF input, enabling the picture from the Sky box to be received on every TV set in the house in addition to the off-air channels. Sky RF modulators are unique in that they have two outputs, one of which features line power and a low-frequency return path to support the "digilink" system, which allows the Sky box to be controlled from the other TVs. See diagram of this setup. This blog entry, however, will focus on the RF output rather than those additional features.

The modulator is completely shielded, but the shielding clips off easily to expose the insides. Much like the rest of the Sky box, the modulator is very highly integrated, and it uses a Freescale MC44BS373CA single chip solution. Impressively for a design which handles signals of up to nearly 1GHz, the modulator is built on a single-layer PCB, presumably to keep costs low. The circuit appears to be largely based on the application circuit in the datasheet, with the addition of some passives and transistors to handle the line power injection, IR return path, and amplification of the RF input. The 75-ohm termination resistor on the video input is missing.

The MC44BS373CA is frequency-agile, which means it can be programmed to work at different frequencies, all the way down to 45MHz in fact. Despite this, the Sky box only allows selection of UHF channels, despite VHF System I still being used in Ireland, so let's find out why not...

Programming the modulator

The modulator has a very simple I2C interface documented in Table 8 in the datasheet, and it supports 5V and 3.3V operation, allowing easy interfacing to Arduino, Raspberry Pi, etc.

The controller is supposed to have a programmable I2C address, but this feature is not available on the package used in this modulator, so it is fixed to 0xCA (8-bit).

There's not a lot of settings that can be configured. The main settings of interest are the oscillator frequency (N11:N0), divider (X2:X0), and test pattern enable (TPEN). The sound frequency bits (SFD1:SFD0) should simply be set to the appropriate setting for the region (10 for System I).

The relationship between frequency, divider and N11:N0 is simple, and I've put it into a table here:

X2:X0 (Divider)	N11:N0	F (MHz)
000 (1)	4F	N/4
001 (2)	8F	N/8
010 (4)	16F	N/16
011 (8)	32F	N/32

The oscillator is rated for 460MHz to 880MHz, so it's necessary to use the divider to use lower frequencies.

Example project

I made an Arduino sketch to control the modulator. It allows selection of the channel number, from which the frequency and divider are automatically calculated, plus selection of the system (B, D, I, M) and the test pattern.

I haven't included a schematic because the wiring is very simple; all pins are defined in the code. The only important components to remember are the pull-ups on the I2C bus (hidden under the LCD) and the 75-ohm termination resistor between Video In and GND. Failure to include the latter results in horrendous close-spaced ghosting caused by signal reflection.

This controller was used to enable easy control of the modulator during testing.

Link to the code on GitHub.

Real-world testing

My current oscilloscope can only show the spectrun of signals up to 25MHz, so we can't look at the output spectrum, but what we can do is examine the output picture under various different test conditions.

The datasheet gives two figures for the minimum frequency in different places: 30MHz and 45MHz. The latter seemed to be true.

The programmable oscillator seemed to work down to about 400MHz, below which there was no output and it was necessary to up the divider. It worked fine up to 900MHz, the highest any TV I had went up to, so it may have gone even higher.

The single-sided board didn't seem to compromise the quality at higher frequencies.

The picture had lots of 'sparklies' when using the highest divider (16). It's not needed to access the lowest frequencies anyway.

Harmonics

What parts are of particular interest? These graphs...

Look at the signal levels of those harmonics. Unlike this newfangled digital stuff, analogue TV is very suspectible to interference, and a signal to noise ratio of 46dB is required for noise-free viewing. These harmonics result in a signal to noise ratio well below that at affected frequencies, which will spoil anything on those frequencies. The 2nd harmonic is at two times the set frequency, 3rd at three times, and so on, so this isn't a problem when using UHF output frequencies, but at VHF output frequencies, this becomes a problem.

Example 1: Set frequency (1st harmonic) 119MHz, harmonics at 357MHz, 595MHz, 833MHz.

Example 2: Set frequency (1st harmonic) 48MHz, harmonics at 144MHz, 240MHz, 336MHz, 432MHz, 528MHz, 624MHz, 720MHz, 816MHz.

Here we examine the harmonics on a TV screen when the test pattern is enabled. The datasheet only shows graphs for the 2nd and 3rd harmonics, but in fact there's a lot more where those came from; whilst I couldn't find the 4th harmonic, the 5th, 7th, 9th, and so on, are quite strong too, but each harmonic is weaker than the last.

Now let's see what happens when one of those harmonics happens to correspond to a TV channel. An analogue channel is viewed on C24 (495.25MHz), and the modulator is set to 165.08MHz (then 99.05MHz) so that the third harmonic (fifth harmonic) is at the same frequency as the channel being viewed. Note that the Arduino example cannot select this frequency, so a direct I2C write is required (N=2641, divider=4).

Unsurprisingly, the result is terrible co-channel interference, which looks like this:

When the third harmonic is the source of the interference, it is possible to see a faint image of the picture being transmitted by the programmable modulator. The interference is reduced with higher harmonics. The last screenshot shows the quality of the 5th harmonic with the source of the real C24 disconnected.

Noise of a different kind

The convenient 5V power supply makes it tempting to power projects using it from a phone charger. This should be done with great care, as any noise from the power supply will be visible on the modulated output. I can't provide a screenshot of this; the picture has to be watched to understand the irritation of the effect properly.

Summary

These modulators provide good results and flexibility as long as their limitations are considered. The I2C interface allows easy programming and integration into video-based microcontroller projects such as VBIT-Pi (as long as the noise is considered), and the loopthrough and dual outputs allow easy integration into TV distribution systems. The only real limitation is that when VHF channels are used, it will usually be necessary to use external output filters to combine the new channel with a distributon system to avoid interference from the harmonics.

Other bonuses of this modulator include the high signal output level, which allows the signal to be split to many TVs without introducing noise, plus I believe the RF input is amplified a bit too, though I haven't been able to test that.