Dynamic Signals

 

Lesson Learned: Dynamic signals have multiple dimensions that must be measured to ensure they are behaving as expected. Make sure this is in your development plan.

Key Point: Just because something powers up and works does not mean that it is working as intended. There is a spectrum of signal quality, from marginal to as-designed. It's no different from measuring all the blueprint dimensions of a physical part.

Example: Incorrect clock speed causes 10% of messages to be dropped. This results in glitchy behavior, and the increase in traffic due to resent messages affects the behavior of a seemingly unrelated system.

Risk: Failing to verify signal integrity can lead to excessive wasted time trying to track down intermittent problems that don’t make sense. 

In theory, we have a nice square digital signal that goes from 0 to 5 V instantaneously. In reality, it may range from 0.5 V to 4.3 V and take XX nanoseconds to slew and then overshoot by 2 V and ring for a while. 

With many communication signals, both the sender and the receiver need to be using the same timebase. If the two clocks are out of time, by the time the sender gets to bit #50, the receiver might be expecting bit #51. The mismatch results in lost messages and increased bandwidth consumption.

Practical Steps for Engineers:

• Simulate Low-Quality Signals: Inject low-quality signals to verify the performance of intended receivers.
• Characterize Signals: During the design phase, evaluate and characterize all signals to define what a “good” signal should look like. Verify these with simulations and actual hardware.
• Use Oscilloscopes and Logic Analyzers: These tools give visibility to otherwise invisible signals.
• Engage Design Engineers in Testing: This opens their eyes to the reality of signal quality.

Questions:

• Equipment Readiness: Do we have the right equipment to measure all the signals? If not, start acquiring it; some pieces may cost more than expected.
• PCB Design Process: What is the team doing to accommodate the tests outlined in the FMEA? (Add test points or software features to access key signals. Failing to do so can add significant time and effort for the test group.)
• Test Group Involvement: Who from the test group is reviewing the FMEAs and PCB layouts? What are their requests for signal access? What is being added to the software to accommodate testing?
• Test Plan Leadership: Who is in charge of the test plan to verify signals when the boards are up and running? Are they QCC*? Where is the test plan? Is it integrated into HIL?
• Noise/Error Sources: Are tests being run with and without noise/error sources and different use cases (battery charging, running fully loaded, no load, etc.)?
• Signal Integrity Checks: Please show where in the test plan we have signal integrity checks.

*QCC: Qualified, Competent, and Capable