IN-18 Blue Dream PWB

[dixter]

Any one have a source for a PWB for the IN-18 Blue Dream Clock....  mine is acting up and I am wondering how long it will last....  so I am going to try and purchase a new PWB kit to fix it....

thanks

Dixter

[Greg P]

What is a PWB kit? 

[dixter]

PWB = Printed wire board or PCB= Printed circuit board....   

[Greg P]

Thanks for the clarification.  That's a new one on me, never heard that term.

What exactly is the issue with your clock?  I'm sure the folks here can help troubleshoot the issue or failing components.  Might not be necessary to source a new PCB.

Have you reached out to the Nocrotec/Dieter for help?

[MichaelB]

Yep, I recently had an issue with that clock and it ended up being a shift register. Easy fix. Ping Dieter and tell him what the issue is. He may be able to advise you on a fix.

[gregebert]

When you find the cause of the failure, please share. It helps us design better clocks.

[dixter]

working with Dieter on the issue now...

Note:  Blue Dream Nixie Clock

Symptom is flickering of the two hour nixie tubes.  for example when a 0 is displayed you also see a 1 flicker on at the same time for both nixie tubes in the 

hour slots...  schematic reference is Valve 1 and Valve 2

strange item is that if you pull the power plug from the clock and let the clock sit for a few minutes and re-power the clock, then the flickering goes away for several hours and then it shows up again...   shouldn't be a heat issue as its not hot at all where the clock is located...  

I also didn't have a schematic... but I do now and should be able to scope the actual part when I get it apart...     

for reference suspect part 

74HC595D, SOIC-16/SO-16, SMD
mouser part no. 771-74HC595D-T

On order... maybe get this all fixed next week ..  :-)

[MichaelB]

Sounds like the same exact issue I had. Replaced 2 of the 74HC595D's. Problem vanished

[Nicholas Stock]

I also replaced one of those on a friends blue dream clock for exactly the same issue. 

Nick

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neonixie-l+...@googlegroups.com.
To post to this group, send email to neoni...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/c88756cf-b6af-417f-b702-ab5251bf944d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gregebert]

Those ICs should last forever, because they are not exposed to anything hazardous (high-voltage, high-temp, high current).

My hunch is that there is a design marginality somewhere, and that as the part itself ages, or it's surrounding parts, the marginality becomes a defect.

[Dekatron42]

I don't know anything about this clock in particular but I have come across several other designs where a mix of TTL ic's, CMOS ic's and other ic's with different VCC capabilities has been used, some starting to operate from as low as 1.8V and some like TTL above 4.75V, but all capable of running at 5V as the main VCC voltage.

The problem with these designs have all been that the microprocessor has started at the lowest voltage of all ic's which has then led to latchups in some of the external ic's as they weren't ready to work until the voltage had risen above their minimum operating voltages. The microprocessor started to run its program and communicated with them right away when it was ready as it used its internal power on reset and thought that everything was green to go. Now some of these designs worked for years until they failed due to different reasons, possibly ageing components, some only worked for a short while and some were problematic intermittently. All of these problems were due to not waiting for the voltage to rise above the minimum voltage for the type of ic used with the highest minimum voltage requirement - this I feel can only be blamed on bad design, or poor knowledge on how things should be designed.

In some cases there has been differences between different manufacturers producing the same ic, one under license from the other, and even within different runs from the same 2nd source manufacturer. Even if different manufacturers produced the same ic they didn't work equally under the startup conditions when voltages where rising to their operating levels (and in some cases when the voltages were being removed), in some cases it resulted in lockups or strange behaviours later when the ic in question was being used.

Fortunately most of the problems I have come across could be remedied by adding a POR (Power On Reset) ic to the microprocessor halting it until power had risen to the required level for the TTL ic's that were the most problematic.

Trying to locate this kind of problem is very time consuming but when you know about it is one of the first things I check in a mixed ic environment.

/Martin

[gregebert]

I'm doubtful that latch-up is happening here, because it usually results in a short-circuit across the supply. Also, the problem as described happens after a few hours of operation, and not during power-up. I'm suspecting a hold-time marginality.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

From my experience in chip design, latch-up is initiated when excess current is forced thru a pin. For most IC's, the only way to do this is by applying a voltage greater than Vcc or less than GND (ie, a negative voltage) to a signal pin. Usually, currents well-above 100mA are required to induce latch-up; not many datasheets spec the latch-up current, but you can use the short-circuit current as a guideline for your design. Latch-up can happen on input, output, and inout pins under the right circumstances.

So, what can you do to prevent latch-up ? The highest-risk areas are mixed-voltage designs, where the supplies are not sequenced in a specific manner. If you have a +5V and +3.3V design, a diode forward-biased from the 3.3V supply to the 5V supply will provide a lot of protection as long as the 3.3V supply is brought-up first, and brought-down last. Also, the 3.3V supply must be able to provide sufficient current to hold-up the 5V rail until that supply comes up. Years ago we used this on desktop PCs that had a mix of 3.3V and 5.0V devices; we also had a string of 3 diodes from the 5V supply to the 3.3V supply, and that allowed supplies to come-up in any order. There were millions of PCs built with this approach back in the 90's and I'm not aware of any field returns root-caused to latch-up.

If that wont work, you can add series resistors on signals between power domains to limit the current. Suppose you need to protect signals between 3.3V and 5V domains, and the current needs to be limited to 25mA (the output short-circuit current of an LM348 OP-amp). Be aware it takes at least a 'diode-drop' voltage difference (about 0.7V) to start forcing more current thru a CMOS pin. Knowing this, the series resistance should be at least R= (5 - 3.3 - 0.7)/25mA, or 40 ohms. This will affect circuit timing somewhat; if load-capacitance is around 25pF the signal-delay from the RC-network will be around 1 time-constant, which is 40*25 = 1000psec (1nsec) in this case. This assumes a 2.0V threshold for a 3.3V supply.

Here is a brief paper from TI that discusses latch-up: http://www.ti.com/lit/wp/scaa124/scaa124.pdf

[gregebert]

On second thought, the resistor value I stated is still too low because the worst-case scenario is when the 3.3V supply is off (zero volts), and the 5V supply is fully on. That would make the minimum resistance around 175 ohms = (5.0 - 0.7)/25mA .

[Dekatron42]

Thanks for the link on the TI document.

I agree that in this particular circumstance it is probably not a latchup condition.

In one specific case I came across recently I never dug deep enough to check if it was a proper latchup or not but it certainly looked like it as it pulled the 5V line low. The case was with a TI PCF8574 which was hooked up to the same 5V line as a PIC processor, the PIC processor started to communicate with the PCF8574 on the I2C bus at some 1.8V and then the TI PCF8574 went bonkers, pulling the 5V line to some 2.5V. If I replaced the TI part with an NXP PCF8574 everything was just fine (the design had used the NXP parts for many years without a problem but as soon as the TI parts were used the problem started to pop up intermittently). It was also fine if I let the processor wait until the voltage had reached some 4.85V with a POR ic. I didn't dig further into problem after I added the POR ic to the circuit. Instead of using the TI PCF8574s I made SOIC to DIP adapters and continued to use the NXP PCF8574, but I still use the POR ic as a precaution if NXP change their design in the future and also as a good measure.

/Martin