Normal triggering problem

[marko-pi]

First of all, thanks a lot for this software. It is much better than original, especially triggering is much more stable.

However, I have problem with "normal" triggering. I am using my Hantek to observe I2C communication on Raspberry Pi. The communication consists of cca. 5us pulses between 0V and 3.3V as shown below

(Please note that two signals are offseted for easier observation.)

The problem is that in 90% of cases I2C communication does not trigger the oscilloscope/program. I don't know if I am doing something wrong or maybe there is some trick I don't know.

• OpenHantek version: 20200110 build 589

• OS: Windows 10

• Device: Hantek 6022BE

• Program top line: OpenHantek6022 (20200110 build 589) - Device DSO-6022BE (FW0204)

• Input signal: square peaks, f ~ 100kHz, Vpp ~ 3.3V

• Probe setting: probe X1

• Number of channels used: 2

• Sample rate: 12MS/s

• USB driver: WinUSB (v6.1.7600.16385)

[Ho-Ro]

Unfortunately this is a limitation of the system, it doesn't wait for a trigger but samples permanently and searches in software for a trigger. It works well for repetitive signals but fails for rare occurrences.

[Ho-Ro]

It was set to less aggressive sampling (to reduce the processor load on slower computers as a reaction to #30), but you can tweak it in the source code: https://github.com/OpenHantek/OpenHantek6022/commit/40c6f943548d396eb4da90b14641226d1552453e, https://github.com/OpenHantek/OpenHantek6022/commit/48004826a4d333f632b26cda89678b96b0daf8dd Nevertheless it's a good point - some people want to slow it down, other need full throttle. Currently you can select trigger source "CH[12]" and "CH[12] smooth" (both use the same sample repetition, smooth filters glitches), maybe I can define a more aggressive trigger source "CH[12] fast" where it samples every ms (no problem even with my 10 year old ThinkPad T400).

[marko-pi]

Can you please explain what 10ms sampling means? Does it mean that oscilloscope gets only one value of the voltage in 10ms? That would explain my problems - the whole communication lasts for 0.5 ms, which gives 1:20 chance to catch it (not considering the fact that even within these 0.5 ms, each of the channels is half of the time unchanged).

[Ho-Ro]

The HW has no data storage, so all acquired data must be transfered in real-time over USB to the PC. OpenHantek6022 samples in blocks of 20000 values, either 20000 for CH1 only at max. 30MS/s or 40000 values with interleaved CH1/CH2/CH1/CH2... 8-bit samples at max 15MS/s (for each channel). Higher speed is not reliable, the 48MS/s that Hanteks promises is pure marketing. Slower sample rates use oversampling with bigger raw sample blocks to increase the resolution and SNR. But at least the trigger detection works on 20k blocks. Both sampling and post-processing (spectrum calculation and graphic creation) use own threads. The sampling thread starts the data acquisition and checks every 10..100 ms for completeness. If a complete block is available it will forwarded to pre-processing (e.g. offset correction) and trigger point detection. With your 12 MS/s (text from above, your picture says 10MS/s in the top line) of two channels (i.e. 12 MWord/s = 24 MByte/s) the transfer of one 40k block takes 17 ms. The trigger point detection looks for an edge in this block starting at a position that allows to display a full screen with pre-trigger content and correct trigger point. To typically display 10000 points on the screen, it takes the 20000 block and throws away enough samples so that the trigger point is correctly aligned with the trigger mark on the screen. Read the fine doc: https://github.com/OpenHantek/OpenHantek6022/blob/master/openhantek/readme.md#data-flow Read the real doc™: https://github.com/OpenHantek/OpenHantek6022/blob/933cde9fc158e0b84d8fbf505f70a0a2a71c0829/openhantek/src/hantekdso/hantekdsocontrol.cpp#L575

[marko-pi]

Thanks for the answer. I don't quite understand all the details, but I suppose that the sampling procedure is idle between the time sample block is finished and the time sample block is forwarded to post-processing. This could be reason why triggering event could be overlooked.

But what I find instructing and alarming in the same moment is that you can miss the triggering event if timebase is too large: timebase 20ms could never find triggering event if sampling time is 17ms - you should put that in manual! In fact one should use shortest possible timebase 10ns so that least possible amount of data is disregarded while looking for a trigger and expand timebase later to show the whole event. This makes the fancy idea of full screen signal obsolete - I'd prefer that the whole block is searched for the event even if that would mean that part of the screen remained without signal.

I would also like to point out that (at least) in case of Windows 10, vast majority of the processor load comes from the graph creation. For my computer "normal" triggering loads 5% of microprocessor, while "auto" triggering loads 20% of microprocessor. This can increase up to 40% for full-screen window.

[Ho-Ro]

vast majority of the processor load comes from the graph creation

Yes, but every time new data is available (triggered or not triggered) a new graphic is created to keep the display responsible -> (Another idea that I can check: drop some frames if not triggered but in high speed mode)

shortest possible timebase 10ns

This doesn't speed up sampling, it's only the screen display (it shows only three dots on the screen 33 ns apart) because the maximum sampling rate is 30 MS/s, either 30 MS/s for CH1 only or 15 MS/s per channel when using CH1 & CH2 (or when only CH2 is used, as both channels are then sampled due to the HW structure).

Three additional remarks:

1. You have a I2C clock of ~ 100 kHz, so 1MS/s or even less should be sufficient ; if you sample not so fast you get a 10x longer sample block, maybe worth a try - you can then use the zoom function to increase the
2. If you want to debug protocols I would strongly propose sigrok (together with a cheap saleae clone for ~10€ / 10$). The pulseview program from sigrok has an I2C decoder and a higher level of understanding for special I2C chips.
3. Last but not least I use the scope mostly for audio frequency measurement up to < 1MHz, so I have low frequency and - more important - stationary signals where I look at amplitude (therefore the RMS calculation) and the spectrum.

[marko-pi]

Timebase doesn't speed up sampling but according to this

https://github.com/OpenHantek/OpenHantek6022/blob/933cde9fc158e0b84d8fbf505f70a0a2a71c0829/openhantek/src/hantekdso/hantekdsocontrol.cpp#L575

part of the data block -- in total length of 10 x timebase equalling display width -- is not searched for trigger event. Probably in order that the whole display shows the signal. This means that if a data block is shorter than 10 x timebase, no trigger event can possibly be detected. Larger timebase, bigger problem. Or have I misunderstood something?

EDIT: Ups, I just realised that timebase and sample rate are interconnected within the program. This solves part of the problem I mentioned above. Or does it? For example, default value for 100us/div is 10Ms/s, which means according to my calculation 10k samples on the screen. This means that half of the samples would not be searched for the trigger event.

ANOTHER EDIT: Please note that your calculation was wrong. 20k samples at 12Ms/s is just 1.7ms and not 17ms. Which means a lot of data is thrown away checking data blocks only every 10ms. Plus half are wasted by trigger search - no wonder it is pure luck to catch I2C event. My rough observation of 10% success fits surprisingly well with those data 1.7s/10s/2~9%.

Anyway, thanks for the suggestions. As an amateur I am using oscilloscope for various reasons and I am analyzing I2C and other signals only occasionally, so I do not intend to buy an extra device just for that.

Smaller timebase with manually reduced (non-default) sampling rates might be a simple patch, but I still look forward if you could introduce more aggressive sampling in some future version.

[Ho-Ro]

You're right, it was my fault with the 17 ms. The 50% sample waste is only valid if you display full 10k samples, you can choose the appropriate timing and lower the sample rate manually. This way the time for one screen is preserved, while the sample buffer covers more time than 2*screen. Example: Select 100µs/div -> Display size = 1 ms. The scope automatically selects 10 MS/s (this corresponds to a buffer size of 2 ms, 1 ms is omitted for trigger search), you can reduce it manually to 1 MS/s, the 100µs/div setting doesn't change (this corresponds now to a buffer size of 20 ms, but still only 1 ms is omitted for trigger search):

// |-----------samples-----------| // available sample
// |--disp--|                      // display size
// |<<<<<T>>|--------------------| // >> = right = (disp-pre) i.e. right of trigger on screen
// |<pre<|                         // << = left = pre
// |--(samp-(disp-pre))-------|>>|
// |<<<<<|????????????????????|>>| // ?? = search for trigger in this range [left,right]

One last comment about your

half are wasted by trigger search

They are not wasted, but serve an important purpose, because the scope does not know what you want to see, either the signal after the trigger or the trace before it. What does it help to search the complete 20000 samples in the buffer and detect your I2C trigger condition at position 19999 - what shall be displayed? This software trigger is the consequence of the limited Hantek hardware.

I use automatic downsampling if possible, in this example the scope samples internally still with 10 MS/s but downsamples 10:1 (it averages over 10 samples) which gives >9 bit resolution and a 10 dB better SNR (read more).

I'm currently experimenting with an aggressive acquiring (which itself doesn't burn too many CPU cycles) and at the same time a more relaxed post-processing (calculate spectrum and render the graphics), which is the bigger CPU cycle hog.

[marko-pi]

Faster sampling you intend to do will definitely be a big improvement.

And after reading the code I am aware of the tweak that can be used to improve detectability of rare events. What I suggest is that this information is included in the manual - e.g.

1. number of samples is N=20k
2. number of displayed samples is M=10timebasesampling rate (also displayed above the display)
3. trigger event is looked for in N-M samples Conclusion: in order for better detection of rare events use smaller sampling rate for a given timebase.

[Ho-Ro]

Anyway, thanks for the suggestions. As an amateur I am using oscilloscope for various reasons and I am analyzing I2C and other signals only occasionally, so I do not intend to buy an extra device just for that.

I'm not a salesman, but this small piece of electronic is so incredible useful even for the amateur - what do you do if you don't have I2C but SPI with three signals? Also the scope shows only the physical layer and you have to count bits and calculate values by hand. The pulseview program knows the protocol and decodes it for you. But even if you don't want to use the simple logic analyser board, pulseview can help you because it also supports Hantek6022 as a data source and you can stack the appropriate decoder (analog to logic level / I2C decoder / chip specific decoder) and display fine pictures :)

IMPORTANT If you used your Hantek with pulseview you must disconnect/reconnect it before using it with OpenHantek6022 because pulseview loads a different firmware with different USB VID/PID.

[marko-pi]

This thingy is so cheap I will buy it and test it. Just for a fun. Thanks for a tip.

I should also add that last time oscilloscope helped me find incorrect communication. I wonder if this thingy can do that to.