Back in my first piece on this subject this I briefly mentioned NICAM’s original use-case – FM radio backhaul.
The linked article shows two large (6RU) “coders” stated to have been installed in 1983 [this date may refer to the earlier “NICAM I” design – the equipment shown here is from 1988]. I asked if we could have a look at them, and a few weeks later, I got my wish. A very big thanks to Justin Mitchell for answering all my questions and getting all of the related information out into the public domain. It is this willingness to spend time humouring crackpots like myself which upholds the corporation’s reputation for technical excellence and openness.
First, let’s get the backstory out of the way. Much has already been written on this subject. I am not going to repeat it in detail. I’ll summarise:
Back in the early days of FM broadcast, the BBC had a problem. The studios were here in London, but the majority of listeners were elsewhere in the country. The Crystal Palace transmitter site cannot cover the entire nation. Many other transmitters are required, each needing the audio signal from London in order to broadcast it, but how to get it there?
Various schemes were devised, including, sending them as analogue signals over leased lines (BT landlines). Inevitably over such long distances, the signal quality deteriorated. While listeners in the South East enjoyed pristine sound quality, listeners up North most certainly did not. In many cases they didn’t even get stereo.
Enter the BBC Engineering team for some
levelling up actual problem solving. It was clear the solution was to go digital, even though, ultimately FM is an analogue broadcast. The analogue signals would be digitised in London, distributed around the country using BT’s PDH infrastructure, then converted back to analogue signals at the sites of transmission for Broadcast. Various solutions were explored and built starting from the 1960s, with the BBC finally settling on a NICAM-676 solution, which is still in-use to date.
Throughout this post I will be making comparisons to the Philips NICAM-728 solution we saw previously. It was designed a little earlier than this NICAM-676 solution and has a different purpose but has enough in common to compare.
Yes, this is what we’re here for…
These units have all been removed from service and replaced with a newly built design, still using the exact same NICAM-676 encoding but with contemporary components.
Taking the front off we are greeted with five assemblies, once again fitted to a backplane using DIN41612 connectors.
Each coder and decoder handles 6 channels, or 3 stereo broadcasts. Audio inputs can be either analogue or digital depending on configuration.
Examining the block diagram for the coder, we can see there’s quite a lot going on here. The key difference to what we’ve seen previously is that instead of a modulated RF output, the three stereo outputs are multiplexed into a single data stream, which is encoded using HDB3. This is then transported to transmitter sites using an E1 line provided by BT.
It also differs in that the coder immediately decodes its output, and provides it in analogue form, and digital AES3. There are alarm outputs too, which would have been monitored 24/7 by an operations team.
This assembly has the same job as Unit 3 of the Philips solution, and fundamentally it is very similar. It digitises 3 balanced audio inputs, thus two of them are required per coder. The BBC Engineering team opted for a single Cirrus Logic CS5014 ADC per channel, incorporating most of the front-end leaving only minimal analogue circuitry before the ADC.
Another prominent feature is the 15 KHz low pass (anti-alias) filters. Not so keen to attempt to roll their own, they’ve bought one from (somewhere). I was unable to find any information about the manufacturer. They kind of look like they were made in someone’s garage. On the schematic they are stated to have a dual rail power supply, thus there are likely integrated circuits contained within.
This assembly has the same job Unit 5 in the Philips solution. Visually, it puts its counterpart in the shade, that is because it isn’t just coding – there is a whole lot of other stuff going on here too.
In the near dead centre, we have a very special chip: The BBC’s own NICAM coding (and decoding) LSI. As far as I know, this is the only LSI ever manufactured capable of NICAM coding. Everything else (that I have seen) is either software based using a DSP or CPU, or an FPGA. This in its self is worth recognition because getting custom chips made in the 1980s came with unpleasant strings attached. This is definitely the coolest period coder design I’ve seen.
Where to even begin untangling this thing…
First of all, depending on its configuration – it can accept either a digital input (AES3 format) or digitised signals from the ADC assembly we just looked at. The digitised data is then converted to the appropriate format for compression/coding. Now the coding. Notice that there is only a single NICAM coder, dealing with three channels. The coding is done on a time slice basis by a tangle of sequencing logic, this is (in-part) driven by “EPROM logic” contained within the bank on the left.
The final frame containing all three stereo channels is divided up into a fixed set of time slots. A counter then cycles the EPROM’s address pins through all of the slots, their data lines then effectively providing instructions to the rest of the devices on the board (including the coder LSI) as to what to do at that particular time. Finally we finish with a single 2mbit stream of encoded data – Three 676kbit streams interleaved together. Three radio stations.
But wait, there is more. On the top left hand side, we have three Philips SAA7220 digital filters, which we saw previously in the PM5688. These are here because this assembly also decodes its own freshly coded audio, for the monitor outputs. These chips are a key step in that process. They were also commonly found in 1980s era CD players.
Finally, we have the HDB3 line encoder. With that in the bag this unit is able to directly drive an E1 line (line termination equipment excluded of course).
CPU & AES3 Input
On this assembly we have a Z80 CPU and accompanying logic which provides diagnostics and housekeeping functions. The handbook goes into more detail of course.
Also we have
three four Philips SAA7274 format converters. These convert 6 external AES3 digital audio inputs into the 2’s compliment binary audio format needed internally. The fourth is for provision of a master clock signal over AES3. Despite Philips having made the silicon supporting this, we don’t see them bother with this interface at all in their NICAM-728 solution. I’m told the BBC never used the AES3 inputs either.
The coder also includes an audio output assembly for the monitor analogue output. It is very similar to the assembly used in the decoder. I’ll cover it in more detail later in this post.
It is a simpler design to its decoder counterpart as it does not have signal level monitoring or mute control.
On the rear panel we have a variety of D-sub connectors (the BBC like D-sub connectors it appears) for monitoring and control. All of the analogue audio connections are on rectangular multipin connectors, likely headed off to a patch panel.
A lot of real-estate is allocated to the many XLR connectors for the AES3 inputs and monitor outputs, which never got used. One of the most key connections is labelled “HDB3 OUTPUT”. This is how the coder connects to the E1 line.
At the time of writing these are still in use at transmission sites around the UK. I’m told there is a plan to replace them with the same piece of equipment which has already replaced the coders.
Physically the decoder resembles the coder, both were pictured earlier. A point of interest is that these ancient lumbering beasts still live today, unchanged, having had such a long lifespan. In NICAM-728, receiving hardware was a short lived consumer product, refined every few years, made ever cheaper, ever smaller, ever more integrated; eventually disappearing into a single system-on-chip powering the entire product.
Because the decoder does everything the coder does, but in reverse, we’re going to find that it has things in common with it – specifically that sequencer block is looking rather familiar.
This assembly has the same job as Unit 3 in the Philips solution and is of a very similar design. It can handle all six channels (3 stereo) on its own. Once again we have the legendary Philips TDA1541A DAC we saw used by Philips in their solution. This long discontinued chip is held in high esteem by the Audiophile community to-date and used samples can fetch quite a high price.
It features de-emphasis and an anti-aliasing filter. The de-emphasis is required by NICAM, the anti-aliasing filter is required by the DAC. I have actually swept the frequency response of the circuitry after the DAC (of the Philips counterpart) on this post, the BBC version will be very similar.
It has additional features not found in the coder’s version of this assembly – specifically mute control and signal level monitoring. Like the Philips counterpart each output is doubled up with a second monitor output too.
You may have noticed there are two of these installed in the decoder. Say what?
Examining the block diagram, we can see the BBC’s engineers were quite worried about this assembly failing, because the whole DAC/analogue section is doubled up, the output signals are compared. If differences exceed a pre-set threshold, an alarm signal is asserted.
This assembly looks rather similar to the coders NICAM Encoder assembly. That is because it is. It runs the exact same process, but in reverse. It even has the same BBC designed LSI at the centre, running in “decompress” mode. It also has a mechanism to synchronise the NICAM logic with the source.
But, there are six SAA7220 digital filters instead. That is because it drives two DAC output cards (as detailed in the previous section), so they doubled up. Sure, why not. Even the 74LS674 shift registers feeding these chips are doubled up. Crikey, they were worried. Very worried.
CPU & HDB3 Sync
This card performs the housekeeping and diagnostics functions. An immediately visible feature is the large array of rotary switches seen on the block diagram previously. These are for setting the warning/alarm thresholds of each channel. Inevitably some installations are more error-y than others therefore different thresholds are needed. It’s when the errors go above what is expected that an alarm needs to be raised.
The CPU is able to pry into the decoders memory for fault finding purposes using a bus arbitration system, where there are a number of pre-defined time-slots in the decoding process that allow it to do so. If it attempts to access this memory outside of its allocated slot it is forced to wait. This feature is shared with the coder.
Also on this card we have the logic for synchronisation of the incoming HDB3 encoded data from the E1 link back to London which is needed when the unit is first connected to the source, and when/if sync with the source is lost.
Bonus: RDS Components
Radio data system is the technology which allows receivers to display the name of the track to the listener. It was launched in 1988 and showcased at IBC-88.
At a high level the RDS system provides a multi-drop simplex RS-232 channel between London and the transmitter sites around the rest of the country.
The combiners are the transmitting end of the solution, and lived in London.
The combiner doesn’t have a particularly difficult job and is a part of the solution that the average hobbyist could design and build. It’s based on a Z80 microcontroller. The combining process is simple. The coder sends a regular interrupt to the combiner indicating that it is ready to accept data, the splitter sends the data to the coder (at that exact time), the data is then spliced into spare bytes in the NICAM frame inside the coder. If there is no RS-232 data to send, the combiner still has to transmit a structure to indicate that there is no data available.
It has a some configuration options – baud rate (300 – 9600 is supported), you can even configure the behaviour of the LEDs. The handbook states:
Some people prefer Red LEDs which are normally off. Others want Green LEDs which are normally on.
Personally I like a little bit of both, depending on what the LED is for, and what mood I’m in. The team (or perhaps person) behind this equipment can’t have been on a tight schedule.
There is another rather interesting feature on here, that 40 position ribbon cable connecting the board… to it’s self? The front half of the board is a standard BBC designed microcontroller block, used in other designs, whereas the rear half (containing the UART) is specific to the combiner. The interlink was put there to aid development and debugging.
The splitters are the receiving end of the solution, and lived in the transmitter sites dotted around the UK.
They are extremely similar to the combiners, however working in reverse.
BBC Engineering have released a boatload of additional information about the system detailed in the post:Posted in Broadcast tech, NICAM, Vintage audio
2 thoughts on “NICAM II: BBC Engineering opens the archives, shows us some vintage kit”
You mention about the BBC engineers using dual redundant circuits because they were “worried”. That’s not the case, up until the late ’80s it was just standard practice (& best practice!). However, things changed when cable TV companies started up in competition to BT & they wouldn’t pay for system resiliance – I was designing VLSI chips for E1 & SDH mux’ing/switching in the late ’80s. We had to design the chips to work in 2 operation modes, one without redundancy ( for use in cable TV company’s equipment) & the other mode to work as a dual redundant pair with automatic switchover without data loss ( used in the equipment specifications issued by BT).
Thanks for writing these articles, very interesting to hear about these hidden pieces of engineering & a nice trip down memroy lane – except for being reminded of the nightmare of designing HDB3 codecs in a minimum number of gates 🙁 .
Thanks for the comment. As for the worrying. It depends on your perspective. Good engineers worry about every possible problem 😉