Detect signal ringing

[Leopoldo]

Hello everyone,
I'm starting a project where a microcontroller will use its ADC to record an incoming signal, coming from a transmission line under a serial communication stimulus, and analyze it in order to measure rough "transmission quality" parameters like:
1. average/peak voltage for high and low communication symbols
2. spikes, other form of noise
3. rise/fall time
4. ringing (impedance mismatch)

I'm only at the "concept" phase; I have a couple of ideas for the first 3 metrics, but I'm having trouble figuring out a valid method for detecting the last one, ringing.
The issue is that I'd like to detect the phenomenon with a decent variability in 3 parameters: peak amplitude (i.e. overshoot), oscillation frequency and oscillation decay (I'm reducing the complexity of the problem to a 2nd order undampened system response to a step stimulus). Basically, as a human would detect ringing if it had an oscilloscope and good eyeballs.

Do you have any idea how this could be performed accurately? (Possibily, also efficiently - i.e., maybe avoid repeated convolutions with pre-defined waveforms or FFT).

Thanks!

P.S.:
I'm attaching a zip folder with some Octave (Matlab compatible) scripts containing test waveforms, if you want to try ideas.

[ajb]

This sounds like an interesting project. What sort of ringing frequency are you expecting?  And what sort of serial communication/data rate is involved?  If you could post plots of your test waveforms with at least the time axis labeled that would be more helpful than the raw scripts.

I think the highest sample rate I've seen on an MCU ADC is a few Msps -- and that was with three separate ADCs in interleaved mode -- so measuring frequency from the ADC could be challenging, although reducing the resolution might get you there.  A faster external ADC is of course an option, but at some point the data rate becomes a challenge, or at least will require a parallel interface.  Using a fast edge/peak detector and a high frequency timer might be more suitable -- timers that can operate at ~100MHz or so aren't uncommon on modern MCUs, and you can probably find a couple of ~200MHz or faster options.  Likewise, peak/amplitude measurements probably benefit from some external analog help.  Since this is a transmission line, interfacing to it without causing more SI issues by altering the impedance will require some consideration.  ADCs requires a low impedance source to operate at maximum sample rate, since sampling time is directly proportional to input impedance, so at a minimum you will need an external buffer anyway.  But the specifics will really depend on the frequencies involved.

[ajb]

Another thought: cheap DAC + fast comparator + high frequency timer could be a cheap and efficient way to get magnitude, frequency, and decay measurements, albeit over multiple events.  Sweeping the set point of the comparator and looking for events gets you magnitude, timing them gets you the frequency, and counting them per trigger event gets you the decay time.  A lot of MCUs have all three of these things built-in these days, so would need minimal external parts for one or two measurement channels.  It would be easy to expand with external comparators and DACs (or multiplexing sample-and-holds or PWM DACs with enough filtering) up to as many high frequency timer channels you have available -- having four channels would get you a lot more information over fewer cycles, and a better picture of each individual event rather than the average of many.  (Too many channels and at some point you've just done the ADC method the hard way  ) 

But that might not be the solution you're looking for, if for example doing some DSP is part of the goal of the project.

[Leopoldo]

Thanks ajb for the reply!
So:

What sort of ringing frequency are you expecting?  And what sort of serial communication/data rate is involved?  If you could post plots of your test waveforms with at least the time axis labeled that would be more helpful than the raw scripts.

No idea about the expected ringing. This is an experiment for my daytime job, where we don't have oscilloscopes available yet face constantly communication problems - that's the reason for this project.
The main protocol that I'm interested in is RS485 running at 38.4 Kbaud, so a symbol period of about 26us.
Just to be clear, I really wanted to experiment with the Pi Pico 2040 (though only if the IDE lets me get the full potential of the uC). I read in a forum that someone overclocked it to get the ADC running at 2.5Msps; for me, just having it run at 1Msps (2 channels at 500ksps, for RS485) would be already ok (so an oversampling with a factor of >10). What do you think? My requirements are quite low, even though it could become a more "professional" instrument; I'm really more focused on basic problem diagnosis.
I don't have a recording of the signals as of right now, but I will capture some in the next few weeks.

Using a fast edge/peak detector and a high frequency timer might be more suitable

Just to be clear, with edge detectors you mean the ones already present in interrupt-based digital inputs of microcontroller?

Likewise, peak/amplitude measurements probably benefit from some external analog help

Yes, I thought about a peak detector, though as you said buffering would be mandatory in order not to load the driver and thus change the behaviour of the DUT. So I might consider dealing with this also with the ADC directly.

Another thought: cheap DAC + fast comparator + high frequency timer could be a cheap and efficient way to get magnitude, frequency, and decay measurements, albeit over multiple events.

That's a very clever solution, I didn't think about it! Though yes, this requires a somewhat "periodic" signal, whereas my target protocol only has bursts of 8-12 symbols...
Come to think of it...  could an "overall quality" parameter be extracted via an analog circuit?
Let's establish - for example - that my ideal signal has 0% overshoot and instant decay, and oscillation frequency not relevant. Anything over these value gets a proportionally lower score.
Is there an analog circuit that would accept any share-ish wave, and ignore every other parameter except these ones? So as to characterize the behaviour in hardware.
I'm thinking how to isolate the problematic signal part: off the top of my head, gating the incoming signal with a hardware (or microcontroller) edge-detector (in order to remove any signal transition which is not the ringing part), then removing the average settling voltage level offset (AC coupling might not work), and finally using an envelope circuit and some sort of integrator, calculate the area of the envelope...! The higher the area, the worst the score.
Yes, this would mean a completely different architecture, but I'm questioning what would be the most reliable and accurate direction   

Please excuse the crudity of my drawing... no time to build it to scale and paint it

 

Thanks!

[Leopoldo]

Another way to do it in hardware, which may scale better with other wave behaviour, could be to implement your solution with a circuit
I.e., having an array of basic comparators, say 8, and a resistor ladder. The output could be evaluated by integrating the detected peaks to "count the crossings" and infer decay time. Then reading the values with the ADC.
One problem with this is still setting the bias for the comparators, i.e. subtract the settling voltage level (not knowing it).
The purpose of doing it in hardware would be mainly to gain speed, i.e. not having issues with sampling rates.
What do you think? 

[MathWizard]

So where do these RS485 signals come from, and where does all the noise come from, and what types ? If it's not that much, yeah maybe using hardware comparators, latches and timers, would let you pass or block certain signals.

I'm programming an ATTiny basically to act as a filter and buffer for some commands between chips in my stereo. Lucky for me, the signals aren't distorted.

Can you just add some "buffer boxes" along the lines ? IDK much about RS485, but at least your signals aren't that fast.

[twospoons]

No idea about the expected ringing. This is an experiment for my daytime job, where we don't have oscilloscopes available yet face constantly communication problems - that's the reason for this project.

The cost for your time to develop this would pay for a 100MHz 2-ch scope.

[ajb]

This does sort of sound like a problem that could be solved with an oscilloscope -- and it will be hard to validate whatever you're building without one.  So if you can purchase even a cheap oscilloscope that's probably the way to go.  It might make sense to build into a deployed product for integrated diagnostics, or could be a fun and valuable project for its own sake -- but you will still have a much easier time with an oscilloscope!

That said:  "constantly communication problems" with "RS485 running at 38.4 Kbaud".... are these signals on long wires, between multiple devices? perhaps with some excessive stubs or branches?  Because 38.4k RS485 should be very robust! 

You might be getting some ringing, especially if using higher speed transceivers on inadequate wiring, but if there's significant length involved, the more likely cause of communication woes is reflections.  Especially if the wiring is inadequate, and higher speed transceivers would exacerbate this problem.  Identifying reflections is more complicated because you'll see different things depending on where the reflection occurred relative to the point of observation, what it reflected off of, and what other waves were crossing the point of observation at the same time.  You would be looking for spurious transitions and unusual voltages as transmissions and reflections add and subtract.  At the digital level, data may be totally garbled, occasionally corrupted, or totally fine depending. 

But if you *can* measure a reflection, like with an oscilloscope, you can characterize and locate the cause of it with sufficient analysis -- this capability is commonly built into ethernet PHYs/switches, and is how those network cable testers work, and it's how faults in underground/undersea cables are located.  Or you can do some math based on the cable length and characteristics and estimate where a reflection might be coming from in a system if you don't have special equipment available. 

[MathWizard]

Ok I forgot the OP said they don't have a scope. But I think a few of the cheap "toy" scopes would be fast enough to see your 30kHz signal, in pretty good detail. But I'm not that familiar with differential signals, and probing them. You would need diff probes, or a 2-channel scope with math I suppose.

You might want to check the TestEquipment section for treads on the cheapest hobby scopes. I have a $20 one, and it can do some stuff. It's certainly better than no scope. Some of the $50-100 ones can do legit work, within their limits.

[Leopoldo]

Sorry for the delay, I've been busy at work and I had to stop all developement

This does sort of sound like a problem that could be solved with an oscilloscope

Yes, indeed, at the end of the day I realized I'm better off using an oscilloscope. But this turnaround was only possible because I found out that the RPI PICO (at least the 2040) supports the project "Scoppy" -> https://oscilloscope.fhdm.xyz/
which is an amazing project where you need at minimum 2 wires to create a fully functional 2Msps / ~500KHz bandwidth oscilloscope. This seems black magic to me... I know these uC are capable of doing this wizardries but to this extent... 
So at the and of the day I decided to use this as the main project and build a suitable front end for my needs.

That said:  "constantly communication problems" with "RS485 running at 38.4 Kbaud".... are these signals on long wires, between multiple devices? perhaps with some excessive stubs or branches?  Because 38.4k RS485 should be very robust! 

Ah yes. You are right, it SHOULD be very robust. But you spotted the problem; we are implementing it:
- on quite long transmission lines (up to 100-200 meters)
- up to 120 slaves on the same line - all created with branches from the main line (but overall a hybrid topology)
- using non-impedance controlled line
- using no generator termination and line termination
- on very different devices on the same line; some are drives (inverters), and when they are running create a LOT of interference and CM noise
- sometimes (fortunately, almost no more), non-shielded and non-twisted cables

If this sound like a recipe for a disaster, that's because it is. Fortunately, the devices we use are made to withstand these kind of situations so most of the time we have no problem. Sometimes, however, all is too much.

Ok I forgot the OP said they don't have a scope. But I think a few of the cheap "toy" scopes would be fast enough to see your 30kHz signal, in pretty good detail. But I'm not that familiar with differential signals, and probing them. You would need diff probes, or a 2-channel scope with math I suppose.

You might want to check the TestEquipment section for treads on the cheapest hobby scopes. I have a $20 one, and it can do some stuff. It's certainly better than no scope. Some of the $50-100 ones can do legit work, within their limits.

You are kind of right; we DO have an oscilloscope, but it's not battery powered (making isolating from the grid difficult), and it's quite big (it's a RIGOL DS1074Z), so not really suitable to bring to the field. Also, often we have multiple installations of said network at the same time in different locations, so 1 scope wouldn't do.
But as I said above, I may have found the solution with the Scoppy project.

One final thought, however...
I started this thread with the goal of having a simple and cheap instrument to validate the overall health of a network - meaning I wanted an instrument that "scored" the relevant parameters on its own; no use of the brain to understand what might be wrong.
I may re-open this in the future, because the oscilloscope solution is interesting and all but lacks the simplicity of use that I had in mind (this was supposed to be an instrument given to our technicians, that may not have this technical knowledge).

Thanks everyone for you support! Hope to hear from you again 

[radiolistener]

You can do it with impedance measurement bridge, RF mixers like SA612 and frequency synthesiser like si5351. The schematic is pretty simple just look at NanoVNA schematic. If you don't want to make your own schematic, you can just buy NanoVNA and write your own firmware for it.

In short, you're needs to measure impedance over frequencies and then do FFT to transform it into time-domain, in which you can see every reflection point across transmission line.

Here is my MATLAB/Octave code which doing it with NanoVNA connected to PC:
https://github.com/qrp73/NanoVNA-MATLAB

On this picture you can see impedance in time-domain result, it is was taken on coax cable in cross section of which was inserted T-adapter with 50 Ω terminator on it. As result, you can see 50 Ω impedance in the cable before T-adapter which turns into 25 Ω impedance at 5 ns delay, this is because two 50 Ω loads in parallel make 25 Ω load. 5 ns is delay in the coax cable between NanoVNA and T-adapter:



For better resolution you're needs to take frequency sweep over higher bandwidth. I recommend sweep for at least 1 GHz bandwidth for good visual results

[benseno]

Perhaps, decoding something fuzzy (p.4) could be done with recurrent neural network based time series analysis.

[tggzzz]

Perhaps, decoding something fuzzy (p.4) could be done with recurrent neural network based time series analysis.

That sounds like "if you don't know how to do something, invoke magic".

[benseno]

That sounds like "if you don't know how to do something, invoke magic".

Exactly.
But, i would rather call it statistical representation of deterministic model amid complexity of the latter.
If i am not mistaken those are already used for signal classification and radar signal processing.
Like here https://arxiv.org/html/2212.11172v3

[tggzzz]

That sounds like "if you don't know how to do something, invoke magic".

Exactly.
But, i would rather call it statistical representation of deterministic model amid complexity of the latter.
If i am not mistaken those are already used for signal classification and radar signal processing.
Like here https://arxiv.org/html/2212.11172v3

Such statistical representation and processing is done according to algorithms that is designed, can be analysed, and what inputs will cause it to do can be predicted.

LLMs are not designed but are trained (exactly like the brain), its workings cannot be analysed and LLMs can't even state why they produced the output ("an active research area"!). Thus the envelope boundaries are unknown, and what it will do cannot be predicted.

[benseno]

LLMs are not designed but are trained (exactly like the brain), its workings cannot be analysed and LLMs can't even state why they produced the output ("an active research area"!). Thus the envelope boundaries are unknown, and what it will do cannot be predicted.

RNNs are not LLMs.
CNNs are already sate of art in the computer vision object detection classification and segmentation.

[tggzzz]

LLMs are not designed but are trained (exactly like the brain), its workings cannot be analysed and LLMs can't even state why they produced the output ("an active research area"!). Thus the envelope boundaries are unknown, and what it will do cannot be predicted.

RNNs are not LLMs.
CNNs are already sate of art in the computer vision object detection classification and segmentation.

Neural networks are neural networks, whether they are implemented in wetware, hardware (e.g. WISARD), or software. They are trained, not designed.