Owon SDS7102 No Trigger on both channels; request for help!

[beecurling]

Hi,

I have a problem with my Own SDS7102V (additional Display VGA out over SDS7102). When I was measuring in a 5V circuit (PWM modulator out of a quad comparator) the edge trigger on both channels stopped working. I wanted to access the cursor menu, but I pressed the wrong button(s) - I don't know which exactly. There is a documented issue where apparently edge trigger stopped working after entering the save menu [1]. I tried the slope trigger and lo and behold: the scope triggered. Going down that trouble shooting road I tried to contact Owon (never heard back), I tried to contact the TO of the aforementioned thread (no response), so I started to reset the scope, run self calibration, restore factory defaults and firmware upgrades in different orders - no joy.

Finally, I gave in and took the scope apart. Since both channels are affected, I assume the problem is within a circuit shared between both channels.

I based my debugging on the work Christer Weinigel, who I believe is also active in this forum, and another forum member, tinhead, who reverse engineered the AFE of his scope [2]. Christer got Linux running on the scope [3] and did a lot of work figuring out the digital connections (busses, control signals) [4].

Sidenote: My AFE is different from what tinhead drew. I have neither a ADA4817 nor a ADA4932 in my AFE. Well, at least I could not find it and there are just so many ICs. Instead I have a double diode (I believe), a transistor and an unidentified device with 3 pins, and an additional AD706 in my AFE, that are not in the schematic of tinted. Christer has, as far as I can tell, the same AFE-revision as my scope, although his blog identifies UB and UC as o ADA4817 [4, 5]. But if you look close at the photograph of the PCB you can even make out that the marking of the supposed ADA4817 actually says AD706J [6]. Just an oversight/copy&paste error, I'm sure, but for the purpose of this debugging I felt I needed to clarify, just in case the error/bug is indeed in the AFE. I don't think so, because it would be funny, if the AFEs of both channels broke at the same time, but I'm not an analog expert …

Anyway, from Christer's blog post [4] I started to draw a block diagram and started to measure in the scope. My supposition was, that it likely had to do with something that is shared between both channels. I identified following shared components: the trigger level DAC BU2506FV [7] (setting the trigger level), the trigger comparator ADCM562 [8], the signal voltage offset DAC DAC8532 [9] and dual opamp AD706J [10] for buffering the the two voltage offsets, from Christer's writing. With additional measurements I finally arrived at the following block diagram:


 
From this point I started prodding inside the scope to figure out how it worked. Here is what I found: As noted by Christer, the scope uses LMH6518 [11] variable gain amplifiers (VGA) for signal conditioning. The main output of those VGAs goes directly to the ADC, from there to the FPGA, SoC, and finally the screen.
Because the scope displays the signal just fine, i.e. voltage is correct, time base is correct, voltage offset works, changing DIV/V works, … I assumed at this point that the main signal processing part, i.e. AFE->VGA->ADC->FPGA->SoC was fine. Nevertheless I wanted to rule out the signal offset voltage DAC DAC8532. For this purpose I hooked another scope on the digital input pins and captured the configuration command of the DAC, as I changed the offset voltage. The DAC output voltage matched the commanded voltage on both channels. This was expected, since I could see on the screen, that rotating the offset voltage knobs was having the intended effect of moving the signal on the screen up and down.

I started looking into the (edge) trigger circuit.
Sidenote: I believe slope triggering is done in the FPGA, because it requires analysis of the signal waveform. This would also explain, why the slope triggering function was unaffected.

The VGA has an auxiliary signal output, which is specifically intended for trigger circuits in oscilloscopes. Indeed the (edge) trigger circuit is fed from this output. This auxiliary output is also differential. Common mode voltage on the main signal output as well as the auxiliary output is set to 1.31V. This is in line with the common mode voltage of the ADC (1.26V - 1.33V), derived from a band-gap voltage reference.
(Sidenote: The bandage voltage output on the ADC measured 1.91V, which had me flustered for a minute. But the ADC data sheet revealed that the bandgap voltage output can be pulled to supply voltage to enable a stronger LVDS drive signal. The ADC has no common mode voltage input.)

I reverse-engineered the trigger circuit from the VGA. It seems only the positive leg of the differential signal is used for edge-triggering. The only thing which I noticed is that the common mode voltage of auxiliary output of the VGA is set to 1.31V, but on the auxiliary output I measured a common mode voltage of 1.25V. I don't know if that is relevant, though. I don't think so, but read on …
The trigger multiplexer LMH6574 [12] selects between the different edge trigger signal couplings: AC, DC, HF, and LF. They are all derived from the VGA output and simply generated via R/C filters or capacitive coupling of the trigger mux input. The trigger mux output driver has a 2x amplification, which I guess makes sense, because using just one leg of the differential VGA output signal essentially halves the signal, because the full signal would be difference between the positive and negative leg. I could not find any "proper" differential-to-single-ended conversion between the VGA and the trigger mux. The traces there are pretty visible, there are no chips with unknown functions and measuring the DC input signal to the trigger mix is the same signal that comes out of the positive leg of the VGA.
The 2x amplification of the trigger multiplexer output, results in a common mode voltage of 2.5V. This makes also sense to me, since the trigger comparator is a PECL device fed with 5V. This means a signal offset of 0V (zero volts of the signal are mid-screen at 0 DIV), results in a single-supply trigger signal of 2.5V.
Now I started feeding in the 5V 1kHz square wave from the probe compensation output, with the scope set at 1V/DIV. This resulted in a 1kHz 500mV square wave appearing on top of the 2.5V common mode voltage signal. This signal was also reaching the trigger comparator on both channels.

Now I knew how the trigger signal was generated and had a rough understanding of the signal path before the trigger comparator. The other input to the edge trigger comparator is of course the output of the trigger level DAC. Remaining in the 1V/DIV range I measured and changed the trigger level voltage. It changed 0V to 0.5V. Since the comparator input were never crossing, the comparator never generated a trigger signal.

Next, I did a bypass test. Between the trigger level DAC and the trigger comparator is an RC-filter. I desoldered the series resistor. This allowed me two tests: (1) measure the DAC output voltage when the DAC output is unloaded. The output voltage remained at the measured level. (2) I could feed an external voltage to the trigger comparator. Feeding an appropriate voltage of 2.6V (100mV above the common mode voltage) in fact resulted in triggering at the output of the trigger comparator, as well as a stable wave form on the screen of the scope! The plot thickens …

I confirmed the result of the bypass test by using the AC coupling for the trigger signal. AC coupling should remove the DC component and let only spikes at the edges of the square wave through. This was indeed what I found at the input and output of the trigger mux. With the trigger AC-coupled triggering also worked, because the trigger signal was now crossing the trigger level voltage.

Next, I validated the output of the trigger level DAC against the commanded value from it's digital interface - it matched! Now I am stuck, because the signal input to the trigger comparator is seemingly correct and the input from trigger level DAC also. Maybe it is a software issue after all and the trigger level DAC is configured for the wrong output voltage?

After all, what does the trigger level DAC output, when I set the trigger level negative? Up until now I only varied the trigger level in the positive direction, since I had a 0-5V input signal. When I moved the trigger level negative, the DAC output voltage jumped to 4V, it's reference high voltage. Increasing negative trigger levels caused the DAC output voltage to slowly decrease from 4V. Increasing it in the positive direction again, caused the DAC output voltage to rise, until it wrapped around to 0V and rising from there to 500mV again. Could it be that turning the trigger level adjust simply increments and decrements the value, with which the trigger level DAC is being fed? That would explain the wrapping around. It seems that the trigger level DAC configuration is "missing" the 2.5V DC-offset.

One funny thing I noticed is that the trigger level DAC output only wraps around when the trigger level crosses the 0 DIV mark (mid screen), not the signal level 0, in case the signal has an offset. I guess that makes sense, but my brain is mush after days of debugging this …

At this point I would like to thank whoever read this, that you have stuck around so long! I feel like I'm at the end of what I can debug. I could find no defect, yet the scope does not work properly. I know why the edge trigger does not work (trigger comparator input level do not cross), but I don't know why: is the signal offset wrong, is the trigger level DAC broken (unlikely, but I may have made a mistake …), or is the trigger level DAC configuration wrong?

Do you see any mistake I may have made so far? What else could I measure?
Maybe a brave soul with a working edge trigger is willing to open his/her/their instrument up and provide me with known good measurements?

Other ideas? Anyways, thanks again for reading this, I appreciate any help I can get. I hope I described clearly what I did and why. This is shortened account of my measurements, as I got lost in reverse-engineering the AFE … If, despite my best efforts, there are things unclear or you have suggestion or questions let me know!

PS: Full disclosure: I cross-posted from the german mikrocontroller.net forum: https://www.mikrocontroller.net/topic/515080

[1] https://www.eevblog.com/forum/testgear/owon-sds7102v-trigger-issue/
[2] https://www.eevblog.com/forum/testgear/review-of-owon-sds7102/msg65573/#msg65573
[3] http://blog.weinigel.se/2016/05/01/sds7102-hacking.html
[4] http://blog.weinigel.se/2016/05/27/another-look-at-sds7102-hardware.html
[5] http://blog.weinigel.se/images/2016-05-27-another-look-at-sds7102-hardware/main-back-afe.jpg
[6] http://blog.weinigel.se/images/2016-05-27-another-look-at-sds7102-hardware/main-back-large.jpg
[7] https://fscdn.rohm.com/en/products/databook/datasheet/ic/data_converter/dac/bu2506fv-e.pdf
[8] https://www.analog.com/media/en/technical-documentation/data-sheets/ADCMP561_562.pdf
[9] https://www.ti.com/lit/ds/symlink/dac8532.pdf
[10] https://www.analog.com/media/en/technical-documentation/data-sheets/AD706.pdf
[11] https://www.ti.com/lit/ds/symlink/lmh6518.pdf
[12] https://www.ti.com/lit/ds/symlink/lmh6574.pdf

[Doddy883]

Hey, I need to open my SDS7102V up anyway, as the case isn't aligned properly since I had it apart to sort the sloppy rotary encoders. I can't say I know much about AFEs and the triggering mechanism you've described, but I'm happy to check some voltages for you. You'd need to explain exactly what pins / components you want checking, and I don't have another 'scope to observe waveforms so it will only be DMM measurements.

First I'll need to make sure my edge triggering works- I've only used level triggering up to now. I'll verify that in the next few days.

[beecurling]

Oh, that would be awesome! I'll make up some pictures with what to probe!

I had problems with my rotary encoders as well. Caps helped a bit, but not much. I ended up desoldering the encoders and opening them up for cleaning. Contrary to what I read in the forum, cleaning them didn't help much and made them "crunchy" as there is less/no lubrication between the wipers and encoder disc. What I felt had the best improvement was opening them up and bending the wipers towards the encoder disc, so they make better contact. Additionally, there is sort of a spring washer behind the encoder disc, that presses the encoder disc on the wipers. I bent that up a bit too, to increase contact even more. That really helped a lot, although not all encoder were perfect. Now, together with the caps, all but one encoder are actually usable, some even without caps.

I have to say that my encoders were already bad when I got the scope new 5 years ago and they might be an extreme case.

[beecurling]

I wrote a little guide on how to set up edge triggering as well as setting up the channels on the same settings I use. This is important, so that comparing measurements actually makes sense, since they change with settings.

I’m not sure if you already know this, I think you do, but just in case you don’t a little guide on how to test/set up edge triggering:

You can do that with the scope still assembled to minimize the amount of monkeying around with bare PCBs as much as possible.

I think the easiest method to check/set up level triggering is using the probe compensation labelled „PROBE COMP“ on the lower right of the front panel. Connect the probe to the upper prong.
Set up channel 1:
- Press „CH1“-button to enter the channel 1 menu, if it is not open already.
    - Set „COUPLING“ to „DC“
    - Set „INVERTED“ to „OFF“
    - In the sub-menu „Probe“ set „Attenu“ to „X10“ (and make sure the slide switch on your probe is in the „10X“ position, too) and check that „MeasCurr“ is set to „NO“
    - Set „Limit“ to „full band“
- Press the „VERTICAL POSITION“ rotary encoder of channel 1 to reset offset of the channel to the zero position. The channel 1 zero-indictator (little red arrow-label-thing labelled „1“ on the left side of the screen) should now be in the vertical center of the screen.
- Set VOLTS/DIV to 2V/Div

You should see now a square wave of some sort on your screen. The wave may be jumping around or running from left to right or vice versa. Let’s set up triggering:

Go the trigger menu, by pressing the green „Menu“ button in the Trigger-section of the front panel. On the bottom of the screen there is a row with settings
- Set the type to „Single“ with the buttons to the right of the screen and the „TrigMode“ to „Edge“ with the multi-purpose knob.
- Set the „Source“ to channel 1 by selecting „CH1“.
- Set the „Coupling“ to „DC“, if it is not set already.
- Set „Mode“ to „Auto“ and press „Holdoff Reset“ if „Holdoff" is not „100ns“
- Slope does not matter

Press the 50% button, which is in the „Trigger“-section on the right side of the front panel.

A couple of things should now have happened (If I didn’t forget something while writing this ):
- The waveform should now be stable on your screen.
- Just below the bottom right of the waveform there should be a little field with a „1“ in a red circle, a rising or falling edge indicator (depending on the „Slope“ setting earlier) and a voltage display which should be reading somewhere between 2.46V and 2.54V.

So far so good. Before opening the scope set VOLTS/DIV to 1V/Div and then configure channel 2 the same way, so when the scope is opened up, everything is already set up.

It’s not a problem that you only have a DMM, I’m interested in static voltages anyway. For the measurements leave the BNC connectors simply open (no probe). This also makes handling the PCB on the bench … less awkward.

I’ve made a picture with points to measure (courtesy of Christer Weinigel). You can find the original, uncropped picture here: http://blog.weinigel.se/images/2016-05-27-another-look-at-sds7102-hardware/main-front-large.jpg in case you want or need to see something that is obscured by my lines. I had to crop the image to meet the size requirements for forum uploads.

Most signals are available on a number of components. It does not matter where you measure them. Although checking that they have the same voltage is probably a good idea.
I measured P1 and P3 on the pads of the resistors close to the shielding. That is R113 for channel 1 and R112 for channel 2. I found that location is fairly ok to access.
P2 and P4 I measured on the pads of the resistors R121 (channel 1) and R114 (channel 2) but you can use any of the marked pads, if they are easier to reach in your setup.
R is only available on this one pin of the unlabelled IC, as far as I know, but it is relatively easy to reach, since it is the last pin in the row.

All measurements are against ground. I’d use the inside edge between the PCB and the shielding to rest the probe. This way, the ground probe is relative secure against slipping. Or maybe you want to solder on a short piece of wire on the the edge of the tin to be able to clip in the ground lead, so you don’t have to hold it … there are a 1000 ways

The easiest is point R. This is a 4.096V Reference voltage. Measuring this pin is just a sanity check. You can check your DMM against it

Points P1 and P2 are for channel 1, points P3 and P4 are for channel 2.

I’ve made a spread sheet with measurements that would be helpful for me and to make it easier to keep track of things for you. I hope you can open it and it works for you since I made it with Numbers on a Mac. You can fill them out on the computer, or print it, fill it out and photograph it, it doesn’t really matter. It is mostly there to make things easier for you.

Basically I would like to know the different voltages on the marked positions P1 to P4 for different settings of vertical position and the trigger level (remember to select the correct channel to trigger on in the trigger menu).

I understand if you don’t want to make all the measurements - it’s quite a lot! I guess the minimal set useful for me is for channel 1:
   - 0 Div  with all trigger levels
   - +/- 2 Div with trigger levels 0V, 2V, and -2V
et me know if things are unclear or you have questions.

Again, thanks a million for volunteering to do this!

Oh, two things on setup:

(1) Power supply: I use +8.4V and -7.3V on my lab power supplies to power the scope. But there are different options:
- Power the scope using mains power. This is somewhat cringy, since you have main voltage open in the power supply. Only do it, if you know what you’re doing.
- Power the scope using the battery, if you have it.
- Connect a lab power supply with +8.4V to the battery terminals. The scope will generate -7.3V internally.
- Use a lab power supply for both, 8.4V and -7.3V. I choose this route, because it saves me from having the power supply PCB on the bench too.

(2) Cooling: In the beginning I didn’t hook up a fan when working with the PCB. I added one only, when adding JTAG and the scope was running 24/7 creating memory dumps and the like. For the measurements I think you’re going to be fine without a fan.

[Doddy883]

The mean voltage checking the probe comp is a little low (see attached) but I'll crack on anyway. Checked with my UTG962 too - still read low.

Leave it with me!
Doddy

[beecurling]

Hm, indeed. That's odd. But for probe compensation the level does not really matter. Maybe the ADC is off, because the scope is not warmed up yet?

Anyway for the important measurements it doesn't really matter, since no probe will be connected for them.

[Doddy883]

OK all done, results attached. Formatting did go a bit weird so I saved it as a PDF too. If that helps at all, please share your fix - in case mine goes wrong!

Cheers,
Doddy


EDIT: Just to add, most of this was done with a nearly new Brymen BM789, and I cross-checked a few times with my Flir DM66. Neither are calibrated, but the Flir did say it had been factory checked.
 

[beecurling]

Looks pretty good and it helps a ton!

It also confirms that this is not a hardware issue, but a firmware issue. My advice: stay away from functions storing to internal memory. At this point I suspect that there is a buffer over/underflow issue …

I'll update you, if I have a fix or give up

[beecurling]

I've been disassembling the firmware for about a week now and I have a bit of understanding how the scope works and how the trigger voltage level is set. However, I'm not totally clear on all the details.

What I can is control the DAC from the debugger, and set an arbitrary output voltage. Doing that manually from the debugger results in a working trigger signal. From that, and the reference measurements kindly provided by @Doddy883 from a working scope (thanks again!), I'm now pretty sure that the AFE/hardware side of my scope is fine, but the error is indeed in the firmware.

Here's what I think how the firmware works and what is wrong with my scope: The state is held in a rather large memory area, which I've come to call the "config" area. But its more like the model part from the MVC or MVVM design patterns, if you're familiiar with those. Basically this region contains everything from calibration offsets, to menu settings (trigger level, signal offset, active channels) to magic numbers, as far as they are not part of the code as constants. For the large part, I don't know, what the values in that region mean, but I was able to decipher and reverse engineer a few, for example calibration offsets. Of other values I don't know what they're for exactly, but I know that they're indexed by the scale setting (V/Div) and channel number which helps me zero in on their meaning.
Part of that area is stored to flash, when you switch of the scope, so that your settings (active channels, trigger settings, network configuration) do not get lost.
Calculating the trigger voltage pulls five or six of those values from that config area.

What I think happened is that part of that configuration area got overwritting when I saved to internal storage by a buffer over-/underflow or something along those lines. That would also be in line with what others reported. However, that would not exactly explain, how switching the scope on and off resolved it … [1].
At this point I think that the code itself is fine, only that config area is compromised (but I'm not 100% sure).

At first I though I should be able to figure out the meaning of those configuration values. With the meaning of the values I should be able to tell if a value that affects the trigger voltage calculation is way off or not. However, I've spent a week on this and I'm not even close That the scope's firmware was obviously compiled without any optimizations, does not help reverse engineering either.

This is why I'm asking if something has a JTAG debugger connected to their scope and would be willing to pull that configuration area, memory dump and possibly do a nand flash dump?
Preferable with the same firmware version: 3.8 (checksum F26DB64B) and series (13129xx). You can check the firmware version of you scope by pressing the "Utility" button and then selecting "About" with the row of buttons below the screen.

Connecting a JTAG debuggger and dumping the memory has been described by Christer Weinigel in his blog [2]. However I used the following openocd.cfg, since some options in OpenOCD changed since the blog entry was written:

Code: [Select]

# FT2232H or FT4232H minimodule channel 0 (Channel A)
# Connector  FTDI              Target
# Pin        Name
# ---------  ------            ------
# CN2-11     VIO               VDD_IO (Or connect to CN2-5 on the minimodule instead for a 3V3 interface)
# CN2-2      GND               GND
# CN2-7      ADBUS0 (TCK)      SWCLK
# CN2-9      ADBUS2 (TDI/TDO)  SWDIO
# CN2-10     ADBUS1 (TDO/TDI)  SWDIO
# CN2-14     ADBUS7 (GPIOL3)   nRESET

adapter driver ftdi
ftdi_vid_pid 0x0403 0x6011

ftdi_tdo_sample_edge falling

ftdi_channel 0
ftdi_layout_init 0x00c8 0x00cb

#ftdi_layout_signal LED -ndata 0x0040
#ftdi_layout_signal nSRST -data 0x0080 -oe 0x0080

transport select jtag

adapter speed 20000
#adapter srst delay 100
#reset_config srst_only srst_push_pull srst_pulls_trst srst_gates_jtag

jtag newtap s3c2416 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x07926f0f
#target create s3c2416.cpu arm920t -endian little -chain-position s3c2416.cpu
target create s3c2416.cpu arm926ejs -endian little -chain-position s3c2416.cpu

nand device 0 s3c2412 s3c2416.cpu
init

proc dump_all {} {
dump_ram
dump_flash
}

proc dump_ram {} {
show_ttbr

dump_config config-area

echo "This should take 5 to 10 minutes"
dump_sdram_virt sdram-virt-0.bin          0 0x3c00000
echo "This should take ~1 minute"
dump_sdram_virt sdram-virt-1.bin 0x33c00000 0x0400000

echo "This should take 5 to 10 minutes"
dump_sdram_phys sdram-phys.bin   0x30000000 [expr 64 * 1024 * 1024]
}

proc dump_flash {} {
echo "This will take 10 hours+"
dump_nand /tmp/nand-dump.bin 0 [expr 128 * 1024 * 1024]
}

proc show_ttbr {} {
echo "TTBR is at: 0x[format %x [arm mcr 15 0 2 0 0]]"
}

With this config file you can just type dump_ram to only do the RAM dump, which should take 20 to 30 minutes and will output four files: config-area, sdram-virt-0.bin, sdram-virt-1.bin, and sdram-phys.bin. Addiitionally, it will print the physical address of the page table base, or Translation Table Base Register in Arm lingo, TTBR for short. It's only important if it is different than 0x33ff8000.

You can dump the NAND flash with the command dump_flash which will create the files nand-dump.bin and nand-dump.oob.bin. Unfortunately this will take 10 to 11 hours to complete. I hope I can find what's wrong with my scope with the RAM dumps alone. Having the NAND dumps too is more a belts-and-suspenders type thing. Plus, if the JTAG is already wired up one might as well …
I found that only roughly half of the flash was used in my scope, the rest was empty. Therefore I included the command dump_flash_64 which will only dump approximately 64MiB in the hope that other scopes don't use more than that. This will cut the download time in half, down to 5 to 6 hours.

I know this is a pretty specific and involved request, which requires taking your scope apart, soldering the JTAG connector to it, etc. Maybe someone has an SDS7102/V as their secondary scope and doesn't mind tinkering with it …

PS: @Doddy883: I totally forgot to ask how it went with your rotary encoders? Did you rebuild them or change them out completely?

[1] https://www.eevblog.com/forum/testgear/owon-sds7102v-trigger-issue/
[2] http://blog.weinigel.se/2016/05/06/sds7102-hacking-2.html

[DavidAlfa]

This might help :
https://www.eevblog.com/forum/repair/wons-ds7102-boot/msg1959460/#msg1959460

[beecurling]

Oh thanks! It actually did help. I was able to fix the Ext and Ext/5 trigger input sources (which I didn't even know were affected by this issue)!

I'm still working on getting channel 1 and 2 as trigger input sources working.

[Doddy883]

@beecurling, apologies, I've only just seen this.
My rotary encoders are all good except channel 1 vertical size which can be a bit iffy. At least it's useable now, couldn't really get anything done without getting angry with it before!

Regarding your last request, I think it's beyond my current capabilities. I've used and repaired plenty of equipment but never messed with the memory and software side. I've got some uni assignments to concentrate on for the next few weeks, if I find myself with some time to kill after that then I may have a look into it. I can't promise anything as the pubs reopen next week too!

[scopeman]

I know this is an old thread but I had an issue with bad encoders on my Owon SDS7102. I sent an email to their US suppor or I called them I can't remember which but IIRC I bought a replacement PCB from them what had all of the encoders and a set of new knobs (I think they changed the encoder vendor) and I think it was arount 25.00 USD. Much easier than trying to fix them.

Sam
W3OHM

[TomC]

Oh thanks! It actually did help. I was able to fix the Ext and Ext/5 trigger input sources (which I didn't even know were affected by this issue)!

I'm still working on getting channel 1 and 2 as trigger input sources working.

I'm wondering if you found a solution to the edge trigger problem, I have an SDS7102 that developed the same symptoms that you describe. I also noticed that in addition to edge not working, pulse, ext, and ext/5 are out. I can use slope and AC successfully, but wasn't able to test video for lack of an appropriate signal. I also notice, as you described, that I can get a brief edge trigger when moving the trigger level across the 0v line. So it seems that whatever is ailing my machine is likely the same thing that's happening to yours.

So far I've have tried reflashing the firmware to several older versions and then back to the latest version available for my scope ( 3.8 ). However, the same problem persists on every firmware version that I tried.

****** UPDATE:

Received two patches from OWON on 2023 2-26. The following describes my experience step by step:

1. After running the first patch (SDS7102V-EDS102CV-V5.15.0-BI) the splash screen faded and after a short time turned to solid yellow. The scope didn't reboot automatically.

2. After initiating the second patch (SDS7102V1246320) I rebooted the scope manually. The second patch hung-up on "wait for machine process". After waiting for 5 minutes I aborted the update and rebooted the scope. The scope booted to a yellow screen and kept automatically rebooting every few seconds.

3. I thought the scope was bricked, but tried running the second patch again while the constant rebooting was going on. The patch seemed to run normally this time. There were progress updates along with brief "wait for machine process" messages. The patching process ended with the "rebooting machine" message. The scope's screen was still solid yellow at this time and didn't reboot automatically. I closed the patch program and rebooted the scope manually.

4. This time the scope booted normally to Chinese language (even though I had selected English while running the patch). I changed the language to English and started testing the scope's functionality. Found that edge trigger was working properly now. The registration of the Probe Comp waveforms on the screen didn't seem normal, so I ran "self calibration" and it cleared these issues.

5. I tested all the features that had stopped working (edge trigger, Ext trigger, Pulse trigger, Autoset, Autoscale) and they are all working correctly now. I tested other common features to verify that they were not compromised. This included slope trigger, various Measures including view all, cursor measure for both time and voltage, Save waveform and settings, Help. Everything seems to be working fine.

6. The About screen now reads: SDS7102V,     S/N 1251320,  Version 5.15.0,  Checksum E200593E.
   Previously it read:         SDS7102V, series: 1246320, Version: 3.8,    checksum: BB9734B5.

7. Aside for the serial number and version number being different now (see 6 above), I noticed some changes in the menus:

   a. Measure type has several more types available now, including FRR, FRF, FFR, FFF, ... . I haven't figured out what these are yet, they
      are not described in the latest manual available for download.

   b. Measure "Show All" has 3 fewer items than before: DelayA->B]~PD, DelayA->B[~ND, and Phase~RP. However, all three are still available
      to add individually.

   c. Utility Function Output has three more items than before: Connect Computer, Connect Printer, and Print. When I press Connect Computer
      or Connect Printer I can hear my PC's USB connect sound. Print is shaded, I presume it needs a printer connected to become available,
      but I haven't figured out how to do that yet. These new menu items are not documented in the latest manual available for download.