One sure way to kill your FE-5680A or FE-5650A
We recently had a customer that purchased an FEI FE-5650A (basically a
repackage version of the FE-5680A) and reported that it worked for several
hours, then died. We promptly sent another unit, and he reported that it
died as well. He had nothing but power hooked to the unit.
On return of the first unit, it was examined and found to have corrupted
code. The corrupted code problem was thought to be associated with doing
bad things to the serial port (like framing errors), and we still believe
this to be the case. However, the customer said only power was connected
to the unit.
I was asking some questions about how he was powering the unit, when he
said he turned on the power supply (a large HP variable supply) and turned
the voltage up to +15V (our 5650's are single supply). Ah hah, slowly
ramping the voltage up on these oscillators appears to be a no no.
The second oscillator has now been examined and it too was confirmed to
have corrupted code. So, the word of warning is - DO NOT slowly ramp the
supply voltage of FE-5680A and FE-5650A oscillators. I can't say what
slowly is, but this guy was good at killing them. If I get some time I may
try to repeat the results.
My advice was to set the supply at 15V and just turn it off and on. I have
not heard from him since.
If anyone out there has a 5680A or 5650A that does not lock, the code issue
is very likely the problem. I have seen several 5680 units as well as a
few 5650 units with this problem. The good news is that they can be
fixed. I would happily do this for any time-nut that has one if return
postage is included with the unit. The bad news is that we don't know the
nature of the code problem that trashes the software (stack overflow, error
handling routine, etc.) so units can only be restored to their original
condition that still has the bug in the code.
Otherwise, the 5650 and 5680 are great values to get rubidium performance
at very reasonable prices. I have 1000's of hours on them and 100's of
power cycles, with a lot of serial port use, so if treated correctly they
are reliable units.
Regards,
Skip Withrow
RDR Electronics, Inc.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-2322-b
Virus-free
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-2322-b
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Hi
Thanks for the heads up !!
It almost sounds like they are doing some sort of “use flash as eeprom” trick and not
quite getting it right. Maybe updating a “how many times turned on” counter in that
memory space.
Bob
On Jun 7, 2016, at 5:22 PM, Skip Withrow skip.withrow@gmail.com wrote:
We recently had a customer that purchased an FEI FE-5650A (basically a
repackage version of the FE-5680A) and reported that it worked for several
hours, then died. We promptly sent another unit, and he reported that it
died as well. He had nothing but power hooked to the unit.
On return of the first unit, it was examined and found to have corrupted
code. The corrupted code problem was thought to be associated with doing
bad things to the serial port (like framing errors), and we still believe
this to be the case. However, the customer said only power was connected
to the unit.
I was asking some questions about how he was powering the unit, when he
said he turned on the power supply (a large HP variable supply) and turned
the voltage up to +15V (our 5650's are single supply). Ah hah, slowly
ramping the voltage up on these oscillators appears to be a no no.
The second oscillator has now been examined and it too was confirmed to
have corrupted code. So, the word of warning is - DO NOT slowly ramp the
supply voltage of FE-5680A and FE-5650A oscillators. I can't say what
slowly is, but this guy was good at killing them. If I get some time I may
try to repeat the results.
My advice was to set the supply at 15V and just turn it off and on. I have
not heard from him since.
If anyone out there has a 5680A or 5650A that does not lock, the code issue
is very likely the problem. I have seen several 5680 units as well as a
few 5650 units with this problem. The good news is that they can be
fixed. I would happily do this for any time-nut that has one if return
postage is included with the unit. The bad news is that we don't know the
nature of the code problem that trashes the software (stack overflow, error
handling routine, etc.) so units can only be restored to their original
condition that still has the bug in the code.
Otherwise, the 5650 and 5680 are great values to get rubidium performance
at very reasonable prices. I have 1000's of hours on them and 100's of
power cycles, with a lot of serial port use, so if treated correctly they
are reliable units.
Regards,
Skip Withrow
RDR Electronics, Inc.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-2322-b
Virus-free
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-2322-b
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
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.
The units were never intended for a slow ramp
I assume it runs into a meta stable condition
Neither on or off and then corruption
Glad you're can repair them
On Tuesday, June 7, 2016, Bob Camp kb8tq@n1k.org wrote:
Hi
Thanks for the heads up !!
It almost sounds like they are doing some sort of “use flash as eeprom”
trick and not
quite getting it right. Maybe updating a “how many times turned on”
counter in that
memory space.
Bob
On Jun 7, 2016, at 5:22 PM, Skip Withrow <skip.withrow@gmail.com
javascript:;> wrote:
We recently had a customer that purchased an FEI FE-5650A (basically a
repackage version of the FE-5680A) and reported that it worked for
several
hours, then died. We promptly sent another unit, and he reported that it
died as well. He had nothing but power hooked to the unit.
On return of the first unit, it was examined and found to have corrupted
code. The corrupted code problem was thought to be associated with doing
bad things to the serial port (like framing errors), and we still believe
this to be the case. However, the customer said only power was connected
to the unit.
I was asking some questions about how he was powering the unit, when he
said he turned on the power supply (a large HP variable supply) and
turned
the voltage up to +15V (our 5650's are single supply). Ah hah, slowly
ramping the voltage up on these oscillators appears to be a no no.
The second oscillator has now been examined and it too was confirmed to
have corrupted code. So, the word of warning is - DO NOT slowly ramp the
supply voltage of FE-5680A and FE-5650A oscillators. I can't say what
slowly is, but this guy was good at killing them. If I get some time I
may
try to repeat the results.
My advice was to set the supply at 15V and just turn it off and on. I
have
not heard from him since.
If anyone out there has a 5680A or 5650A that does not lock, the code
issue
is very likely the problem. I have seen several 5680 units as well as a
few 5650 units with this problem. The good news is that they can be
fixed. I would happily do this for any time-nut that has one if return
postage is included with the unit. The bad news is that we don't know
the
nature of the code problem that trashes the software (stack overflow,
error
handling routine, etc.) so units can only be restored to their original
condition that still has the bug in the code.
Otherwise, the 5650 and 5680 are great values to get rubidium performance
at very reasonable prices. I have 1000's of hours on them and 100's of
power cycles, with a lot of serial port use, so if treated correctly they
are reliable units.
Regards,
Skip Withrow
RDR Electronics, Inc.
<
Virus-free
<
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
time-nuts mailing list -- time-nuts@febo.com javascript:;
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com javascript:;
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On 6/8/16 6:19 AM, paul swed wrote:
The units were never intended for a slow ramp
I assume it runs into a meta stable condition
Neither on or off and then corruption
Glad you're can repair them
On Tuesday, June 7, 2016, Bob Camp kb8tq@n1k.org wrote:
Interesting, we just had a similar issue on a circuit here at work..
someone slowly brought the supply voltage up on a bunch of DC/DC
converters, and some didn't start. This was in initial checkout of a new
board.
Switch it on with a bang, and it works just fine.
So for some of these things there's apparently a minimum dv/dt.
I've seen this before with DC/DC converters.. if the voltage drops too
low, they draw too much current - because they're basically constant
power devices- and the overcurrent trip shuts them down. There's a
delicate interplay between the overcurrent and undervoltage trips,both
of which have some sort of time constant, and I suspect that for a lot
of circuits, the "slow ramp up of input voltage" isn't something they
are designed for. Once it's up and running, when the supply sags, the
UV trip works just fine, tripping before the OC trip goes.
Linear regulators.. they may be not the most efficient thing in the
world, but they have a lot less "weird" behavior. (although I've had
linear regulators go into thermally driven oscillation)
Sounds similar to the issues you encounter with Atmel and some other
EEPROM/Flash based MCUs when they're not held in reset until VCC becomes
stable.
http://atmel.force.com/support/articles/en_US/FAQ/Prevent-EEPROM-corruption
Some more info:
On 8 June 2016 at 16:20, jimlux jimlux@earthlink.net wrote:
On 6/8/16 6:19 AM, paul swed wrote:
The units were never intended for a slow ramp
I assume it runs into a meta stable condition
Neither on or off and then corruption
Glad you're can repair them
On Tuesday, June 7, 2016, Bob Camp kb8tq@n1k.org wrote:
Interesting, we just had a similar issue on a circuit here at work..
someone slowly brought the supply voltage up on a bunch of DC/DC
converters, and some didn't start. This was in initial checkout of a new
board.
Switch it on with a bang, and it works just fine.
So for some of these things there's apparently a minimum dv/dt.
I've seen this before with DC/DC converters.. if the voltage drops too
low, they draw too much current - because they're basically constant power
devices- and the overcurrent trip shuts them down. There's a delicate
interplay between the overcurrent and undervoltage trips,both of which have
some sort of time constant, and I suspect that for a lot of circuits, the
"slow ramp up of input voltage" isn't something they are designed for.
Once it's up and running, when the supply sags, the UV trip works just
fine, tripping before the OC trip goes.
Linear regulators.. they may be not the most efficient thing in the world,
but they have a lot less "weird" behavior. (although I've had linear
regulators go into thermally driven oscillation)
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.
--
Clint.
No trees were harmed in the sending of this mail. However, a large number
of electrons were greatly inconvenienced.
The same problem may appear on some poorly designed crystal oscillators.
Some circuits depend on the spectral component of a fast power-on and will not start reliably if the supply voltage is ramped slowly - as can happen if the oscillator stage is fed by a voltage regulator with high value capacitor blocking at its output.
That is why oscillator testing standards like IEC 60679-1 define the test for reliable start-up to consist of a slowly ramping up supply voltage.
Another way to identify potential start-up problems is to cool down the unpowered oscillator to the minimum operating temperature (or upper operating temperature) and then to apply a slow supply voltage ramp
Bernd
DK1AG
-----Ursprüngliche Nachricht-----
Von: time-nuts [mailto:time-nuts-bounces@febo.com] Im Auftrag von jimlux
Gesendet: Mittwoch, 8. Juni 2016 17:21
An: time-nuts@febo.com
Betreff: Re: [time-nuts] One sure way to kill your FE-5680A or FE-5650A
On 6/8/16 6:19 AM, paul swed wrote:
The units were never intended for a slow ramp I assume it runs into a
meta stable condition Neither on or off and then corruption Glad
you're can repair them
On Tuesday, June 7, 2016, Bob Camp kb8tq@n1k.org wrote:
Interesting, we just had a similar issue on a circuit here at work..
someone slowly brought the supply voltage up on a bunch of DC/DC converters, and some didn't start. This was in initial checkout of a new board.
Switch it on with a bang, and it works just fine.
So for some of these things there's apparently a minimum dv/dt.
I've seen this before with DC/DC converters.. if the voltage drops too low, they draw too much current - because they're basically constant power devices- and the overcurrent trip shuts them down. There's a delicate interplay between the overcurrent and undervoltage trips,both of which have some sort of time constant, and I suspect that for a lot of circuits, the "slow ramp up of input voltage" isn't something they are designed for. Once it's up and running, when the supply sags, the UV trip works just fine, tripping before the OC trip goes.
Linear regulators.. they may be not the most efficient thing in the world, but they have a lot less "weird" behavior. (although I've had linear regulators go into thermally driven oscillation)
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.
On Wed, 8 Jun 2016 08:20:45 -0700, you wrote:
Interesting, we just had a similar issue on a circuit here at work..
someone slowly brought the supply voltage up on a bunch of DC/DC
converters, and some didn't start. This was in initial checkout of a new
board.
Switch it on with a bang, and it works just fine.
So for some of these things there's apparently a minimum dv/dt.
This problem also occasionally shows up in integrated circuits where a
slow power ramp does not allow the bias circuits to start. I think
Bob Pease related an instance where this was caused by a missing
connection and capacitive coupling to the substrate was enough to
start the bias circuits but nobody noticed the problem until after it
was in production.
I've seen this before with DC/DC converters.. if the voltage drops too
low, they draw too much current - because they're basically constant
power devices- and the overcurrent trip shuts them down. There's a
delicate interplay between the overcurrent and undervoltage trips,both
of which have some sort of time constant, and I suspect that for a lot
of circuits, the "slow ramp up of input voltage" isn't something they
are designed for. Once it's up and running, when the supply sags, the
UV trip works just fine, tripping before the OC trip goes.
These problem seems to crop up more with newer designs. In old
off-line switching power supply designs that I have studied, most have
a deliberately designed in hard start capability where when an
extended fault condition is detected, the regulator is completely
reset by momentarily shorting the bias supply. If the fault
continues, then the power supply periodically ticks as it tries to
restart so there is a nice indication of the problem without self
destruction.
The negative input resistance characteristic of switching power
supplies can have another bad result. Some will continue to operate
at low input voltages drawing excessive current eventually damaging
themselves do to I^2R losses.
Power on reset circuits can have this problem in a different way. If
power is removed and then reapplied within a short time, an RC circuit
may not discharge enough to retrigger. Adding a diode to discharge
the capacitor when the supply falls is usually enough to fix this.
Some "universal input" off-line switching power supplies are marked to
run from 90 VAC to 270 VAC but actually cannot because they use an
automatic switching voltage doubler at their input. If the input is
between the 120 VAC and 240 VAC ranges, they toggle back and forth
until they self destruct. Luckily these are less common now with
active power factor correction inputs becoming ubiquitous.
Linear regulators.. they may be not the most efficient thing in the
world, but they have a lot less "weird" behavior. (although I've had
linear regulators go into thermally driven oscillation)
Linear regulators with foldback current limiting can have startup
problems with some loads. Integrated regulators are usually designed
to put out full current as long as secondary breakdown limits are
observed and rely on their thermal protection which is itself designed
to have significant hysterisis to allow for hard starts under any
conditions. But if the input to output voltage difference is high,
they can fail to start into some loads.
Bob Pease recommended saving low gain transistors for operating margin
tests.
On Wed, 8 Jun 2016 18:35:58 +0200, you wrote:
...
Another way to identify potential start-up problems is to cool down the unpowered oscillator to the minimum operating temperature (or upper operating temperature) and then to apply a slow supply voltage ramp
Bernd
DK1AG
For what it’s worth, the GPS boards I’ve designed for the FEI devices use the TPS54[23]31 for the primary 15v supply (which also powers the 5v supply), and it has been configured with a hysteretic UVLO with a start threshold above 16 volts. Additionally, the slow-start is configured for somewhere between 1 and 10 ms, which I would posit is acceptable. I haven’t actually measured the delay between the +15 and +5 supplies, but I don’t have much reason to believe they’d be “unreasonably” far apart.
The ATTinys have brownout detectors in them that’s supposed to keep them from going bonkers during undervolt periods.
I’ve powered up my 5680As a bunch of times with these boards and since identifying that one firmware bug in my code where the serial output dropped a byte in the tuning command, I haven’t had any trouble.
On Jun 8, 2016, at 9:22 AM, Clint Jay cjaysharp@gmail.com wrote:
Sounds similar to the issues you encounter with Atmel and some other
EEPROM/Flash based MCUs when they're not held in reset until VCC becomes
stable.
http://atmel.force.com/support/articles/en_US/FAQ/Prevent-EEPROM-corruption
Some more info:
On 8 June 2016 at 16:20, jimlux jimlux@earthlink.net wrote:
On 6/8/16 6:19 AM, paul swed wrote:
The units were never intended for a slow ramp
I assume it runs into a meta stable condition
Neither on or off and then corruption
Glad you're can repair them
On Tuesday, June 7, 2016, Bob Camp kb8tq@n1k.org wrote:
Interesting, we just had a similar issue on a circuit here at work..
someone slowly brought the supply voltage up on a bunch of DC/DC
converters, and some didn't start. This was in initial checkout of a new
board.
Switch it on with a bang, and it works just fine.
So for some of these things there's apparently a minimum dv/dt.
I've seen this before with DC/DC converters.. if the voltage drops too
low, they draw too much current - because they're basically constant power
devices- and the overcurrent trip shuts them down. There's a delicate
interplay between the overcurrent and undervoltage trips,both of which have
some sort of time constant, and I suspect that for a lot of circuits, the
"slow ramp up of input voltage" isn't something they are designed for.
Once it's up and running, when the supply sags, the UV trip works just
fine, tripping before the OC trip goes.
Linear regulators.. they may be not the most efficient thing in the world,
but they have a lot less "weird" behavior. (although I've had linear
regulators go into thermally driven oscillation)
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.
--
Clint.
No trees were harmed in the sending of this mail. However, a large number
of electrons were greatly inconvenienced.
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.
NAND Flash is especially bad about this. Not only can the data being
currently erased or programmed be corrupted but other data can be
also. That is why NAND Flash drives are so prone to complete failure
even if a log type of internal file system is used; it is one thing to
protect against corruption of the last written data but another when
any data can be destroyed.
On Wed, 8 Jun 2016 17:22:38 +0100, you wrote:
Sounds similar to the issues you encounter with Atmel and some other
EEPROM/Flash based MCUs when they're not held in reset until VCC becomes
stable.
http://atmel.force.com/support/articles/en_US/FAQ/Prevent-EEPROM-corruption
Some more info: