K
Kevin Aylward
Guest
wrote in message news:h45ikfh1r2jtd2hhkfo1inv6l5vqim11nt@4ax.com...
On Fri, 28 Aug 2020 07:32:25 +0100, \"Kevin Aylward\"
<kevinRemovAT@kevinaylward.co.uk> wrote:
Knew that was coming
Yeah... it has been considered... several times....stunningly difficult to
to this digitally within the noise and current constraints.
The target is of the order of -175 dBc flatband phase noise, -85 dBc close
in . Any on board processing generates switching noise all over the place
just for starters. 10 nV/rthz on a supply is a problem. Step changes in
frequency are disastrous, so the DAC output can\'t wiggle about much. 1uv at
1Hz on the vcxo line is a problem thus with a 1V full scale the A/D and DAC
needs 20 bits at least, realistically 24 bits. Analog has \"infinite\"
resolution...
MEMS oscillators do do it all digitally, so its not entirely hopeless. They
use two oscillators next to each other. One with a deliberate large
temperature coefficient. The difference in frequency gets you temperature.
No A/D needed, just a counter.
Memory lifetime is a also a problem... telecoms stuff specs 10 to 20 year
lifetimes. We use fuse blown rom. Typically only need a few hundred bits,
not bytes.
-- Kevin Aylward
http://www.anasoft.co.uk - SuperSpice
http://www.kevinaylward.co.uk/ee/index.html
On Fri, 28 Aug 2020 07:32:25 +0100, \"Kevin Aylward\"
<kevinRemovAT@kevinaylward.co.uk> wrote:
\"John Larkin\" wrote in message
news:5b5gkf5m98m00prljl4ihrgee7mc7d8jh9@4ax.com...
On Thu, 27 Aug 2020 15:57:40 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:
On 2020-08-27 15:42, Kevin Aylward wrote:
\"John Larkin\" wrote in message
news:4qvfkfl9c10o4ca4hpfsjdla0i7ol6r1o9@4ax.com...
On Thu, 27 Aug 2020 19:40:15 +0100, \"Kevin Aylward\"
kevinRemovAT@kevinaylward.co.uk> wrote:
wrote in message news9eakftpajnd1lncmi09km6789riupttuq@4ax.com...
Or think you do.
It surprises me how many people can\'t.
Some people invent stuff which is novel enough to patent. John
Larkin
doesn\'t seem to be one of them.
I\'m looking forward to him inventing my current mirror variation on
Baxandall\'s class-D oscillator (which nobody has bothered to
patent, but
I\'ve not >seen anywhere either).
if it takes so long to make that the patent is expired before it is
done
why bother
Right. As people copy your designs, just stay a generation ahead.
Designing is fun. Patent applications aren\'t fun.
I agree. Patent applications are stunningly daunting.
.>.. as it happens... recently been notified that my first ever 2
patent
applications have been granted...
The fortunate bit is that I did practically nothing in the whole
application
process... the company has a dedicated guy to do that...
...yes... unfortunately... until recently I have not been clever
another to
find an existing idea to copy and rework it for a new purpose until
now...
Its actually one of real value. Typically TCXOs can get temperature
compensated to around 100 ppb to 300 ppb due to multiple
perturbations in
the crystal. This technique allows one to get a 10 times better post
compensation. The first prototype asic actually worked!
Since it\'s patented, please tell us how it works!
So.... Barrie Gilbert wrote papers in the 70s of how to linearize a
differential gain controlled amp...
The standard problem to be solved is having a very low noise front end
gain controlled amp that is linear but with a wide input range. A full
gilbert cell (input diodes) itself adds a fair bit of noise . A typical
application is to do variable tuned, narrowband RF channel filtering
digitally, e.g. mobile phones, which is pretty much impossible to do in
analog. The input range being uVs to 100s mv. If the input distorts, the
digital filtering wont work.
A diff pair can only take about 50mV max whatever the gain control tail
current does.
Gilberts\'s idea is to use several diff stages in parallel but with
different offset voltages. Thus forming an offset sum of tanh()
functions. As the gain of one drops off, another takes over. I have a SS
example... somewhere.
Now... xtals have up and down frequency shifts (100 ppbs) with
temperature, all different from unit to unit, sitting on top of a main
3rd order chebychev 20 ppm shape. We use up to 4th order chebys for the
main compensation, but to compensate these wiggles is not practicable
with more chebys. The inflection points are all over the place.
Thus I realised that I could pinch the idea to use the offset diff pairs
to form summed tanh() correction curves to take out the xtal wobbles.
The 1st application actually got rejected, not surprisingly, the idea of
using S curves to compensate processes had already been
patented...However very surprisingly, our man reworked it to make it
more specific and bobs your uncle....
For me, what is significant is that.....
Usually, top brass pass down the chain decide what they want to produce,
and the surfs churn the handle for them.
In this case, I was pondering the problem of poor yields due to the
variability of the xtals and the knowledge of Gilberts technique popped
up in my noggin as a solution. I explained the idea to my local work
mates, we did some simulations with real xtal data and tanh() in Excel
and convinced ourselves that it would work. We presented the idea to top
brass and they said go ahead, make a test ASIC. Although a few teething
issues with the ASIC, it worked well enough to prove the concept worked.
So, this is a method that should give at least a 5 times improvment in
temperature stability, yet originated from a surf with no remit....
Well, get out the serfboard and celebrate.
That\'s a cute technique, thanks. My underwater projects are always the
best too.
Cheers
Phil Hobbs
Given that you can approximate a function out of N piecewise segments
of arbitrary length and slope, is there a process to locate the
segment endpoints for minimum (peak or RMS maybe) error? I usually do
it by eyeball but there must be a better way.
Yes. There is. The \"piecewise\" bit was a key issue being solved though. One
needs a smooth transition to get a low dV/dT slope. The slope error is
typically more of a problem for the frequency stability that the actual
stability itself
Overlapped TANHs is cute. One could slide them around (offset) and
adjust their slopes (tail currents).
Exactly. The blocks have programmable slope, offsets and max current, with
polarity.
One uses the solver in Excel!
One constructs a table with the data of the curve that is to be
compensated.
Then construct a sum of tanh() functions with co-efficients
A_n.tanh(B_n.T+C_n)
One tells Excel to find the best co-efficients that minimises the summed
squared error of the original function and the approximating function.
Its really simple. One just selects the co-efficients to be varied and
Excel
just churns out the answer. No math knowledge is required at all.
It practice, one actually uses measured data tables from the blocks. It
doesn\'t actually matter what the exact shape is so long as it is S like.
That\'s all cool, but the obvious question is, why not do this
digitally, with a lookup table and a DAC? It could be clocked at 1 Hz
or something.
It would be fun to take a conventional uP and clock it *really* slow.
Run at micro-MIPS.
Knew that was coming
Yeah... it has been considered... several times....stunningly difficult to
to this digitally within the noise and current constraints.
The target is of the order of -175 dBc flatband phase noise, -85 dBc close
in . Any on board processing generates switching noise all over the place
just for starters. 10 nV/rthz on a supply is a problem. Step changes in
frequency are disastrous, so the DAC output can\'t wiggle about much. 1uv at
1Hz on the vcxo line is a problem thus with a 1V full scale the A/D and DAC
needs 20 bits at least, realistically 24 bits. Analog has \"infinite\"
resolution...
MEMS oscillators do do it all digitally, so its not entirely hopeless. They
use two oscillators next to each other. One with a deliberate large
temperature coefficient. The difference in frequency gets you temperature.
No A/D needed, just a counter.
Memory lifetime is a also a problem... telecoms stuff specs 10 to 20 year
lifetimes. We use fuse blown rom. Typically only need a few hundred bits,
not bytes.
-- Kevin Aylward
http://www.anasoft.co.uk - SuperSpice
http://www.kevinaylward.co.uk/ee/index.html