(Example there is one who picture DSO5202B but then you read he sell DSO5102P where is total 24k capture memory)

Nice catch, rf-loop. Are you sure you've got the right model, John?

BTW, I know this has gone seriously off-topic, but since this is already the longest thread in the history of mankind , I hope tinhead won't mind:

I was looking through the TARIC codes and rates for various test equipment from various countries (such as the duty amount for shipping a DSO from the US to the EU) and it appears that, generally, there is NO duty on any type of T&M equipment shipped from any country (except perhaps very specialized gear - as in aviation). I'm not sure why that is - but it's good to know. You just have to be sure that shipped equipment isn't misidentified by the local customs office as some kind of consumer electronics (which are usually 13-25% duty).

right, there are these "down to price" models with "P" in name (or as they call them, "High Cost-Effective" DSO).

There is nothing wrong with them, sure the 1M SRAM is not anymore there, so you have to work with 24k only, but everythingelse is the same.

Btw, the 24k value is what the FPGA can handle with best speed vs. memory ratio. Up to now (with fw 2.6 and 2.7) with 4k therewas still enough "room" and 40k it was already bit slowish. I have here test firmware (3.x) with 24k instead of 40k and so far it's ok (yes, there are as well other steps).

But back to "P" models, when you need 1M, then this DSO-line is not what you need. But when you don't need these 1M memory then this is probably the cheapest and best DSO you can get for money.

Logged

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

Yes, tinhead just this - nothing wrong if it meets needs, this is not point in my post. But when compare prices it is good to compare jackfruit to jackfruit.

All do not need long memory. Some do not need never.

There is lot of manufacturers and models where is sample buffer starting from 4k etc.

Many times I use example my one Tektronix I set it for 500 point or 1k and not 50k.

If I look what is going on just on the screen area and not at all interest about what is out of screen... . It is good to realize that with 1Gsa/s and with 2ns/div there is just 20 real sample point visible on the screen if screen area is 10div horizontally. So, sometimes I hope I can adjust memory to 20 sample but capture this "waveform" as fast as possible.

« Last Edit: April 03, 2013, 04:02:25 pm by rf-loop »

Logged

If practice and theory is not equal it tells that used application of theory is wrong or the theory itself is wrong.-Harmony OS

Many times I use example my one Tektronix I set it for 500 point or 1k and not 50k. If I look what is going on just on the screen area and not at all interest about what is out of screen... . It is good to realize that with 1Gsa/s and with 2ns/div there is just 20 real sample point visible on the screen if screen area is 10div horizontally. So, sometimes I hope I can adjust memory to 20 sample but capture this "waveform" as fast as possible.

same here, i always trying to use the fastest (but still long enough to capture what i wish to capture) setting on DSOand longest/fastest combination on logic or protocol analyzers (this is where length matters).

Logged

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

omg...I would never notice this ahahha. Thanks !! But still the 100mhz scope with 1M is 250 pounds whereas the Conrad's version is 290 for 60mhz... Obviously they are the same but at least if I decide not to hack the scope to higher bandwidth 100mhz would be pretty much sufficient for me... About the VAT and duty charges I might be wrong...I just don't see the point of paying VAT to a country which has nothing to do with the production of the product...

attached only the PDF file, if someone need it as Altium version please let me know.

What not included - picture of PCB with part placements, i don't have time for that anymore. If someone wish to do it, you welcome.

I've added as well as much as possible of hw1005, three nets are not connected due the fact that i don't have hw1005.Everything else on hw1005 is reversed from pictures, so don't blame me if i missed something.

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

About a year ago Tinhead mentioned the utility 'fpga.exe' in this forum thread. This file was present in early firmware versions, later it was removed.About two weeks ago this file was again mentioned in mikrocontroller forum thread "TEKWAY DST1xx2B Oszilloskop". Here Tinhead hints to the possibility to create a kind of menu by reading the frontpanel buttons before the main program is started. Well, this is indeed possible as shown here.

I copied the utility 'fpga.exe' into the '/dso/app' directory, together with script 'demo'. The script reads the key-buffer in the fpga memory until it finds one of the 'watched-for' keys, then exits.The script can also be added to the bootscript 'rcS', I prepared a demo 'rcS' for this. Copy it to '/etc/init.d' after saving your original one of course. Now the script will wait while the scope is displaying the bootlogo until you push either F1 or F2, then it exits after starting 'dso.exe'. Here you could insert a different command for another, renamed, 'dso.exe' version that is present somewhere in the filesystem.

I was planning to use this to make it possible to start an 'upgraded' DSO/MSO in either the DSO or in the MSO mode.

HOWEVER....

The 'upgraded' DSO/MSO is running a later Linux version and fpga.exe is not running here. It is depending on some older library files not present. To solve it properly fpga.exe should be recompiled with the proper libraries. I tried a few tricks found on several forums, like symlinking an older library, but no succes.

So far for my attempt to create a DSO - MSO menu.

For those who want to experiment I added 'fpga.zip', my script 'demo' and the special 'rcS' are in 'F1F2demo.zip'.

I found fpga register 0x0d has a key-buffer status bit, bit 5, that is set when the key-buffer contains data to read.Register 0x0e reads the key-buffer: bits 4, 5 and 6 represent the contents of counter UF1B for multiplexer UF3 of the front panel schematic; bits 1, 2 and 3 for UF1A and UF2; bit 0 is zero when the found key is pushed and is set when the key becomes released. My demo uses F1 key, databyte 0x26 when pushed and F2, databyte 0x36.

connect your DSO to PC,run this tool, insert usb flash drive into the front USB and copy the dso.exe from your P model to the flash drive (simply go to shell tab and try cp /dso.exe /mnt/udisk/dso.exe or cp /dso.exe /mnt/dso.exe. I think /mnt/udisk/ should work).

Then zip the dso.exe and upload here or somewhere .. when i have it i can tell you more about hack of these P models

Logged

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

I was planning to use this to make it possible to start an 'upgraded' DSO/MSO in either the DSO or in the MSO mode.

HOWEVER....

The 'upgraded' DSO/MSO is running a later Linux version and fpga.exe is not running here. It is depending on some older library files not present. To solve it properly fpga.exe should be recompiled with the proper libraries. I tried a few tricks found on several forums, like symlinking an older library, but no succes.

So far for my attempt to create a DSO - MSO menu.

so you picked up my idea, cool.

I've tested the script, so far it does works great on 2.6.14. To make this idea "complete" i recompiled the fpga.exe for Linux 2.6.30.4 (it must be simply linked against ld-linux.so.3, not ld-linux.so.2)

Btw, where you found the proper register? Or did you simply tried them all?

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

You mentioned this idea earlier, but your comment on fpga.exe in the 'Tekway DST1xx2B' thread two weeks ago on the mikrocontroller forum made me decide to look into it.

Quote

I've tested the script, so far it does works great on 2.6.14. To make this idea "complete" i recompiled the fpga.exe for Linux 2.6.30.4 (it must be simply linked against ld-linux.so.3, not ld-linux.so.2)

Thanks again, great: "simply recompile". I did find that problem with: 'readelf -l fpga.exe | grep "program interpreter" ' but I had no idea how to proceed further. Lots of learning to do.

Quote

Btw, where you found the proper register? Or did you simply tried them all?

Well,.. You published a disassembly some time ago of dso.exe. Here I searched for 'key' and 'fpga'. Found 'READ_FPGA_kb_buf' function calling 'read_fpga_device' two times, once after loading R0 with 0x0d and once with 0x0e. The rest was just trial.

I will work further on the idea, to see if it is not complicating things too much in view of later updates of the firmware. Anyway when the "definite' firmware for the MSO is available the switching is no longer needed, I hope.

I've tested the script, so far it does works great on 2.6.14. To make this idea "complete" i recompiled the fpga.exe for Linux 2.6.30.4 (it must be simply linked against ld-linux.so.3, not ld-linux.so.2)

Thanks again, great: "simply recompile". I did find that problem with: 'readelf -l fpga.exe | grep "program interpreter" ' but I had no idea how to proceed further. Lots of learning to do.

in the gpl code (e.g. for MSO) there is in "third_part" directory the 4.3.3 gcc toolchain, with all the libs whcih need to be set in ldconfig flag. I made it very simple, created new directory in third_part, copied fpga code there, re-used make filefrom "bmptogif", added section in make file in dir above nad in top dir - that's all. Now, when i compile kernel and driversand what so ever tools the fpga code will be compiled as well (with proper gcc, libs, etc. - no need to spend any unnecessarysecond on that).

EDIT: attached my sources and make files. All you need is to download the MSO GPL sources, install them into /opt/build/mso_env,untar attached file to / and build it (make from /opt/build/mso_env or /opt/build/mso_env/third_part)

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

Today I received the QFP100 SRAM = IS61LPS51236A-200TQLI.What HW mods need to do to use a 2M capability in DSO1202B(exDSO1062B) ?Somebody tested SRAM replacement? Any results?

in principle you need to replace the SRAM, sometimes connect the ZZ pin (pin 64) to GND (some SRAM types have pull-downintegrated, some not - with floating pin you might get strange errors) and then change in EEPROM licensing to enable 2M.

edit: The licensing is described on first thread page.

« Last Edit: June 22, 2014, 09:15:18 am by tinhead »

Logged

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

I did not get 2Mb IS61LPS51236A-200TQLI to actually work in bench HW1007 correctly. I do see 2MB option enabled in scope menus but actual capture repeats itself when 2MB is allowed, so I assume addressing problem with highest used address pin. Have to check if CPLD pin 47 (used in handheld for SRA18 signal) gives anything out during 2MB capture. Also the SDRAM ZZ pin is not grounded, have to test the effect of that too.

I did not get 2Mb IS61LPS51236A-200TQLI to actually work in bench HW1007 correctly. I do see 2MB option enabled in scope menus but actual capture repeats itself when 2MB is allowed, so I assume addressing problem with highest used address pin. Have to check if CPLD pin 47 (used in handheld for SRA18 signal) gives anything out during 2MB capture. Also the SDRAM ZZ pin is not grounded, have to test the effect of that too.

hw1007 is benchtop, so when running firmware for B models you will not get 2M working. This is because there is a check forlinux version in the firmare, BM/BMV models have 2.6.30.4 instead of 2.6.13 on B models.

On Handheld there is no 2.6.13, there was from the beginning 2.6.30.4 and 2M works.

Logged

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

I did not get 2Mb IS61LPS51236A-200TQLI to actually work in bench HW1007 correctly. I do see 2MB option enabled in scope menus but actual capture repeats itself when 2MB is allowed, so I assume addressing problem with highest used address pin. Have to check if CPLD pin 47 (used in handheld for SRA18 signal) gives anything out during 2MB capture. Also the SDRAM ZZ pin is not grounded, have to test the effect of that too.

hw1007 is benchtop, so when running firmware for B models you will not get 2M working. This is because there is a check forlinux version in the firmare, BM/BMV models have 2.6.30.4 instead of 2.6.13 on B models.

On Handheld there is no 2.6.13, there was from the beginning 2.6.30.4 and 2M works.

I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ... I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.

I am testing my new MSO5102D (updated to latest Hantec SW but not hacked) and notice that the logic analyser results seems to lag the analogue channels by one trig. ie. I get the data sampled on the previous trigger for the analyser part and fresh result for the two analogue channels. Is this a know issue? I do not seem to find anything about it elsewhere.