I ordered some tools and got a tracking code, with a shipping date of Nov 25th. The tracking said the local courier had not yet received the package. After several weeks I queried this and was told that the package had in fact been returned due to an inadequate address. They send a pdf of the package label. The address was correct. The courier (Hermes) must just have been lazy. OK this may not be CTC’s fault but their failure to inform me about the return IS.
They did give me a refund but had taken payment from paypal in USD, in spite of the website being priced in £ sterling, so the refund came out £6.66 short due to the exchange rate changing. They refused to make up the difference, citing a policy (who reads those) which said prices were given in sterling “as a service”.
So, six weeks after shipping, I have no tools and am £6.66 the poorer for it.
No doubt they will protest that none of this is their fault, but it is just cause for poor reputation; I could have spend a few pounds extra and received my tools in good time. I suggest you do the same!
This article describes some informal/experimental work in which various sources of data were processed to find traces of mining history in the names of places.
A few of the results from the place name search, displayed over an Open Street Map
The Geographic Area
My area of interest is broadly-speaking the Peak District and adjacent areas. For practical purposes, I have defined both a detailed boundary and a rectangular bounding box. The latter takes in all of the former, which is defined using Parish (and similar town/urban) boundaries. Since the boundary of Sheffield stretches into outlying areas which are of interest, this way of defining the boundary ends up including the city and Eastern areas. The same is not the case for Greater Manchester. Noteworthy cases where areas outside the Peak District are included are: the Churnet Valley and Alderley Edge.
The bounding box is (E-min, N-min, E-max, N-max): (381355, 340577, 445079, 402069)
Coordinates will either use fully-numerical eastings and northings to 1m, or use 100km letters (SK covers most of the area) and a variable number of digits.
Where source data is chunked according to 100km or 20km tiles, the small excursion of the boundary north of 400000 is neglected.
Data Sources and Pre-processing
All data sources are ultimately from the Ordnance Survey, but with some qualifications:
OS Open Map Local* for NGR squares SJ and SK, was used, limited to shapefile data files “NamedPlace” and “Road”.
OS Open Names* is provided in 20km tiles; CSV files with the following names were used: SJ 84, 86, and 88; SK 04, 06, 08, 24, 26, 28.
OS 1:50,000 Scale Gazetteer is no longer available from OS but I had a copy from 2009 on disk. This contains names which are not present in currently-available OS downloads. It was processed to extract entries occurring in the same area as used for Open Names (the data includes the tile designator).
The Visions of Britain “GB 1900 Gazetteer” (the abridged version) was initially limited to the area extent then an attempt was made to remove entries which are descriptive of features (e.g. “Old Lead Mines”) rather than being names. This is a somewhat subjective exercise. Proper names for lead mines are quite common in this gazetteer; these were left in, although the main intent of the activity is to find place names which had arisen from mining activity, rather than finding named mines.
A final spatial filter was applied in all cases to limit the input data to the “detailed area”.
Search Terms
The range of possible name-parts of interest is split up, largely according to variation-spellings of the same root, but with some “misc” categories which contain various thematically-related words. The categories/terms are given below, with the category name in bold.
coal: words starting with “coal”, “cole”, or “collier”. Historically, charcoal was also referred to this way.
pit: names ending, or having a word ending, in “pit” or “pits”.
lead: words beginning “lead”, “led”, “lyd”, “lidgat” or “lidyat”.
mine: words starting “mine”.
cost: words starting “coars”, “cost”, or “coast”. These could be due to Old English names indicating a mining trial (see PDMHS Bulletin 7-6 pp 339-341).
mining misc: a word beginning with one of “rake” or “raike”, “delf” or “delph”, “gin” or “engine”, or “ochre”.
bole: a word containing either “bole” or “brenn”. The latter catches “brenner”, the operator of a bole.
smelting misc: terms other than “bole”, which signify smelting: “sm.lt” (where . is any letter), “cupola”, “pig”, or “slag”.
misc: catches names with words containing “jagger”, “belland”, “forge”, or beginning with “copper”, “bloomery”, “furnace”, or “furnes”.
While it is clear that these search terms will include obviously-erroneous names, these are not excluded from the results; given the status of this work as “for interest and as stimulus”, this feels appropriate.
Search results were further processed to try to remove unwanted multiplicity arising from either the same name appearing in several sources, and from linear features such as roads having multiple entries. This was done by checking for identical names within 500m. This sometimes fails, as different sources may differ in capitalisation or make composite words such as “Bolehill”.
Three maps were created due to difficulties combining all the options using the Leaflet technology which underpins the web maps. For maps which do not immediately show the names, simply place the mouse cursor over a point.
Some Observations
Some of the search terms will give less-obvious false “hits”, and so all should be taken with some caution; place name specialists rely on written records from far earlier than those used here. Some example false friends are: “coal” might originate from “cold”, although we might reason that local geology makes the former more likely; “lydgate” is often though to derive from Old English “hlid-geat”, a swing gate. I will consider the case of “lyd” in a later post.
Almost all of the hits for “mine” are named mines, with a few exceptions such as “Miner’s Cottage”, “Miners Hill”, or “Miners’ Standard PH”.
This took a little while to do; there doesn’t seem to be anywhere explaining how to add WMS layers and controls in simple terms… so here it is for anyone else. Pieced together from various places, the leaflet documentation, and some guesswork, here is how to add WMS layers for BGS solid and superficial deposit geology and linear features to a geojson.io view. The layer opacity has been set to 0.5 to allow the base map to be seen.
You will need to access the developers’ console (F12 on Firefox).
It will look like this:
Enter the following commands where the “>>” is:
var solid = L.tileLayer.wms("https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WMSServer", {layers: 'BGS.50k.Bedrock', format: 'image/png', version: '1.3.0'});
var drift = L.tileLayer.wms("https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WMSServer", {layers: 'BGS.50k.Superficial.deposits', format: 'image/png', version: '1.3.0'});
var linear = L.tileLayer.wms("https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WMSServer", {layers: 'BGS.50k.Linear.features', format: 'image/png', version: '1.3.0'});
var layer_control = {"Solid": solid, "Drift": drift, "Linear Features": linear};
solid.setOpacity(0.5);
drift.setOpacity(0.5);
linear.setOpacity(0.5);
window.api.map.addLayer(drift);
window.api.map.addLayer(solid);
window.api.map.addLayer(linear);
L.control.layers(null, layer_control).addTo(window.api.map);
I find I have to leave the console now.
One thing to note is that the BGS WMS will not return an image if you are very “zoomed out”. Zoom in until the scale bar shows 500m or 1km.
Other BGS WMS layers to add:
var artificial = L.tileLayer.wms("https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WMSServer", {layers: 'BGS.50k.Artificial.ground', format: 'image/png', version: '1.3.0'});
var movement = L.tileLayer.wms("https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WMSServer", {layers: 'BGS.50k.Mass.movement', format: 'image/png', version: '1.3.0'});
Here is a simple spreadsheet to assist with tuning two voiced melodeons: Melodeon Tuning Spreadsheet (Excel).
It has been set up for, and contains working data from, my D/G Hohner Pokerwork retune. I created it for two main purposes: 1) to plot the existing tuning; 2) to calculate the amount of de-tune for a Viennese tuning with an equal beat all the way up the scale (also known as Dedic tuning from Ian Dedic). I also used it to measure the tuning on a fairly new Serenellini melodeon with drier tuning, to get a better idea of what the tuning of a newish mid-range melodeon is like.
Some notes on using the spreadsheet for those who don’t want to find out by fiddling:
leave the “Notes Lookup” sheet alone; it contains the look-up from the piano key numbers to the note name and frequency.
On the sheets “G Row” and “D Row”:
change the entries in the “Piano Key” column if your button layout or keys are different; “Note Name” and “Concert Freq” change automatically.
If you want to find the tuning to achieve a constant beat frequency, alter the values in cells F3 and G3. I have chosen 4Hz (beats per second), which is in the tremolo range, and set this as -2Hz/+2Hz for Viennese tuning.
Alternatively… it is common for accordions to be tuning with tapering amounts of reed de-tuning going up the scale, with the beat increasing somewhat. Entering values into row K will compute the beat frequency in row L.
The sheets “… Measurements” should automatically populate the left-most columns. This should be mostly self-explanatory. I made columns to record measurements with the reed in the box and on the reed block on a tuning table, computing the difference (“delta”). Since tuning on the table is far easier than in the box, I use this to estimate a correction to my target tuning when using the table.
The “block hole number” is just a reference to my numbering of the holes on the chord block… its very confusing working out which reed is which!
I you are interested in melodeon tunings, or in the practicalities of tuning a melodeon, the melnet forums are essential reading.
From a visit with Beth Knight earlier this year, here are the locations of some underground workings on Chinley Churn. This post is not a recommendation to visit; the workings contain dangerous loose rock and areas liable to collapse.
Point Name
WGS84 Longitude
WGS84 Latitude
OS Grid Ref. 10m
Altitude
1
-1.94595
53.34832
SK 0369 8349
407.5 m
2
-1.94561
53.34882
SK 0371 8355
416.6 m
3
-1.94563
53.34927
SK 0371 8360
415.2 m
4
-1.94546
53.34964
SK 0372 8364
423.6 m
5
-1.94625
53.35133
SK 0367 8382
422.1 m
Photographs showing the entrances, in the same order as the points above:
Eagle does not lend itself to unusual, possibly artistic, board outlines copper tracks, silk screen etc. There are a number of Eagle ULPs (user language programs) that can import DXF files, and yet more which import bit maps as a mass of polygons, but I struggled to get any of them to work, or simply balked at the number of fiddly steps required. Basically: it was just too hard or error-prone. Then I stumbled across an article by Shabaz Yousaf complaining about the same problem but pointing to HPGL (Hewlett Packard Graphics Language) as a solution. He provides a C program to do the conversion but: a) I wanted to make a ULP for ease of use and b) I wanted to add some configurability at run-time. This article outlines the approach I took. I am assuming that images are created from the outset in Inkscape but Inkscape can import many formats, so it should be possible to use it on existing images, and any graphics software supporting HPGL output should work (HPGL appears to be very simple, but it may be the case that other software creates HPGL in a way my code does not recognise… so your mileage may vary!).
The User Language Program – hpgl2scr
The latest version is in my GitHub ULP repository (direct link to ULP). Please report bugs via GitHub if possible. Also any friendly guidance; this is my first ULP. This is available under an open source licence.
It should be fairly self-explanatory to use after a bit of messing about. Note that the wire (or polygon boundary) width auto-changes depending on the layer that is chosen. Adding more layers is easy by editing the ULP.
Some notes on usage:
HPGL files can contain several separate lines (think a pen moving about in an old-school plotter). Hpgl2scr creates one or more paths of wires or polygon boundaries in the specified layer.
A .scr file is created in the same folder as the .hpgl input. This file may be used to repeat the import.
In normal use choose the Wire output type. When using polygon output, note that setting the pour type = cutout may be used after import for subtractive effects (but only for copper layers).
All units are mm.
The imported image can be positioned in four ways:
Aligned to the x and y axes with all wires at positive coordinate values, i.e. in the correct position for a board outline.
Centred at a chosen position.
Off-board (on the opposite side of the origin compared to option 1). This is the best place to group-select the shape and manually move it into place.
Absolute positioning; (0,0) of the original graphic maps to (0,0) on the board. Absolute positioning may be useful if several layers are used in an image and each converted to separate HPGL files for separate importing. Beware that the origin for Inkscape is top left, whereas for boards in Eagle it is bottom left.
The Scale to Fit Box setting will rescale the image (preserving aspect ratio) so that it fits within a box of the specified size (in mm). This is quite useful in that it allows Inkscape to be used without worrying about absolute size, but the final board can be within the limits for PCB cost etc.
Using Copper Layers
As imported, copper layers do not form part of the circuit as far as Eagle is concerned. You cannot just connect to them and use them as pre-routed tracks (OK, so you can leave partially-routed tracks but dangling airwires just feels so untidy, and I always check for unrouted airwires so this would just be another cause of missed mistakes). The solution to this problem is to set the name of the imported wire to be the same name as an existing net. Use the “Name” tool to find the name of the airwire you are interested in, and the Name tool again to change the name of the imported wire to match it. Once done, an airwire should appear from your imported wire. The you can now manually route a trace to the imported wire and it connects nicely.
Note: if you now do a “rip-up all”, your imported wire gets ripped up!
Hints and Tips for Inkscape
I recommend setting document properties to give mm as the default units (File > Document Properties).
Note that the inkscape image elements MUST be saved as paths (vectors) to export to HPGL. Use the Path menu: Path > Object to Path. If your image does not appear in inkscape check this first!
Simply “save as”, selecting the HP Graphics Language file type.
Pen number and flatness are irrelevant. Other parameters should be as shown. Make sure resolution is 1016 dpi if the absolute size matters.
The thickness of the lines in inkscape is irrelevant; the HPGL just follows the path.
Being Ambitious
If you want to be ambitious and to compose several different elements (board outline, various bits of copper and silk) in a single inkscape image you will end up using layers in inkscape. Use a separate inkscape layer whenever the HPGL import parameters will differ (e.g. Eagle layer, wire vs polygon, wire thickness). Make all inkscape layers but one be invisible and export to HPGL, ensuring that the “Plot invisible layers” checkbox is not checked (see the “HPGL Output” screenshot above).
The import will probably be best done with the “absolute” positioning. It would be possible to import “off-board” and to move the elements into place, but positioning will not be easy to replicate in eagle. The trickiness arises because Inkscape uses the top left as origin (0,0), whereas Eagle uses the bottom left. This is easily fixed by checking the “Mirror Y-axis” option on export. Make sure that the image is right down in the bottom left corner so that ends up in roughly the right place in Eagle.
An Example
Here is a quickly executed (and slightly wonky) LED star for a “magic wand”. This followed the approach mentioned above of using 2 layers in inkscape. The inner and outer stars were positioned and sized using typed-in values in inkscape and imported one layer at a time with absolute positioning. The imported copper wire was re-named to GND (I had already named the net in the schematic).
It look about 20 minutes, including some time forgetting most of the hints I’ve given!
The DFU bootloaders that Atmel supplies, as Intel HEX files, for its Xmegas have pre-determined pins used to sense whether or not to skip the bootloader and start the application, or to register the device to the host PC via USB. These are slightly hidden on the Atmel website and the source code requires IAR to compile it (and an easy port to AVR-GCC is thought to be impossible on size grounds). A number of threads on AVRFreaks have discussed this matter, including: “Building bootloader for ATXMega16A4U from avr1916.zip” and “Where’s the DFU bootloader?“. I didn’t fancy installing IAR, but was intrigued by comments about dis-assembling the HEX files and tweaking bytes. The process was not explained, but in spite of starting off totally “in the dark”, an evening of fumbling and fiddling got me through to a result that worked. This post explains the process, in case anyone else wants to do the same. It is also my notes-to-self for when I forget!
Background
The Atmel application note AVR1916 has essential background info and the associated zip file contains the Intel HEX files for different xmega chips. The zip file also contains source code but: a) this needs IAR (see intro); b) it is deeply hard to follow!
Atmel AVR1916: USB DFU Boot Loader for Atmel XMEGA: pdfzip
The zip file is not so easy to find by google/bing; you pretty much have to go to the Atmel site, find the xmega section, go to documents, and select “application notes” from the drop-down.
Tools
There are probably lots of options, but I used:
avr-objdump, which is part of the avr-gcc toolchain. I used a recent toolchain download from the Atmel site. If you use Atmel Studio, look in {install directory}\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin.
Tiny Hexer by Markus Stephany. This is available from numerous places on the web, although not from the author’s original site mirkes.de .
Procedure
In what follows, I am dealing with an ATxmega32A4U. The method should translate to other chips very easily. I am ONLY concerned with changing which pin is sensed on a hardware reset to determine whether to start the application or wait for USB communication of a new application.
From a command window, execute:
avr-objdump -m avr -D file.hex >> disassembly.txt
That looks somewhat daunting to a non-assembler hobbyist person like me but it turns out not to be quite as bad as all that. The key thing to note is that we’re looking for references to a single I/O pin. Which pin it is may be found in AVR1916.
Default boot-sensing pin configuration table from AVR1916.
So, for my target it is Port C, pin 3. Consulting the xmega manual…
Base IO memory map addresses for the GPIO ports.IO port memory map offsets (apply to all ports, simply add to the base address for the port to get the address of the appropriate register)
So, setting the direction for port C will address 0x0640 (offset is 0) and PIN3CTRL will be at 0x0653 (offset is 0x13).
To cut a long story short, the important lines in the disassembly are:
As an exercise, work out which registers are being accessed. The STS and LDS commands are direct store and load instructions. SBRS is “skip if bit in register is set”. In this case we can see bit 3 is being used, which is as it should be, and the value in register 16 is the IN value for the port.
Suppose we want to change the sensing pin to be Port D pin4 (physically pin 24 on a 44 pin xmega). This indicates a base address of 0x0660 and changing the instructions to:
Open Tiny Hexer and import the Intel Hex file appropriate to your chip from the AVR1916 zip file. Now it is just a case of changing the hex representation of the appropriate bytes. Note that the byte order of 0x0640 is reversed in the disassembly and in the HEX file. Here are some screenshots of Tiny Hexer after changing the required bytes:
…
Now export from Tiny Hexer as Intel HEX, saving with a new name (!).
At this point, it is a good idea to run avr-objdump again, on the new HEX file, to make sure that it still makes sense to an AVR. I also did a file-diff on the new vs original disassembled files. The results are as follows, although there is also a block of FF that got inserted between code blocks. This has no effect, and simply reflects the fact that Tiny Hexer exported a continuous block rather than two blocks with a space in between.
…
Looks like I got it right! Only the instructions I wanted to change got changed, and the flash memory addresses came out correct for a bootloader.
All that remains is to program this onto the chip with your programmer of choice (I use the Olimex AVR-ISP-MK2 clone since my Dragon utterly fails to even get the device ID 95% of the time), making sure the BOOTRST flag is correctly set if it is a new chip. Erase the chip, program and go!
A Cheat
If you can find two HEX DFU bootloader files for the same target chip, but with different sensing pins, a quick thing to do is to disassemble both and do a diff. I bet they will be from the same basic source code, and will quickly reveal which instructions need changing. Confession: that is how I got started on this problem.
Uploading Using DFU
To be honest, I think FLIP is a bit rubbish, and using the command line batchisp.exe is a pain in the arse. I’ve found dfu-programmer to be much nicer to play with (although the 0.7.1 version does contain a bug that fails to account for the xmega bootloader living in separate flash and so reduces the available flash for applications; this is fixed in 0.7.2 but is not released AFAIK at the time of writing).
I use dfu-programmer from Atmel Studio as an “external tool” via a small “bat file” command script.
In Atmel studio, point the external tool command at the .bat file and add the following into the “arguments” slot:
To work, you do need to select the project file with the same name as the hex file before invoking the tool.
My .bat file just contains:
@echo off
REM supply the hex file location as 1st argument e.g. "dfu-programmer script argument blink.hex",
REM supply the target device as the 2nd arg e.g. atxmega32a4u
ECHO Erase, flash %1 and application launch.
ECHO Device = %2
ECHO ==========================================================
ECHO.
SET PATH=%PATH%;C:\Users\Adam\Desktop\dfu-programmer
dfu-programmer %2 erase --force
dfu-programmer %2 flash %1 --debug 2
dfu-programmer %2 launch --no-reset
ECHO -----------------------------------------------------------
Further Adventure?
I have not done this, but see this line:
800e: 08 e1 ldi r16, 0x18 ; 24
That is setting the value of register 16, which is immediately stored to PIN3CTRL in the original code. A quick look at the datasheet shows that, as expected, this is setting a pull-up on Port C pin 3. Fancy changing that?
MicroKorg “prg” files files are downloaded from the microKorg by the Korg Sound Editor software, and are often posted online (e.g. the microKorg sound bank). But sometimes it is nice to be able to see what the patch is, or post it online in a plain text form. Plain text patches are also a handy way of documenting your own patches in a nice durable format: on paper. Also, if you want to share a patch, posting a readable version of the patch is a nice thing to do, and ideally without having to work your way through the whole matrix, transcribing the settings. Transcribing settings is boring, error-prone…
I have written a small program to convert “.prg” files for the microKorg to a nice readable format. So, if you have Sound Editor working, you can just download your custom patches, locate the place where the .prg files are stored, and away you go. Similarly, it is really quick to see what the Korg sound bank patches (or whatever) are doing at a glance, which I find is a good way of working out the tricks…
e.g. If you drop the “atmos” patch from the microKorg sound bank, you get:
It only works for single-patch files right now, but is can be used for single and layered patches and vocoder patches. On most web browsers (recent versions of Firefox, Chrome, Internet Explorer), you should be able to drag-and-drop a .prg file. Otherwise you have to use the old-school “Browse” button. There is more technical information on the decoder page, and a link to report bugs or make suggestions (although you can do that as comments to this post if you do not wish to create a GitHub account).
The following are field notes from a visit to the valley just to the W of Drystone Edge to inspect the Upper Namurian, especially the Ringinglow coal outcrop and associated seatearth and marine shales (contorted beds). The locations were logged using a Garmin GPS60, and may be downloaded in GPX format. The points are named in the format “ORC %N”, and referred to below.
ORC 001 – SK 02262 68251 – Roadside parking.
Proceed N up the road to Readyleech Green. Just past the house, the road swings NW, following a fault with downthrow on the SW side. To the right is the Upper Namurian Chatsworth Grit (CG), while the higher ground to the W of the road (Knotbury Common) is Westphalian (Coal Measures) Woodhead Hill Rock (WH). The right of way track around the S side of Knotbury Common approximately follows the lower boundary of the WH.
ORC 002 – SK 02198 69014 – Shaft Hummock. This is in the shales between the Chatsworth Grit (CG) and Rough Rock (RR). The coal sits just above the CG.
Section through Drystone Edge and Orchard Common looking North
At this point you are on Open Access Land. Descend to the stream, which is easy enough if you follow the fence approx Southwards on its stream-side.
ORC 003 – SK 02170 68842 – Good clean exposure just above the stream bed of CG followed by seatearth then coal. There may be a detectable marine band here but I didn’t look. The seatearth shows interesting patterning. There is also some evidence of fossilised vegetation.
ORC 004 – SK 02330 69112 – Contorted Bed.
ORC 005 – SK 02319 69450 – Quarry in Rough Rock. Look at the texture, grain size, bedding etc to compare with CG on Drystone Edge (ORC 009). The top of the RR is the top of the Namurian; a band of marine shale with distinctive fossils marks the bottom of the Westphalian (Coal Measures).
ORC 006 – SK 02598 69608 – Contorted Beds.
ORC 007 – SK 02680 69725 – Some nice pieces of loose coal (apparently not in situ, but 5-10cm longest dimension).
ORC 009 – SK 02698 69152 – Scarp exposure of CG on Drystone Edge. Look NW towards the RR quarry visited earlier and consider the section (above), which follows the same line.
These are personal notes, shared for whoever may find them useful. I am not a qualified geologist; more details may be found in the Geologist Association Guide No. 26, by F. Wolverson Cope. I used this book to visit the site, although the account above contains additional sites, and more precise location for some of Cope’s sites.
The lay of the land and the nature of the water channels probably makes this route over Kinder Scout easier to find when taken from Crowden Clough to Kinder Downfall. The path is generally visible but a compass is necessary equipment to avoid being misled in poor visibility. HOWEVER, the right of way marked on the OS map appears not to be the way people go, and an attempt to follow this route with a GPS is likely to be an unhappy experience (Google/Bing will reveal stories).
In case anyone should wish to follow a GPS track, or to compare an on-the-ground route with the OS map, here is my track log.
…
