Archaeology Resistivity Meter

When I was a boy there was a shell midden behind our house on the edge of town that was excavated and the local kids were allowed to participate.  I remember the squares that were laid out, the trowels, and using a rule to measure depth.  There weren't any grand discoveries but it was great fun.  That was many years ago.  The area is now filled in and there houses on top of what used to be a shallow horseshoe lake and woods.

TI do a nice DAC available in 16 or 12 bit versions fro £4.61 or £2.03 (DAC80501 or DAC60501).

SPI in and voltage out. It has a built in voltage reference which we can use for everything else as well.

So we need to connect the DAC to the FPGA in the block diagram rather than to the micro.

MK

michaelkellett

Most Likely two boxes one the PI & HDA, Power, etc. The second box on the hand bar would have your keyboard, LED display, and most likely some switches to control the probes.  Personally I would interconnect the two boxes via the CAN bus. Waterproof boxes are easy to find they are all gasketed and made from abs. You can also pick up a Pelican case as well. make sure that you waterproof cables, and connectors. To power the 'thing '  you could b powered from a motorbike or small car battery.

115200 baud confirmed functioning.

So, one day the snuffler software can be replaced (or at least partially) with Android code if desired. Or could be used to e-mail or upload the data in real-time so someone can remotely check it while the survey is still being performed.

The test setup was as shown here:

Hi Guys,

I've been reading your plans on Element14 for an Archaeology Resistivity Meter after seeing it on Facebook.

Its very exciting. Have you considered using a Raspberry Pi unit? I don't know much about the electronics but you can get a GPS unit to fit it. The Pi will also run QGIS software which is 'A Free and Open Source Geographic Information System' which runs on Pi's and Windows Laptops. I have some experience of adding features to QGIS using Python. You could use QGIS to show your results, your position and the grid in the same way as 'High End' Gradiometer Carts do. (Carts can cost £40K or more.) You could use QGIS to display results on a grid, or map, in real time.

I hope this helps.

Paul D

The Pi has been suggested on a couple of occasions.

By the time you have built a Pi and a display and the required power supply and other goodies need to run a serious graphics type application you end up with something rather big and quite power hungry.

For some applications that's no problem at all but for others it is.

The current plan is that the basic box will have interfaces that will allow it talk to anything - USB, logic level UART, BlueTooth and possibly WiFi.

It will have its own controls and display options (simplest display being 4 lines x 20 characters, maximum 800 x 480 pixels with capacitive touch.)

With a simple display I would expect it to use less than 1W (averaged over a day's work).

There would be no problem making it talk to a Pi or anything else.

We haven't got to talking about control software architecture yet but the plan in my head would have the core resistance measuring engine controlled by a simple protocol that can be exposed either to an internal GUI or to the external interfaces.

A Pi would be able to use an external interface to fully control the instrument.

The idea is to rule nothing out but still make the basic system simple enough to get going reasonably cheaply and quickly.

I'm assuming that it will all be open source so access to protocols won't be an issue.

I've come at this from the electronics side of things so QGIS is  new to me - I'll take a look.

It would be great to have Pi based data processing software route and any help in that respect would be massively welcome.

MK

Hi Paul,

I like using Python too. It will be awesome to see what code could be used or developed for this project.

This is a rough sketch of some (not all) of the connectivity methods and how they might be used:

GPS expansion will be feasible by plugging the GPS module directly into the Pi, but it might become unnecessary, since there's the possibility of either sending GPS position from a phone (via Bluetooth or BLE) or sending the measurements into the phone. The only limitation is what's coded, since the underlying hardware covers lots of popular interfaces (USB, BLE, etc). There's memory on-board too, so in theory the data is reliably stored and the SD Card is for transferring stuff (edit: there's no SD card option, it's unnecessary since there are better wired and wireless options) . Also, if it's more comfortable for someone to analyze remotely from a larger computer, then any captured data can be sent in real-time from the phone - assuming it is coded!

I wasn't thinking of supporting an SD card interface, unless others feel this to be essential:

1) The low power Cortex M4 processor doesn't support it

2) If we change processor to one that does we'll need probably to go to 144 pin chip

3) The code to support SD card is complicated

4) You have to support a full on disc filing system

5) Could use a support chip as Gene suggested but it will use a lot of pins.

6) All the above if we support USB OTG except the low power processor is OK with it.

Probably not clear on my original block diagram that the options in the dotted processor outline might need to use a different processor.

On the other hand if we go for a more powerful processor we do get the benefit of faster processing all the time. The H7s support

dual voltage SD card at up to 104MHz - there is some free software from ST which seems to support FAT.

An H7 will burn more power speed for speed and about 300mW more at full (400MHz) speed.

See ST app note AN5200

I'm agnostic on this one - I've got quite used to STM32H7s now

MK

This is a fascinating open source project.

I'm rather curious as to whether there are ways to improve the 1m or 0.5 meter sampling distance accuracy, in terms of achieving repeatability. As in, say you need to return and remeasure a segment within the 20m x 20m grid. What steps are required to achieve this.

My presumption is that GPS might not give you the fine granularity required, or maybe it does (I'm no expert). So, I'm wondering if Bluetooth 5.1 or UltraWideBand (UWB) tech could assist here. Just a thought.

Oh, I see.. sorry I'd blindly copied that and not noticed the dashed line. I'll remove it, I cannot see it ever being needed, since there's more flexible wireless and wired options to transfer data.