Archaeology Resistivity Meter

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  and of course the PI would handle the GPS.

Oh, sometimes the oldies are the best!

Paul D

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.