Archaeology Resistivity Meter

I thought it might be helpful to explain my reasoning for some of my suggestions.

My concept was to end up with an instrument that can be made cheaply and be competitive with the commercial offerings in performance.

It has to make good measurements and never lose data.

That rather means that the data must be stored in simple on board media. My solution is a soldered in flash chip. With a little care you will never lose

more than the pending reading, no matter how the processor is stopped. None of the big OSs can do this without great difficulty or special hardware,

usually both.

Having got the data safely stored it has to be transferred to a computer with a screen and suitable software (which all demands a big OS) - we have logic level UART,

UART over USB, Bluetooth and possibly WiFi which covers a lot of bases. Almost everything has USB, the others add to the possibilities.

We have a flexible SPI display interface which can support displays from 2 lines character up to 800 x 480 with touch screen.

Several reviews of exsiting hardware comment on it being difficult to control  - my solution is to offer the option of two rotary encoder type controls with additional buttons.

Menu based character display interfaces with a rotary control are not too bad to operate - gives quite a lot of bang for not many bucks.

To be reliable implies a single board design - or as close as we can get.

The processor is a low power ARM Cortex M4 which clocks at 120MHz - enough welly to cope with any forseeable data collection load but only needing about 50mA at 3.3V.

In that package you get 640k of RAM, fast ADCs for overload monitoring, 3 hardware SPI ports  etc, several UARTS and other stuff.

The only way you can get close to using all the resources in modern processors is have flexibility with pin allocation which only happens if you solder the chip to your own board.

As I explained in an earlier post I'm expecting the instrument to controllable by a simple serial protocol which can be used internally between the human interface

and the measuring core or by external devices. Such protocols must be easy to code to and debug, which implies human readability.  CAN does not easily lend itself to this

because it is small packet (8 bytes max unless you use FD) based. Of course you can send text streams over CAN but it's messy. The strong features of CAN (non destructive

arbitration and the abilty to exist with many equal status nodes) don't do us any good in this application since we only envisage exactly 2 nodes in the network.

(For clarification, the "measuring core" is the hardware and code that does the actual measuring, hard real time control and safe data storage.)

The processor does have a CAN port  - so it could be done.

As far as I can tell from a quick scan of the web the ESP module will average about 150mA from 3.3V when WiFi is on and connected, maybe less.

No problem at all for transferring a few Mbytes of data but less good for continuous operation.

The output driver will use about 900mW max when actually measuring, call that 1W when psu losses are added in.

The rest of the works will need about 500mW (very roughly, a pretty display would double that).

The battery  will need to be capable of at least 15 W hrs, continuous WiFi would take that up to 20W hrs,  well within reasonable lithium ion range.

Shabaz's mega camera battery is about 40W hrs.

MK

You posted your

phoenixcomm  wrote:

 

shabaz   ok no matter what you do you will need 2 CPUs.

• one controlling the probes, etc most likely a PI, I would also have the GPS module there as well, and a CAN Module for talking to the control panel.
• the control panel could be an Arduino mega, 4x20 LED I2C display, a keyboard, and maybe some switches.

Please refer to my Bolg Adventures In CANaerospace (the hardware is the same as CANbus).

All you would do is take msgs off the CAN bus and put them on the display. You can also transmit messages the same way. easy peasy.

while I was writing mine so I didn't see it.

If by controlling the probes you mean generating the signals and mesuring them I'm not quite sure how a Pi would do that.

MK

michaelkellett

michaelkellett  wrote:

 

You posted your

phoenixcomm   wrote:

 

shabaz    ok no matter what you do you will need 2 CPUs.

• one controlling the probes, etc most likely a PI, I would also have the GPS module there as well, and a CAN Module for talking to the control panel.
• the control panel could be an Arduino mega, 4x20 LED I2C display, a keyboard, and maybe some switches.

Please refer to my Bolg Adventures In CANaerospace (the hardware is the same as CANbus).

All you would do is take msgs off the CAN bus and put them on the display. You can also transmit messages the same way. easy peasy.

while I was writing mine so I didn't see it.

 

If by controlling the probes you mean generating the signals and mesuring them I'm not quite sure how a Pi would do that.

 

MK

MiK ~~ I assumed you inserting the probes into the ground, as you would do with a Meger.

which would mean the PI using GPS would tell you when to stop and lower the probes?  after taking the reading, you would then have to raise them. rinse and repeat,  over and over.

~~Cris

one more comment if you use standard CAN yes there are 8-byte payloads, BUT there is a way to send "extended" frames which can have a variable payload.

please refer to https://en.wikipedia.org/wiki/CAN_bus  as It is easy to send longer data payload then 8 -bytes. Please note the yellow DLC field which controls the length of the red data field,

In CAN FD, the frame/message ID has been increased to 29-bits compared to only 11-bits in the classic CAN. The message payload size has been increased to 64 bytes of data in each CAN-frame / message, compared to only 8-bytes in the classic CAN frame. CAN FD can handle CAN frames/messages with 11-bit ID as well. A frame is a message transmitted as a sequence of binary bit-pattern. In CAN FD, the data rate (i.e. number of bits transmitted per second) is increased to be 5 times faster than the classic CAN. CAN FD protocol specification includes some other enhancements as well, such as better detection of errors in the received CAN message and the executing software flexibility to dynamically select (from a list) and switch to faster or slower data rate transfer, as and when required. Some sensors on the CAN BUS operates at slower data rate and others at faster data rate. CAN BUS is a shared pair of wires onto which electronic sensors, controller units and ECUs are connected. CAN Bus is used for exchanging information between operational units periodically or on demand. The electrical condition and configuration of the CAN Bus, i.e. the total number of units connected, the length of the CAN Bus wires and other electromagnetic factors determines the fastest data transfer rate possible on that CAN Bus. This because when units are connected to a CAN Bus (e.g,  Sensors, Controllers, or ECUs), it changes the electrical condition of the CAN Bus somewhat. The change may result in limiting the CAN FD protocol from achieving the maximum theoretical data transfer rate.

I did mention the possibility of CAN FD in my note, I don't think that it is supported by the STM32L4R5xxx processors.

CAN FD doesn't improve throughput by as much as you might hope, (very few systems actually manage the maximum possible data rate).

There is still the problem that CAN is a short packet based system and you end up with a complicated multi packet protocol to

send longer than packet size messages, and no standard PCs have CAN interfaces.

All these issues can be got over, but I still can't see what advantage would be gained from using CAN.

The primary reason the instrument needs interfaces is to connect with computers that run Windows or Linux, they all have USB,

none of them have CAN without add ons.

MK

michaelkellett there is no multi-packet protocol. when a message is received  It looks at the ID to see if is for him he sucks the message (the whole thing) you look at the DLC  fields value if its 8 just take the next 8-bytes,  or for longer values do whatever the DLC requires. There are a bunch of semi makers, TI is one of them and they send samples

~~Cris

It's quite true that if you use CAN in a simple point to point system you could use it as you suggest.

It isn't usually used like that in automotive or aerospace applications but there is certainly no reason why you shouldn't.

MK

Just jumping in having read through the discussion. This is an exciting project!

A few thoughts, apologies for a long post and to those who are experienced archaeological geophysicists.

There is much discussion of implementation, but it doesn’t feel like some of those advancing a particular line of attack necessarily understand the task, so there’s a danger of trying to decide whether an M4 or an M5 screw should be used before knowing what is to be fastened to what and what loads will be.

The essence of any geophysical survey of this type is a set of readings with exact knowledge of where each set of readings is taken. Most GPS is not suitable for this. Grids are achieved with lines which guide the operator where to place the probe frame. The smallest interval commonly used along the line is every 0.5m. Unless using RTK or synchronised PPK with event interpolation, GPS positions can be perhaps 20 or 30 cm out. Taking an extreme case, if successive epochs were 25cm out at either extreme along the line of advance, instead of readings showing true distance along of 0.5, 1.0, 1.5, 2.0 metres they could be recorded as 0.75, 0.75, 1.75, 1.75. Furthermore, as you walk along using a probe frame, you tend to swing it, drop the probes into the ground, walk forward and by the time it has taken the reading you are at least up to the frame. The idea is to keep a walking gait, not stop&start every half or one metre. What this means is that the frame is not always vertical. To get a good skyview, the GPS antenna would have to be mounted on a pole so the lever arm could be up to two metres. Some of the newest survey kit can correct for that, but it is building more complexity in which is un-necessary and the pole will make the probe frame even more unwieldy.

Having said all of the above, what could conceivably be of use is storing an approximate GPS position for say the start and end of each line of readings. This is not to provide co-ordinates for the points, but is to assist when collating individual grids, especially if the post-processing is done a little while later. Instead of searching for field notes to try and work out, say, was grid one at the E or W end of the baseline, even a crude GPS position accurate to a couple of metres would be sufficiently diagnostic; and if start and end of each line was logged, even if some were occluded, there should still be sufficient redundancy. Those GPS positions would not though provide co-ordinates for any of the readings. A GPS embedded in the controller could achieve this type of function (but would need extra in the UI to ensure if cold-started that it had acquired almanac and PDOP was sufficiently low).

Full processing is unlikely to be achievable in real time – there are potentially a whole series of steps which have to be run through, some of which need to take account of multiple grids. Furthermore, the average operator needs to keep their eyes where they are going (most of the time at least). Conceivably you could have a quick peek at the end of a grid – but mid-grid isn’t the time to look at results.

What is possibly useful is a checkerboard type display if the operator gets confused over which way to go; that could be also very valuable when obstacles are encountered to make sure sufficient dummy readings are entered (and no more). Otherwise, a count of points and lines and/or countdown, and an audible end-of-grid are all that is really needed.

With a well-designed probe frame and a well-designed UI, the display could rotate at the end of each line so as to prompt the user to optimally traverse (not as so important as with some magnetometers, but ideally the probe frame orientation should remain constant irrespective of whether heading ‘up’ or ‘down’ a line to avoid introducing striping effects). ‘Soft keys’ (membrane buttons, not a touch screen) placed symmetrically either side of the screen with legends that move with the display could mean the full UI remains identical whichever side of the frame the operator was on.

I recall one comment about the fixed probe position – it needs to remain fixed for the duration of a grid, but when surveying any worthwhile area it can be moved a considerable number of times in a day. When the fixed probes are moved, the absolute readings on the next line will inevitably be different – but the post-processing software should deal with that. Also, I think I recall someone mentioning storing readings in one byte – need more precision plus gain/range, so will need at least several bytes.

There has been discussion above on how to connect boxes, but from the perspective of a unit to be actually used in the field, I can see lots of disadvantages and no advantages in a multi-box solution. One box, two connectors in normal use – one to the probes on the frame, one to the fixed pair of probes. Those connectors need to be mud, damp etc. proof and the Bulgin ‘Bucanneer’ type used on some commercial kit work well.  If download via serial or USB etc. then need a protected connector for that, and one to charge batteries if to be charged in situ (sufficient battery or robustly field-swapped like on, say survey GPS would be good). The box needs to be easily dismountable so when the frame is chucked in the back of a van or pick-up the box can be taken inside.

One aspect which I didn’t spot so far in the thread (apologies if I missed it) is that if a suitable probe frame is used, a ‘clever’ instrument could mux the probes and, at one point, take readings with different spacings/combinations or configurations (Wenner, Schlumberger, double-dipole etc.). For that, would need provision for say four on-frame probe connections so make it a four-way connector. Futhermore, would suggest possibly having ability either on that connector (or a dedicated one) to power and control a bigger mux to allow inversion arrays to be used – that could/should legitimately be a second box.

I can easily see three use cases: the primary users will be the vast majority who will be traversing grids; second would be using an external mux to drive an inversion array – only used occasionally by a few users but a valuable add-on option. The third use case is one which, whilst exciting, I would suggest shouldn't be allowed to distract from the core instrument. The third case is a wheeled instrument (propelled by human or towed by ATV etc.) – that needs different triggering, odometry, postion logging, navigation etc. – would suggest that is kept until a core instrument that can achieve good, reliable results in the field is proven.

Finally for now, for those who aren’t familiar with archaeological geophysics, could I suggest three works:

‘Seeing beneath the soil: prospecting methods in archaeology’ by Tony Clark

‘Revealing the buried past: geophysics for archaeologists’ by Chris Gaffney and John Gater

‘Looking into the earth: an introduction to geological geophysics’ by Alan Mussett and Aftab Khan

and in regard to this specific technique:

‘Earth resistance for archaeologists’ by Armin Schmidt

Dave

Thanks Dave - good stuff !

I do electronics and didn't start thinkingabout measuring Earth Resistance until Ken started this thread.

I think the direction of travel is broadly in accord with your suggestions.

I think it's likely we'll use the camera style batteries  - the biggest ones on offer at Amazon claim 65 Whrs so would cope with any suggested features.

Totally agree about tough connectors.

I'm interested that you think a multiplexer might be worthwile from the start - not that hard to do (at 4 ways).

Single box - for sure.

We'll have at least 1 Mbyte of on board memory - so good for at least 8192 readings (at a very generous128 bytes per reading)

We need to think carefully about the ergonomics, I like the idea of using the box either way up - I'd seen the Frobisher box descibed as being left or right handed.

If we have  a graphics display it can work either way up without too much trouble.

I'd spotted Schmidt's book but balked at the price !

I found a useful paper he co-wrote

eac_guidelines_2_final.pdf,

EAC Guidelines for the use of Geophysics in

Archaeology: Questions to Ask and Points to Consider.

Item Type Report

Authors Schmidt, Armin R.; Linford, P.; Linford, N.; David, A.; Gaffney,

Christopher F.; Sarris, A.; Fassbinder, J.

MK

Thanks Michael.

Firstly, the Frobisher I understand does offer ‘left-handed’ and ‘right-handed’ operation – but doesn’t rotate the display, it just has two sets of five buttons (probably wired in parallel I guess) so it doesn’t really deliver what I described above. From the Frobisher TAR-3 manual “The two sets of buttons have the same functions and are for left or right-handed use”.

In various posts earlier there is mention of variable oscillators etc. etc. and adverse comment on square wave excitation. I think there may be some misconceptions. The measurements are performed in DC, and it is measuring resistance, not impedance. Whilst technically it is a square wave, a better way to view it is DC with periodically-reversing polarity. If pure DC is used, any electrolyte in the soil (which is a necessary precursor for sufficient current to flow and a potential to be measured) can become polarised around the electrodes. Measurements are made within the steady portion of each DC excursion, be it +ve or –ve going. There’s no need for variable frequency oscillators or synchronous filter or digital or analogue synthesis etc. I’m not actually convinced you even need a D-to-A other than as an easy way to generate controllable square-wave with mild variation in frequency (say 40 – 137 Hz) and voltage up to, say, +/- 60v. These frequencies are really within just bit-flipping scope. Voltage doesn’t change on-the-fly necessarily so very simple requirements.

The switching frequency can be changed on some kit, but a good default is 137Hz as mentioned earlier, as it doesn’t beat (for long at least) with 50 or 60 Hz mains. There are times though where you may want to pick a lower frequency if there’s no mains interference in the ground (more on that below).

Sequence of operation at each point is:

• Operator drops probe frame onto the ground and probes penetrate ground
• Readings are being taken continuously, but until steady, they are discarded. This means recording auto-starts when good contact is made, irrespective of how long since frame lifted from previous point, and without need to press a trigger as in EPE project.
• Readings taken and averaged, when sufficiently consistent, reading is accepted, stored and ‘beep’ sounded to tell operator OK to move to next point.

Within each measurement, there is a hold-off or delay from the leading edge of the ‘square wave’ to allow settling, before starting to take readings. In some isolated conditions, the readings don’t settle within the width of the DC pulse (say a bit over 3ms for 137Hz), so some rigs offer the option to – in electrically quiet areas – select say 40 Hz to give up to 12ms for the signal to settle.

Dave