I’ve now got current builds of both the University of Manchester and University of Southampton Thesis Templates on Github – see the Resources page for the links.
Here’s a poster I’ve designed to be used as a reference for people working with Itrax or other core scanning equipment. It is a table of the elements (with much of the usual information these traditionally contain), with the electron configurations, common x-ray emission spectra, and information on efficiency of detection using Mo and Cr source tubes. Hopefully you’ll find it helpful – if you use it in your lab I’d love to hear from you!
A high-resolution vector image file can be downloaded from the resources page.
You may be familiar with the classic GRADISTAT for calculating particle size statistics. It is a set of macros written into a Microsoft Excel spreadsheet by Kenneth Pye and Simon Blott. At the time of writing it was last updated for use with Microsoft Excel 2007, and is becoming increasingly difficult to use with newer versions of Excel. After recently troubleshooting some odd GRADISTAT outputs for one of our lab users, I decided to see if there were alternatives available.
G2SD, written by Regin Gallon and Jerome Fournier, does everything GRADISTAT did and a little more, and all as an easy to use package in R. Easy to use R? I hear you ask! Well yes, because it has the option of using a web-based interface (built using the “shiny” R package). I’m (very) still starting out with R, and I’m not finding it easy! However, this package can be used with minimal knowledge – just follow my instructions below. Want to try it out first, or only need basic functionality? Why not use the hosted web-based version, available here for use with delimited text files (e.g. *.csv, *.tab).
Install R and G2Sd
- Assuming you are a Windows user, visit the R website, download and run the installation file, selecting the default options.
- Visit the repository for G2Sd and download the latest stable version.
- Open RGui, and from the top navigation menu, select Packages>Install Packages From Local Files.
- Navigate to the downloaded *.zip file that contains G2Sd files.
- G2SD is dependent on some other packages. Install the first by typing install.packages(“shiny”).
- Repeat step five but replace shiny with xlsx, then rJava, xlsxjars, reshape2 & ggplot2.
- You only need to do this once!
Loading and Using G2Sd
- Load G2Sd by typing library(G2Sd), or by navigating Packages>Load Packages>G2Sd from the top navigation menu.
- Run the web browser based GUI by typing granstat(web_interface=TRUE). A web-browser should appear!
- The data should be in the format:
- The first column are the sieve mesh sizes in microns, in descending order (from largest to smallest aperture). Size “0” is the pan.
- Columns subsequent to the first are a sample. The first row is the sample identifier.
- From here you can visualise and download the data.
Using the Command Prompt Instead
- Load G2Sd as previously described.
- Load CSV data into an R dataframe by typing mydata <- read.table(“mydata.txt”, header=TRUE, sep=”,”). If you don’t have your own data, an example dataset is included in the package. Try loading it using data(granulo), and exporting it to a CSV datafile using write.table(granulo, “granulo.txt”, sep=”,”).
- For statistics, try typing granstat(mydata). There’s a lot more functionality here – check out the package documentation for more.
- If you want to export these to a CSV file, just combine the two functions we met previously: type write.table(granstat(mydata), “mydata.txt”, “sep=”,”).
- For graphics, try trying grandistrib(mydata). There’s options for multiple samples to be plotted, and a number of different styles – try granplot(mydata) or granplot(mydata, xc=2:4) for a couple of examples. Check out the package documentation for more.
- To export a graphic generated in the data frame, right click the figure and save using the dialog box.
Blott, S.J. & Pye, K. (2001). “GRADISTAT: a grain size distribution and statistics package for the analysis of unconsolidated sediments”. Earth Surface Processes and Landforms v26, pp.1237-1248.
Fournier J., Gallon R. (2014). “G2Sd: a new R package for the statistical analysis of unconsolidated sediments”. Géomorphologie : relief, processus, environnement v20(1), pp.73-78.
I’ve hooked up one of our lab balances to a PC!
For users of the Geography Laboratory
In the main lab is a networked computer that I’ve connected to the Ohaus Adventurer AR-Series balance. To use it:
- open “C:\SPDC Data Collection V2.01\SPDC Data Collection V2.01.exe”
- click “Browse”, find the Excel spreadsheet you want to import to, and click “Open”
- click “Run”. It will automatically open the spreadsheet and connect to the balance
- select to cell you want to populate, and press the “Print” button on the balance; it will populate the cell with the current reading.
How’s it Done and Can You Do This With Other Balances?
Almost all laboratory balances have RS232 communications built in as standard, but for some reason they seem to want to make it as hard as possible to use them! This is unfortunate, because this functionality is really handy for connecting them up to spreadsheet packages like Excel for automatic data entry. If you can get it working, it is an easy way to save all your lab users time and reduce transcription errors. I’ve had a good hack at the Ohaus balances in our lab, and here are some notes on my experiences. My next project will be to pipe these serial connections over IP, and then allow access via a WIFI hotspot. Just connect to the WIFI hotspot, start the wedge software and measure away – well that is the plan, anyway.
Ohaus Adventurer AR-Series (like above)
These should be straightforward – they have configurable Rs232 communications and a standard male DB-9 connector. Of course, for reasons best know the the manufacturer, they have completely non-standard pin assignments. The pin assignments are shown in the manual, so you’ll have to build your own null modem cable to connect it, or the ground ends up connected to the CTS and you get nonsense. On the plus side, Ohaus supply the wedge software for free, which will allow direct input into a .xlsx, .csv, etc. The standard serial settings are 2400 7N2 (yeah, why not?), but these are configurable so you could change them to something this side of sensible (like 9600 8N1). Once it is all up and running, just press “print” to fill a cell.
Ohaus Explorer (& Pro)
Now here’s a thing: although the pin assignment and default serial settings are the same as for the Adventurer series, the RTS/CTS is implemented differently. No problem, just set the correct flow control in the wedge software, right? Well, we would if we could, but the Ohaus wedge software doesn’t implement hardware handshaking properly! Open a serial connection using Minicom or PuTTY and you’ll have no trouble sending and receiving (when you configure the handshaking properly), but try the Ohaus software, and it won’t play. You’ll have to tie the CTS and DTR pins together to get them to work – it’s a bit ham-fisted, but it’ll do. This will be my next project.
Naturally, Mettler Toledo fit a serial interface without the familiar DB-9 connector. I’m working on sourcing it, but I suspect it’ll be £££.
Haven’t started on these yet, because we don’t have many in the labs, although previous experience tells me they are usually good at implementing serial comm’s over RS-232.
I’m on GitHub! At the moment I’m using it to develop, update and distribute the LaTeX templates for typesetting theses, associated with the courses I deliver on the subject. Expect the addition of some of the Python-based dGPS, ADS-B and other radio-science scripts I’ve written.
If like me you’ve been experimenting with Raspberry Pi’s you’ll know putting monitors, mice and keyboards costs far more than the units themselves and presents some difficulty. Not just that, but running “headless” systems is normally preferable for the kind of applications I’m working on (servers, radios, desktop gadgets). If you can get away with only hooking up KVM (keyboard, video, mouse) once (or not at all!), great! There’s loads of guides knocking around, but here’s how I do it:
Using a KVM
First, I connect the Pi to the telly with a spare HDMI connection, plug in a wireless mouse and keyboard and run NOOBS to install Raspbian. I assume the systems are on the same local network, so use hostnames here. If you are connecting over the internet, you’ll need to replace these with a public IP or domain name.
Using the Serial Interface
First I connect a Raspian image onto SD and connect up a TTL serial interface (find the pinouts for your Pi). Use Device Manager to find the COM number of the interface on your PC, then use PuTTY to configure it (the baud is 115200) and connect to a session on the Pi. Use the default logins and follow the instructions below.
First I run sudo raspi-config and enable SSH and change the hostname. I choose not to reboot, but quit raspi-config and run sudo shutdown now. Now, simply login from Windows from PuTTY using the hostname and default settings. Using the hostname avoids the need to assign a static IP.
If you want a desktop, RDP is built into Windows 10 and is an easy way to remote into the x-window system, all you need to do is install xrdp. Just install like any other package (sudo apt-get install xrdp). Now reboot the Pi and find the Remote Desktop Connection client on your Windows 10 system, and enter the hostname to connect.
Remember, by opening up remote access servers like these, you open the Pi up to potential attacks, especially if you have external access from the internet. Internal attacks might not be a big problem on your internal network, but if you choose to open these up over the net, think about using random port numbers, public/private keys and tunneling the RDP over SSH.
I’ve been experimenting with a Raspberry Pi B v3, which has an onboard bluetooth radio. I’ve been interested in using GPS (or more correctly, GNSS) radio receivers with the Raspberry Pi for a while now, but the price of development platforms for the Raspberry Pi is quite high. I dug out a bluetooth GPS receiver from a box of old electronics, and found it surprisingly easy to connect to. I think I’m still going to have to invest in a proper development board at some point because the bluetooth GPS lacks a pulse-per-second (PPS) output with I’d like to use to build a stratum-1 NTP server, but for now, here’s how I got the GPS working:
Connecting to the Bluetooth Device
The program bluetoothctl can be used to control the bluetooth radio on the Pi. To connect to a bluetooth device, follow these steps:
- use the command bluetoothctl at the CLI. This opens the program. Try the command help to see a list of possible commands.
- power on
- scan on – find and note the target mac address from the list
- agent on
- error message? Try:
- select YO:UR:MA:CA:DD:RE:SS:00
- agent on
- error message? Try:
- pair DE:VI:CE:MA:CA:DD:RE:SS & enter code if required
- trust DE:VI:CE:MA:CA:DD:RE:SS (if you want to skip confirming trust in future)
- exit (to exit)
Connecting to the Bluetooth Serial Interface
We use the program RFCOMM to connect to the bluetooth serial interface. First, load it with the command “sudo modprobe rfcomm”. Now connect (or “bind”) the GPS receiver to the RFCOMM “device” using “rfcomm bind rfcomm0 DE:VI:CE:MA:CA:DD:RE:SS”. Note that the connection will only be initialised when a program attempts to open the RFCOMM device.
Checking the State of the NMEA Messages
Most GPS units will communicate using messages sent in ASCII over a serial data connection. The format is standardised with the NMEA0183 specification, with compliance highly variable! Most receivers have the same serial communications settings – 4800 baud 8N1 (that is, data bits=8, parity=none, stop bits=1, handshake=none). You can use Minicom in Unix-like system (or PuTTY in Windows) to view the messages as they arrive. On the Raspberry Pi, you could use minicom – or you could skip directly to GPSD to probe the messages sent by the GPS.
To use minicom, you need to install it (sudo apt-get install minicom) and then open the configuration menu (minicom -s). Select “configure serial port” and give it the NMEA standard settings above. Set the serial device to “/dev/rfcomm0”. Save the setup as the default, exit, and start the program (minicom). You should see the messages as they come in! Remember to exit it’s the intuitive (!) CTRL+A then X.
You might also use GPSD, a program designed to utilise GPS devices in a number of ways. One of the best things about GPSD is that it automatically detects and configures the connections, so you don’t have to tell it what kind of serial connection you need or what messages to expect. It does need to know to look for the bluetooth connection though, so…
- Install using “sudo apt-get install gpsd gpsd-clients python-gps” (ok, there’s some extra bits there for later…)
- a bit of housekeeping to avoid some conflicts in manually run instances (sudo systemctl stop gpsd.socket, then sudo systemctl disable gpsd.socket)
- sudo gpsd /dev/rfcomm0 -F /var/run/gpsd.sock to connect the rfcomm0 device to the GPSD socket, and
- gpsmon to open the program that both parses the position data and displays the messages as they arrive.
What do these messages mean? I won’t go through them all, not least because the specification is not freely available, but also because there are all sorts of different messages. A bit of Google-fu might be required if you see something unusual, although the document IEC 61162-1 is very closely derived from NMEA0183 and you may have easier access to this document. A GPS unit will output a number of lines, cycling through them; for example, mine outputs a RMC, VTG, GGA, GSA x5 times over, then GSV spread over four lines then repeat.
- RMC contains the “minimum recommended data for GPS”
- VTG contains “velocity made good” speed and heading information,
- GGA contains essential fix data including quality indicators
- GSA contains GPS dilution of precision and information on satellites in use
- GSV contains information on the satellites that could be in use based on available data – this is often spread over multiple lines
$GPGGA,161229.487,3723.2475,N,12158.3416,W,1,07,1.0,9.0,M, , , ,0000*18
- $ defines the beginning of the message
- GP is the “talker ID” and identifies the type of unit that is sending the message. This is sometimes programmable, but is always two letters, most commonly GP for generic GPS
- GGA defines the type of message the follows – this is always three letters. Here, GGA means the message is a “Global Positioning System Fix Data” message. This defines what the following commas separated values are:
- 161229.487 is the UTC time in hhmmss.sss format
- 3723.2475 is the latitude in decimal degrees, in the format ddmm.mmmm
- N refers the hemisphere of the latitude, north or south
- 12158.3416 is the longitude in the same format as the latitude
- W is the hemisphere of the longitiude, east or west
- 1 defines whether the signal is valid and whether it is from a standard or differential fix
- 07 is the number of satellites used to calculate the fix
- 1.0 is the horizontal dilution of precision – or the accuracy in the x and y plane
- 9.0 is the altitude above mean sea level
- M is the units (here, meters) of the altitude above mean sea level
- the next three fields are blank, as they refer to parameters for differential fixes
- 0000 is a null value as it refers to a parameter for differential fixes
- * defines the end of the message
- 18 is a checksum for error-checking the previous message, and may or may not be present
There are messages that give detail of the number of satellites present and their status, on timing signals, or the various dilution of precision in all planes. The protocol defines messages for all kinds of other equipment, like depth sondes, radar and inertial motion units.
My colleague John Moore pointed out a couple of cut mark Ordnance Survey benchmarks on and around Oxford Road. This prompted me to look up the nearest benchmarks and find them. I’ll keep updating this post as I photograph them – some are currently off-limits because of building work, others have likely been destroyed. These marks are a legacy of a need for marks for local surveyors using optical levels, alidades, chains and plane tables – these marks are no longer maintained by the Ordnance Survey. A modern surveyor will use a GPS receiver that uses a correction signal from a receiver located on a known position – the organisation provides an “active” network of continuously running transceivers on known positions, and a “passive” network of survey marks with published positions upon which a surveyor may locate their own transceiver.
- SJ84849678, Number 81 Upper Brook Street, north-west face, west angle. 38.868m O.D. – No longer extant.
- SJ84579662, Museum, west side Oxford Road, south side gateway, north-east face, north angle. 38.384m O.D. Obscured by building works at present.
Because loss-on-ignition (L.O.I) can be so time consuming in routine analysis of soils, peats, lake or marine sediments, we’ve been testing a CEM Pheonix microwave furnace as a substitute to the old muffle furnace methods.
Determining Ramp, Cooling Times and Batch Sizes
The muffle furnace takes around 45mins to get to 550deg.C, and cooling is a three-step process, where the furnace cools naturally to around 250deg.C, then transferring the crucibles to a heat sink plate to cool to 50deg.C, then transferring to a desiccator until room temperature for weighing. This three-step process takes about an hour and a half to two hours. A single batch in the muffle furnace consists of 64 samples.
The microwave furnace takes around 20mins to get to 550deg.C, and cooling is pretty much instant because of the quartz fibre crucibles. A single batch is up to 15 samples.
Determining Ignition Time
For loss-on-ignition, the standard ignition time is 2 hours. For the microwave furnace, I performed a test to determine the most appropriate time, using a mixed peat that had been powdered and dried overnight at 105deg.C. Sample sizes were around 0.3g dry weight.
5mins = 95.4% L.O.I @ 550deg.C – the sample was observed to be igniting when removed from the furnace
10mins = 95.8% L.O.I @ 550deg.C
20mins = 96.4% L.O.I @ 550deg.C
30mins = 95.4% L.O.I @ 550deg.C
60mins = 96.5% L.O.I @ 550deg.C
As an initial test I tested the same peat used in the test above, with three repeats. Sample sizes were around 0.7g dry weight.
Muffle furnace = 95.165+/-0.09g L.O.I @ 550deg.C
Microwave furnace = 95.367+/-0.69g L.O.I @ 550deg.C
I’m planning further analyses to compare with results derived from elemental analysers, muffle and microwave furnaces, but these initial tests indicate the methods are likely to be comparable.
Both units provide comparable results. The muffle furnace has a total batch time of around 4hrs45mins, and a maximum batch size of 64, whereas the microwave furnace has a batch time of under 35mins, and a batch size of 15, so a 64 samples could be analysed in under 3hrs. The microwave furnace has the added advantage of integrated balance and L.O.I calculations, and fewer hot surfaces, particularly when using the recommended quartz fibre crucibles. There is no reason why the microwave method wouldn’t be suitable for ignitions of 950deg.C for estimating inorganic carbon content.
I’ve added a new poster of a stereomicroscope to my previous post on microscope diagrams for the lab.