AMX TX

[ivconic]

If I didn't see it 16 years ago, it's certainly because I didn't see much interest in it, otherwise I would remember it.
Just because I don't write a lot of posts doesn't mean I don't look at posts....
And I may have several accounts who knows... My first design 30 years ago now approx
Come on, I'll stop bothering you
I'm going to have to calm down because here I am on my 39th message!

You don't bore me a bit, on the contrary; I'm so glad there are still people alive here!
Yes, I think you hit the spot; many (like you) just keep quiet and watch what's going on.
And they can't even write anything.
If you followed the initial posts on the topic of the AMX project (God kill me if I know why they called it that)...
well, if you followed the initial posts; then you probably read that we debated a lot about the choice of hardware.
In the beginning it was a question of direct sampling or analog integrators.
For direct sampling, "heavy machinery" should be picked with a lot of resources.
And that is a technology inaccessible to many, for one reason or another.
That's why I advocated another approach, analog integrators and the signal "chewed" to the end, and only then introduced into the MCU.
In that case, even a more modest ADC would get the job done. Modest MCU too.
And at the very beginning it was said that we would vote for one of the options.
Suddenly one day I come to the forum and see that they have already "voted" and chosen the first option; direct sampling.
How did you vote? Where? When? Who?
I don't know, but I see that the second option has been removed and that the first one, direct sampling, has been selected.
Then we continued the debate about the choice of ADC chip. There was no consensus there either. Because the megalomaniacs prevailed.
And while you slapped your palm against your palm; silence... after weeks of heated debate... suddenly silence.
Carl shows sporadically and says that the work is already underway!??? "Works"? What "works"?
And so... I had to make an extra effort and risk getting on many people's nerves;
in order to "pluck out" a couple of rather incoherent pieces of information from Carl.
I know Carl from before, it's difficult with him.
When you provoke him enough;
then there is no better person than him and his explanations are somehow the best and easiest to understand and learn from.
But you have to put in a lot of effort to get there, play the fool and get on everyone else's nerves.
So now, you too were provoked enough to show up. What have you been waiting for? Didn't you have anything to write long ago on these topics?
Do I always have to be the only "bad, boring and avoidable" one here?

[ivconic]

Ok Carl, Paul, aynbody else...
One more question for you, this time a bit more serious one.
If we look at the schematic you last posted:



There are two signals (pulses I assume) comming from the MCU; TXPCLK and TXNCLK, which, I assume; stands for TX-Positive-CLK and TX-Negative-CLK.
This means it need the same signal, same pps (or frequency, call it anyway), same duty cycle, same amplitude (5Vpp or 3.3Vpp I assume) BUT with 180 degrees phase difference, right?
So, You will write code to output one of those two on one MCU pin and another of those two on another MCU pin, right?
So actually it is the same signal, comming from the same clock, but only one inverted in relations to another.
In order to run those two fets; Q5 and Q6 properly.
Question;
why two pins?
why not one pin, one signal and then inverter?
This is simplified simulation of the main point in my question:






Answers like:
1) Because I feel like it,
2) Because the luxurious hardware allows me to do that,
3) Because it is a rather fancy solution,
4) Because it seems profane,
5) Because it's posh to work like that...

I won't take it seriously.

[Qiaozhi]

I suspect the answer is that these two pulses need to be non-overlapping, otherwise you could short out the power supply. Otherwise known as short-through.

[Carl-NC]

Suddenly one day I come to the forum and see that they have already "voted" and chosen the first option; direct sampling.
How did you vote? Where? When? Who?
I don't know, but I see that the second option has been removed and that the first one, direct sampling, has been selected.
Then we continued the debate about the choice of ADC chip. There was no consensus there either. Because the megalomaniacs prevailed.
And while you slapped your palm against your palm; silence... after weeks of heated debate... suddenly silence.

The reason previous "group projects" failed was precisely because people could not agree on what to do. Everyone has their own agenda. So I suggested that success would only happen under the leadership of a benevolent dictator, someone who listens to opinions and then makes a decision. No one else seemed to be interested in the position so I appointed myself. I am still subject to a coup if that is the will of the forum.

The decisions I've made so far are in the interest of the goal of the project, which may not be in the interest of individuals. For example, the choice of direct sampling was made based on what it can (potentially) accomplish that may not be possible with demods, unless you have a lot of demods. But I've also stated a fall-back plan of using demods. And anyone who wants to can build their own system using demods. The hard part of the project is the TX circuit and getting the preamp noise low enough. After that, it's mundane circuitry. BTW, the ADC is a good example of the system working right. I suggested a family of ADCs based on a wide selection of bits & speed, but Paul pointed out a better solution based on a larger peak-to-peak input range. So I switched to his suggestion.

I've also stated that this is a spare time project for me. I have a full-time job with several projects going on there, plus my own personal projects, plus trying to finish writing a book. And occasionally I like to take some leisure time and walk in the woods. So my efforts tend to be in spurts of furious work with dead time in between. Sorry, that's life. Anyone who wants this thing to go faster is welcomed to volunteer as dictator.

I'm always glad to answer questions and explain things. Otherwise, I wouldn't be here. To answer your specific question, Q is correct, you want good control of the dead time to prevent shoot-through currents. Many micros have timers designed for motor control which make them excellent for things like this.


P.S. -- AMX == Artisinal Mining Experimental. My choice. Anyone else could have suggested something different, but they didn't.

[ivconic]

I suspect the answer is that these two pulses need to be non-overlapping, otherwise you could short out the power supply. Otherwise known as short-through.

I doubt that. Yet I don't want to deny it too, until I hear Carl too.
Besides, CD4069/6 has 30nS delay at 10V.
Six of them. Do the math.
I just want to se if I can avoid wasting pins on MCU and yet drive the TX without issues.

[ivconic]

The reason previous "group projects" failed was precisely because people could not agree on what to do. Everyone has their own agenda. So I suggested that success would only happen under the leadership of a benevolent dictator, someone who listens to opinions and then makes a decision. No one else seemed to be interested in the position so I appointed myself. I am still subject to a coup if that is the will of the forum.

The decisions I've made so far are in the interest of the goal of the project, which may not be in the interest of individuals. For example, the choice of direct sampling was made based on what it can (potentially) accomplish that may not be possible with demods, unless you have a lot of demods. But I've also stated a fall-back plan of using demods. And anyone who wants to can build their own system using demods. The hard part of the project is the TX circuit and getting the preamp noise low enough. After that, it's mundane circuitry. BTW, the ADC is a good example of the system working right. I suggested a family of ADCs based on a wide selection of bits & speed, but Paul pointed out a better solution based on a larger peak-to-peak input range. So I switched to his suggestion.

I've also stated that this is a spare time project for me. I have a full-time job with several projects going on there, plus my own personal projects, plus trying to finish writing a book. And occasionally I like to take some leisure time and walk in the woods. So my efforts tend to be in spurts of furious work with dead time in between. Sorry, that's life. Anyone who wants this thing to go faster is welcomed to volunteer as dictator.

I'm always glad to answer questions and explain things. Otherwise, I wouldn't be here. To answer your specific question, Q is correct, you want good control of the dead time to prevent shoot-through currents. Many micros have timers designed for motor control which make them excellent for things like this.


P.S. -- AMX == Artisinal Mining Experimental. My choice. Anyone else could have suggested something different, but they didn't.

I missed your answer.
Ok, then tell me what would be the timing difference between positive and negative pulse?
Still doable with one pin, I hope.
Until Nucleos arrive (hopefully one day); I might try to drive the TX with Arduino, for testing purposes.

[Carl-NC]

This is an exaggeration of the timing but it illustrates the non-overlapping pulses and dead zones. I suspect there will be a narrow window of operation. Too little dead time and you get shoot-through, too much and the tilt losses get worse. I may be surprised and find that it's rather insensitive to overlap, but I'd rather plan for the worst than regret I did not.



This project will likely need a 64-pin micro, which should have plenty of timers, ADC ports, GPIOs, SPI, and other peripherals. I don't understand why you would want to skimp on a timer when it only makes the design harder. Let the micro do all the hard work!

[waltr]

This project will likely need a 64-pin micro, which should have plenty of timers, ADC ports, GPIOs, SPI, and other peripherals. I don't understand why you would want to skimp on a timer when it only makes the design harder. Let the micro do all the hard work!

And by having this timing done in the processor it is VERY EASY to make changes.

I did this with my version of the Hammer Head II. I first got it going as a simple PI then later (after reading much more on this forum) I added GEB without any change to the hardware PCB, just a change in the code (of which I did post source). I can even change TX pulse width, RX pulse width and delays on the fly through the processor.
This is quite the opposite of the old HH and other detectors here that use hardware (555's, etc) to do the timing. If a change is desired then one most modify the components on the PCB.

Any of the processors we have discussed have versions with plenty of pins and do not cost much more then ones with less pins.
This is the modern way to do design.

[green]

This is an exaggeration of the timing but it illustrates the non-overlapping pulses and dead zones. I suspect there will be a narrow window of operation. Too little dead time and you get shoot-through, too much and the tilt losses get worse. I may be surprised and find that it's rather insensitive to overlap, but I'd rather plan for the worst than regret I did not.



This project will likely need a 64-pin micro, which should have plenty of timers, ADC ports, GPIOs, SPI, and other peripherals. I don't understand why you would want to skimp on a timer when it only makes the design harder. Let the micro do all the hard work!

It's been while sense I've looked at any of this metal detector stuff. Not what I was thinking. I'm thinking coil current at lowest sample time should be the same as coil current at any time above, maybe 10us or 100us. Does anyone have a LT spice for the circuit in #122or do I need to make one?

[Willy Bayot]

Nucleo is based on STM32 CPU which has a number of Outpout Compare functions.
These functions support the definition of dead-time bewteen complementary square wave signals.
With the same timer, you get two complementary pins generating square wave with guarantee of a programmed dead-time made by the hardware and not by software

[ivconic]

Nucleo is based on STM32 CPU which has a number of Outpout Compare functions.
These functions support the definition of dead-time bewteen complementary square wave signals.
With the same timer, you get two complementary pins generating square wave with guarantee of a programmed dead-time made by the hardware and not by software

My trouble is that I don't have it on the table in front of me yet, it has yet to arrive.
And when it arrives... it will take me a few days to maybe a couple of weeks to learn the basics and feel comfortable working with that dev board.
I've been working with various Arduino dev boards for years and feel very comfortable... and yet sometimes I burn something nasty!
I have to be very careful this time because I only get two Nucleo dev boards.
That's why in the meantime I'm familiarizing myself as best I can with the details of other hardware used in project.

[ivconic]

This is an exaggeration of the timing but it illustrates the non-overlapping pulses and dead zones. I suspect there will be a narrow window of operation. Too little dead time and you get shoot-through, too much and the tilt losses get worse. I may be surprised and find that it's rather insensitive to overlap, but I'd rather plan for the worst than regret I did not.



This project will likely need a 64-pin micro, which should have plenty of timers, ADC ports, GPIOs, SPI, and other peripherals. I don't understand why you would want to skimp on a timer when it only makes the design harder. Let the micro do all the hard work!

Ok, now I fully understand the problem.
Your illustration could not be clearer.
Isn't there some method to protect fets in both cases you mentioned (too little... and too much... cases) ?
Some kind of super fast "current sensing" circuit that will turn off the circuit or voltage coming from the buck reg. in those cases?
That fet with a diode, which you added, which "chops" the voltage from the buck reg. seems ideal to me (but without the diode) to serve as a "switch".
Not to digress; do we have any idea about the precise timing between positive and negative pulses? "Safe zone" I would call it.
I didn't read carefully about the coil... it needs a really big focus only on this project, and I don't have it for objective reasons,
but isn't the coil resistance actually the best protection?
What do we lose with a higher resistance TX coil?
We're "losing" current.. ok, anything else?
The point is; you need to come up with an "intelligent" way to protect the TX circuit from bad timing.
You must not rely only on the code in the processor.
You think that you have all the control over the code, and then something happens... and it happens, when and where you least expect it.
Analog technique goes wrong mostly due to outdated components and digital goes wrong because of bugs and insufficiently perfect code...
Something from the outside can also disturb the mcu to start bugging.
Of course, these are all rare extreme situations and 90% of the time nothing bad will happen. But the point is that TX needs protection.
Let's start from the very likely assumption that the cable from the coil or the coil itself will suffer some damage during operation.
It is enough that the coil connector is not properly inserted or that the pins are not soldered properly.
And I can give examples like this all day, no need, the point is very clear.

[ivconic]

When I look at the schematic again... "Rsens" of 0.1 ohm seems to be the sweet spot for the current sensing point.
You didn't explain... or I didn't read it, but is that what the ADC1 and ADC2 samples are for?

[waltr]

Nucleo is based on STM32 CPU which has a number of Outpout Compare functions.
These functions support the definition of dead-time bewteen complementary square wave signals.
With the same timer, you get two complementary pins generating square wave with guarantee of a programmed dead-time made by the hardware and not by software

Yes, and so does some of the PIC32 processors and a few others.
This is a good reason to do the H-bridge drive timing within the processor.

[Carl-NC]

Ok, now I fully understand the problem.
Isn't there some method to protect fets in both cases you mentioned (too little... and too much... cases) ?
Some kind of super fast "current sensing" circuit that will turn off the circuit or voltage coming from the buck reg. in those cases?

Yes, you could probably design some kind of fast shoot-through sensor and, with a lot of extra circuitry, figure out a way to deal with the problem. But again, why not just take advantage of the micro and do it the easy way? And yes, I always include lock-up protection in the TX by capacitor-coupling the TX clocks. I haven't shown that yet, but it's in the actual design schematic, which is unfinished. The exact timing is TBD, I won't know that until I build the circuit.

Coil resistance almost solely determines power consumption so you want it as low as possible.