25 Feb
2011
25 Feb
'11
4:43 a.m.
On Fri, 25 Feb 2011, Philip Pemberton wrote:
On 24/02/11 18:01, Steven Hirsch wrote:
That's quite clear, thanks! Depending upon license specifics, bolting the
DiscFerret's acquisition feature to existing CW decode logic may be a
cheap and dirty way to get started.
Long term, I have some ideas for a software framework that would be
relatively simple to build decoders on. More when I've had a chance to
think about it.
Steve
--
I will look into it. Thinking out loud: I wonder
if the data format is
compatible with any of the open-source Catweasel code, or could be
converted in such a manner.
It could be, but you'd have to resample the data. Basically, it's one
floating-point multiply operation per transition.
CatweaselValue = DiscferretValue * (CatweaselClock / DiscferretClock)
CatweaselClock -- Catweasel acquisition clock rate, in Hz
DiscferretClock -- 100e6 (for the latest firmware)
DiscferretValue -- timing value from the DiscFerret
CatweaselValue -- equivalent value from a Catweasel
You'll be throwing away a fair amount of timing resolution, and you need to
be careful about timing overflows. Use the appropriate CatweaselClock value
to get the most resolution without the value clipping to 127.
If memory serves, the Catweasel starts counting from 0, in which case you'll
need a -1 on the end of that. The DiscFerret uses a stored byte of '0' as a
special value -- "the counter overflowed, add 127 to the next count value".
It actually counts from 1, i.e. "there was a 10ns gap between the last two
transitions". Bit 7 is still used for the state of the INDEX bit, though if
the group wishes, a config bit could be added to use the entire 8 bits for
timing data...