<azonenberg>
bits 44:16 are address 31:3, then 2:0 are 2:0
<azonenberg>
you're shifting by 16 bits not 13
<azonenberg>
so the high chunk of the address is off by 3 bits
<azonenberg>
I think it should be (uint32_t)((data & 3) | ((data >> 13) & 0xFFFFFFF8)),
<d1b2>
<mubes> Yeah, I guess it’s coming back in samples rather than packet size. Can you add it to the spreadsheet when you send it in so we can track it?
<azonenberg>
@mubes: already sent the email
<azonenberg>
forgot to put in spreadsheet. oops
<d1b2>
<mubes> S’ok, I can do that. Early here, hasn’t checked mail 🙂
<miek>
azonenberg: yeah, you're right. i thought i had pushed up that fix but i must've got sidetracked
<_whitenotifier-e>
[scopehal] azonenberg 3f1e0ec - HyperRAMDecoder: fixed bug causing high address bits to be shifted
bvernoux has joined #scopehal
<Degi>
10 bit sure looks nice
<azonenberg>
Yeah. you do lose BW doing it IIRC
<azonenberg>
But on the 2104x+ it might not actually hurt
<azonenberg>
on the higher BW sds2000's it does reduce max BW
<Degi>
Would be nice for the Rigol, its got 5.7x to 114x oversampling anyways
<azonenberg>
i mean i plan to add software based res enhancement filters at some point too
<Degi>
Or 400x if you set the lowest bandwidth limit
<azonenberg>
this is done in hardware in the adc
<Degi>
Nice ^^
<azonenberg>
Found an appnote from lecroy in 1999 that talks about their "eres" filter module
<azonenberg>
they give filter size parameters
<azonenberg>
0.5 bits -> 2 taps
<azonenberg>
1 -> 5
<azonenberg>
1.5 -> 11
<azonenberg>
2 -> 25
<azonenberg>
2.5 -> 52
<azonenberg>
3 -> 106
<azonenberg>
however, it does *not* specifythe coefficients of the taps
<azonenberg>
it's a low pass filter of some sort but i'm not clear on the details
<azonenberg>
Pico, meanwhile, uses power of two sized flat moving average filters
<azonenberg>
2 to 256 taps for 0.5 to 4 bits
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
<Degi>
I wonder if its such a good idea to reduce bits to sqrt(n) instead of n, since doesn't that also add some quantization noise?
<Degi>
Also software based filters would be very nice, the ones on the rigol are kinda terrible, especially if I need a signal with a few MHz or even kHz BW but small amplitude, it still gets drowned by noise even when I enable "high res" or the math filters, which have quite a high minimum value
<azonenberg>
yeah software based filters are coming. it's a simple FIR
<azonenberg>
the only hard part is figuring out the tap values
<azonenberg>
i did a quick thread summarizing everything i found for big name scopes
<azonenberg>
everyone has their own way of doing it lol
<Degi>
Hmm, maybe we could try a simple sin(x) / x
<azonenberg>
sinc is normally used for upsampling
<azonenberg>
which is a whole different problem
<Degi>
I see
<azonenberg>
i have that already
<Degi>
Or a multistage rectangle filter like delta sigma ADCs use
<azonenberg>
This is turning a signal at a fixed sample rate into a signal with lower bandwidth but more bits
<azonenberg>
by LPFing it
<Degi>
I mean delta sigma ADCs somehow get 24 bits with relatively low oversample factors, like instead of 2^48 its around 10 k to 100 k
<Degi>
(But I guess that also has to do with noise shaping in the converter itself)
<azonenberg>
yeah here you are just taking advantage of the noise thats already there in the system
<Degi>
Hmm, though a sinc filter could also work as a pretty hard lowpass
<Degi>
And I guess decimation is not absolutely necessary, though it doesn't make much sense to keep all the extra samples
<azonenberg>
decimation can be nice but i prefer to do it in a separate block if i need it
<azonenberg>
sometimes it can help to have the extra samples, even if just for appearance's sake
<Degi>
yeah
<Degi>
Then you don't need to sinc re-interpolate the signal as much
<azonenberg>
so for example right now the downconvert block just mixes the incoming RF with I and Q local oscillatorsd
<azonenberg>
no LPFing
<azonenberg>
you have to do that in a separate filter block
<azonenberg>
(although the two are typically chained)
<azonenberg>
related: perhaps the eres filter would make most sense to simply do as a LPF?
<azonenberg>
i.e. is a 0.5 bit eres just a FIR LPF with cutoff of Fnyquist/2?
<Degi>
Hmh maybe we can try to apply a sinc filter and see if it looks fine
<azonenberg>
well i was specifically thinking the existing LPF because i have code to do it, and calculate taps, aleready
<Degi>
(Though one question is how big it needs to be to not have artifacts when signals are on the edge of a decimation input block)
<azonenberg>
already*
<azonenberg>
it's just a matter of adding some glue to let you specify number of bits rather than cutoff
<Degi>
Ah I see, this is having number of bits as a parameter
<Degi>
Maybe instead of bits it can just have a number, since bits limits the increase to 2^n
<azonenberg>
normally that's what all the other scopes do
<azonenberg>
half bit steps
<azonenberg>
each half bit is a factor of 2 decrease in BW
<azonenberg>
so this would be a familiar UX
<azonenberg>
and again you can always do a raw LPF with any cutoff you want manually
<Degi>
true
<azonenberg>
one thing i want to do is add support for hiding some filter parameters that in derived classes need to be either read only or hidden
<azonenberg>
so for example the channel emulation filter is derived from de-embed but the "max gain" setting for de-embed makes no sense when doing channel emulation
<azonenberg>
so i want to add an option to mark it as hidden from the gui