Tom Bishop: Lab Notes

I like working on my data presentation, and I thought I could probably improve the current offering on this page. I made a graph that I preferred, then set it up on a simple Github Pages that re-generates each weekday using Github Actions.

The lab is cold and half-empty because of the current COVID-19 social distancing measures in place. These are aimed at reducing the risk associated with viral transmission by aerosols. This means reducing the number of people breathing into a given volume, and increasing the turnover of fresh air in the same volume. There are many calculations and computer simulations that have gone into developing these rules, but the basics are pretty simple – more ventilation, fewer people. In practice this is quite easy to achieve in a laboratory like ours – the three fume cabinets along one wall mean there is a high turnover, and we’ve got lots of smaller side labs.

A number of researchers have proposed that the CO₂ concentration of a volume provides a good proxy for the overall potential risk in every-day settings, and that this presents a low-cost empirical way of managing this risk. This is because CO₂ is a by-product of people breathing (breath has a CO₂ concentration of around 38,000 ppm), and if a room has poor ventilation the CO₂ will gradually increase. If a room is well-ventilated it will equilibrate with the outside air, usually around 400 ppm. Some have proposed that a CO₂ concentration of 600–1000 ppm should be aimed for, others have complex models for setting the risk level (see Peng & Jimenez, 2020).

We have many way of measuring CO₂, including the Los Gatos gas analyser, The ADC IRGA, and Sarah Brown’s low-cost sensors, but I was curious to see just how cheaply it could be done. The system I have built uses a generic Arduino UNO-type board (~$2), a breadboard (<$1), a 4-segment display (<$1) and at its heart, a Winsen MH-Z19B NDIR CO₂ sensor (~$12). The entire package can be made for around $15. My implementation uses the code implemented by Github user Erriez, available at Github (Erriex/ErriexMHZ19B). Before I discovered Erriez’s implementation I spend an evening learning to use Realterm to send and receive hex strings for the first time. I also added a quick way to enable the calibration mode by wiring in the pin (shown near the reset button) and adding a spare wire (in red) to short this to pin to ground. When I get a moment in the lab I’ll check it against our reference units and see how it performs.

I’ve recently made my first submissions to Wiki Commons – a set of images of the very famous Rhynian Chert, which contains some of the earliest fossils. The images are available at Wiki Commons here. The slides come from the Manchester Museum and were imaged for educational purposes, including some mosaics.

I’ve been cycling to work for three years now, and I have been asked what the benefit is. There are three:

1. It’s cheaper; I will save £5,875 over a 5 year period compared to if I were to travel by rail.
2. It’s quicker. I will save 125 hours (over 5 entire days) per year compared to travel by rail.
3. It’s good for my health. It improves my core strength, muscle tone, and at 280 calories per day (≈ 1.5 pints of beer), makes it easier to balance my diet.

I have based my calculations on my records from the last three years. The bicycle cost £510 (including a cycle scheme reduction). I have spent only £75 on servicing, but have invested in my own tools to do my own where possible. Spare parts, accessories, clothing and tools have combined to cost £810 over the three years I’ve owned the bike.

Having covered 10,470 km in commuting (and another 1,360 km of riding for fun), the bike costs me less than 8 pence per km, which compares favourably to the HMRC rate for business travel by bike, which is 12 pence per km.

I should add that these costs can be reduced considerably – my bike was expensive (£680 list price), and is over-specified for commuting (because I use it for fun sometimes!). In addition, my calculations include the cost of my tools, which will last much longer than the 5 years. Also, I choose to wear sports clothing to ride (mostly because I have changing and shower facilities at work), but many would choose not to. A wiser choice of cycle for commuting would also mean lower running costs, for example by using a cycle with an enclosed drive chain; perhaps treat my costs as a higher estimate.

As for the often asked questions regarding safety, I’ll say this: my ride along a busy commuter stretch of the A6 at rush-hour every day never fails to show me examples of poor driving, with the most common offenses being drivers not paying attention (turning without signalling, creeping over ASL’s and using mobile phones), and drivers “rushing to go nowhere” (that is, speeding, performing close-passes, or undercutting only to end up in the same queue of traffic a few yards on). However, in the last three years I have never collided with a motor vehicle – I have collided at low speed with a pedestrian who ran in-front of me at a pelican crossing while I turned on a green signal (we were both absolutely fine). My good fortune so far is probably a consequence of defensive cycling and dumb luck, and I long for good quality, segregated infrastructure, but I won’t let the under-investment in road infrastructure and the poor standard of UK motorists cost me the already very real benefits of riding my bike to work every day.

I’ve been window shopping for single-sided headsets for portable operating, but at £80-120 I thought of how I might make my own. I purchased a cheap headset, a copy of a military style designed to be worn under helmets, marketed for airsoft enthusiasts. It has the advantage of being cheap (about £20 including PTT adapter), lightweight, and packs up small, but needs modifying to connect to a Yaesu radio, and the microphone is found wanting.

I had previously toyed with the idea of modifying a spare MH-31 handset by adding an electret microphone element (I might still do this), so I had a few Panasonic WM-53B capsules (these cost a few pounds each), although I imagine many cheap electret capsules are appropriate. I started by hacking open the boom and replacing the stock element with the WM-53B electret. If you are trying this mod, be sure to make a note of the polarity of of the connectors on the boom arm, as you’ll need this information when wiring it in later.

Then I opened up the PTT enclosure. This helpfully has plenty of room inside, so I removed the existing cable (designed for a Baofeng HT) and fitted a chopped up network cable RJ45 and a chopped up 3.5 mm mini-jack. I also added a 3.5 mm mini-jack socket to connect an iambic key. I connected this to the “up” and “down” keys and these can be used for CW work, although the limitations of the FT-817 means it’s actually inferior to connecting to the dedicated socket in the rear of the transceiver. I also connected the PTT using the existing button, and directly connected the microphone output to the 8 ohm transducer for the speaker.

I then moved on to the wiring for the microphone. Usefully there is a spare 5 volt supply from the Yaesu transceiver via the RJ45 socket; with the addition of a resistor to drop this voltage it can be used to supply the electret microphone element. A DC blocking capacitor is added across the microphone elements, and optionally a capacitor can be added on the output signal to act as a high-pass filter to optimise the audio. I’ve put a large capacitor to create a thin, punchy sound optimised for SSB, but in the future I might add a switch so I can bypass this to prioritise fidelity for FM work. I need to do some work to optimise the microphone gain (and speech processor in the FT-867D), so I’ve got a dummy load in the post to help with this.

It’s always nice to be name checked in papers where we’ve been involved in lab or field work, and it’s even better when it’s a great paper in a top journal! For this work we assisted in the methodological development of the microplastic extraction procedure. Microplastic extraction is a complex and time-consuming process involving density separation of the material in a sample, and the nature of the sediment and depositional context and process needs careful consideration.

Kane, I. A., Clare, M. A., Miramontes, E., Wogelius, R., Rothwell, J. J., Garreau, P. and Pohl, F. (2020). Seafloor Microplastic Hotspots Controlled by Deep-Sea Circulation. In Science 30 April 2020. DOI: 10.1126/science.aba5899

I’ve recently worked on a piece with Technicians Make it Happen about the work I’m doing while the university campus is closed. You can read it here.

Introduction

The Raspberry Pi is a small-format computer that can run a number of general purpose operating systems, the most popular of which is a build of Linux.

Most computers have relatively poor in-built timekeeping. A time server reads a reference clock and distributes that information over a network. Most computers that have an internet connection regularly synchronize from a publicly accessible timeserver over the internet without the user even knowing.

Accurate timekeeping is important for a number of computing applications; for amateur radio operators using digital modes like JT-X, it is essential to the correct operation of the mode. This blog post explains how I used a cheap GPS chip and Raspberry Pi to serve time to my home network.

Choosing the GPS Chip

The global positioning system is familiar to many as a constellation of orbiting satellites that provides positioning information, but at the heart of each satellite is an atomic clock – the entire system works by comparing slight differences in the time it takes signals from 3 or more satellites to reach a receiver. If you can pick up a signal from a GPS satellite, you have the output from a precise atomic clock, and this can be used to “discipline” (synchronize) your timekeeping.

Most GPS chips pass a message every second containing positioning, diagnostic and timing information. Because this message always arrives slightly (and unpredictably) late, some GPS chips can also supply another channel that pulses to precisely mark the beginning of every second (pulse-per-second, or PPS), a bit like the “pips” on the radio. Obviously the two sources of information need to be combined, as the PPS doesn’t tell the time or date, only the beginning of each second.

You will need a GPS chip that has a serial output, and ideally a pulse-per-second (PPS) output. I used a very cheap (£7 delivered) board from China called a “Beitian BS-280”, which has an integral antenna and a U-BLOX G7020-KT GNSS receiver. It has 6 I/O connections:

• Tx: TRANSMIT, the channel on which serial data is transmitted from the GPS to the Raspberry Pi
• Rx: RECEIVE, the channel on which serial data is received by the GPS from the Raspberry Pi
• GND: GROUND connection
• VCC: POWER connection for the GPS, typically 5v
• PPS: PULSE-PER-SECOND timing signal
• U.FL: optional external antenna connection

Initial Configuration of the Raspberry Pi

I’ll assume a certain familiarity with Raspberry Pi and/or Linux, so I will refrain from offering a complete step-by step guide to the initial configuration of the Raspberry Pi, as there are many guides available on the internet. I will say that I installed a minimal version of Rasbian 10 (Buster), expanded the filesystem, configured a WiFi connection to my home network using wpa_supplicant and ran the usual updates. The entire configuration was performed via a remote SSH connection.

Connecting the GPS Chip

Firstly, make the following connections between the Raspberry Pi and the GPS:

• RasPi Pin 10 <-> GPS Tx
• RasPi Pin 8 <-> GPS Rx
• RasPi Pin 4 <-> GPS Vcc
• RasPi Pin 6 <-> GPS Gnd
• RasPi Pin 7 <-> GPS PPS

Remember to position your GPS antenna somewhere it can receive a signal – normally with a direct line-of-sight to a sky view. My GPS receiver performs very well in the loft, with the antenna facing the sky.

Next we need to configure the Raspberry Pi to listen to the GPS on the serial interface. By default the Raspberry Pi has a terminal setup on those pins, so we need to run sudo raspi-config and enable to serial connection, and disable the serial console. You can check the interface is now working by running cat /dev/serial0 or cat dev/ttyS0. You should see NMEA formatted data. If you see new data appearing every second, everything is working.

Next we must check that the PPS signal is working correctly. On my unit, the PPS signal is also linked to a LED on the unit, so it is easy to tell when a PPS signal is being produced. To check it is being received:

1. Install software using sudo apt-get install pps-tools.
2. Add the line dtoverlay=pps-gpio,gpiopin=4 to the bottom of /boot/config.txt.
3. Reboot, and check the output of sudo ppstest /dev/pps0; you should see a line every second.

Setup Timeserver Software

Disable NTP in DHCP

In order to run the Raspberry Pi as a timeserver, we first need to stop it trying to look for another timeserver to syncronise with!

1. Remove ntp-servers from /etc/dhcp/dhclient.conf.
2. Delete /lib/dhcpcd/dhcpcd-hooks/50-ntp.conf

Install GPSD

Next we install the software that parses the information from the GPS chip and makes it accessible for the time server software.

1. sudo apt-get install gpsd-clients gpsd
2. Edit /etc/default/gpsd as follows:

# /etc/default/gpsd
#
# Default settings for the gpsd init script and the hotplug wrapper.

# Start the gpsd daemon automatically at boot time
START_DAEMON="true"

# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="false"

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/serial0 /dev/pps0"

# Other options you want to pass to gpsd
#
# -n    don't wait for client to connect; poll GPS immediately

GPSD_OPTIONS="-n"

3. Now the moment of truth – test it with gpsmon. You might need to use set term=vt100 if it looks odd. This should display both GPS position (latitude and longitude),and a number next to “PPS”.
4. It needs to be setup to boot at background, so use:
   • systemctl daemon-reload
   • systemctl enable gpsd
   • systemctl start gpsd
5. Test the system by rebooting and immediately checking sudo ntpshmmon. You should see the two sources.

Setup the Time Server

1. Check that both time sources are being seem in sudo ntpshmmon.
2. Install NTP with sudo apt-get install ntp.
3. Modify/etc/ntp.conf by adding the lines:

# GPS PPS reference
server 127.127.28.2 prefer
fudge  127.127.28.2 refid PPS

# get time from SHM from gpsd; this seems working
server 127.127.28.0
fudge  127.127.28.0 refid GPS

4. Restart with systemctl restart ntp.
5. Check with ntpq -p. Please note, if you run this command a few times for the course of an hour or so, you’ll see things change quite a bit.
6. Eventually, you’ll want to see the PPS (.SHM.) as the * (selected for synchronization), probably the GPS removed (x or -) and a few random servers in the mix (+) as well. There’s lots of information out there on how ntp decides what the time is by combining multiple sources.

Use the Timeserver

Having a timeserver on the network isn’t much use if your computers don’t know its there! On some network routers with DHCP you can define the server using the internal IP Address (you should also bind the MAC address of the Raspberry Pi to a fixed IP address!), or you can define the address of the server in your operating system settings.

Our Wolman Plate didn’t return from its last expedition, so I looked around for a replacement and was quite surprised to see just how much distributors will charge for what is essentially a thin sheet of aluminium with some holes in. Combined with some long lead times and with the next job looming, I made my own!

Many thanks for the B.15 Architecture Workshop for the use of their laser cutter. They cut my design from high visibility 3 mm Perspex sheet. You can cut your own from my AutoCAD files if you have access to a laser cutter, or order online from a manufacturer using the same file if not.

For more details on measuring coarse stream beds, start with the classic papers like Wolman (1954) and Leopold (1970).

Configuration of the UGGA

The UGGA is relaively simple to configure – simply turning the instrument on will begin measurement and recording. The status of the instrument can be checked using a laptop or tablet computer. Download a copy of a VNC terminal program, connect to the WiFi network broadcast by the instrument (SSID and password printed inside the instrument), and connect using the IP address, username and password in the manual. This will give access to the diagnostic screens.

At this point I recommend making a record of any offset between the UGGA clock and local time.

Configuration of the eosMX

Click on the top menu bar to minimise the LGR UGGA monitoring software, and open the Eosense multiplexer control software. Use the dialogue to test the chambers mechanical operation and program the required cycle, and start the process. The cycle events and data from any connected sensors will be recorded.

Importing Data into eosAnalyze

1. Place the UGGA recording file (gga_YYYY-MM-DD_fnnnn.txt) and the eosMX logfile (FRMonitor_nnnn.log) in the same folder as the software (eosAnalyze-AC_v3.6.2.exe).
2. Open the software and in the menu Data > Analyzer Data Path set the location to the location of the software (eosAnalyze-AC_v3.6.2.exe).
3. Toggle the Options > Toggle European Timestamp options so it is set to American timestamp format.
4. Ensure that the LGR UGGA is selected in Options > Equipment > Select Analyzer Type.
5. Ensure that Eosense eosAC (Multiplexed) is selected in Options > Equipment > Select Chamber Type.
6. The default values in Options > Equipment > Chamber/Analyzer Settings are usually acceptable, but if you have modified the system, you may need to change them.
7. If you have connected the auxiliary sensors, you must configure them in Options > Equipment > Configure Auxiliary Sensors. We have Decagon MAS-1 and RT-1 instruments available.
8. Now click on Collect Data and set the time range for your required measurements. I recommend setting a time range larger than the experiment duration so no data is truncated.
9. If the process has been successful, you will see measurement records appear in the Measurements window. Double click on one of the measurement records to bring up the Measurement Settings dialogue.
10. Modify the lower and upper deadbands (shown on the graph in green and red respectively) by changing the Data Domain values. Try to exclude the obviously bad data at the beginning and end of the measurement duration. Select Apply Deadband Range To All and OK to apply these parameters to all of the measurements.
11. To export the processed data, select Data > Export Data Table and select a location for the data file.