The Spicy Spud is a unique Cambridge phenomenon which probably occurs in other places too. Every fish and chip or kebab take away in Cambridge seems to do them – except the ones that don’t. There is no standard recipe or supplier, so each shop has their own version. This recipe is my attempt to recreate the spicy potato of my youth. Best eaten with huge gobs of chip shop mayonnaise – the nastiest, gloopiest, vinegarest, stuff available – after several pints of IPA and a terrible band at the Sea Cadet Hut. The Spicy Potato is heaven in a greasy cardboard box.
It is basically a potato chunk, covered in a batter and rolled in breadcrumbs. The only spice it actually contains is pepper but various salts are used to give it extra flavour. Adjust the ingredients to your taste until you are taken back to the halcyon days of The Destructors belting out “Sewage Worker” while you jump up and down and try not to spill your 70p pint.
Ingredients:
3 or 4 large potatoes. I use baking potatoes, chopped into roughly 30mm cubes.
For the batter:
50g flour
2 tsp onion salt
½ tsp garlic granules
½ tsp celery salt
85ml milk
For the coating:
6 Tbsp breadcrumbs
6 Tbsp flour
1 Tbsp coarse ground black pepper
Put the potatoes in boiling water, bring them back to the boil and simmer for 5 minutes. Drain well and make sure they are dry. Let them cool down for a bit. Don’t cook them until they are soft – we don’t want mashed potato.
Heat a pan of sunflower oil (about 40mm deep) to 140C. Pre-heat your oven to 180C.
Make the batter by mixing the ingredients together and smushing out the lumps. Coat the potatoes with the batter and put on a rack to drain the excess. You don’t want too much batter on them or you end up with huge lumps of coating. This can also happen if the batter is too thick.
Mix the coating ingredients and roll the battered pots in it to get a nice even coating. Be careful when handling them because it’s easy to scrape the coating off at this stage. Like Luke Skywalker, I use the forks to move them around.
Put them in the oil in batches of 4 or 5. Cook them for 30 seconds and whip them out again. All you are doing is solidifying the batter and infusing some oil into the coating. The actual cooking happens in the oven.
Put them on a baking tray and put them in the oven for 25 minutes, turning at 15 minutes. For an authentic non-crispy coating, cover them with foil after 15 minutes and cook for another 20 minutes.
Enjoy your spicy potatoes with the cheapest, most horriblest mayonnaise you can find.
I have just upgrade 18.04 to 20.04, which went fine. But when I tried to log in, it would just dump me back at the login screen again. Looking through the logs I saw the line
(EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)
The permissions for /dev/tty7 were fine. Various pages suggested solutions like removing .Xauthority, editing /etc/X11/Xwrapper.config, re-configuring gdm3 or uninstalling and reinstalling gdm3 and ubuntu-desktop-simple. This place has got loads that didn’t work for me.
Anyway, long story short – I noticed that there was a big delay logging in to a console. Sometimes this can be because it’s trying to mount a remote filesystem with NFS and timing out. I had 4 entries – two of which were for a computer which was turned off. They both had the “noauto” flag set, meaning they shouldn’t be mounted automatically but they were still messing up the login procedure. Commenting them out fixed the problem and I could log in normally.
This is a little sub-project of what I’ve been working on recently – a hideously over-engineered Raspberry Pi-based system to measure the amount of beer left in the kegs in my keezer.
Normally I would simply set up a web server on the Pi and have it on the home network, so I could see the levels remotely. The problem is that the routers are all inside the house and the Pi is in the garage, invisible to them all thanks to the 2 external walls between them. I needed some way to read out the beer levels on my phone – after all, walking up to something and looking at the level gauge is so last millennium.
So – Bluetooth or some sort of ad-hoc Wifi thing? I like to re-use stuff I’ve got lying around in drawers, so the solution seemed to be an old WiFi dongle that was gathering dust. And Bluetooth is awful. Setting up a Pi as an access point is fairly well covered on the internets, but this is a bit different in that we don’t want to forward traffic onto our network like an access point – not that it could connect anyway, being out of range. I also didn’t want to install a web server on the Pi. It’s only a Pi 1 model B, so sticking Apache and PHP on it might be asking a bit much – especially when you can do it all with one command and a small BASH script.
So the cunning plan was to take advantage of a feature of public access points – the ones that show you a registration page for you to fill in with fake info.
When you connect to a public WiFi hotspot your device tries to load a page on the internet using non-SSL http. It might be any page (captive.apple.com/ seems to be popular), but it will be a web page that the device knows should exist and if it loads, your device knows the internet is working.
A public access point intercepts the page request and, rather than forwarding it, sends a 30x redirect HTTP response back to the device – basically hijacking the request and spoofing the reply. Your device then loads up the page it has been redirected to and displays it as a sign-in page.
It is this mechanism that I used to show the keg levels on any phone, just by connecting to the Wifi. This is how to do it if you want to do something similar. I’m assuming you SSH on to a Pi connected with an ethernet cable to your network, and you have a Wifi dongle hanging out of its USB port. In all likelihood they will be eth0 and wlan0 respectively, so I’ll use them.
wlan0 is going to use a different range of IP addresses from the ones used by eth0, so edit /etc/dhcpcd.conf to manually assign an IP address to the wlan0 interface. Add this at the bottom (comment out any existing definition for wlan0):
The second two commands disable the services we just installed so we can edit config files before starting them again.
Create the file /etc/dnsmasq.conf and put this in it:
interface=wlan0 # Usually wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h
address=/#/192.168.4.1
This tells dnsmasq to assign the range 192.168.4.2 – 192.168.4.20 with a netmask of 255.255.255.0 and a lease time of 24 hours. The third line tells it to return the server address for all domain lookups that aren’t in /etc/hosts, i.e. all of them. When dnsmasq restarts it will look at this file and load up the config information.
Now to set up hostapd. Create /etc/hostapd/hostapd.conf and put this in it:
interface=wlan0
driver=nl80211
ssid=Your SSID here
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
ignore_broadcast_ssid=0
It’s pretty obvious what is happening there, other than some of the technical bits; wmm_enabled is something to do with packets (no idea what, though), macaddr_acl tells it to whitelist all connections and ignore_broadcast_ssid tells it to broadcast the SSID – set it to 1 to hide it. There is no WPA password or setup, obviously. Change the SSID to something hilarious.
Now you need to tell hostapd where to find the config file when it starts. Edit /etc/default/hostapd and add (or uncomment and edit) the line:
DAEMON_CONF="/etc/hostapd/hostapd.conf"
We have now set up our access point. Start dnsmasq and hostapd again:
If there are no errors, your AP should show up in the list of APs on your phone, laptop etc. Try connecting to it – it should connect but you won’t be able to see the internet because there is no forwarding. One thing you can still do however, is connect to SSH on the Pi. You really don’t want any ports other than 80 visible from an unsecured AP. We’ll use iptables to set up a firewall and do the test page hijacking.
sudo iptables -A INPUT -p tcp -i wlan0 --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -i wlan0 --dport 53 -j ACCEPT
sudo iptables -A INPUT -p tcp -i wlan0 -j DROP
sudo iptables -t nat -A PREROUTING -p tcp -i wlan0 --dport 80 -j DNAT --to-destination 192.168.4.1:80
The first two tell iptables to allow through connections on port 80 (HTTP) and 53 (DNS), the second tells iptables to drop all other TCP connections from wlan0. The third redirects any connection with a destination port 80 (regardless of the IP address) to the Pi at IP address 192.168.4.1, port 80, for our server to handle. If you are a bit confused about how iptables work, this flowchart will either clear things up or make it more confusing. Basically there are 4 tables – filter (default if no -t switch), nat, mangle and raw which each contain “chains” such as INPUT which are the instructions on how to route traffic. It’s a vast subject and I learned just enough to work out the 3 lines above. There are other guides that go into more details.
One thing to do at this point is make it so that the iptables configuration is not lost when the system is rebooted. This command saves it to a file:
sudo iptables-save >/etc/iptables.ipv4.nat
To reload the configuration on boot put this in /etc/rc.local
iptables-restore < /etc/iptables.ipv4.nat
So, moving on to the web server. I’m using socat and a bash script. socat is one of those amazing Linux tools that is impossible to explain to a layperson. “What it does is, it takes data from one place and puts it in another but it’s more complicated than that…” and so on. Best just to tell them it’s the computer equivalent of magic, before their eyes glaze over and they start thinking about feigning an illness in order to escape. We are going to use it to pipe data from an internet port to a script and back again. Incoming text from port 80 is sent to the script on stdin and anything written to stdout gets sent back to the port. It’s easy enough to set up with this command:
Obviously change “your_path_here” to where you are doing all this stuff and put this line in /etc/rc.local if you want it to start automatically on boot. The command tells socat to listen on port 80 and then fork off the script when there is a connection. The script referred to as /home/your_path_here/server.sh is this:
#!/bin/bash
PAGE_NAME="kegs"
FOUND_URL="http://1.1.1.1/$PAGE_NAME"
request=""
while read -r -t 5 line; do
if [[ ! -z "${line:-}" && $line == *[^[:cntrl:]]* ]]; then
if [[ ${line:0:4} == "GET " ]]; then
request=$(expr "$line" : 'GET /\(.*\) HTTP.*')
fi
else
break
fi
done
if [[ "$request" == "$PAGE_NAME" ]]; then
printf "HTTP/1.1 200 OK\n"
printf "Content-Type: text/html\n\n"
cat index.html # Show this as a registration page.
else
printf "HTTP/1.1 302 Found\n"
printf "Location: $FOUND_URL\n"
printf "Content-Type: text/html\n\n"
printf "Redirect to <a href=\"$FOUND_URL\">$FOUND_URL</a>\n"
fi
That’s pretty dinky for a web server, huh? Don’t forget to change permissions of server.sh with chmod 755 server.sh. Rename PAGE_NAME and FOUND_URL to whatever you want. Note that because we are grabbing all port 80 traffic coming in on wlan0, it doesn’t matter what you put for an IP address – it’ll all go to our server. The first block of code reads the HTTP request coming from the device, which will be saying something along the lines of:
GET / HTTP/1.1
Host: captive.apple.com
Accept: image/gif, image/jpeg, */*
... and so on
The script ignores everything except the GET /… part, from which it extracts the page name, if any. It won’t match (unless the test page is called “/kegs” – unlikely), so it will respond with the redirect code 302, to send the device to “/kegs”. The device sees the redirect, thinks it’s for a registration page and loads 1.1.1.1/kegs. This time the script sees that /kegs has been requested, sends a 200 OK code and the contents of index.html, which the device displays. My beer measurement system generates index.html as a page showing how much is left in each keg.
As a useful tool with which to quickly see the levels of my kegs without any fuss, this is rubbish, quite frankly. But then the whole raspberry-pi-based-keg-measurement thing could be replaced with cheap mechanical bathroom scales, so I might as well go all in on the pointless technology.
Updated 10/6/2020 : Improved the firewall rules. Updated 18/2/2021 : Improved DNS rules.
In part one of this guide it became clear that a Raspberry Pi with a 700 mm long wire on pin 7, running a variant of the PiFM software is an easy way to make a nuisance of yourself. We might not be broadcasting kilowatts of power and realistically, you are not going to be knocking planes out of the sky, but the Pi is a dirty old man when it comes to broadcasting and we need to clean up its act.
The obvious way to do that is to put a filter between the Pi’s output and the aerial. If the design considerations and analysis of the filter’s performance don’t interest you, skip to the end for circuit diagrams, construction instruction and purchase info (possibly).
As always, these posts are for educational use only. Do not use your Pi as a transmitter unless it is legal for you to do so, which is highly unlikely. Using a filter will not make it any less illegal for you to use your Pi as a transmitter. Always brush your teeth before bedtime and be nice to people.
To recap, this is typically the sort of thing that comes out of your Pi when you use it as an FM transmitter:
There’s a lovely spike around the 144 MHz mark, which is the amateur radio 2m band. There are probably not many radio hams near me that like the sort of music I listen to. Come to think of it, some times I’m not sure I do either. In general, it’s a broad splattering of crap all over the spectrum. And the Pi’s transmitted output is just as bad, ho ho ho. Ahem. This is the sort of thing we need:
You might notice R1 there. The GPIO pins are not designed to drive inductive or capacitive loads, so we need to make the filter input a bit more friendly. The easiest way is to put a resistor between the Pi and the filter’s inductor. I’ve tried it and it works, but it does reduce the range of the transmission. If you want to try it without R1, don’t blame me if you fry your Pi. There’s about 5 dB loss with this design, which might be fine for you. For me, it reduced the range just enough that the signal was fading out if I stood in the wrong part of the kitchen. The solution was either to avoid using the fridge or to amplify the output a bit.
I’m not an expert with RF circuits (although I probably know more than you), so I used the interwebs to find a design that would
Be cheap
Work on a 5V supply
Not require any fine tuning
Be cheap
Be easy to make
Not have any expensive components
You can probably tell what my priorities were. This was the prototype:
Those with a keen eye have probably already spotted that it looks shit. Bear in mind that it’s already been bodged around a bit, and it looked worse than that by the time I’d finished experimenting with the poor thing. It is a single stage class C amplifier with a low pass filter on the output. The 2N4427 transistor is old and cheap; I bought 5 from China for about £3. Everything else (apart from the variable capacitors) is bog standard and the coils are easy to wind. The variable capacitors are stupidly expensive – there is about £20 worth of them in that photo, so they had to be replaced with fixed ones that cost pennies.
The end result was this circuit:
Pi Hat Filter – click to enlarge.
It’s cheap, simple and it works quite well. This is the finished hat installed and working:
This is the output with the filter hat on:
Out of band signals are attenuated by at least 20 dB, which means they are 1/100th the power of when it was hatless. There is even a little bit of gain at our broadcast frequency, which also amplifies the in-band harmonics, unfortunately. It’s not exactly BBC quality but it should stop you annoying the neighbours. If you want to get the absolute maximum performance out of the filter, use 5-95pF variable capacitors instead of C7, C8, C13 and C16 and keep tweaking them until it becomes apparent that you aren’t really having any effect.
The design files are here. If you would be interested in a kit of parts or a ready made hat, leave a note in the comments and I’ll look into it.
I’ll leave you with a comparison of the filtered (orange) Vs. unfiltered (blue) Pi:
One of the million things you can do with a Raspberry Pi is using it as an FM radio transmitter. It is stupidly easy; you just attach a 700 mm long wire to pin 7 and install one of the manyvariants of the original program which was hacked together at a code club meeting. And now you are a radio pirate. This guide is aimed at those who can do the above but don’t know why it might be a bad idea. If you already know about harmonics or know that they are bad but don’t care why, you can skip to the next post which is about adding a filter to your Pi.
At this point it is traditional to say that broadcasting without a license is illegal in most countries and doing something like using your Pi to stream internet radio stations to the analogue radio in your kitchen is wrong and makes Eben Upton cry.
One thing you will often hear in discussions about Pi radio is that lots of unwanted harmonics are produced on frequencies other than the one you are broadcasting on. These can interfere with legitimate users of that frequency; for example a passing pilot might not want to hear the Crisp Biscuit Breakbeat remix of Josh Wink’s Higher State of Consciousness instead of the control tower telling her where to land. You might think that anything broadcast from your little Pi won’t be powerful enough to interfere with a professional communications system, and you are very probably right. But what exactly is coming from our Pi’s aerial? This is what we would like to see:
What we would like to see coming out of our Pi. Click for a better view.
Along the X axis are all the frequencies from 50 MHz to 350 MHz. The Y axis shows the level of the signal at that frequency in dB. If you just clicked on the “dB” link and are none the wiser, the upshot is that the dB makes it easy to compare the relative powers of signals. For example, a +3 dB difference is twice the power and a -3 dB difference is a half the power. So +6 dB means the signal is quadruple the power of whatever you are comparing it to – it’s the same as a +3 dB doubling and another +3 dB doubling. As the dBs go up in linear fashion, the corresponding power goes up exponentially: +3 dB, +6 dB, +9 dB corresponds to x 2 power, x 4 power and x 8 power.
The graph shows the main peak of our transmission at 107.3 MHz, at about +11 dB, a harmonic at 214.6 MHz at -25 dB and another at 321.9 MHz at -30 dB. These unwanted harmonics are bad, but their levels are a lot lower than the main broadcast frequency. If the harmonic’s signal level is -36 dB compared to the main one, it means it’s about 4000 times weaker and we don’t really need to worry about it, given that the main signal only goes a hundred metres or so. The other unwanted signal is even lower: -41 dB compared to the main signal so I’m not even going to bother to work out the exact value because it is so small. OK, it’s 12,500 times less than the main signal. That won’t even make it out of the room.
So that’s our ideal transmitter, with a nice strong signal on the frequency we want and weaker signals on the frequencies of the harmonics we don’t. How does this compare to the actual signal from a Pi? Take a look at this little beauty – it is what’s coming out of my my Pi when it’s broadcasting on 107.3 MHz:
Actual output from a Pi. Barf.
It’s spewing crap from 50 MHz to 800 MHz and probably beyond. One of the harmonics is actually more powerful than the frequency we want to transmit on. The signals coming out of that aerial are dirtier than a dog in a field of incontinent cows [todo: change this to something more tasteful]. The neighbours are probably wondering why old skool breakbeat trance music is coming out of their hoover.
It gets worse though. The harmonics coming from the Pi change in number, size and position as you change the frequency. Broadcasting on exactly 100 MHz actually produces a graph somewhat similar to the first one, but drop the frequency by 1 MHz to 99 MHz and you get this:
99 MHz – Craptastic!
Now that is quite pretty, but it did genuinely start making lines go down my monitor and a hum come out of my speakers. God knows what it was doing to the output electronics in the poor Pi.
So, before doing anything else, you need to pick a frequency that won’t make music come out of your granddad’s fillings. The cleanest one is 100 MHz, but where I live there’s already a commercial station there, so that was out for me – my little Pi couldn’t compete with the big boys. You don’t want to pick one that’s close to 100 MHz either because they seem to be the dirtiest. Trial and error, picking the gaps between existing stations, seems to be the way to do it. Ideally, you want a spectrum analyser like the one I used to make the graphs, and surprisingly, you can get the hardware for about £20, and use something like this to turn it into a spectrum analyser. At the very least, you could pick a frequency and see how many times your broadcast appears when you tune your radio up and down. As a general rule, the fewer times the better.
But however carefully you choose your frequency, your Pi will still be broadcasting all over the spectrum and possibly making someone near you very angry. You can improve things by putting a filter on its output, and I can show you how in the next post.
It is stupidly easy; you just attach a 700 mm long wire to pin 7 and install one of the 
