Archaeology Resistivity Meter

Great thank you.

Hello Ken,

mk2 block diagram.

Several changes,

The DAC is driven by the FPGA

The ADC has changed type to a TI single channel audio type (much cheaper (about £3.30) and OK for our purpose I think.)

The ESP chip provides Bluetooth and WiFi, chosen because its widely available, dead cheap and there is a lot of app material on the web.

The battery type is defined as Sony NP-F970 equivalent, 5AH gives about 35Whrs, and I estimate a WiFi and display on power

consumption of 3W so the available batteries should give at least 10 hours per charge. I bought 2 and a charger for about £40.

The display is ideally a Riverdi 4.3" which uses the Bridgetek controller and has SPI interface. You can get a bare bones one for about £36

but the nice one with the touch screeen and flat glass front (like the PI display) is about £50. Or you can use a sub £5 quarter VGA type from

China - but I won't be writing code for it

Any illegible and unguessable features, please ask.

MK

Hi Ken,

That makes sense, that's a fairly straightforward condition to detect.

However, I'm wondering if a sensor should be added to assist, It's a cheap (in terms of hardware) thing to attach, to get better sensing of the physical state of the equipment (e.g. if it is physically moving or raised). Hi michaelkellett it sounds like a MPU-9050 (or similar, since I think that's obsolete) might be useful : ( or at least easy-to-access pins on the I2C bus. A bit of feature creep though.

EDIT: just to throw another idea out there, maybe it is better to just have a generic socket, e.g. PMOD or (perhaps even better since there's a huge range) Mikro-E Click, rather than a MPU.. sensor. Then people can experiment with add-ons such as additional sensors to adapt the design further.

Re headroom in the current injection:

Instruments typically offer range of constant-currents to inject - such as 0.1mA, 1mA, 10mA.

When you are about to start actual measuring, best practice is to take a couple of test readings at the most distant points of the (typically three) grids that you intend to measure from one C1P1 fixed probe location, and effectively check that you're maybe not using more than, say half your range to achieve that. Hopefully then you won't hit a range problem mid-grid.

Just to answer Michael's question about changing the injection current during a survey.

It is absolutely a fact of life that if you survey a non-trivial area, conditions will change. What you strive to do is to ensure that any changes are between grids, rather than mid-grid. The normal/expected discontinuity occurs when you relocate C1P1 after three grids or whatever. (Good) processing software will look for step-discontinuities between grids and will adjust them out. The not-uncommon error is that the operators forget to advance C1P1 in time so they run out of cable part-way through a grid. If you just relocate them, the readings are inevitably different due to distances and also possibly different soil conditions. You can then see operators doing the hokey-cokey with the probes - one watching the res on the screen whilst their oppo moves the probes in and out; or sometimes the operator will try (if the machine allows) try fiddling the calibration. The problem is that a mid-grid change in measured resistivity is usually associated with an underground change, so you can't risk auto-adjusting it; whereas a similar change between all twenty or forty points on each side of a grid boundary are usually associated with a change in the reference conditions.  That is usually C1P1 relocation, but could also be a change in injected current.

I have seen a change mid-grid due to the operator running out of range, and it was repeatable; the effect wasn't enormous, and if the data points also all log the conditions such as the constant-current used then the discontinuity could be a documented/visible event - but it would be better if it didn't occur; and if it did occur, it shouldn't be a silent auto-ranging, the UI should prompt the operator along the lines of 'Max range exceeded - change current now mid-grid? or change current and re-start the grid?'

Dave

shabaz  wrote:

 

Hi Ken,

 

That makes sense, that's a fairly straightforward condition to detect.

However, I'm wondering if a sensor should be added to assist, It's a cheap (in terms of hardware) thing to attach, to get better sensing of the physical state of the equipment (e.g. if it is physically moving or raised). Hi michaelkellett  it sounds like a MPU-9050 (or similar, since I think that's obsolete) might be useful : ( or at least easy-to-access pins on the I2C bus. A bit of feature creep though.

Shabaz/Ken,

Its not an instrument dynamics device or sensor, its whether or not current is passing C1 to C2 ...

Dave

Hi Dave,

That's understood. This isn't to replace detection using the probes. It's about the potential to make the software more intelligent about precisely when it sounds an alert, for instance if the user decides to take a few seconds longer before setting the instrument down.

Yes agreed, but as Shabaz says a fairly easy condition to detect.

Ken

I have other instruments which make sensitive measurements, and (since I'm working on a desk and not in a field) I end up having to use rigid wire so that even the cabling doesn't move more than required to get the tests done. A movement or change in the bend of the wire causes a detectable difference for those types of measurements, partially because reactance changes.

In the field, perhaps some of this can also be reduced, by (say) having an alert at the beginning to advise the user to verify the location of C1P1 is adequate and to use the specified wire technique (for instance not to loop the spare cable in your hand for part of the grid and not the rest of the grid), and so on, i.e. assist in training the user based on whatever best practices you have. Anyway, some of this can come later when the software or user procedures are documented by someone.

Re. Sound,

I did think about this a little while ago but forgot about it.

The processor has an on chip DAC with good DMA control  - so we need to add a simple filter and power amplifier

( and a louspeaker) and we can make any sounds you can imagine.

Perhaps Ken can add these to the block diagram.

Re. Quality of connections to the ground and estimating such,

The other point to bear in mind is that the processor is using it's 12 bit ADC to monitor the output voltage from the current source,

so it can make a cycle by cycle (or even faster) assessment of how the current source is coping. To facilitate this there will need to be

a digital signal from the FPGA to trigger the processors ADC. I always try to have a few uncommited signals available between

FPGA and processor for when this sort of thing crops up.

MK

Hi kltm

It will end up looking something like this on the block diagram:

Many thanks!

Great.

I think I'm ready to draw up schematics.

(You might think a formal spec should come first  - but we have a lot of stuff in this thread already and I find

that trying to make a a complete design often helps focus on issues that abstract planning misses.

Think of it as an Agile approach to hardware design And schematics are easily changed.)

I'm wondering if we should start new threads or make a new group for this project.

MK

Great.

I think I'm ready to draw up schematics.

(You might think a formal spec should come first  - but we have a lot of stuff in this thread already and I find

that trying to make a a complete design often helps focus on issues that abstract planning misses.

Think of it as an Agile approach to hardware design And schematics are easily changed.)

I'm wondering if we should start new threads or make a new group for this project.

MK

Hi Michael,

Hehe by random coincidence I was reading last night that it's a valid approach, to have elements of architecture and design co-occurring like you intuitively suggest! it's ISO 42020.

Regarding group/thread I've never created a group on the platform so I'm unsure how it works but sounds like the right thing. Maybe Dudley or cstanton can advise the best method for such a project.

Also, either way if a tag is also used (e.g. some unique codename/project name) and it is added to the new content and to this old thread, then it can be conveniently grouped up by Jive perhaps (like with a custom banner and intro etc, or at least just searchable based on that tag).

Another option is to create a Document. It can be maintained by several people and has versioning.

You can set who has edit right.

Editing it is identical as with a blog post.

If there's a good reason for a group to be made then I can help that to happen.

If the problem is trying to trawl through this entire thread, then there's an URL you can use which helps to display all of the comments, and that is Archaeology Resistivity Meter where ?displayFullThread=true is at the end of the URL.

Hi Christopher

I would welcome your assistance in helping to set up a group for this project please.

Ken

I need to know:

- Who will administrate the group

- Whether it should be publicly visible, or private

- Depending on that, whether or not there is a list of people (links to their profiles or of their usernames are useful) who you want to be able to create content in the group, for example you might want a limited set of people to create discussions and blogs and documents, but only allow the public to comment on them.

- If you have a preference for 'where' the group is listed or created on the site, which will be taken into consideration

This can be sent in a private message.