Firmware source bug report thread

[qu1ck]

So I finally got some time to look deeper into the firmware source.

I already found the issue with the encoder and why it's skipping detents.
This table is not right: https://github.com/JYEtech/DSO-Shell-op ... mand.c#L63

There should be 4 positions which rotate CCW and 4 that rotate CW, currently there are only 2 each.
I'll try to verify this and maybe submit a patch whenever I get to it.

Will continue posting any new findings here.

[Petroid]

Nice one!
Maybe you could look into this http://www.jyetech.com/forum/viewtopic.php?f=19&t=1183 really annoying bug, JYE said they will patch it quickly but they still haven't done so. It looks to me that bug is in that lib they refuse to open-source but I might be wrong lol

[jye1]

We are about to release a new version firmware which implemented a "workaround" for the encoder "skip" problem. By pushing ADJ you toggle ON/OFF the "fast adjustment" mode. Under fast adjustment mode VPos, HPos, and Trigger level can be moved faster. The mode is indicated by a ">>" sign appearing on top of screen. Attached please see the code.

113-15001-061.zip

(48.72 KiB) Downloaded 539 times

[qu1ck]

Fast adjustment feature is great! Not sure though why we can't have both that and fix for skipping.

You've attached the firmware binary, not the code. I'll wait until code is updated on github, but fixing encoder skip issue should be pretty straightforward.
I still haven't had a chance to test this but here is what you have:
0001 -> 1
0010 -> -1
1101 -> -1
1110 -> 1

And here is what should be correct encoder signal decoding:
0001 -> 1
0010 -> -1
0100 -> -1
0111 -> 1
1000 -> 1
1011 -> -1
1101 -> -1
1110 -> 1

[jwm]

Is it possible there are different versions of the encoder in the wild? Or when developing it you used a different version? I know some that give one pulse per detent, and some that give two but look otherwise identical. It's something a lot of random dev boards get wrong. Bad or buggy encoder decoding is a pet peeve of mine.

[qu1ck]

In this case, judging by the code it's standard 2 channel encoder with 4 positions rotating 00->01->11->10->00... It doesn't send pulses it shorts A and/or B with common. It's usually hooked up with a pullup to get high when there is no continuity. Same approach is used in dso shell, those pins are also multiplexed with LCD bus.

[jye1]

@ qu1ck:

For the encoder used in the Shell transitions are duplicated for each click in your table. We only need to take one of them. See below.

A ) 0001 -> 1
B ) 0010 -> -1
C ) 0100 -> -1 (same click as G)
D ) 0111 -> 1 (same click as A)
E ) 1000 -> 1 (same click as H)
F ) 1011 -> -1 (same click as B)
G ) 1101 -> -1
H ) 1110 -> 1

[toshi]

I rewrited the new firmware. But there seems to be a new bug in the new firmware.

LEFT:113-15001-055.hex(LIB:15003-045) RIGHT:113-15001-060.hex(LIB:15003-052) It is similar to 113-15001-061.hex

(1) The top of the sample buffer is not captured properly. (input signals are all 1kHz 3.3 V of DSO150)

(2) Trigger level setting due to long press of TRIGGER does not function properly.

(3) The left half of the measurement result display does not function properly.

(2) and (3) caused by the function GetVPosOfs() in the library libdso150.a returning double the value.

(4)The zero level is offset to minus with a sweep later than 50ms/DIV(input signals are all 10Hz 3.3 V from external generator)

I hope you will be able to release the bug fix version of the library or the old library.
Thank you.