A quick introduction: by day, I'm a DevOps Engineer at Red Gate, a software company in Cambridge, UK. Outside of work, I enjoy both amateur radio (hence the callsign, M0VFC) and community broadcast radio at Cambridge 105. This blog aims to span all those interests - so feel free to ignore the posts that aren't relevant!
Feel free to get in touch on Twitter (@rmc47).
73 / Best wishes,
Rob
While operating at GB15NH, we managed to let the magic blue smoke out of two radios: Gavin M1BXF's IC-756ProIII, and my Elecraft K3.
The cause was entirely self-inflicted: our 20m and 17m antennas were probably 1m apart, and we didn't have a 17m band-pass filter to hand. We survived a day like this, but on the second day, the beams ended up facing each other, and this proved too much. The ProIII let out some smoke. We swapped it for the K3, which showed the "HI RFI" warning, then went suspiciously deaf.
Symptoms were:
A bit of searching online pointed to D25, a double PIN diode. Iain M0PCB also reported problems with D5 on the KXV3A board.
Inspecting D25 (on the bottom of the RF board, near the LPA) showed it looking a bit supicious, and trying to remove it to test led to it disintegrating:
D25 is a BAR 64-05 PIN diode, and costs all of £0.40 from Mouser - plus a £12 delivery charge for small orders! I ordered 10, to give me plenty of spares if it happens again...
The new part installed:
Everything sprung back into life, with a -40dBm test signal from the Rigol DSA815's tracking generator lighting up the S-meter to 9+50dB, a much more reasonable value.
This bank holiday weekend, Cambridge 105 broadcast live from the Homegrown music festival in Barrow, Suffolk. We bought sets live from the two stages, as well as interviews and live acoustics sets from a backstage green room area.
Jon Watts has published some fantastic photos of the weekend if you want to see what it's like from the point of view of an audience member, but this is a look at the behind-the-scenes engineering.
At the highest level, it's a simple problem: you need some set of sources (microphones, music sources, feeds from stages), a way of mixing them together, and some way of getting the output back to the studio in the centre of Cambridge. However, the reality looks more like this:
By using a digital mixer like the X32, a lot of routing that would previously been complex is made easy. For example:
Talkback was particularly important for this setup: we engineered the show from our outside broadcast van, but the presenters and acoustic performers were in a green room area, out of sight. We needed to be able to cue presenters when the main stages (also out of sight) were about to start, stop, go into new tracks and so on, all while the presenters were live on air.
As well as getting the engineering of this right, it's a real skill for the presenters to be able to keep going while having a voice in their ear talking at them - all credit to Neil and Julian for doing this so well!
Along with the digital mixer comes digital snakes or multi-cores. The S16 allows us to have 16 inputs and 8 outputs remote from the mixer using only a single Cat5E cable - much lighter and easier to handle than a conventional snake.
Finally, we have to get the signal back to the studio. Barrow is much further away from the studio than most of our outside broadcasts, so this demanded a new approach. We used a combination of an IP stream from a laptop in the OB van over 3G and a band 1 (~53MHz FM) link back to a remote receive site where it then hit a separate IP stream. The 3G stream was our primary feed, but automatically fell back to the band 1-fed stream in case it dropped. In the event, 3G held up remarkably well, but it's dangerous to rely on it as the only option, particularly at a festival where a much larger than normal collection of people suddenly turn up in a rural area with their mobile devices.
We just hit a rather confusing issue while building up some new infrastructure for the new Redgate website. We have a couple of IIS servers, sitting behind nginx, which proxies requests through.
Pointing nginx at the old IIS boxes worked fine, but changing it to the new ones resulted in a gateway unavailable error from nginx. More curiously, running curl from the load balancer's console gave an SSL unknown protocol error, yet if we put a hosts file entry on the IIS box itself, everything worked.
Cue tcpdump, Wireshark, and so on, and we could see that after curl sent an SSL Client Hello packet, IIS instantly terminated the connection with [RST, ACK], never sending the expected Server Hello.
Eventually, it turned out we had no default (no-SNI) binding set, and nginx and curl weren't passing a hostname that matched an SNI-enabled binding. So IIS was terminating the connection - very aburptly!
The fix was easy: use the --resolve switch in curl, and the proxy_ssl_server_name and proxy_ssl_name settings in nginx to pass the correct SNI header to IIS.