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.

Hello Sabaz,

I'd prefer the FTDI chip (FT230X) since I've used it before and had no problems - no regulator needed.

It doesn't have good ESD protection either.

I'll look at the Microchip part.

I usually design boards with lots of test points , compatble with those little wire loop 'pins', or wires, since it's a pad with a 1mm hole.

The full processor debug will be available and at least two FPGA pins.

I'm leaving mpx till a later design and additional pcb. If the expansion interface carries some signals and power it can do almost  anything.

MK

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

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.

Hi Michael,

Great, I'll get that board ordered too.

I've installed the ST dev environment to get some familiarity, and will try to sketch about how things could function in the software in the next couple of days.

I'm thinking when it comes to the code, to write the first bits for both the ST environment and mbed environments, so that we have some options initially, and eventually just sticking with one stream as I get up-to-speed adding more and more code features (i.e. likely ST since you're familiar with it too).

I'm not very familiar with the ST compiler tools - only the libraries. So I'm perfectly willing to be converted to mBed for this project.

I'd be very interested to hear about your comparison of the tools.

MK

Hello, I had a bit of time left at the end of today and installed the MbedStudio I had downloaded.

That was the good bit, then I tried to run it - OMG - what a disapointment !

It flouts all the usual windows standards of look and feel so I found it a total pig to navigate, It doesn't have functional Help in the usual way.

There is a help itme in the menu bar but it doesn't provide a normal Help facility at all.

I got it to load up the "bare metal blinky" example - which is still a .cpp file relying on an OS. It included masses of odd files (including things like CAN drivers).

And worst of all it doesn't build - there are errors relating to some deprecated legacy file (writing from home now so  I don't have it in front of me.)

That's when the lack of Help really bit - I couldn't work out how to close the current project and open a new example file - aargh - then it was time to go home.

This evening I downloaded the ST CubeIDE.

I am familiar with the Cube thing for setting up pins  and clocks. The clock thing is actually quite useful. The way the ST tools "organise" the generated code is disgusting,

But that's OK - you just put things somewhere sensible.

The generated code compiles witout errors.

And of course the IDE is Eclipse so looks and behaves like we've all got used to.

The Help still isn't a patch on Keil's but it does a good bit more then the Mbed.

So on the basis of this very quick and quite unfair test - I'm going to play more with the ST tools.

I'm very keen to hear if you can get the Blinky to work on Mbed.

(Is there a way of keeping it to C or Mbed fundamentally C++)

MK

I compiled the blinky for OS6 on mbed studio for your board and it compiled correctly. See small screen capture I posted above.

I too prefer the Eclipse way of working more than MBED Studio. But not that much more that it would decide a way forward.

Hi Michael,

I've not used MbedStudio, but Mbed capability is also a bunch of Python scripts replacing the usual Makefile. I've used that (on Linux, but in theory workable with Windows), i.e. using any text editor (e.g. Visual Code) and then using the command line to run the script to build the project, and another command to program the board. It's possible to create a script, i.e. type something like ./install in order to flash the device. Visual Code allows the command line to be dispensed with, but it's just a preference thing.

The language when working with Mbed is partially C++, the main benefit is the libraries are nice (they're high-level, since the same APIs have to work with other manufacturer devices too). Some of the APIs use C++ functionality however, so typing in pure C is not possible.

I'm currently writing some ideas on paper, at first thought there seems to be about 8 'work areas' a user might want to get involved with, and each seems to be separate so that can make things easier, i.e. launch into any work area based on user input or otherwise. But I'll probably focus on the core area first (calling it Survey for now) since by trying to design that (on paper) it will force me to concentrate on the important bits of the main functionality, so that code for testing bits of hardware is quicker to be done.

Also, if you know which Flash chip you want to use, I can order that too, so I can play with getting some basic file method to meet all the workflow areas to the extent of being enough for a prototype.

The ideas so far are (not really user stories, just very brief half-baked brainstorming, I've only spent 10 mins on it so far : )

EDIT:  From Jan's screenshot it looks like ARM have implemented MbedStudio on top of a modification of Microsoft Visual Code, the icons and layout look very similar.

I wasn't originally a fan of Visual Code, but it's flexible to a lot of coding tasks, and so many coders use it now, that it's likely to remain around for ages. I like that it's extremely expandable, but there's definitely a learning curve to it - lots is unconventional with it : (

I used to use the paid 'UltraEdit' but it offers low value now that Visual Code is around.

Thanks for note.

Here's a bit of the Mbed console output during compile:

Building project mbed-os-example-blinky-baremetal (NUCLEO_L4R5ZI, ARMC6)
Scan: mbed-os-example-blinky-baremetal
Compile [  0.4%]: mbed_tz_context.c
Compile [  0.8%]: AnalogOut.cpp
Compile [  1.2%]: AnalogIn.cpp

ABOUT 240 other compiled files skipped !!!!!!!

Compile [ 99.2%]: USBPhy_STM32.cpp
Compile [ 99.6%]: trng_api.c
Compile [100.0%]: watchdog_api.c
Link: mbed-os-example-blinky-baremetal
[Warning] @0,0: L3912W: Option 'legacyalign' is deprecated.
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Limit (referred from c:\ProgramData\Mbed Studio\mbed-studio-tools\ac6\bin\..\lib\armlib\mc_w.l(malloc2.o)).
[Error] @0,0: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Warning: L3912W: Option 'legacyalign' is deprecated.
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Limit (referred from c:\ProgramData\Mbed Studio\mbed-studio-tools\ac6\bin\..\lib\armlib\mc_w.l(malloc2.o)).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Finished: 0 information, 1 warning and 3 error messages.
[ERROR] Warning: L3912W: Option 'legacyalign' is deprecated.
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Base (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Limit (referred from c:\ProgramData\Mbed Studio\mbed-studio-tools\ac6\bin\..\lib\armlib\mc_w.l(malloc2.o)).
Error: L6218E: Undefined symbol Image$$ARM_LIB_HEAP$$ZI$$Length (referred from BUILD/NUCLEO_L4R5ZI/ARMC6/mbed-os/platform/source/mbed_sdk_boot.o).
Finished: 0 information, 1 warning and 3 error messages.

Notice that this "bare metal" blinky compiles more than 240 files !!!

The actual Blinky is this:

/* mbed Microcontroller Library
 * Copyright (c) 2019 ARM Limited
 * SPDX-License-Identifier: Apache-2.0
 */

#include "mbed.h"

#define WAIT_TIME_MS 500 
DigitalOut led1(LED1);

int main()
{
    printf("This is the bare metal blinky example running on Mbed OS %d.%d.%d.\n", MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION);

    while (true)
    {
        led1 = !led1;
        thread_sleep_for(WAIT_TIME_MS);
    }
}

I have about a million problems with this but the main ones are:

Even a simple project is dependent on literally hundreds of unknown files - an error in any one of them will break it.

Its typical of what I would call 2nd decade code - everything slowly percolates down to the hardware though layer upon layer of abstraction (obfuscation !).

The error is typical of this approach - I have no idea why we need to build mbed_sk_boot or what legacyalign was meant to do, (or how it can be wrong in example code) !

I come from a hardware for mass production/ high reliability back ground and I aim for:

• Every line of code should be embedded in the project itself, so it can be rebuilt, byte accurate, 10 or 20 years later.
• Every line of code should be traceable to a requirement in the specification (rarely met except in aerospace but a good goal).
• There should be no dead code.
• The code should be as simple as possible, for example timers should be set up by direct control register writes, rather than through some opaque API call
• which has stuff to work 100 timer features not present on the hardware you are working.

It seems to me that the Mbed approach is aiming for a sort of baby Linux on embedded processors - there will be places where that is a good thing but it's not the route I would choose for this project.

Having said that, if others really want to go that way, I won't throw my toys out of the pram.

The core code on the processor needs to be able to set up some circular buffers for data from its own and the external ADCs and DACs and DMA for SPI to the FPGA and for the internal ADCs and DACs.

It will have to support regular maintenance of these buffers - probably at a faster rate than a typical OS tick rate.

I'm assuming that the  Mbed OS will support this (although a super loop would do it better and more transparently ) so I can't see why the thing shouldn't work in Mbed.

MK