Archaeology Resistivity Meter

Hi Michael,

I had these initial thoughts, but I've not had time to think things through (I have some time late Wednesday to do that):

There was mention of more sense probes, but maybe the expansion interface is sufficient for that, since one could drive (say) a latching relay via that. Or maybe space for on-board relay?

A minor point was, for the USB UART, for MCP2221 I already have Android code. But FTDI is totally fine too, i.e. if you've already got the schematic entered for that portion then it's quicker for me to just hunt for demo code for FTDI, if you let me know the chip number. Below is the the schematic I've used previously for the MCP2221 (it needs an external 3.3V regulator which probably the FTDI device doesn't, and has 4kV protection which likely isn't enough, I didn't place any additional ESD protection on this schematic).

One other thought was for a test facility, if there was were four jumpers or four DIP switches on the board which would connect a potential divider across the source (two switches for that) and two switches to connect the sense wires to the divider. Maybe jumpers are easier. But probably there will be test points on the board for easy soldering of a mini test harness during software development anyway.

I've looked at the Microchip part, very little to choose between it and FTDI, Microchip possibly better documented.

I like both companies - so I'll go either way !

BATTERY

I have results form first battery test.

These are nominal 7.4V 8.8Ah batteries from Amazon at £40 for two including a USB powered charger.

Not an ideal way to power a dual charger for these batteries - it would be quite safe to charge them at 2A max each

taking about 5hours, charging at less than 0.5A each is going to be slow.

My electronic load can do a simple (constant current load) battery rundown test so I set it for 0.5A load and

5.9V end point. The battery voltage has bounced back a little once the load was removed, which is not unusual.

I've recorded 7.527 Ah, which isn't that bad for a dead cheap battery rated at 8.8Ah. Its fine for this application.

It would be better to test at constant power, but the Rigol can't do that.

I might have squeezed a bit more by ending at 5V (2.5V per cell) but experience tells me that there won't be much

energy left between 2.95 and 2.5 volts per cell and it's not good for long life to repeatedly discharge to that level.

I've got the battery on charge and I'll run it again, then I'll try the other one.

I estimate that I got 54.2 Wh out of it - I'm looking for  a minimum of 30Wh for this application, so unless it dies

very quickly it looks OK.

MK

Hi Shabaz,

Re:

shabaz  wrote:

...

There was mention of more sense probes, but maybe the expansion interface is sufficient for that, since one could drive (say) a latching relay via that. Or maybe space for on-board relay?

...

Not sure about relays, especially latching ones...

There are two probe-switching scenarios. The much-less frequent use case 2, a static line of probes used to 'sound' and derive a cross-section, uses 'N' where N maybe a dozen or twenty probes, and that is the scenario where I was suggesting the interface allow driving an external mux (as various probes will be used as the C and P probes in turn). That could use relays, but they would be in the expansion mux, not the main instrument.

The on-frame scenario in the most frequent use case (use case 1) would be muxing between probes on the frame; this would be within a small number, perhaps two or three. All of the measurements would be done in time that the frame is in the ground and in the normal rhythm of using a res frame (commercial auto-triggered, not EPE style) the frame may only be in the ground for 500mS, so for each of the, say, 800 points per grid, those relays would cycle quite a lot!

Dave

WRT the maximum output voltage, right now I'm proposing differential output from amplifier using +/- 15V supplies, giving output voltages of 30Vpk or 60V pk-pk.

If you are correct that in excess of 60V pk (120V pk-pk) may be required this raises serious safety issues. While there is no clear single accepted standard for maximum safe

voltage on exposed terminals there is no doubt whatsoever that 60V can be lethal. The implication of this is that if the possibility exists that 60V or more appears between the output

terminals the current must be limited (even under fault conditions) to less than 10 mA.

This is not impossible but it is difficult and expensive - and arguably not a suitable project for home building.

On the other hand - it almost certainly is not necessary - the measuring technique proposed is fully capable of accurate measurements operating at -60db signal to noise ratio,

(ie operating correctly when the noise is 1000x or more bigger than the wanted signal.)

I'm thinking that the best route to get this thing to fly is to get quickly to a prototype and I certainly think it should stick with 60V pk-pk since this is simple and totally safe.

This gives twice the voltage of the Beck design (and is comparable with some commercial offerings (in so much as their specs make any sense)).

If necessary a higher voltage output power amplifier could be designed but I don't think we should kick off with that.

It would also complicate the design of the input stage which would then need high impedance switchable attenuators (more relays).

The instrument needs to be able to measure the currently actually being injected C1C2. In the simplest DC square-wave (periodically reversed DC), the current will hopefully stabilise towards the end of the injection period. The voltage measured P1P2 may never appear 'stable' due to noise or stray currents (mains, telluric, electric fencing etc.). The time taken to stabilise is why some kit offers ability to reduce the polarity switch rate to allow longer for the DC current to settle. The control processor needs to know when the current has settled, in order to take P1P2 voltage readings, otherwise its just guesswork and hope (and some early kit did operate that way). If non-square-wave excitation is being tried, it will be even more important to know the instantaneous current actually flowing C1C2. If the instrument has the needed current measurement, then measuring cycles can be optimised and that will also facilitate taking, for example, muxed sets of readings at each point.

A current source will force the current to be what you set (unless it runs out of voltage compliance).

Try running the TINA model for the current source that I've already posted (TINA is a free download from TI) .

If the voltage between P1P2 is not stable, and the current is stable then one thing that is definite is that you are not measuring current though a resistor.

Ohm's Law: I = V/R.

The measuring technique you suggest offers no discrimination against interference at all  - synchronous and  phase sensitive detectors just don't work like that. All (and it really is all) rational detectors require that measurements be made over multiple cycles and the discrimination against interference signals at other frequencies increases the more cycles are used per measurement.

(I think I did post some fairly clear models and explanation of this before).

MK

Hi Michael

I agree with your points entirely, I also agree that we need to get to a working prototype as quickly as possible, I'm sure this will prove the theory.

Ken

Thanks Michael,

I have heard of V=IR before, the problem is that it is not a simple resistor. At 50m between P1C1 and P2C2, the 'device' under test is approximately thirty thousand cubic metres of potentially-soggy interference-laden non-homogeneous earth; and if you go out to 100m as Ken mentioned he could with his commercial rig, its over a quarter of million cubic metres of earth in the circuit.

I'm sorry if I'm not being clear, if I may, I'll try and explain the sequence differently.

Phase 1: leading edge of square wave, try to apply, say, 10mA.

Constant current source will apply as much voltage as it is able/allowed to.

It can take maybe 2mS or more to get the injection stable(*1). There is no point in trying to measure until the injection is stable.(*2)

Phase 2:

Injection is stable, starting measuring P1P2, repeat as many times and as fast as possible until end of pulse. Apply filtering to try and get best reading.

Phase 3:

Reverse polarity.

Repeat above until get consistent filtered voltage and hence res, or until some form of timeout. Typically may sample for 20-50 full cycles.

*1) 2mS is a reasonable time for injection to stabilise, and usually works fine with 137Hz reversal, but in some conditions the 3.75mS pulse can expire before injection stabilises, which is why some modern commercial kit offers option to reduce reversal rate down as low as 17.5Hz

*2) I appreciate you could use processor ADC as, I think both you and Shabaz mentioned, to monitor this by looking for output voltage is stable and not maxed-out, and that might be sufficient indication for square-wave, but still believe that proper digitised value of the instantaneous current actually being injected will be necessary to explore non-square-wave excitation.

Dave

OK - great - I've made some progress on designing the input circuits and I might be able to post something by the weekend.

Unfortunately for this project, real work has picked up somewhat recently (although it's a welcome thing for me of course) so I have

less time free than I had.

I'm happy to take the electronic design as far as laying out a pcb and even building one or two but it would be nice to have a

volunteer or two to do software !

For now I'll post schematics as .pdf in this group - I can set up a Github repo if you would like (although I'm no expert in Git -so very

happy for some one else to do it if they can.)

MK

Hi Michael,

Better to be busy than not! : ) I've been a little tied up too, but will download the development environment and start getting used to the support libraries (not used ST's dev environment but am sure I can get up-to-speed quickly).. I'll be able to write code and test it on an off-the-shelf ST dev board, and then can try to bring up a board from a PCB as the hardware is developed.

I'll order a dev-board just as soon as I can find the processor number.. I think you typed it but it's buried in the hundred comments : )

EDIT: I think it is STM32L4R5VGT6 from a sketch, and the suitable board is NUCLEO-L4R5ZI (just a higher pin-count chip with I/O that can be ignored, and more RAM).

If that's correct, I'll go ahead and get that ordered.

Also, incidentally if it is that device, then Mbed OS is supported too : ) (Mbed doesn't support all processors, only very specific ones). I'm very familiar with that, and could speed up development a lot. (Mbed has an RTOS (RTX), huge suite of library functions, and a development environment famous for being online, but is downloadable - it uses GCC and Python scripts. But happy to use ST environment too. I could try both initially, until there's some skeleton code.

I was hoping you might

I'll look at the implications of using the exact same processor as the Nucleo board - it's one less thing to worry about if the code just drops in.

I have to say that my experience with RTOS and library code on these processors is very negative, but I've not used Mbed so that might be better.

My usual route is Keil tools (not an option here because much too expensive) and my own register access level code for almost everything else.

I'm interested in ST's development environment which I believe is truly open source.

MK

I've had a quick look at the Nucleo boards - there are two - one for the standard processor and one for the P version.

Farnell have no stock of P type processors so I'm going for the standard version.

(The P types can use an external SMPS to drive the core - I'll try to design our board to use either but I don't expect to

use the external SMPS - it offers no advantages in this application.)

I've ordered a Nucleo (Farnell 2845537)

The Nucleo processor has 144 pins and 2M of flash. (The extra pins won't hurt and may help so I'll design the board for the same chip.)

MK

shabaz  wrote:

 

...

 

...I think it is STM32L4R5VGT6 from a sketch, and the suitable board is NUCLEO-L4R5ZI (just a higher pin-count chip with I/O that can be ignored, and more RAM).

If that's correct, I'll go ahead and get that ordered.

Also, incidentally if it is that device, then Mbed OS is supported too : ) (Mbed doesn't support all processors, only very specific ones). I'm very familiar with that, and could speed up development a lot. (Mbed has an RTOS (RTX), huge suite of library functions, and a development environment famous for being online, but is downloadable - it uses GCC and Python scripts. But happy to use ST environment too. I could try both initially, until there's some skeleton code.

It's that device Farnell 2845537.Farnell 2845537.

I don't have one, but checked, and the off-line MBED studio supports it with MBED OS 6.

Also supported by CubeIDE so all options are open.

shabaz  wrote:

 

...

 

...I think it is STM32L4R5VGT6 from a sketch, and the suitable board is NUCLEO-L4R5ZI (just a higher pin-count chip with I/O that can be ignored, and more RAM).

If that's correct, I'll go ahead and get that ordered.

Also, incidentally if it is that device, then Mbed OS is supported too : ) (Mbed doesn't support all processors, only very specific ones). I'm very familiar with that, and could speed up development a lot. (Mbed has an RTOS (RTX), huge suite of library functions, and a development environment famous for being online, but is downloadable - it uses GCC and Python scripts. But happy to use ST environment too. I could try both initially, until there's some skeleton code.

It's that device Farnell 2845537.Farnell 2845537.

I don't have one, but checked, and the off-line MBED studio supports it with MBED OS 6.

Also supported by CubeIDE so all options are open.