Concept Design

[David_1]

ADC on all the esp's seem much slower than the documentation so it would need an external one..

[Tinkerer]

• ESP32-S3
  • performance : dual-core 240MHz with SPI @ 80MHz
  • development boards : very cheap ($10 to $20 for 3 units)
  • development IDE (C, C++) : ARDUINO IDE, ECLIPSE extension, Visual Studio extension
  • stock level : 800 units @ mouser
  • Price : $3 to $5

ESP32-S3 seems to be the way to go

[Willy Bayot]

I also agree with that strategy.
The whole family being pin-compatible will allow us to easily upgrade an existing PCB in speed and resolution if necessary.

Now, let's concentrate on the CPU selection.
My list of candidates is:

• PIC32MZ
  • performance : 200MHz with SPI @ 50MHz
  • development boards ; available but expensive (100$)
  • development IDE (C, C++) : MPLAB, free
  • stock level : OK
  • Price : $15 to $20
• STM32F4xx
  • performance : 180MHz with SPI @ 45MHz
  • development boards : NUCLEO available , cheap ($10 to $20)
  • development IDE (C, C++): STM32CUBE IDE, free
  • stock level : STM32F446 300 units @ mouser
  • Price : $10 to $15
• ESP32-S3
  • performance : dual-core 240MHz with SPI @ 80MHz
  • development boards : very cheap ($10 to $20 for 3 units)
  • development IDE (C, C++) : ARDUINO IDE, ECLIPSE extension, Visual Studio extension
  • stock level : 800 units @ mouser
  • Price : $3 to $5

[moodz]

... they are probably the same ADC "binned by speed" by the manufacturer on the production line. ( like they do for CPUs ).

I vote with Carl ... the ADC wars are over.

moodz

[Carl-NC]

I've been looking at ADCs for direct sampling. I think 24 bits is overkill but others want the option, so I used that as an anchor point in looking at compatible packages for other bits and speeds. It turns out that the LTC2380 is part of a big pin-compatible family of ADCs, as follows:

Bits	SNR	LTC2376 250ksps	LTC2377 500ksps	LTC2378 1Msps	LTC2380 2Msps
16	97dB	$21	$30	$31	$38
18	102dB	$35	$48	$58	X
20	104dB	$47	$61	$61	X
24	100dB	X	X	X	$66

The other benefit is that there are also speed options. Again, I doubt that 1Msps is necessary but for those who want the option, it's here. The other big plus is that the package is an MSOP-16 which is not hard to hand-solder, and it has a small footprint. Also, these things are low power. Drawback is obviously the price, and I find the choice of input range to be a bit restrictive. Most likely I will start with an 18b-250k ADC which looks to be a sweet spot on SNR and probably sufficient speed.

I also want to look at options for baseband sampling. For that I'll consider 8-channel simultaneous sampling ADCs, also from 16-24b. My only experience is with the ADS131E08, and I would never abuse anyone by selecting this chip.

[ivconic]

Multitasking does not help iproving the total performance of a CPU, this is a function of an RTOS not of the CPU.

Pre-emptive multitasking
The RTOS distributes the CPU to multiple tasks according to interrupts based on priorities. (RTOS) or to timesharing (e.g. UNIX or WIndows). The CPU can only do one task at a time, even the interrupt service routines steal the CPU cycles at a highest priorities.

Cooperative multitasking
This is a style of programming in which multiple tasks take turns running. Each task runs until it needs to wait for something, or until it decides it has run for long enough and should let another task run.In cooperative multitasking, a scheduler manages the tasks. Only one task runs at a time. When a task gives up control and starts waiting, the scheduler starts another task that is ready to run. The scheduler runs an event loop which repeats this process over and over for all the tasks assigned to the event loop.

Multprocessing needs several CPU cores.
With the help of a RTOS, this is real parallel processing. For example, the ESP32-S3 has a double core, thus, this one has real multiprocessing capability witth the support of its specific RTOS.

Thanks!
But I had on my mind multi-core processors.
There are ARMs with 2 cores that are already available on modules.
I stopped following there, in meantime there are probably with more cores then two on market available in form of module.
Otherwise, I am not sure how RTOS will improve anything at single core mcu... except maybe to save time on writting IRQ's by yourself.
I use IRQ's on my own. But on single core all the things you can do are still within single core limits.
One click at the time.
This takes me way back in time, to 1982, when I used to write instructions in a line editor, exactly in the order in which they would be executed.
You don't have to explain those things to me. I'm so old I forgot them 10 times by now!

[waltr]

Timing resolution of STM32 : 12nsec, PIC32MZ = 10nsec (Proven to be more than enough in precision in actual working systems)
All timings of OC functions are also working under DMA, no interrupt. So, real parallel processing with the main DSP tasks as well as DMA.

The DSP tasks have only to be executed every time we get a NET RESULT from the ADC integration, thus, every 10msec or so.

I can guarantee that those CPU are able to do the job.

I agree totally and the PIC32MZ-EF is very powerful with an FPU and mips DSP core.. I was pleasity surprised at the speed DPS processing could be done.
That is also my experience with the PIC32's using the OC modules. Excellent timing and all done in hardware - the CPU can idle.
Also no need to do DSP tasks on every pulse cycle. I was doing 1500Hz pulse rate and sum 8 cycles before processing (5.3msec). At fast pulse rates one can sum 16-32 cycles before processing and still have a 'near real time' response to the user.

I did discuss this in another thread and posted my code. Others', please take a look at how this can be done here:
https://www.geotech1.com/forums/foru...ng-in-hardware
https://www.geotech1.com/forums/foru...ke-on-the-HH3=

Last link has an overview of splitting real time tasks over the multiple cycles.

[David_1]

esp32... had several pcbs made and assembled by jlcpcb ... all very good work

[Tinkerer]

https://jlcpcb.com/partdetail/319830...N16R8/C2913202

JLCPCB seem to have no problem assembling ESP 32 S3 parts at reasonable prices

[Willy Bayot]

We gonna need multitasking capable mcu here.
Under the RTOS.
So it seems.

Multitasking does not help iproving the total performance of a CPU, this is a function of an RTOS not of the CPU.

Pre-emptive multitasking
The RTOS distributes the CPU to multiple tasks according to interrupts based on priorities. (RTOS) or to timesharing (e.g. UNIX or WIndows). The CPU can only do one task at a time, even the interrupt service routines steal the CPU cycles at a highest priorities.

Cooperative multitasking
This is a style of programming in which multiple tasks take turns running. Each task runs until it needs to wait for something, or until it decides it has run for long enough and should let another task run.In cooperative multitasking, a scheduler manages the tasks. Only one task runs at a time. When a task gives up control and starts waiting, the scheduler starts another task that is ready to run. The scheduler runs an event loop which repeats this process over and over for all the tasks assigned to the event loop.

Multprocessing needs several CPU cores.
With the help of a RTOS, this is real parallel processing. For example, the ESP32-S3 has a double core, thus, this one has real multiprocessing capability witth the support of its specific RTOS.

[Willy Bayot]

Totally valid assessment ... the "processor" for a "general purpose" direct sampler will have to not only capture the data but also provide ( and execute in real time ) a suite of DSP functions like boxcar / fourier / FIR not only for RX ... BUT also possible synthesis of the TX signal ( eg chirp / sine etc ) AND perfectly synchronously with at least 10 nanosecond resolution.
In my experience using general purpose CPU no matter how fast always results in compromises that degrade potential peak performance - because code executes sequentially not synchronously ( yeh DMA is great ... but it would be better if the DMA piped through a stream processor ).

I am at 15 Khz PPS and using 20 nansecond resolution on the MAGPI and quite frankly its not fine enough.

Just commenting not arguing

moodz

Timing resolution of STM32 : 12nsec, PIC32MZ = 10nsec (Proven to be more than enough in precision in actual working systems)
All timings of OC functions are also working under DMA, no interrupt. So, real parallel processing with the main DSP tasks as well as DMA.

The DSP tasks have only to be executed every time we get a NET RESULT from the ADC integration, thus, every 10msec or so.

I can guarantee that those CPU are able to do the job.

[ivconic]

We gonna need multitasking capable mcu here.
Under the RTOS.
So it seems.

[moodz]

An STM32 @ 180MHz or a PIC32MZ @ 200MHZ are perfectly able to capture an ADC output @ 1MSPS under DMA
The only limiting factor is their max SPI clock, 45MHz and 50MHz.
I have calculated the max capture rate of the SPI with a data stream of 24 bits. I get in both cases a rate of approximatively 1MSPS.

I can put another choice on the table
ESP32-S3 is a dual-core XTensa LX7 MCU, capable of running at 240 MHz. Its SPI clock can go up to 80MHz.
Worlwide development support, many widely available and cheap development boards
All types of ESP32 can be programmed in C or C++.

It is now time for the 'boss' to make the main architecture decisions so that we get going with more details like defining circuits and selecting real components:

• Coil Assembly type
• XMIT model
• AFE model
• ADC
• CPU and development board

Totally valid assessment ... the "processor" for a "general purpose" direct sampler will have to not only capture the data but also provide ( and execute in real time ) a suite of DSP functions like boxcar / fourier / FIR not only for RX ... BUT also possible synthesis of the TX signal ( eg chirp / sine etc ) AND perfectly synchronously with at least 10 nanosecond resolution.
In my experience using general purpose CPU no matter how fast always results in compromises that degrade potential peak performance - because code executes sequentially not synchronously ( yeh DMA is great ... but it would be better if the DMA piped through a stream processor ).

I am at 15 Khz PPS and using 20 nansecond resolution on the MAGPI and quite frankly its not fine enough.

Just commenting not arguing

moodz

[David_1]

im messing with PI at present but is the application of the signals similar across different design types ... what is best

[ivconic]

Don't worry. I'm still here.
Just trying my best not to get involved with this project as I'm busy with other things.
Also, these so-called collaborative projects tend to fizzle out after a while, although this one may have a chance since Carl took over the reins.

Now you know who is your true friend and who is thinking of you.
You haven't been on the topics for a long time.
Who thought to ask about you?
Just me!

Yes, past experience with ideas is not very great. Many ideas and none of them completed.
And this one here... after a long debate, we still don't have a consensus.
Carl and Willy have already declared themselves in favor of direct sampling.
I thought we were all going to vote.
I am for both; that both approaches develop in parallel.
For many reasonable reasons, which I would not repeat here, a lot has already been written about it.
I expected you to at least give your opinion on that.
There is still no definitive decision about the ADC. Nor about the MCU.
I'm afraid the whole story will come down to only two/three being able to work on the project going forward.
And the rest of us will be carried thirsty across the water...