Okay. Can't this be derived from the TTScope decompilation?
well, when the software would work as supose to work then i would not spend time on
protocol debuging ... but the software is definitely not working properly.
The reason ( i remember i posted it already) is very simple, TTScope was designed for the first
Tekway DSO model - DST1xxx (not B ). These scopes are unsing 320x240 display with 10x8 DIVs
and 2500kpoint memory (no long memory available)
The current scopes are 20 virtual (19 visible) x 10 (9visible) DIVs, with 4k to 2Mpoint memory
and 640x480/800x480 reslution ...
TTScope (when you look deep inside you will cry) is not completly customized for the currenty models,
just run e.g. XY Sheet - you will see 8x4 DIVs - how the hell Hantek got that value? No idea, but when you click on run
icon you will see the waveform as on DSO but the timebase/grid is not matching.
So before i start to analyze such TTScope code like that :
signed __int64 __cdecl CalcVoltBase(signed int a1, int a2)
{
signed int v2; // ecx@1
signed __int64 result; // qax@2
float v4; // [sp+Ch] [bp+4h]@3
v2 = a1;
if ( a1 == 1 )
{
result = 2 * a2;
}
else
{
v4 = 2.5;
if ( v2 % 3 != 2 )
v4 = 2.0;
result = (signed __int64)((double)CalcVoltBase(v2 - 1, a2) * v4);
}
return result;
}
double __cdecl CalcVoltBaseEx(signed int a1, int a2, int a3, int a4)
{
signed int v4; // ecx@1
double result; // st7@3
int v6; // edi@7
int v7; // eax@8
float v8; // [sp+8h] [bp+4h]@5
float v9; // [sp+10h] [bp+Ch]@8
v4 = a1;
if ( a1 == 1 )
{
if ( a4 == 1000 )
{
*(_DWORD *)a2 = 1;
CString::Format(a3, "%s", dword_10012174);
result = 2.0;
}
else
{
*(_DWORD *)a2 = 2;
CString::Format(a3, "%s", dword_10012178);
result = (double)(2 * a4);
}
}
else
{
v8 = 2.5;
if ( v4 % 3 != 2 )
v8 = 2.0;
v6 = a3;
result = CalcVoltBaseEx(v4 - 1, a2, a3, a4) * v8;
if ( result >= 1000.0 )
{
v7 = *(_DWORD *)a2 - 1;
*(_DWORD *)a2 = v7;
v9 = result * 0.001;
CString::Format(v6, "%s", dword_10012170[v7]);
result = v9;
}
}
return result;
}
and hope the code is working with current models (which is in most case not really, additionaly many current model
features are missing in TTScope ...) is maybe smarter to use USB sniffer,
push some buttons and analyze the USB data to get something like that:
byte 001 - 53 msg header
byte 002 - D2 00 msg length
byte 003 - ^
byte 004 - 81 msg type (see "types", here 81 = "DSO echo data" as answer to "01" = "get DSO echo data")
byte 005 - 01 ch1 channel on/off - "00" off/hidden, "01" on/visible
byte 006 - 02 ch1 volt/div position - 00 = lovest position, 0A highest position, e.g. when x 1 00=2mV/DIV and 0A = 5V/DIV
byte 007 - 00 ch1 coupling - 00 = DC, 01 = AC, 02 = GND
byte 008 - 00 ch1 bw limit - "00" off, "01" 20MHz bw on
byte 009 - 00 ch1 volt/div fine/coarse - "00" = "coarse", "01" = "fine"
byte 010 - 01 ch1 probe multiplier - "00" = x1, "01" = x10, "02" = x100, "03" = x1000
byte 011 - 00 ch1 invert on/off - "00" = invert off, "01" = invert on
byte 012 - 00 ch1 volt fine position - max 32 steps with autozero (when next coarse level reached)
if changing between x2 voltage levels (weird heh, when changing from 1V/DIV to 2V/DIV
the ratio is x2, when changing from 2V/DIV to 5/DIV ratio is 2.5) and max 75 steps with
autozero (when next coarse level reached) if changing between x2.5 voltage levels.
When increasing value from "00" = current coarse level, then "01","02" and so on
up to "31"=49step or "4A"=74step (see above why!) and reseting to "00" when
next coarse level reached.
byte 013 - 00 00 ch1 volt position (Little-Endian) - Max position = (+-)25.0DIV, each DIV = 25 steps.
When increasing (pos "+") value is increasing from 00 00 to max F4 01 (500)
When decreasing )pos "-") value is decreasing from FF FF to max 0C FE (65036 which mean 65536-65036=500)
byte 014 - ^
The TTScope decompilation might be useful for some things, that's for sure, but as long i can
track back the USB dumps results to "taken action" no need to send time on guessing the decompilation.
A better source as TTScope is of course the
ARM disassembly itself, but still there is some additional effort necessary
to track back things... but even in ARM code (the firmware itself !!) there are
some traps :
- byte 179 - FFT algo - "00" = "hanning", "01" = flatop", "02" = "rectangle", "00" = "barlett", "01" = "blackman"
So why 00 and 01 are used twice in ARM code? The answer is simple, originaly these DSOs has been developed
with only 3 FFTs algos, later 2 algos has been added but the developer forgot to add 2 additional values into
"DSO echo/status" code ...
Home
Help
Search
Login
Register
