Back to the roots at 50: Introducing Spectral-G4 (AI meets VLF)

[Repwoc]

Have you tried changing the Dead Time in the timer settings ? maybe that would help.

hi Marchel

Thanks. I had tried changing the dead time but it seemed to make little difference. I decided to look more closely. I had set the dead time to 100 nS and verified that there would be no shoot through by oscilloscope, comparing the bridge voltage with the relevant mosfet gate voltage at rising and falling edges..

CH1 (yellow) = bridge (Tx), CH2 (teal) = high-side (p-chan) mosfet gate, CH4 (green) = low-side (n-chan) mosfet gate, CH3 (red) = Rx

With 100 nS dead time:



Clearly there is the expected 100 nS delay between the gate voltage transitions. It could be argued that 100 nS is a little tight as the low-side gate voltage begins to rise before the bridge voltage reaches ground potential, however the high-side mosfet is definitely off before the low-side one comes on.

There is some ringing on the high-side mosfet gate apparent which coincides with the low-side mosfet gate voltage starting to rise.

Note there is noise on the Rx signal when the high-side mosfet gate voltage begins to rise, despite there being no change to the bridge voltage at that point, then again when the low-side mosfet gate voltage rises again when the bridge voltage is relatively stable.

With 300 nS dead time:



Obviously the delay between the mosfet gate transitions has increased to 300 nS. The low-side mosfet gate now transitions well after the bridge voltage reaches ground potential.

The ringing on the high-side mosfet gate is much reduced.although there is still a little overshoot. There is now a dip in the high-side gate voltage coinciding with the low-side gate coming on.

The Rx signal noise is different, but I'm not sure that it has improved or got worse overall.

The sweet spot seems to be at just over 135 nS (23 ticks @ 170 MHz). At that point the low-side gate comes on just as the bridge gets to ground potential. However, given that the bridge voltage is unchanged by switching on the low-side transistor and switching it on is a major source of noise I'm wondering if it would be best left switched off during the half-cycle that the corresponding high-side mosfet is switching.

I can't figure out how merely starting to charge the mosfet gates creates so much noise on the Rx signal.

Dead time = 135 nS:

[Marchel]

hi Marchel

Thanks. I had tried changing the dead time but it seemed to make little difference. I decided to look more closely. I had set the dead time to 100 nS and verified that there would be no shoot through by oscilloscope, comparing the bridge voltage with the relevant mosfet gate voltage at rising and falling edges..

CH1 (yellow) = bridge (Tx), CH2 (teal) = high-side (p-chan) mosfet gate, CH4 (green) = low-side (n-chan) mosfet gate, CH3 (red) = Rx

With 100 nS dead time:



Clearly there is the expected 100 nS delay between the gate voltage transitions. It could be argued that 100 nS is a little tight as the low-side gate voltage begins to rise before the bridge voltage reaches ground potential, however the high-side mosfet is definitely off before the low-side one comes on.

There is some ringing on the high-side mosfet gate apparent which coincides with the low-side mosfet gate voltage starting to rise.

Note there is noise on the Rx signal when the high-side mosfet gate voltage begins to rise, despite there being no change to the bridge voltage at that point, then again when the low-side mosfet gate voltage rises again when the bridge voltage is relatively stable.

With 300 nS dead time:



Obviously the delay between the mosfet gate transitions has increased to 300 nS. The low-side mosfet gate now transitions well after the bridge voltage reaches ground potential.

The ringing on the high-side mosfet gate is much reduced.although there is still a little overshoot. There is now a dip in the high-side gate voltage coinciding with the low-side gate coming on.

The Rx signal noise is different, but I'm not sure that it has improved or got worse overall.

The sweet spot seems to be at just over 135 nS (23 ticks @ 170 MHz). At that point the low-side gate comes on just as the bridge gets to ground potential. However, given that the bridge voltage is unchanged by switching on the low-side transistor and switching it on is a major source of noise I'm wondering if it would be best left switched off during the half-cycle that the corresponding high-side mosfet is switching.

I can't figure out how merely starting to charge the mosfet gates creates so much noise on the Rx signal.

Dead time = 135 nS:

This interference can also be caused by a weak H-Bridge power supply. Try adding a 1-2 Ohm resistor and choke between the power supply and the H-Bridge input and it might help.

[Repwoc]

Besides optimizing the dead time, I would also try:

- Slowing down the MOSFET edges with the gate resistors, and doing it asymmetrically: a larger resistor (e.g. 22 Ω) for turn-ON, with an anti-parallel diode so turn-OFF stays fast. This reduces dV/dt (less coupled noise) without increasing the shoot-through risk.
- An RC snubber across the bridge or the TX coil to damp high-frequency ringing.
- Reviewing the PCB layout and current return paths. Common impedance coupling between the H-bridge and the analog front-end is very often the real culprit with this type of noise.

One more thought that may reframe the problem: since your noise is exactly synchronous with the TX, after synchronous demodulation it does not look like noise at all. It becomes a constant offset vector in I/Q. If it is stable, your nulling / baseline subtraction removes it entirely. What actually hurts you is its jitter (another reason why clean dead-time and stable switching instants matter) and its thermal drift. It also helps to sync the ADC sampling to the TX grid, so the sampling instants never land on the switching edges.

Hi Taktyk

Thanks, all useful ideas.

I have 10 Ω gate resistors currently. I did try higher values (by quite a lot) but it made no difference to the Rx noise and with the larger resistors (100 Ω) the mosfets got quite hot really quickly.

I already tried RC snubbers at each end of the bridge too. No noticeable difference to the Rx noise.

The "PCB" layout is a good point. I'm still experimenting using a solderless breadboard at this point so yes, that could be the culprit. I guess I'll just have to bite the bullet and make some test PCBs.

I get your point regarding the noise being filtered out by demodulation. But these spikes are quite big and I think they would rail the pre-amp.

[Marchel]

Hi Taktyk

Thanks, all useful ideas.

I have 10 Ω gate resistors currently. I did try higher values (by quite a lot) but it made no difference to the Rx noise and with the larger resistors (100 Ω) the mosfets got quite hot really quickly.

I already tried RC snubbers at each end of the bridge too. No noticeable difference to the Rx noise.

The "PCB" layout is a good point. I'm still experimenting using a solderless breadboard at this point so yes, that could be the culprit. I guess I'll just have to bite the bullet and make some test PCBs.

I get your point regarding the noise being filtered out by demodulation. But these spikes are quite big and I think they would rail the pre-amp.

For testing, you can also use this board that I designed, it also contains an H-Bridge.
https://www.geotech1.com/forums/foru...elopment-board

[duanpb]

Good job, looking forward to the finished product

[Taktyk]

Hi all,

Time for a status post. Short version: I'm parking the project until October because work is eating my time, then I'm giving it two solid months - November and December - to get hardware and software finished and ready for testing. That's the deadline I'm holding myself to.

Before the break, a summary of where things landed, including two changes to what I posted earlier.


--- The frequency grid changed ---

I originally went with f0 = 7812.5 Hz and harmonics 1/3/5 (7.8 / 23.4 / 39 kHz), picked to grid-lock against 250 kSPS. It's now:

f0 = 4.5 kHz, harmonics 1/3/9 -> 4.5 / 13.5 / 40.5 kHz
fs = 32 x f0 = 144 kSPS

Two reasons. First, the spread: with 1/3/5 the top tone is only 5x the fundamental, and the whole point of multi-frequency is separating targets by how their response rolls off with frequency. Going to 1/3/9 widens the frequency ratio from 5x to 9x, which spreads the targets further apart in the signature space. I ran both grids through a simulator against the same target set and the wider one wins clearly.

Second, it grid-locks better. 162 MHz clock, HRTIM period 36000, conversion timer 1125, all integer dividers off one clock, so the sampling stays exactly phase-locked to the transmitter and the three tones land on exact DFT bins. No leakage, no windowing.

The SHE pattern was re-solved for the new grid: equal power on 1/3/9, hard zeros on the 5th and 7th (they'd sit inside the receive band between tones), 17 switching events per period. Verified against the analytic spectrum and then through the demodulator on the PC before any power went near the bridge.


--- The smart probe lost its microcontroller ---

Bigger change. The probe was going to have an STM32G0 inside the coil doing 12-bit vector nulling with its own DACs, temperature compensation and a coil ID in flash. It doesn't anymore.

The probe is now passive: it powers itself off the rectified TX drive, and the two digital pots that do the balancing are clocked by the transmitter waveform itself. The base bit-bangs one data line in sync with the timer, so the cable carries a single digital wire instead of a protocol between two MCUs.

There's a nice accident in there. My switching pattern has 18 segments per period, which means 9 clock pulses - exactly one I2C byte frame, 8 bits plus ACK. A three-byte transaction fits in four TX periods. I wrote a host test that plays both waveforms tick by tick with an independent protocol monitor watching the line, and the bytes come out clean with 1.2 us of setup margin against a 0.1 us requirement.

That change deleted a whole microcontroller, its firmware, the base-to-probe protocol, the temperature sensor and the coil ID scheme. Best kind of design decision - the one where the parts count goes down.


--- The one that cost me time ---

My demodulation test failed with the 40.5 kHz bin sitting at 30% of where it should be. I went hunting for a bug in the switching pattern. The pattern was fine.

SHE nulls the harmonics you ask it to null - in my case the 5th and 7th. Everything above is untouched, and it isn't small: the 23rd harmonic is 0.27 of the fundamental. At 144 kSPS that lands at 103.5 kHz and folds straight back onto the 40.5 kHz bin, contributing 42% of that bin's amplitude. I was sampling a raw square wave with no filter in front of it.

So the failing test turned into a hard requirement: anti-alias filtering above 100 kHz before the converter, non-negotiable. It's the kind of thing that would have looked like a coil problem or a nulling problem for weeks if I'd found it on the bench instead of in a test.


--- What's actually done ---

Everything that doesn't need the analog board, and all of it covered by tests that run on a PC:

- TX switching pattern, solved and spectrally verified
- timer scheduler that plays the edges through DMA
- per-harmonic demodulation, CORDIC magnitude/phase, phase dispersion
- ground balance, per-harmonic, with auto-tracking
- envelope filters per operating mode
- display core, menu system, target presentation, audio with threshold
- config storage with CRC, telemetry protocol
- the probe's single-wire transport, proven against a protocol monitor
- probe PCB designed, built, schematic reviewed against the netlist
- PC-side tooling for measurement sessions, labeling and dataset building

Which means the pile waiting on hardware is exactly the pile that has to wait: front end, converter, transmitter power stage, coil, and then the fun part - scoping the real spectrum against the model.


--- The plan ---

October: back at it, assemble the DSP board, bring up the front end.
November: transmitter live, coil wound and characterized, real acquisition.
December: dataset collection, then the AI side, which has been waiting on real data the whole time.

End of year: hardware and software finished and ready for testing. Two months is tight, but the digital half is done and tested, so what's left is the part that needs a soldering iron rather than the part that needs thinking.


--- Following along, or helping out ---

The project has a page at spectral-g4.pl, with the technical write-up and roadmap also on github.com/takzen/spectral-g4-showcase.

If anyone wants to help it along, there's a fundraiser here:
https://whydonate.com/fundraising/sp...on-engineering

It goes straight into parts - boards, converters, coil materials for the Series 0 units. Supporters get a prototype at production cost and a say in how the software ends up working. No pressure either way; the project is happening regardless, a bigger parts budget just means fewer compromises and less waiting between iterations.


See you in October.

Cheers