Validating data line signal rise time in production??? ......... - Page 1
Forum section: electronics / projects

author: Smokey
author_rank: Super Contributor
timestamp: February 08, 2024, 09:58:35 pm
content: I'm putting together a production functional final test setup for a new product that has many 5V data output lines, with a minimum data rate of about 1MHz.Because of the protection circuitry on those data lines, each has it's own RC and associated protection diodes. I'm expecting a certain rise time based on the components selected that will both meet the minimum data rates and also maintain protection for the drivers.The problem now is... how do I automate the validation that each data line has the correct components installed?Thoughts:1) I could just send the data lines into a receiver on the fixture and confirm the data is not corrupted, but that leaves the possibility that the rise times are too fast and the protection would not work.2) I could apply the worst case survivable over-voltage condition into the data lines and check if it broke stuff, but that would not confirm the minimum data rates are met.3) I could combine both 1 and 2, but that's a lot of multi-channel circuitry and switching.4) I could capture the analog waveform and run external analysis to confirm risetimes, but that requires an additional piece of test equipment and switching/processing in the fixture system.What's the "right" way to do this that minimizes complexity and test time for the setup?

author: David Hess
author_rank: Super Contributor
timestamp: February 09, 2024, 03:30:02 am
content: Universal counters can measure rise and fall time, but maybe there is a better way.I might attach a window comparator to each output, which will return a pulse with a width inversely proportional to rise or fall time.I think a better way however would be to monitor the output as the frequency is increased. At some point the output will become slew rate limited and stop switching, and then the frequency gives an idea of the time constant of the output network.

author: nfmax
author_rank: Super Contributor
timestamp: February 09, 2024, 07:09:42 am
content: You could try using the mask test function on a suitably equipped DSO - it’s exactly the sort of thing mask testing is designed for. Be careful with your trigger source though.

author: fourtytwo42
author_rank: Super Contributor
timestamp: February 09, 2024, 07:23:29 pm
content: Most of your tests would be validated at the prototype stage not in production. As far as the wrong components being used that is down to the assembly process and quality control, not unit test.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: February 09, 2024, 07:30:51 pm
content: Quote from: Smokey on February 08, 2024, 09:58:35 pmYou could sense the rise at two levels, and gate a counter or gate a current source into a cap.A fast dual comparator is one way.Or, you could use CMOS parts chosen for different thresholds - like 74HCS14 and SN74LV6T17 families.Those will switch just over 1V apart on a rising edge.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 09, 2024, 09:02:13 pm
content: Quote from: fourtytwo42 on February 09, 2024, 07:23:29 pmThis. It's an organizational problem, not an electrical one. If your assembler isn't putting parts where they're supposed to, that's their problem, not yours. I would consider such boards as production fallout, to be addressed by optimizing yield. Whatever steps that entails: following components, reels, magazines, etc. more closely (improve documentation, paper trail, tags, barcoding or RFID, etc.), better training, tweaking machine settings or debugging the controls or parsing of files, etc. Optical inspection of boards during assembly, after soldering (esp. AOI, and x-ray if applicable), etc. Automated test of easier-to-measure parameters that can infer other component values (say the R gets swapped, a simple DC test will suffice; obviously you can't tell if the capacitor did aside from risetime or AC impedance probing).Soldering errors are (should be?!) much more common than swapped components, and they should be mostly detectable by AOI.Unless your application / customer / client has unusually stringent test requirements, like every article has to meet EMC, not just a production proof test. In which case, they'll be expecting the increased testing cost, and yeah, mask test with an automated scope is the way to go. Plus a big switch mux for all signals being tested.Tim

author: MarkT
author_rank: Frequent Contributor
timestamp: February 09, 2024, 09:10:23 pm
content: Quote from: fourtytwo42 on February 09, 2024, 07:23:29 pmThis _is_ quality control!

author: wraper
author_rank: Unknown
timestamp: February 09, 2024, 09:18:41 pm
content: Quote from: fourtytwo42 on February 09, 2024, 07:23:29 pmComponents may be wrong, missing or tombstoned and circuit still seem to operate properly on a first glance. Checking every unit helps to catch such issues.

author: Smokey
author_rank: Super Contributor
timestamp: February 11, 2024, 05:39:25 am
content: Great feedback.I'm much less concerned about actually wrong components. While I have had that happen it was because of mislabeled parts not because of machine errors necessarily. I have had assembly issues with 180 rotates parts from a tube one time.I'm obviously validating functionality in the design/prototype phase. I'm more worried about missing or unconnected diodes and caps, where the circuit would appear functional but not have adequate protection. I agree that AOI should pick those up, but I've seen other stuff get through AOI before.You could make a lot of statements about "simple" assembly stuff you shouldn't need to test, like user connector soldering joints who's signals could have very well been tested with pogo pins on test points. I feel like those are the things a final functional test is supposed to catch.Mask test in-instrument is interesting since it requires no data processing, but I need multi-channel analog switching into a scope.The different family/threshold inverters or maybe comparators is pretty creative. It essentially swaps an analog measurement for a time measurement. Cool idea.I'm going to have to think about this one a bit.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 11, 2024, 07:59:59 am
content: Well uh... just how many are you testing in design/proto phase? If it's not sufficient to just test everything by hand, Idunno, that's a pretty damn big batch of protos to justify a test fixture and programming.Not to say it doesn't happen, there exists products with many stakeholders who need prototypes; but these are also uncommon, and the expense of hand testing is easier to justify. Making a whole test fixture just for doing a single batch and that's it (andmaybefuture production if the proto miraculously goes into production (nearly) unchanged), less so.Also, the recontextualization: is it the right question to be asking? How aobut incorporating self-test features in the board? More design time, less testing time. Almost certainly takes more time programming it, and probably there's increases in cost from more interfaces, IOs, maybe more chips, but it may also be that this is acceptable.Tim

author: Siwastaja
author_rank: Super Contributor
timestamp: February 11, 2024, 08:04:20 am
content: General manufacturing quality control + AOI for missing/tombstoned parts or solder issues. No one actually measures signal rise times unless it's a critical aerospace assembly or something like that. You can manually measure one per batch to see if correct reel of passives was used. It is very very unlikely that a P&P machine picks part from the wrong feeder such that isolated units from otherwise functioning batch get wrong value capacitors.If you still want to do it, many modern-day oscilloscopes can do it: you can specify reference envelope and get a PASS/FAIL output if the measured signal stays within the envelope. So you just do bed-of-nails or motorized CNC probe and one-by-one connect a function generator to an input, and connect the oscilloscope, using a pogo pin, to the test pad you added on the PCB just for this purpose. You control the function generator and the oscilloscope through their GPIB/whatever interfaces and get pass/fail.

author: Smokey
author_rank: Super Contributor
timestamp: February 11, 2024, 09:13:52 am
content: Quote from: T3sl4co1l on February 11, 2024, 07:59:59 amI'm making a Production fixture setup that programs, calibrates, and functional tests the boards... in production...

author: T3sl4co1l
author_rank: Super Contributor
timestamp: February 11, 2024, 10:52:37 am
content: Quote from: Smokey on February 11, 2024, 05:39:25 amAh; this could be read multiple ways. I read it as "obviously I want to validate prototypes", on second look, the more likely reading is "obviously, I already did that".Tim