It occurred to me yesterday that if we had a second-order modulator, instead of a simple first-order modulator, our scope mode would not work. Does anyone suppose otherwise?
I starting drawing up a schematic last night for a simple external modulator for the P1; which I may build and test on a protoboard after the holiday. Although I actually have two designs in mind. One would be a simple RIAA phono playback filter; which has a particular low pass response. So what if I inject the P1 generated comparator output into the differential amplifier in two places; one that has the full bandwidth of whatever the pin is giving us; and the other which is being subjected to the same processing as the audio. That's it - for design candidate one. Design number two is a secret; for now - although I am a sure that there are some people here who know about chopper modulation, etc., and that's all I am going to say about that one.
What that implies of course is that unless you do something like what some of the original op amps did; and what some video op amp do; which is to let you choose your own external capacitors for the various time constants; then an audio rate modulator what also performs some useful function like RIAA compensation; or loudspeaker crossover with a real 4th order filter will destroy the scope modes and the video modes; that is unless you are planning on releasing a propeller which has 6 extra pins per ADC for the application specific requirements. So I think the right track is to keep all options open - except for the must haves in hardware or ROM as the case may be; i.e., streaming, sinc2/3, raw bits.
Here are four possible double-integration windows:
Blackman, length 24, sum 256
Hann, length 32, sum 510
Tukey, length 47, sum 1020
Tukey, length 70, sum 2040
The lengths include a leading and a trailing zero.
The above windows have the same first three taps and all 12 taps could be the same with shift register skipping and this is how my BASIC program works. However, the way to deal with different taps in hardware is to mux the particular shift reg bits. The muxing logic would be less with triple-integration as it has fewer taps.
I wish I had time to do some SPICE work. I really want to see if adding many parallel first-order modulators with different current offsets would get around the problems of the first order, but provide both a higher number of bits per clock, while still affording something like a simple scope mode that looks at a small range of samples.
That's what this does; or will do. I'll let you know when it compiles on the P1 under simple IDE.
#define OVERSAMPLE (5)
void sigma_delta::process_block (vector<MATH_TYPE>& src)
{
int w3[] = {1,3,3,1};
int w4[] = {1,4,6,4,1};
int w5[] = {1,5,10,10,5,1};
int w6[] = {1,6,15,20,15,6,1};
int w7[] = {1,7,21,35,35,21,7,1};
int w8[] = {1,8,28,56,70,56,28,8,1};
Too much time being wasted here! Is it now 4+ weeks?
There is so much more important things to be done and tested. Only then if time permits, continue this.
Too much time being wasted here! Is it now 4+ weeks?
There is so much more important things to be done and tested. Only then if time permits, continue this.
Just my 2c
I will add $2 to the 2 cents.
Pick a thing and do it and move on. End the endless chain of suggestions of things to try.
I know a guy named Nelson Pass. His company makes excellent Hi-Fi amps. He is kind of the living grandfather of solid-state Hi-Fi, I think. He once told me that the very fastest amplifier is a common-gate configuration. Picture the gate pinned at a certain voltage. The source is modulated to create change on the drain. This might be key to making a faster ADC front-end.
That same principle works for speeding up optotransistors, which tend to be rather slow. By attaching a common base amplifier to the emitter of the opto, the voltage on the emitter does not change, eliminating delays due to the opto's Miller capacitance. The downside is a requirement for multiple voltage supply levels.
That same principle works for speeding up optotransistors, which tend to be rather slow. By attaching a common base amplifier to the emitter of the opto, the voltage on the emitter does not change, eliminating delays due to the opto's Miller capacitance. The downside is a requirement for multiple voltage supply levels.
-Phil
So, it's a current amplifier. That's what we have coming into the ADC front end, really. Maybe a quick second order treatment, along with a higher bandwidth front end can be accomplished before the respin.
Here are four possible double integration windows:
Blackman, length 24, sum 256
Hann, length 32, sum 510
Tukey, length 47, sum 1020
Tukey, length 70, sum 2040
The lengths include a leading and a trailing zero.
The above windows have the same first three taps and all 12 taps could be the same with shift register skipping and this is how my BASIC program works. However, the way to deal with different taps in hardware is to mux the particular shift reg bits. The muxing logic would be less with triple -integration as it has fewer taps.
Here are the double iterated taps for the above in the same order:
CMA[3,5,17] (sum 255) taps, double and triple iterated in that order:
0 1 2 5 6 7 17 18 19 22 23 24
0 3 5 8 17 20 22 25
Although the window values determine the exact number of taps, triple iterated can be significantly smaller at the 'expense' of a few more adders which will be there anyway for Sinc3 mode. The other point to note is that triple iterated length is one longer than double.
It occurred to me yesterday that if we had a second-order modulator, instead of a simple first-order modulator, our scope mode would not work. Does anyone suppose otherwise?
In my tests, the scope filter works even better with a second-order modulator.
|-------|--digital out
[R] [R]
| |
in--[R]--|--[R]--|--digital in
{C} {C}
| |
gnd------|-------|--GND
Omitting the caps to Vio.
This circuit does not seem to work. I tried to simulate it in my code with different values and either it performs like a first order modulator or it doesn't work at all.
It occurred to me yesterday that if we had a second-order modulator, instead of a simple first-order modulator, our scope mode would not work. Does anyone suppose otherwise?
In my tests, the scope filter works even better with a second-order modulator.
|-------|--digital out
[R] [R]
| |
in--[R]--|--[R]--|--digital in
{C} {C}
| |
gnd------|-------|--GND
Omitting the caps to Vio.
This circuit does not seem to work. I tried to simulate it in my code with different values and either it performs like a first order modulator or it doesn't work at all.
Saucy, what is the ratio among the R values? Have you found that some don't work and others do? Is there any rule-of-thumb to go by?
|-------|--digital out
[R] [R]
| |
in--[R]--|--[R]--|--digital in
{C} {C}
| |
gnd------|-------|--GND
This circuit does not seem to work. I tried to simulate it in my code with different values and either it performs like a first order modulator or it doesn't work at all.
Such circuits with no buffers and multiple RC nodes, always struggle because they interact and load so much.
You could try making the second stage with R/C impedances over 10x the first stage, and see if that helps, but I think the 'correct' approach is to use a dual opamp as a proper integrator.
Then, you do get proper charge totals over many samples.
Opamps that look suitable are OPA2365 and maybe OPA2320 (lower Slew, but better Vos)
Saucy, it will saturate in the cases of the magnified modes, even if the diodes clamp the 1x modes before saturation. We need to handle saturation by returning $FF, or not getting there, in the first place. The new ADC modes have the same issue. They want to saturate to 2^n on all 1's coming in, whereas we need to limit them to (2^n)-1.
Saucy, I have a question for you... You know that by adding log values of numbers, you are really multiplying them, while subtraction divides, left shift by one squares, and right shift by one square-roots. So, logs are useful for achieving higher-order functions from lower-order ones. I am wondering... What can be done with log values of log values? Some of you may have an idea.
What if you want an arbitrary power instead of a square or square root? You could take the log and multiply. Or you could stack another log on and do the multiplication as an addition.
octave:160> 2^(2^( log2(log2(10)) + log2( 6 ) ))
ans = 1.0000e+06
octave:161> 2^(2^( log2(log2(10)) + log2( 2 ) ))
ans = 100.000
octave:162> 2^(2^( log2(log2(10)) + log2( 1.45 ) ))
ans = 28.184
octave:163> 10^1.45
ans = 28.184
octave:164> 2^(2^( log2(log2(5)) + log2( 1.45 ) ))
ans = 10.316
octave:165> 5^1.45
ans = 10.316
|-------|--digital out
[R] [R]
| |
in--[R]--|--[R]--|--digital in
{C} {C}
| |
gnd------|-------|--GND
This circuit does not seem to work. I tried to simulate it in my code with different values and either it performs like a first order modulator or it doesn't work at all.
Such circuits with no buffers and multiple RC nodes, always struggle because they interact and load so much.
You could try making the second stage with R/C impedances over 10x the first stage, and see if that helps, but I think the 'correct' approach is to use a dual opamp as a proper integrator.
Then, you do get proper charge totals over many samples.
Opamps that look suitable are OPA2365 and maybe OPA2320 (lower Slew, but better Vos)
A true integrator has gain below its cutoff, and 2nd order sigma-delta modulation relies on gain
in the second integrator - without voltage gain (cascaded RC's), you have to use different gains in the feedback
paths to compensate I think.
I've given up on the RC second-order modulator for now. The P2-ES board is much more fun.
' Rectangular window with Goertzel ADC
' Currently configured at 240MHz / 20 bits = 12MSPS
'
con gtzpin = 1 ' used for monitoring the ADC window
adcpin = 12 ' Analog in
xpin = 8
ypin = 9 ' Analog out
samples = 20
shift = 2 ' try to keep ((samples*2)<<shift) < 256
' to avoid overflow
xtal = 20_000_000
dv = 2
mlt = 24
pdv = 1
clk = 1 << 24 | (dv-1) << 18 | (mlt-1) << 8 | (pdv==1 ? 15 : (pdv-2)/2 ) << 4
sys_clk = xtal / dv * mlt / pdv
' set up clock
dat org
kx hubset ##clk | %0000_01_00 'enable crystal+PLL, stay in 20MHz+ mode
ky waitx ##20_000_000/100 'wait ~10ms for crystal+PLL to stabilize
kz hubset ##clk | %0000_01_11 'now switch to PLL running at 80MHz
' make a rectangular / sawtooth table in LUT
mov z,#$1FF 'make 512-sample sin/cos table in lut
sincos mov x,z 'get angle into top 9 bits of x
'shl x,#32-9
'qrotate #$7F,x 'get sin/cos of (ro,theta)
'getqx x 'get cos
'getqy y 'get sin
'subr x,#128
mov x,z ' Generate sawtooth
shr x,#2
add x,#128 ' Offset lets us distinguish between
' streamer active and idle
setbyte x,x,#1 'duplicate sawtooth into byte1 and byte0
mov y,#$101 ' Just use 1 for the rectangular window
setword x,y,#1 'copy bytes 1,0 to 3,2
' xor x,##$8080 'make bytes 1,0 positive (not used, but could be)
wrlut x,z 'write sin:cos:psin:pcos into lut bottom bytes
djnf z,#sincos 'make 512 samples
' set up I/O
wrpin dacmode,#gtzpin 'enable DAC output and ADC input on same pin
drvh #gtzpin
wrpin adcmode,#adcpin 'enable ADC pin (Goertzel may use gtzpin directly)
dirh #xpin 'enable X,Y pins for future DAC output
dirh #ypin
' Do Goertzel loop, show accumulations on X,Y pins for scope in X,Y mode
loop setq f1 'ready frequency
xzero m1,#0 'issue Goertzel command
' waitx ##samples+2 ' optional delay lets the streamer finish
' before reading. If it does finish, then
' the differentiator below is needed.
getxacc x 'get last Goertzel accumulations, x first
mov y,0 'y comes through s
' sub y,ydiff ' optional differentiate y
' add ydiff,y ' ADC breakthrough p13
add y,#samples+1 ' We want DAC 0 to be minimum input voltage
' Since the Goertzel subtracts on zero input
' we need to compensate
shl y,#shift ' Multiply to get closer to full scale
setbyte xymode,y,#1 'y pin update
wrpin xymode,#ypin
jmp #loop 'loop
xymode long %0000_0000_000_1011100000000_00_00000_0 'DAC for x,y scope output (0-2V)
'adcmode long %0000_0000_000_1001110000000_00_00000_0 'ADC input, 100x mode
adcmode long %0000_0000_000_1000110000000_00_00000_0 'ADC input
dacmode long %0000_0000_000_1011000000000_01_00000_0 'Goertzel DAC, also used as ADC
f1 long ($4000_0000 /samples +1) *2 ' dividing $8000_0000 doesn't work, sign extend issue?
m1 long %0000_0001<<24 + adcpin<<17 + 1 'Goertzel mode, DAC0 output. 1 cycle
x res 1
y res 1
z res 1
ydiff res 1
We don't need the Goertzel hardware to do a rectangular window. I'm using it so it's easy to change to an arbitrary window later.
I configured it to sample as fast as possible and output to the DAC. It passes decent quality NTSC video. Note that you DON'T need to sample it above 7.16MHz for the color to work. The color seems to alias back up to the proper frequency in the DAC after aliasing down during the sampling. Of course it degrades the quality, but "it works!"
There might be an issue with Goertzel mode. If I wait for it to finish sampling, it doesn't clear the accumulators upon read. The difference between consecutive readings is fine. Either this is not the intended behavior or it's not documented.
Saucy, Goertzel does not use the RDFAST/WRFAST mechanism, but it could. This would allow streaming to/from hub memory. What kinds of operations might be useful?
Saucy, Goertzel does not use the RDFAST/WRFAST mechanism, but it could. This would allow streaming to/from hub memory. What kinds of operations might be useful?
Obviously streaming the accumulated x and y to hub would be good for software defined radio. But when? It would be inconvenient to have the sample rate locked to a multiple of the carrier frequency. If we had a pre-windowed sine/cosine in the LUT then we could stream windowed samples to the hub. It would be inconvenient to change frequencies as that would mean generating a new LUT. And for best performance we would want one window ramping up while another is ramping down.
If we could stream from HUB instead of LUT then we could retune instantly by changing the address. Or have a window longer than 512.
My concern with the above code is that if I enable the "waitx ##samples+2" between xzero and getxacc then I also have to enable "sub y,ydiff ' add ydiff,y" to get sensible output data. That code computes the difference between consecutive y readings. So it appears that adding the delay causes the Goertzel accumulators to not be reset.
I'm not sure whether the 1st or 2nd derivative method will be used to generate scope mode window filters. The latter is superior in my view as fewer taps required. The 2nd derivative is only 2-bit in range -2..+1 and it is very simple to specify the taps of a cascaded moving average filter cma(x,y,z) in terms of x, y and z:
Assuming x <= y <= z,
if y > x then each ramp has a linear section,
if z > x + y then there is a plateau (more than two max values),
if z = x + y then two taps cancel out and have no effect.
BASIC program:
xyz:
input "x,y,z? ", x, y, z: if x < 1 or x > y or y > z then goto xyz
length = x + y + z 'includes leading and trailing zeroes
sum = x * y * z
'sum clamp value m
m = 1
mx2:
m = m * 2: if m < sum then goto mx2
'taps
t0 = 0
t1 = x
t2 = y
t3 = z
t4 = x + y
t5 = x + z
t6 = y + z
t7 = x + y + z
topbit = t7
print " x", " y", " z", "length", " sum"
print x, y, z, length, sum: print #1,
print "taps:": print " +", " -", " -", " -", " +", " +", " +", " -"
print t0, t1, t2, t3, t4, t5, t6, t7: print #1,
dim t(topbit)
for x = 0 to topbit: t(x) = 0: next x 'clear bits
inta = 0: intb = 0: intc = 0
'print "iter", "adc", "delt", "inta", "intb", "intc", "samp", "clam"
print "iter", "adc", "d2w", "dw", " w", "intw", "samp", "clam"
for iter = 0 to topbit * 2 + 1
for x = topbit to 1 step -1: t(x) = t(x - 1): next x 'shift bits
if iter <= topbit then t(0) = 1 else t(0) = 0 'new adc bit
delt = t(t0) - t(t1) - t(t2) - t(t3) + t(t4) + t(t5) + t(t6) - t(t7) 'd2w
inta = inta + delt 'dw
intb = intb + inta 'w
intc = intc + intb 'intw
clam = int(intc / m)
samp = int(intc / (m / 256)) - clam
print iter, t(0), delt, inta, intb, intc, samp, clam
next iter
end
The sum and maximum tap length of cma(x,y,z) are x*y*z and x+y+z, respectively, therefore by choosing and factoring the sum everything can be determined without any guesswork.
I mentioned before that using a large sum, e.g. 12- or 13-bit bit, will mean that small value taps on their own won't count when the result is truncated to 8-bit.
Will there be any changes to the Goertzel? I have never used one and I can't help until I learn more about it.
The only thing I plan to change in the Goertzel is to have all four LUT bytes signed internally, then invert their MSBs whenever they are output to DACs. This will make it possible to use three phases for output, 0, 120, and 240 degrees, while leaving one for 90 degrees, so that we have the requisite 0 and 90 for input, but get 3-phase concurrent output.
I've got the SINC2/SINC3 smart pin mode done and I'm working on the scope mode, again. Not sure how many derivatives I'll use. I will be using TonyB_'s tap sets, though.
An off-topic question for all you digital filter experts.
At Hackaday, they ask if drone noise can be detected through background airport noise;
" I always hear a multirotor and look up to see it, so I’d take the approach of listening for the distinctive sound of multirotor propellers. Could the auditory signature of high-RPM brushless motors be detected amidst the roar of sound near airports?"
This is a very good idea to fit into a hopefully very good year! A perfect application for a phase shift array microphone in a single chip! Not only detect but also spot!
Happy New Year to all!
I've got all this SINC2/SINC3/conversion/raw/scope stuff done, finally.
Now I can get onto updating the streamer.
Thank you, Everyone, for your help on this stuff.
The SINC smart pin mode does the following:
1) Complete 1..14-bit SINC2 conversions in 2^(n-1) clocks.
2) SINC2 filtering at 1..8192-clock period
3) SINC3 filtering at 1..512-clock period
4) Raw 32 bits every 32 clocks
5) Internally or externally clocked
In practice its a very small noise source in a very large area next to some spectacularly loud noise sources,
and specialized radar is more likely to be used.
Comments
I starting drawing up a schematic last night for a simple external modulator for the P1; which I may build and test on a protoboard after the holiday. Although I actually have two designs in mind. One would be a simple RIAA phono playback filter; which has a particular low pass response. So what if I inject the P1 generated comparator output into the differential amplifier in two places; one that has the full bandwidth of whatever the pin is giving us; and the other which is being subjected to the same processing as the audio. That's it - for design candidate one. Design number two is a secret; for now - although I am a sure that there are some people here who know about chopper modulation, etc., and that's all I am going to say about that one.
What that implies of course is that unless you do something like what some of the original op amps did; and what some video op amp do; which is to let you choose your own external capacitors for the various time constants; then an audio rate modulator what also performs some useful function like RIAA compensation; or loudspeaker crossover with a real 4th order filter will destroy the scope modes and the video modes; that is unless you are planning on releasing a propeller which has 6 extra pins per ADC for the application specific requirements. So I think the right track is to keep all options open - except for the must haves in hardware or ROM as the case may be; i.e., streaming, sinc2/3, raw bits.
Blackman, length 24, sum 256
Hann, length 32, sum 510
Tukey, length 47, sum 1020
Tukey, length 70, sum 2040
The lengths include a leading and a trailing zero.
The above windows have the same first three taps and all 12 taps could be the same with shift register skipping and this is how my BASIC program works. However, the way to deal with different taps in hardware is to mux the particular shift reg bits. The muxing logic would be less with triple-integration as it has fewer taps.
That's what this does; or will do. I'll let you know when it compiles on the P1 under simple IDE.
#define OVERSAMPLE (5)
void sigma_delta::process_block (vector<MATH_TYPE>& src)
{
int w3[] = {1,3,3,1};
int w4[] = {1,4,6,4,1};
int w5[] = {1,5,10,10,5,1};
int w6[] = {1,6,15,20,15,6,1};
int w7[] = {1,7,21,35,35,21,7,1};
int w8[] = {1,8,28,56,70,56,28,8,1};
size_t sz = src.size();
MATH_TYPE x0, x1, x2;
MATH_TYPE z0, z1, z2, sc;
sc = (1.0)/(OVERSAMPLE);
int i,j;
for (i=0;i<sz-2;i+=2)
{
x0 = src;
x1 = src[i+1];
x2 = src[i+2];
src=0;
for (j=0;j<OVERSAMPLE;j++)
{
z0 = sc*(x0*(OVERSAMPLE-j)+x1*j);
z1 = sc*(x1*(OVERSAMPLE-j)+x0*j);
// straight wire test
// src+=0.5*(z0+z1);
src+=get_sample(z0,z1);
// src+=w8[j]*get_sample(z0,z1);
}
src*=sc;
src[i+1]=0;
for (j=0;j<OVERSAMPLE;j++)
{
z1 = sc*(x1*(OVERSAMPLE-j)+x2*j);
z2 = sc*(x2*(OVERSAMPLE-j)+x1*j);
// straight wire test
// src[i+1]+=0.5*(z1+z2);
src+=get_sample(z0,z1);
// src[i+1]+=w8[j]*get_sample(z1,z2);
}
src[i+1]*=sc;
}
}
-Phil
There is so much more important things to be done and tested. Only then if time permits, continue this.
Just my 2c
I will add $2 to the 2 cents.
Pick a thing and do it and move on. End the endless chain of suggestions of things to try.
Besides, there is a lot to test.
My .02
-Phil
So, it's a current amplifier. That's what we have coming into the ADC front end, really. Maybe a quick second order treatment, along with a higher bandwidth front end can be accomplished before the respin.
Are you aiming for a specific frequency, Chip? Or is this to reduce the clumping of the sigma delta?
Declumping can be achieved by lower integrator C.
A faster front end would allow us to digitize higher speed signals, and make the Goertzel way higher bandwidth. It could cut the phase delay way down.
Here are the double iterated taps for the above in the same order:
Blackman taps, double and triple iterated in that order:
CMA[3,5,17] (sum 255) taps, double and triple iterated in that order:
Although the window values determine the exact number of taps, triple iterated can be significantly smaller at the 'expense' of a few more adders which will be there anyway for Sinc3 mode. The other point to note is that triple iterated length is one longer than double.
In my tests, the scope filter works even better with a second-order modulator.
This circuit does not seem to work. I tried to simulate it in my code with different values and either it performs like a first order modulator or it doesn't work at all.
Saucy, what is the ratio among the R values? Have you found that some don't work and others do? Is there any rule-of-thumb to go by?
Such circuits with no buffers and multiple RC nodes, always struggle because they interact and load so much.
You could try making the second stage with R/C impedances over 10x the first stage, and see if that helps, but I think the 'correct' approach is to use a dual opamp as a proper integrator.
Then, you do get proper charge totals over many samples.
Opamps that look suitable are OPA2365 and maybe OPA2320 (lower Slew, but better Vos)
What if you want an arbitrary power instead of a square or square root? You could take the log and multiply. Or you could stack another log on and do the multiplication as an addition.
A true integrator has gain below its cutoff, and 2nd order sigma-delta modulation relies on gain
in the second integrator - without voltage gain (cascaded RC's), you have to use different gains in the feedback
paths to compensate I think.
Indeed this paper suggests you don't need any feedback to the 2nd stage at all: cmosedu.com/jbaker/papers/2014/A_Passive_2nd_Order_Sigma_Delta_Modulator_for_Low_Power_Analog_to_Digital_Conversion.pdf
We don't need the Goertzel hardware to do a rectangular window. I'm using it so it's easy to change to an arbitrary window later.
I configured it to sample as fast as possible and output to the DAC. It passes decent quality NTSC video. Note that you DON'T need to sample it above 7.16MHz for the color to work. The color seems to alias back up to the proper frequency in the DAC after aliasing down during the sampling. Of course it degrades the quality, but "it works!"
There might be an issue with Goertzel mode. If I wait for it to finish sampling, it doesn't clear the accumulators upon read. The difference between consecutive readings is fine. Either this is not the intended behavior or it's not documented.
Obviously streaming the accumulated x and y to hub would be good for software defined radio. But when? It would be inconvenient to have the sample rate locked to a multiple of the carrier frequency. If we had a pre-windowed sine/cosine in the LUT then we could stream windowed samples to the hub. It would be inconvenient to change frequencies as that would mean generating a new LUT. And for best performance we would want one window ramping up while another is ramping down.
If we could stream from HUB instead of LUT then we could retune instantly by changing the address. Or have a window longer than 512.
My concern with the above code is that if I enable the "waitx ##samples+2" between xzero and getxacc then I also have to enable "sub y,ydiff ' add ydiff,y" to get sensible output data. That code computes the difference between consecutive y readings. So it appears that adding the delay causes the Goertzel accumulators to not be reset.
Sometimes taps will coincide and either reinforce or cancel out, as shown in these examples: Assuming x <= y <= z,
if y > x then each ramp has a linear section,
if z > x + y then there is a plateau (more than two max values),
if z = x + y then two taps cancel out and have no effect.
BASIC program:
The sum and maximum tap length of cma(x,y,z) are x*y*z and x+y+z, respectively, therefore by choosing and factoring the sum everything can be determined without any guesswork.
I mentioned before that using a large sum, e.g. 12- or 13-bit bit, will mean that small value taps on their own won't count when the result is truncated to 8-bit.
The only thing I plan to change in the Goertzel is to have all four LUT bytes signed internally, then invert their MSBs whenever they are output to DACs. This will make it possible to use three phases for output, 0, 120, and 240 degrees, while leaving one for 90 degrees, so that we have the requisite 0 and 90 for input, but get 3-phase concurrent output.
At Hackaday, they ask if drone noise can be detected through background airport noise;
" I always hear a multirotor and look up to see it, so I’d take the approach of listening for the distinctive sound of multirotor propellers. Could the auditory signature of high-RPM brushless motors be detected amidst the roar of sound near airports?"
Happy New Year to all!
Now I can get onto updating the streamer.
Thank you, Everyone, for your help on this stuff.
The SINC smart pin mode does the following:
1) Complete 1..14-bit SINC2 conversions in 2^(n-1) clocks.
2) SINC2 filtering at 1..8192-clock period
3) SINC3 filtering at 1..512-clock period
4) Raw 32 bits every 32 clocks
5) Internally or externally clocked
The Scope smart pin mode does the following:
1) 70-tap Tukey window
2) 47-tap Tukey window
3) 30-tap Hann window
4) dual 6-bit-level hysteresis triggering
douglas-self.com/MUSEUM/COMMS/ear/ear.htm#pers
Though acoustic camera's are the new way to do this.
In practice its a very small noise source in a very large area next to some spectacularly loud noise sources,
and specialized radar is more likely to be used.