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.