Most switch mode power supplies actually run a voltage doubler on the input when running on 110V. This puts over 300V across the transformer and switch. Also the regulation loop crosses the isolation barrier introducing more failure points that can result in overvoltage.

Robert G8RPI.

--- On Mon, 1/6/09, SAIDJACK@aol.com SAIDJACK@aol.com wrote:

I have seen it talked about (around the LF fraternity, but generally they
are stable enough there and just need calibation) a lot but not accomplished
yet.

How about injection locking the on board osc....maybe gating the feedback
with the reference....note I havent tried this? Another technique I have
used to shift "logic-block" oscillators is to vary their supply voltage,
they will oscillate from around 3v to well over 5.5v ....that might enable
you to phase lock it  using a variable regulator to vcxo to crystal??

Alan G3NYK

----- Original Message -----
From: "Rex Moncur" rmoncur@bigpond.net.au
To: "'Discussion of precise time and frequency measurement'"
time-nuts@febo.com
Sent: Monday, June 01, 2009 10:59 PM
Subject: [time-nuts] Sound Cards for locking to GPSDO 10 MHz references

readily

can

internal

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

The concern I'd have with modifying a USB sound card, or any of them for
that matter, is that the glue logic between the ADC and the USB chip may be
designed for a certain relationship between the ADC and USB clocks.  Running
the ADC asynchronously may or may not be robust depending on the assumptions
baked into the gate array.  It might be OK if your app can tolerate
occasional misclocking or dropouts but I'd be reluctant to use a hacked
sound card for anything timing-critical.

I just (last week) got an AD7760 ADC eval board working with the Digilent
Nexys2 FPGA platform, with the EVAL-AD7760 board running from its own 40 MHz
clock.  It will accept an external 40 MHz clock source that, in turn,
wouldn't be hard to derive from 10 MHz.  Way overkill for ultra
low-bandwidth work, but if anyone is looking for a clean digitizer for audio
rates in general, you could do a lot worse than this approach.  Cost isn't
too bad either, at $130 for the Nexys2 and $150 for the ADC7760 eval board.
Of course the big drawback is the lack of any sort of standardized audio
driver on the host side.

If/when I spin a PCB for this project I'll definitely include a 10 MHz
input.

-- john, KE5FX

Some of the "pro" sound interfaces have a "word clock" input.

There are a variety of things that take a external input and generate a S/PDIF that's properly timed, as well. Lots of boxes will take a S/PDIF sync input (e.g. the Edirol FA-66 which was used by lots of Flex-Radio folk), so maybe that's something you could easily generate from your 10MHz.

A chart at Cakewalk shows that MOTU has a USB interface (828MkII) which has a word clock sync. It's going to be a pricey beast though, with 8in/8out ($800?)

Even if you have a word clock input, you're going to have to synthesize that from the 10 MHz.  Maybe it's easier to just make a S/PDIF which is a MUCH more common sync signal. ( I think S/PDIF is something like 3 MHz)

The HPSDR folks also might have something...

Most likely failures on power supplies are with the power components.
Failure of the pass transistor in a linear supply is likely to result in
overvoltage at the output, while failure of the switch on a switchmode
supply will blow the fuse instantly.

It is been my experience (after 30 years in the field) that a properly
designed switchmode supply is at least as reliable as a linear supply of the
same output power, if for no other reason than the lower dissipation and
resulting reduced failure rate.

By using integrated controllers with lots of protection features built-in,
switchmode supplies tend to be smarter than linear ones, and their failures
tend to cause fewer damage to other circuits.

Of course, your mileage may vary...

Didier KO4BB

I use a Lynx One sound card, it has analog and digital I/O and MIDI I/O
and clock I/O.  Their manuals are available on line at
www.lynxstudio.com.  These are profession 24 bit cards, the analog I/O
uses balanced interfaces.  They handle AES/EBU and SP DIF digital audio
formats.

The sound card can take an internal clock, an external clock input on
the MIDI port, there is a parallel clock header on the PC board, and a
digital clock input on the digital audio lines.

It can accept a 13.5 Mhz video dot clock, a 27 Mhz video dot clock, and
a word clock and word clock/256.

It can also take a single source frequency as a referenve clock.

Its basicaly set up to sync and slave SMPTE timing systems

Hope that helped......

Rex Moncur wrote:

Brian Kirby skrev:

13,5 MHz is ITU-R BT.601/BT.656 luminance sampling rate.
27 MHz is BT.601/BT.656 luminance/chroma-difference combined sampling
rate (4:2:2).

27 MHz is the video reference rate of them all. Sad that they broke it
when they did the North American HD stuff. Breaking numerology like that
isn't very nice... it always cost extra now.

I think you mean word-clock * 256 as this is Digidesign/ProTools clock
distribution strategy, giving 12,288 MHz for 48 kHz sampling rate.

Cheers,
Magnus

Didier
Your comments regarding SMPS are very valid, but there are SMPS designs and
then some !
I bought a Wavetek 395 Function Generator with a totally blown up SMPS for
approx $100. I attempted to repair this unit but the PCB was badly
damaged/burned and one 8-pin Dil device was blown to bits - plus burnt out
resistors. I tried to obtain a replacement from the manufacturers without
success. After hooking up external supplies and proving that it was
otherwise OK, I contemplated building a linear supply within the box - it
would have been heavy and difficult to fit. This latter point reinforces
your comment about size and power dissipation. The original unit was
identical to the average small PC PSU, but with very different outputs.
After about 10 months of looking for a solution - I thought I recognized a
Wavetek 395 Function Generator in Bob Mokia's Lab. photo, and ask him if he
could find me a spare PSU, after a short while he came back with a
replacement for around $50 - presto I now have a fully working 395 for $100,
which I notice sells for $1500 in the US.
Footnote:
No axe to grind, but like others in the Group,I have found Bob Mokia to be a
"straight" and helpful dealer.
Roy

----- Original Message -----
From: "Didier Juges" didier@cox.net
To: "'Discussion of precise time and frequency measurement'"
time-nuts@febo.com
Sent: Tuesday, June 02, 2009 3:24 AM
Subject: Re: [time-nuts] Thunderbolt - any negatives ?

Most likely failures on power supplies are with the power components.
Failure of the pass transistor in a linear supply is likely to result in
overvoltage at the output, while failure of the switch on a switchmode
supply will blow the fuse instantly.

It is been my experience (after 30 years in the field) that a properly
designed switchmode supply is at least as reliable as a linear supply of the
same output power, if for no other reason than the lower dissipation and
resulting reduced failure rate.

By using integrated controllers with lots of protection features built-in,
switchmode supplies tend to be smarter than linear ones, and their failures
tend to cause fewer damage to other circuits.

Of course, your mileage may vary...

Didier KO4BB

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Lux, James P skrev:

S/P-DIF [iec60958-3] has a baudrate which is 128 x sample rate and a bit
rate which is 64 x sample rate, which is inherited properties from
AES/EBU [aes3] [tech3250] [iec60958-4].

Locking up a S/P-DIF (128 x sample rate) is about the same job as
locking up a superclock (256 x sample rate) or wordclock (1 x sample rate).

As long as the signal is samples with low jitter and A/D converted in a
good fashion, delivery over S/P-DIF should not be too hard. An ADC is
slammed onto a AES/EBU/S/P-DIF chip which is fairly trivial extra work.

Cheers,
Magnus

However, if you're buying an off the shelf audio interface, you're stuck with whatever the mfr is providing for a sync input, and a (very) casual inspection of what's available these days (particularly at low cost) shows that S/PDIF seems to be the most common.

J.D. Bakker wrote:

I am in complete agreement with this kind of solution. Sampling on the
second channel a reference signal of known value allows the software
to make a simple adjustment. No need to switch on the soldering iron...
Never do in hardware what can be done in software.... :-)

73  Alberto  I2PHD

Hello The Net:

For portable operations with a laptop, usually only one input channel is
available
and it is at mike (not line) level.

The alternative to sum the analog reference and the analog signal of
interest may be
possible if the reference noise can be kept out of the signal of
interest bandwidth.
Maybe a external USB soundcard with at least 2 input channels is more
appropriate.

Stan, W1LE    FN41sr    Cape Cod

Alberto di Bene wrote:

Lux, James P skrev:

Do they really lock up to the S/P-DIF input? I doubt it for the cheap
boards. Rather, they decode the S/P-DIF signal and ship the samples into
the DSP. The DSP tends to make very rought sample-rate conversions like
dropping samples etc.

A lockable board isn't that expensive. You can get them off ebay for
instance.

Cheers,
Magnus

Alberto di Bene skrev:

Such a double-frequency conversion cancels fairly well the transfer
oscillators frequency and jitter, as long as it is sufficienly low.

Respectfully I disagree. There are tasks which is better managed by
software and tasks which is better managed by hardware. In the world of
FPGAs, it is also worth mentioning that some tasks is best done there.
The big trick is to find a balance between various methods, available
resources, partitioning of the problem, doing it on time and achieving
the needed performance.

There is an overbeleif in what software is suitable for IMHO.

Cheers,
Magnus

Magnus Danielson wrote:

Of course you are right, the best solution must be decided case by case.
But the biggest plus of the software is that it can be changed on the fly,
without an expensive reworking station, and the manual ability to correctly
use it.  And a side effect is speed : you can test many variants of a solution
in a time frame of a few minutes.  Not so easily doable with hardware changes.

73  Alberto  i2PHD

Alberto di Bene skrev:

This is why we do alot of things in FPGAs today, and in the FPGAs we
often put dedicated DSPs of various complexity, often adapted to their
task. Keeping quick turn-around is on our mind, but in general, the
shorter turn-around, the poorer testing usually happends, and the
sloopier design is often found, and the longer it takes to get the job done.

In general, a CPU is suitable for doing non-common tasks. More dedicated
designs like firmware and hardware is suitable to do things which is
essentially the same but happends over and over and over and often at a
high speed. Such monotonic tasks just waste energy, space and
complexity when done in CPUs. The problem with a generic CPU is that it
is generic, so it can do all kinds of tasks, which makes timing-critical
bulk-processing tasks problematic to combine with sporadic and possibly
high-dynamic processing. Splice the bulk off to some dedicated
processing, which can be done in another CPU, and better performance is
yielded. There are loads of designs where a few well thought 8-bit
processors work together and shine over a more modern fancy design.

One such example is found in the SR-620 which has a Zilog Z-8000
processor as main CPU and a Z-80 co-processor which only does the X-Y
vector display. The Z-80 has so small program that it is loaded into
SRAM from the Z-8000 as it boots.

The HP 5334A has actually 3 different 3870 processor, one for overall
control, one for measurements and one for GPIB.

Hmm, do you get a feeling that I am actually object very much to just
toss it into the processor. I think you are right. :)
Nothing wrong with software, but use it wisely. Build the test-benches
as if you where doing a ASIC or full-custom design and thus also think
about each compile costing you milions of dollars and a pipe-line depth
of many months (6-9).

I guess I am becomming more conservative by the day. From my own and
others mistakes and succsesses.

Cheers,
Magnus