Archaeology Resistivity Meter

Interesting ideas so far.  I meant to chime in earlier, but things have been pretty busy for me lately (building a deck and entertaining my Grandchildren again).

Several years ago, I was asked to sit in with some friends of my sister that work at a geotech company.  They were looking to build impedance measurement devices for soil surveys.  I came across this amazing looking chip from Analog Devices that looked like a great way to measure impedance (including a complex component).

Here is a snippet from the specification:

The AD5934 is a high precision impedance converter system solution that combines an on-board frequency generator with a 12-bit, 250 kSPS, analog-to-digital converter (ADC). The frequency generator allows an external complex impedance to be excited with a known frequency. The response signal from the impedance is sampled by the on-board ADC and a discrete Fourier transform (DFT) is processed by an on-board DSP engine. The DFT algorithm returns a real (R) and imaginary (I) data-word at each output frequency.Once calibrated, the magnitude of the impedance and relative phase of the impedance at each frequency point along the sweep is easily calculated using the following two equations:Magnitude = 22IR+Phase = tan−1(I/R) A similar device, available from Analog Devices, Inc., is the AD5933, which is a 2.7 V to 5.5 V, 1 MSPS, 12-bit impedance converter, with an internal temperature sensor, available in a  16-lead SSOP.

This might be of some help in your planning.

Good luck and let me know if you need any help on this project.

Hi Gene,

It's a super-interesting chip, I was keen to use it a few years ago for plant soil purposes, and for hydroponics - to try to see if the soil or liquid has nutrients. The idea being to have a signature of known good soil or water by sweeping through the spectrum. I never got to try it though sadly, the project moved on to something else.

It was felt that it could have had a lot of merit because then you could publish the signature, so others could try to replicate a yield (it wasn't going to be for farmers, more for home use), and to not waste nutrient. But, I have no idea in practice if the result would have been usable, or too inconsistent/variable.

I wish I'd done some work on it at the time, since it could have been useful for other purposes too.

The proposed design so far is one half of the impedance measuring system, but with digital processing. In theory it could be converted to an impedance measuring system with no additional hardware change, just a software upgrade, since the frequency will be know, and there will be some sync pulse from the FPGA, we just need to internally multiply with a 90 degree out of phase signal from that sync pulse too.

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

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.

A lot of the hand drawn lines look a bit dashed.

I was just warming to the idea of an STM32H7 ...... but I think lower power is better really.

MK

Shabaz,

I have changed your outline. In the UK two of the probes are 'fixed' and can be in the same position for the day (or longer)

The QGIS team have vast experience to call on in displaying this type of data  Many groups in the UK use QGIS and some run training days in Python.

You can have a table and power at P2C2 and use existing equipment (including a tea and coffee facilities - YES most groups have a tent that could be pitched close to the 'fixed' probes if needed) My editing of your original is very bad, sorry.

When I said "What about a Pi" I meant "QGIS would be good. it runs on Laptops and a Pi"

Paul D

Hi Paul,

I've updated it to incorporate your comments regarding the probes and software. One underlying difference (won't make a difference to the user apart from a major improvement hopefully!) is that the older existing designs use analog circuitry for most of the signal generation and processing. In this design however, more of that is done digitally, and so needs precise timing and regular fast calculations, which would be an overhead for the Pi, so all that underlying processing needs a microcontroller (and an FPGA), hence the separation between that and the Pi. The Pi has full control via USB Serial, which is a key difference to Snuffler. The Pi can instruct the desired frequency, start/stop measurements and acquire the data in real-time, i.e. the Pi is in full control using Python, C or any desired language. Also, the interface can still work with existing software in real-time (I've run Snuffler to examine what data is expects), so I've listed those in the diagram now.

For those who want to use a laptop, they will find it equally seamless with Windows and existing software, it's just more convenient to use USB rather than have the older RS232 DB9 connector. Just like with the Pi, they can have full control using any programming language if desired.

For those who want to use Android, initially there could be just a simple skeleton app which doesn't do much but provides some basic visuals, or just collects up the data to e-mail it.

Shabaz,

What software are you using to create your drawings? They are great.

Paul D

Hi Paul,

Thanks! I'm using Powerpoint. I've used it a lot and so already had things like the Pi and display ready to use.

For items like the phone graphic, I usually google search for (say) 'phone transparent png' and then it finds stuff with the transparent background.

michaelkellett I do agree with you, but

1. The Pi4 can support Debian (Linux)
2. I disagree with Shabaz about using USB between PI and control head, As said before CAN bus is robust and you don't have to write the protocol.
3. I disagree with Shabaz about  using WiFi ( sucks power)
4. If you go with the Pi, then with a USB3 to SATA adapter (this is what my VOIP server is running on) and run a notebook drive, for the OS and Data The Pi can be set not to boot from the SD card if you wish.
5. if you use a tablet, that's overkill + you would have to write an app.
6. if you use a small control box (operator panel) you could put Arduino in it. The would drive the CAN bus communications,  4xx20 I²C display, and keyboard, plus and switches etc.
7. So if you go with my suggestion you need two cables in the waterproof cover.
   1. (5 Volts and Ground)
   2. two-wire shielded twisted-pair (50-ohm stuff works fine.

~~ Cris

.

michaelkellett I do agree with you, but

1. The Pi4 can support Debian (Linux)
2. I disagree with Shabaz about using USB between PI and control head, As said before CAN bus is robust and you don't have to write the protocol.
3. I disagree with Shabaz about  using WiFi ( sucks power)
4. If you go with the Pi, then with a USB3 to SATA adapter (this is what my VOIP server is running on) and run a notebook drive, for the OS and Data The Pi can be set not to boot from the SD card if you wish.
5. if you use a tablet, that's overkill + you would have to write an app.
6. if you use a small control box (operator panel) you could put Arduino in it. The would drive the CAN bus communications,  4xx20 I²C display, and keyboard, plus and switches etc.
7. So if you go with my suggestion you need two cables in the waterproof cover.
   1. (5 Volts and Ground)
   2. two-wire shielded twisted-pair (50-ohm stuff works fine.

~~ Cris

.

michaelkellett  and of course the PI would handle the GPS.

Hi Cris,

The existing visualization/archeology software doesn't use CAN, it uses serial (either RS232 or USB serial, either will work with them). If CAN is used between Pi and the main unit could you approximately sketch or list what modules etc will do the translation to RS232, or will appear like /dev/ttySerial to the software? (and appear like a Serial interface to the PC too, otherwise people cannot use the existing Snuffler software, which only runs on Windows).

Just to clarify although it says USB, really the underlying communication is traditional 9600 or 115200 etc baud serial, i.e. easily swapped to RS232 or any long distance, robust method. If anyone wants these methods, they would be very easy to convert, and no code changes are required because there's no USB protocol being coded, there is a UART-to-USB chip (which could be unsoldered and replaced with UART-to-RS232 or to any other desired method). If anyone knows what hardware to use for wiring CAN to Pi and write some code for it, then it can be easily wired in, because there's no USB from the microcontroller, it's two-wire UART Tx and Rx. That detail will appear on the block diagram that Ken is drafting.

I agree regarding WiFi, I don't see the need for those comfortable with the other methods, but it's an option for those who feel more comfortable programming for an ESP chip. It's just to accommodate them, so they can contribute too if they want to. I don't know how to use the ESP, and it is labelled as an option for anyone else (if they want to) to contribute.

The tablet/phone is a low-priority option, it is enabled for zero additional hardware cost since it uses the same connection (USB Serial). Using it would give some free advantages (by free I mean no hardware cost, beyond owning a phone) such as the potential to grab positioning data, or sending data using cellular. For those more comfortable doing it with the Pi and GPS module, that's totally fine.

I'm self-encouraged to write a simple mobile app if anyone sees an advantage in it. I did some brief testing last night to confirm for myself that I'm not over-promising by putting the tablet in the diagram and then subsequently discovering it is impossible. If no-one wishes it, that's fine, the time wasn't wasted because I can use that for a different project one day. It could be a really poor solution, for instance if the mobile battery dies etc. I don't know.

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.

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