Concept Design

[moodz]

..so I dug my old HDL code for the AD7760 and combined with a FPGA based VGA waveform code block it compiled OK and loaded into the board is mostly working :-)

The FPGA can generate VGA signals with just a few resistors. So I basically have a 24 bit sampling programmable realtime CRO at 2.5 SMPS.

The ADC inputs are not connected to anything so waving my hand near them (5 cm ) lifts the noise floor considerably. This indicates that though there is no gain on the input ... 24 bits is very sensitive.

Happy to post the code if anyone wants it ( very alpha needs more work though it is getting 24 bit data from the AD7760 into the FPGA and that is the main thing ).

Obviously can sync the TX by generating output sigs from the FPGA.

[Willy Bayot]

About the LTC2380 which is specified capturing at 2Msps, I made a quick calculation taking into account the max clock speed of SPI for the STM32 and the PIC32MZ.

According to the datasheet of the ADC, tCONV = min 343nsec, minimum tACQ = 95nsec for 24 SPI clock periods. with a minimum tCYC of 500nsec (2Msps)

PIC32 max SPI clock speed = 25Mhz or period 40nsec--> tACQ = 40x24 = 960nsec, tACQ+tCONV = 1.3µsec/sample = 770 Msps

STM32 max SPI clock speed = 42Mhz or period 24nsec--> tACQ = 24x24 = 576nsec, tACQ+tCONV = 0.9µsec/sample = 1100 Msps

Thus, in practice, we can expect to get more or less one raw sample every µsec in Direct Sampling mode

I have recalculated the timings we could get from a LTC2380-24 on STM32 and PIC32MZ
Actually, the master clock of STM32 being 180MHz, the SPI clock is 180/4 = 45Mhz and the master clock of PIC32MZ being 200MHz, the SPI clock is 200/4 = 50Mhz

The 24 bits running through the SPI of the STM32 is taking 533nsec + tCONV 343nsec = 876nsec = 1.14Msps
The 24 bits running through the SPI of thePIC32 is taking 480nsec + tCONV 343nsec = 823nsec = 1.21Msps
We still get approximatively the same capture rate.

[ivconic]

I was joking of course, I had Trump in mind.
Let's cut the story short and get dead serious.
Although direct sampling is a more tempting option; I think it will be more difficult for the reasons mentioned several times so far.
Let's start with an analog approach, a 16-18 bit ADC and a processor that can be found on many development systems and modules.
STM32. It can also be programmed in the Arduino environment.
It is available on several modules and in several variants.
ESP32 for example with BT and WiFi. I think I've seen some other variants.
In this way, a larger number of people will be able to get involved in the development, making, testing, etc.
That is my final suggestion. And I won't interfere anymore. If adopted ok, if not adopted... again ok.

[Carl-NC]

I'm still exploring concepts, I'm not 100% sure of the final direction. My problem is I am only able work on this every 3 or 4 days so it's a slow process.

If I were the boss, I would have fired you all a few weeks ago!

And I would be fine with that. But like a political coup, whoever fires me has to take over as Boss.

[ivconic]

1. Draw the schematic
2. Design the circuit

That doesn't work very well for me.

Not for me either.
But one would think by now that you already have something ready, after so many topics and so many written pages!??
How many more topics and posts to finally appear the schematic? At least with parts that are easy to define?
I'll say it again; not spice scribbles, but drawing in a program designed for that.
There is no consensus about the supply voltage either... as far as I can see...
If I were the boss, I would have fired you all a few weeks ago!

[Carl-NC]

So let's go step by step.
Schematic first.

1. Draw the schematic
2. Design the circuit

That doesn't work very well for me.

[ivconic]

Just caught me doing it... literally every day I spent several hours on drawing parts, 3D printing... adapting for some pcb and more often drawing pcb first but keeping in mind what comes later, trying to optimise both to match each other and not to make tradeoffs on eiter sides at all.
One man band. Unfortunatelly not a team player.
So I must have all from docs infront of me... or I will not start working on it at all.
What you see on photos above is just 1/1000 of my works so far.
Those are ones I am finishing these days.
I don't have time to be bored and annoyed...

[ivconic]

[ivconic]

The way I see a team working together, is that each one applies his knowledge to the part of the project where he has something to offer. Not everyone of the team members needs to be a programming expert. There are many parts of the detector that need to be designed.

For example: the detector needs to be extremely rugged and yet ergonomic. Do you have any ideas on that?

By adding the strength of every team member we can find the solutions, not by everybody trying to repeat what the others do.

In order to follow the topic; I usually need correct and complete schematic, let me repeat again: drawn exclusively in any conventional schematic capture software, pick anyone that suits you.
...
Rugger and ergonomic? Ok. First I have to see schematic, then we have to draw pcb(s) for it. And just then; when we know the volumes of pcb, positions of which goes where: I could anticipate the enclosure.
I am talking this from ongoing experience, since 2018. till this very moment (just caught me doing it) in "putting the pieces together". One leads to antother. In order to get enclosure; first I draw pcb. While drawing pcb; all the time I keep in my mind all the next
steps I 'll have to do; drawing 3D enclosure and parts (usually it is not one volumen but several parts later put together). While drawing 3D parts; all the time I have to keep in my mind all the peculiarities, features and specifics related to 3D printing.
Looong story! Vicious circle, one leads to another, one depends on the other... I've been doing numerous devices like that since 2018. From the "ground zero" to finished product.
But everything has its strict order.
A house is not built starting from the roof, but starting from the foundation... if you understand what I mean.
So let's go step by step.
Schematic first.
Later goes other steps...

[Tinkerer]

I can't find it!? The TX thread is fed up with parts of spice attempts. You can't call it schematic.
Because I don't deal with spice simulators and I can't decypher the whole scribble presented there.
My suggestion is to trasnlate "all that" what You think is alright to a real schematic, drawn in real schematic capture software.
And then place it on fixed space (usually first page of thread) and say "this is real anf final schematic of this and that".
Same goes to TX part. And every other part.
Otherwise this is a mess. One claims "i did this and it si good", another claims "i did it different ways and it is good", third claim "both methods are fine but i know better"... "i suggest this"... "i suggest that"....
Me, guys; i am lost. Therefore me annoying you here with constant demands.
You can't expect me or any other to join here and work something, first by spending huge ammount of timy by decipehring those scribbles and all that mess done by now.
No order, nothing. Just a mess.
Extract most accurate version of schematics and place them on one fixed place and then say "this is what you need to join the work done by now".
...
Otherwise; there will only be a few of you klingon speakers working on this project because this is definitely not the way electronics are done so far.
I'm slowly getting the idea that a few of you are doing all this on purpose. In order to reduce the number of interested parties.
If it is like that; it is fairer to say so. Lock this thread and only allow "Klingons" to participate.

The way I see a team working together, is that each one applies his knowledge to the part of the project where he has something to offer. Not everyone of the team members needs to be a programming expert. There are many parts of the detector that need to be designed.

For example: the detector needs to be extremely rugged and yet ergonomic. Do you have any ideas on that?

By adding the strength of every team member we can find the solutions, not by everybody trying to repeat what the others do.

[Olly]

yeh the boards I am using just plug together .. no soldering .. pure luck as they came from different sources and the FPGA pins are remappable as you know but the FPGA board is a bit dated now. The Artix or similiar would be the go nowadays.
I am not doing much DSP ... the code is set up as a 24 bit oscilloscope .. vga output from the FPGA ... It was setup for a pulse induction detector so it samples the decay waveform ... averages it and displays on the VGA.

moodz

Not quite plug and play for me I'm afraid, the main issue will be matching the 2V5 I/O of the ADC board with the 3V3 I/O of the CMOD A7 (All it's user I/O banks are on the 3V3 plane so not quite as simple as powering one of the banks with 2V5).
Should be a nice powerful platform once I've got that sorted out though.

Olly

[moodz]

Very cool Moodz, I've got the exact same AD7760 evaluation board and am coupling it with a CMOD A7-35T (Artix 7) FPGA board to follow along with this experiment.
My HDL code is written in Verilog not VHDL like yours but both work just as well.
Looking forward to porting the DSP (once the concept is finalised) to the Artix as it has a number of high performance DSP blocks which should be just the ticket.

Olly

yeh the boards I am using just plug together .. no soldering .. pure luck as they came from different sources and the FPGA pins are remappable as you know but the FPGA board is a bit dated now. The Artix or similiar would be the go nowadays.
I am not doing much DSP ... the code is set up as a 24 bit oscilloscope .. vga output from the FPGA ... It was setup for a pulse induction detector so it samples the decay waveform ... averages it and displays on the VGA.

moodz

[moodz]

FPGA ... really!? Seriously!?

FPGA is only a whole lot of logic gates in a programable chip similiar to a memory chip. Remember 74XX TTL and wirewrap boards ?? FPGA is just programmable wire wrap in a way.

I have some circuit diagrams for old video games like space invaders and Galaga etc .. you can enter those diagrams into a FPGA and the whole logic board for one of those games some with hundreds of TTL chips runs in one FPGA.

Yeh it is gonna restrict alot of ppl who havent had the time or inclination to pursue this part of the hobby .. but for some of us its the way to try out new ideas that maybe would not be possible otherwise. An FPGA with and ADC bolted onto it is a very powerful tool not just for metal detectors.

Having said that though I still reckon we can also come up with a more traditional design .. OK it will have a CPU but small that can still provide top shelf performance.

moodz

[Olly]

Stuff is happening .. I have dug out my FPGA bread board and it has a 2.5 MSPS AD7760 ADC on it ... I have already tested the CC transmitter on a VLF coil and it seems to work fine... but obviously will need DSP .. I already have the HDL code for the ADC to talk to the FPGA.

From a modular point of view it is coming together and everything is translatable to different hardware if needs be.

Once the building blocks are tied together the hardware can be finalised.

moodz

Very cool Moodz, I've got the exact same AD7760 evaluation board and am coupling it with a CMOD A7-35T (Artix 7) FPGA board to follow along with this experiment.
My HDL code is written in Verilog not VHDL like yours but both work just as well.
Looking forward to porting the DSP (once the concept is finalised) to the Artix as it has a number of high performance DSP blocks which should be just the ticket.

Olly

[ivconic]

..it will get there .. no point publishing schematics of a moveable feast. Some projects are designed in a cathedral and some in a bazaar .... I am more the walk around the bazaar and change my mind 20 times but I will go back to the best shops.
In the cathedral its all done by the numbers and everyone wearing strange clothes.

Stuff is happening .. I have dug out my FPGA bread board and it has a 2.5 MSPS AD7760 ADC on it ... I have already tested the CC transmitter on a VLF coil and it seems to work fine... but obviously will need DSP .. I already have the HDL code for the ADC to talk to the FPGA.

From a modular point of view it is coming together and everything is translatable to different hardware if needs be.

Once the building blocks are tied together the hardware can be finalised.

moodz

FPGA ... really!? Seriously!?