Open PawxSpec opened 5 years ago
@VICLER aah, I am sorry, you will also need to update the OS: system_ds213.hex.zip And here are some apps: ds213apps.zip
@gabonator it still doesn't work..
If you open developer console in chrome, what does it say? What is displayed on the device's screen?
@VICLER in the URL replace /web/v2/ with /web/v3/
thanks! it works now!
My screen looks just like VICLER's, and it does come up as /web/v3/ automatically. I tried it with v2 as well, and it's the same deal.
@amzavareei with "GEN::SetWave" on top?
Actually I got past that. It opened up automatically in Chrome for MacOS. Now the settings I change on the web page show up on the DS213, but I don't get any waveforms.
Calibrate it first - disconnect probes from the unit and press Zero offset CH1 and then do the same for CH2. After this simple calibration connect CH1 to GEN and you should see some waveforms
Thanks for the reply. I am getting a signal, but I am only seeing the positive side of the zero crossing, no matter where I set the range or slide the channel icon on the left. What am I doing wrong? The Channel 1 slider moves, then snaps back to the bottom of the graph window. The channel two slider moves, but doesn't change the issue much. Is that supposed to be the Zero crossing? Sorry, this is my first scope so I'm not sure what I'm doing wrong.
So I noticed that when set a channel to auto and set the time base to 1 sec/div it takes forever to refresh. Am I correct in thinking that when you set the time base it doesn't zoom out. Also I would like to either write or pay someone to write some custom probes.
@phillipzan2020, @roops67 and @gabonator:
The wish of zoom functiom came first from avirapatel on 12 Mar ! And I agree this and I miss the function too. I use the version V 1.27 which is for me the best, because it solves the trigger problem, so far I can recognize it.
I can only scroll the time axis in the SINGL-mode and the little rectangle moves over the whole measurement. But this in not zooming it is scrolling ! Zooming would make the rectangle longer, until it is so large, how the whole measurement. In the other modes NORM, AUTO, SLOW, there is no scrolling possible and no zooming. You can only work with the picture on the screen. The only way to zoom is to save the measurement as *.csv-files, so you can look at all samples on the pc, for example with Excel.
If anyone in the forum should have found out how to scroll or zoom in AUTO, SLOW, NORM, then that would be a great help. The description of the DS213 does not contain a key combination here, to activate the functions. I think they are not developed.
In my entry "28 days ago", there I wrote down, which functions are not in the DS213-software related zooming and scrolling.
Unfortunately the minidso-form is in chinese and very difficult for me to handle. In the last days I wrote to Minidso (the Minidso sales point) that they should take a look at this forum, as important suggestions and deficiencies are described here. I got the answer promptly that they will pass the information at the development team. roops67 did this a few days ago too, but via entry in the Minidso-forum.
@phillipzan2020, @roops67 and @gabonator:
Unfortunately I just deleted my comment from 13. of Nov 2020 , so I repeat here the important information: I solved my problem with bad trigger function of the DS213 V1.27 by take an hidden locking into account.
In NORM and SINGL, the trigger readiness is only achived after 1min 4sec, if SINGL 1S is choosen. Trigger events that occur before this time of 1min 4sec has passed, are not recognized by the DS213 and therefore do not lead to a trigger!
In SINGL 1s the recording time of the entire measurement -> is 1min4sec. (the other Blocking times for trigger capability: SINGL 50ms->~4sec; SINGL 100ms->~7sec; SINGL 200ms->~14sec; SINGL 500ms->~32sec). I have to add that these times are valid when the trigger point T0 has been set approximately in the middle of the measurement, which is the normal case. I now found out that the trigger ability does not start with reaching the end of the FiFo, but with the elapsed time, which must be greater than the position of T0 in the planed measurement after RUN has been started. You cannot see the blocking time for the trigger function, and you don't surely want calculate it before. The best way would be to have the RUN button flashing so long as the DS213 is not really ready ! When fully operational is there, RUN should be statically switched on. I hope MiniDso would read this and would understood the problem and solve it.
A normal DSO would never forbid the trigger, but would trigger immediately, even if the pretrigger range is not yet filled. This is probably a weakness with the DS213 that is not documented anywhere and therefore cost me weeks of tests and annoyance. I was seriously about to return the device !!
In AUTO, on the other hand, only 12 seconds (in SINGL 1S / div), as the image of the DS213 shows, because subsequent scrolling is not possible. In addition, it should be noted here with AUTO that the rectangular measurement section must be on the far left, otherwise you will not see anything of the measurement or a repeation of last measurement. A subsequent scrolling is unfortunately not possible here.
As long as Minidso does not provide the same functions for all operating modes (AUTO, NORM) as for SINGL, you can actually only work reliably in the SINGL operating mode.
You get annoyed about these underdeveloped functions because you simply expect them from a standard DSO.
Ultimately, I am researching here, through pure testing, how I can deal with the deficiencies.
I therefore only use SINGL. (in NORM seams to be the same)
How I've done this: I took a 9V battery and of course a stopwatch and I made impulses by tapping the positive pole. To find the position in the measurement I did code them with one short tapping and pause or two short tapping and pause and so on. So you can find reliable the position, again .
I add some diagrams for better understanding: pictures_to_the_background.pdf
There are still some bugs on official v1.27 app firmware. I have fixed some. And add a ROLL mode when timebase >= 200ms/div. DS213_ECHO_v20.11.25.zip https://youtu.be/iGE-QNMqRk0 The project is now open source on Github: DS213_ECHO
@xjtuecho : Thanks for your activity, this makes hope of a better DS213 !
Does the ROLL mode (timebase >= 200ms/div) allow scrolling the display ? this would help then in AUTO and NORM, if the DS213 is in HOLD state, because the operator pressed the RUN button .
Blinking of RUN until triggerung is not ready (for example 1min 3sec in 1s/div) would be helpfull too. So we don't need a list and clock beside the desk to wait when the DS213 is ready. (please see at "Tooluserathome" commented 13 days ago too).
Why is the *.hex-file from your v20.11.25 only 88.5kByte long, while all other version were longer (V1.22 had 100kB and V1.27 had 110kB) ? Is the software DS213_ECHO_v20.11.25.hex normal flashable and removeable like MiniDso published in their operation manual which came withe the DS213 in a box ?
Beside your added ROLL-function. What are the changed functions or the the fixed bugs in compare with V1.27 ?
@xjtuecho I really hope you will release your source code changes.
Inventory of image resolution, sampling rate and memory depth for the V1.27 of the DS213 (only SINGL-Mode)
The display for showing the voltage curve over time (x-axis) is divided into 12 grid units. Such a grid unit is often called as xdiv. The Xpos function can be used to move the image to the right or left in xdiv steps. The picture is shifted by exactly one unit per acoustic peeptone. The temporal measurement cursors can unfortunately only measure on a screen, so you are forced to count all the peeptones and then add everything. The measurement length is always fixed at 135 xdiv, 12 of them are always visible.
With a timebase of 1sec / div down to 5usec / div, the sampling rate (samples per xdiv) is always selected, so that 30.34 pixels per xdiv also correspond to 30 samples. Each pixel that can be displayed is therefore also a real measured value.
With a timebase below 5usec / div, less is scanned and then pixels will be inserted by interpolation in the xdiv. The csv files provide information about this. You can also see there that every measurement basically contains 4096 measured values. If interpolated values were inserted, MiniDso obviously decided not to extend the length of the total measurement, but instead cut the measurement to exactly 135 xdiv.
Therefore It happens that with a timebase of 100ns / div only 1/3 of the measurement can be displayed. You then have to pull a csv file in order to evaluate the rest there with it!
Some determined values: At 100nsec / div there are approx. 10 measured values / div, which corresponds to 100MSa / sec. At 1usec / div there are approx. 24 measured values / div At 2usec / div there are approx. 25 measured values / div At 5usec / div there are about 30 measured values / div
The presence or absence of other channels does not affect the sampling rate of the individual channel.
Remark: I found out that you get only in SINGL-mode an *.csv-file which contains valid signals.
From my point of view MiniDso has there doing 2 things:
1.) The measurement cursors should be able to extend over the entire measurement.
2.) Allow more than 135 xdiv units if interpolated pixels have been inserted, because then you can fully utilize the hardware capabilities of 4x4kSample here!
Hi all, I apologize if this is not the right place where to ask this question, but I'm getting FPGA configuration err after I tryied to upgrade to V1.27, after more attempts, the logo also has gone away. I did it as described on the readme file, that is copying files FPGA_CFG.ADR, STMU_213_018.bin and the DS213AppV1.22.hex for last. Now, my device is stuck on DFU load screen. Reading this thread I noticed you're talking about replacing system, but I can't succeed on anything. Can you link me a kind of tutorial or something to study in order to understand how firmware upgrade of this device works ? I'm trully confident with this kind of things, but this DSO is getting me crazy :-D Thanks in advance.
So the memory layout of DS213 looks like this:
08000000 - DFU 32K
08008000 - APP 425K
08070000 - FPGA 55K
0807D800 - LOGO 10K
The DFU is usually good at protecting itself. It is most likely intact. It can be flashed using UART. Using DFU you can flash other areas by providing a hex file or ADR and bin files.
So enter DFU by holding button 1 + power on. On the computer you should see a drive.
Lets flash the Logo LOGO213.zip Copy the LOGO.ADR. Device will reconnect and you should see on the disk LOGO.SET. Next copy LOGO.BIN, Device will reconnect and you should see on the disk LOGO.USE and LOGO.RDY. You have successfully flashed the Logo.
In a similar way flash the FPGA. FPGA018.zip
Finally flash the App. Its in two parts so do APP1.ADR, APP1.BIN, APP2.ADR, APP2.BIN. APP127.zip Alternatively you can just copy the hex. DS213AppV1.27.zip
At this point, device should be working with latest stock firmware.
@digithom: Look at "roops67 commented on 19 Oct 2020" he described how it works properly, espescially without windows automatics. Windows sometimes made problems, where you will find here many entries in this forum, where people had similar problems.
I took the original DS213AppV1.27.zip outpacked and followed step by step of the readme.txt file there.
The DS213 will install an flashdrive on your pc (each time you connect the USB with your pc). Use the commandline from windows to copy the files only one by one in the flashdrive of your pc and let them fetch from the DS213 (the DS213 seems to be not able to decide which file it has to be taken, if there is more than one on the flashdrive). I took the original DS213AppV1.27.zip and followed step by step of the readme.txt file there. It works at me without any problems.
MotoMaxis may have more experience in details to transfer parts of the software or repair a broken software.
Having owned multiple products from Miniware that all run custom firmwares (their screwdriver and TS80P soldering iron), one thing I can say that seems to be consistent across all their products is that the firmware update process is really wonky in general. It's the same posts on GitHub threads for the TS100/TS80 USB-C soldering iron also talking about the general lack of consensus on the best method to flash a .hex file. It seems the best approach is just to keep retrying different options multiple times. It took me a dozen times to flash my TS80P before it actually worked, using Windows 10.
On Sun, Jan 3, 2021, 6:42 AM Tooluserathome notifications@github.com wrote:
@digithom https://github.com/digithom: Look at "roops67 commented on 19 Oct 2020" he described how it works properly, espescially without windows automatics. Windows sometimes made problems, where you will find here many entries in this forum, where people had similar problems.
I took the original DS213AppV1.27.zip outpacked and followed step by step of the readme.txt file there.
The DS213 will install an flashdrive on your pc (each time you connect the USB with your pc). Use the commandline from windows to copy the files only one by one in the flashdrive of your pc and let them fetch from the DS213 (the DS213 seems to be not able to decide which file it has to be taken, if there is more than one on the flashdrive). I took the original DS213AppV1.27.zip and followed step by step of the readme.txt file there. It works at me without any problems.
MotoMaxis may have more experience in details to transfer parts of the software or repair a broken software.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gabonator/DS203/issues/44#issuecomment-753604442, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE66KDF27KRP3VWQ4VGNZKDSYBJYPANCNFSM4GSSHJPQ .
@cmorche Yes I agree. Especially if the hex files are large, sometimes breaking them up into smaller parts helps. Another tip is try a different PC and different OS if possible.
@cmorche Yes I agree. Especially if the hex files are large, sometimes breaking them up into smaller parts helps. Another tip is try a different PC and different OS if possible.
Thanks a lot for your cristal clear explanation of memory map. At the end, changing OS did the trick, I was using Linux (as for all my daily activityes) and switching to Windows solved the problem. I've already followed the readme instructions but without success, the same thing on Windows worked at the first time, as it should be from the beginning. Then, I played a little with this, trying to take care of disabling cache but, nothing to do, on Linux the firmware files are damaged during transfer and the result is a non working DSO. Thanks for your precious help. I'll take time to investigate the rason of fault on Linux and eventually I'll open a post to help other users.
One thing you can try is change the extension then copy it over then change back to hex when already on the device. The DFU looks for hex, adr, bin extensions.
Did anybody has experience with DS213_ECHO_v20.11.25.zip from xjtuecho ?
I made an comment at his youtube presentation and he responded there, that the reduced file size is reasoned by other compiler he used.
I havn't got no information back about the several small buggs which he has solved. It's only known that the rollmode is new.
Is this software better than V1.27 or was only the rollmode added ?
Did anybody has experience with DS213_ECHO_v20.11.25.zip from xjtuecho ?
I made an comment at his youtube presentation and he responded there, that the reduced file size is reasoned by other compiler he used.
I havn't got no information back about the several small buggs which he has solved. It's only known that the rollmode is new.
Is this software better than V1.27 or was only the rollmode added ? Do you have links? I would test it
Its in his post above https://github.com/gabonator/DS203/issues/44#issuecomment-733725359
Did anybody has experience with DS213_ECHO_v20.11.25.zip from xjtuecho ? I made an comment at his youtube presentation and he responded there, that the reduced file size is reasoned by other compiler he used. I havn't got no information back about the several small buggs which he has solved. It's only known that the rollmode is new. Is this software better than V1.27 or was only the rollmode added ? Do you have links? I would test it
The project is now open source on github: DS213_ECHO. You can build hex file by yourself. This software is better than v1.27 because it was based on v1.27 and fixed bugs of v1.27.
@xjtuecho : Thank you for participating in the DS213 project and for creating the page below https://github.com/xjtuecho/DS213_ECHO.
Unfortunately I am not a programmer and have neither tools nor experience in C to create flashable files. Therefore I cannot create my own file (I only programmed the 8031 in assembler many years ago).
It took me a while to find out that I could download ZIP with the green "Code" icon.
The data sheet of the STM32F103VET6 used states that it is a 100-pin component with 512kByte Flash with 64kBate RAM. It can withstand 10000 flashes and the flash data is retained for> 20 years. With the very high number of flash cycles of 10,000, I would want to try the new software.
For V1.27 of MiniDso the following was recommended in a Readme.txt. 1.Enter DS213 DFU mode. 2.Copy FPGA_CFG.ADR to DFU disk, Then the DFU disk will restart. 3.Copy STMU_213_018.bin to DFU disk, Then the DFU disk will restart. 4.Copy DS213AppV1.26.hex to DFU disk. 5.Restart DS213.
These are now certainly included on my DS213, because it worked without any problems.
Is it sufficient to execute line 4. (copy DS213_ECHO_v20.11.26.hex to DFU disk) and then line 5. if V1.27 is already running on the DS213? Or does the STMU_213_018.bin file also have to be replaced by another * .bin file?
Unfortunately I need your help.
Can another update> DS213_ECHO_v20.11.26.hex be expected in the foreseeable future? If so, then I would still wait.
I 've added in the last days a picture to show the problem of inhibition of trigger (at my comment from the 25. Nov). I think it shows the reason why it is so. And it would be very helpfull to have a sign on the display after RUN-state was reached, that no more inhibition of triggercapability is active to rely.
Is it sufficient to execute line 4. (copy DS213_ECHO_v20.11.26.hex to DFU disk) and then line 5. if V1.27 is already running on the DS213? Or does the STMU_213_018.bin file also have to be replaced by another * .bin file?
Steps 2 and 3 are loading the FPGA code. Unless you get FPGA error, or there is an FPGA update, you don't need to re-flash it every time. The .ADR is just a text file with 0x08070000 to tell DFU where to flash the .BIN which is the FPGA code.
Can another update> DS213_ECHO_v20.11.26.hex be expected in the foreseeable future? If so, then I would still wait.
Check the /Release folder in the zip.
@xjtuecho : Thank you for participating in the DS213 project and for creating the page below https://github.com/xjtuecho/DS213_ECHO.
Unfortunately I am not a programmer and have neither tools nor experience in C to create flashable files. Therefore I cannot create my own file (I only programmed the 8031 in assembler many years ago).
It took me a while to find out that I could download ZIP with the green "Code" icon.
The data sheet of the STM32F103VET6 used states that it is a 100-pin component with 512kByte Flash with 64kBate RAM. It can withstand 10000 flashes and the flash data is retained for> 20 years. With the very high number of flash cycles of 10,000, I would want to try the new software.
For V1.27 of MiniDso the following was recommended in a Readme.txt. 1.Enter DS213 DFU mode. 2.Copy FPGA_CFG.ADR to DFU disk, Then the DFU disk will restart. 3.Copy STMU_213_018.bin to DFU disk, Then the DFU disk will restart. 4.Copy DS213AppV1.26.hex to DFU disk. 5.Restart DS213.
These are now certainly included on my DS213, because it worked without any problems.
Is it sufficient to execute line 4. (copy DS213_ECHO_v20.11.26.hex to DFU disk) and then line 5. if V1.27 is already running on the DS213? Or does the STMU_213_018.bin file also have to be replaced by another * .bin file?
Unfortunately I need your help.
Can another update> DS213_ECHO_v20.11.26.hex be expected in the foreseeable future? If so, then I would still wait.
I 've added in the last days a picture to show the problem of inhibition of trigger (at my comment from the 25. Nov). I think it shows the reason why it is so. And it would be very helpfull to have a sign on the display after RUN-state was reached, that no more inhibition of triggercapability is active to rely.
I have update the README file with detailed description.
Concerning invisible trigger lock: I am now making a proposal for a software addition in general form, in case you cannot find the point in the software that caused the problem, in order to access the blocking notice there.
The blocking notice would be e.g. "waiting for readyness of trigger" or a blinking RUN.
After power on readyness is mostly like T0 is on left side, but it is there as desired. So the best solution is to initialise the DS213 running as if HOLD had been set, so the user manually has to go to RUN, and the behavior is garanteed as normal.
Sorry, but I can't formulate it better. The code should better describe the problem that I noticed with the V1.27.
@xjtuecho : A little update: I've been busy with real c-code from V1.27 and found a position where additional code can placed, so I hope.
Of course, for initial testing it is whether the condition captures the problem area. About the text, I'm not sure, if it works. These are my first lines in c
Update: sorry I forgot the P , so PSMPL is correct.
Update2: uppercase is necessary in the source code. So Psmpl and Empty is the corret notation !
Its not tested yet !
@xjtuecho : I have changed the chiniese language in english, so other in this forum can read the source better.
So I propose that these files should replaced on you project page. Because of my less experience of github I put it here. You can decide to update your project page. DS213_ECHO-master (2).zip
Update: In 2 Files there are chinese part, I've overlooked. Process.c Line 153 // 波形滚动处理 => // Wave scroll processing Sys.c Line Line 144 闪烁 => Flashing
@xjtuecho : I have changed the chiniese language in english, so other in this forum can read the source better.
So I propose that these files should replaced on you project page. Because of my less experience of github I put it here. You can decide to update your project page. DS213_ECHO-master (2).zip
Good job. I have merged your translation to the DS213_ECHO repo. commit a710fdcd3d316d1de50e95f6f323b02598cf4853
I have a survey to all:
Please, give me a thumb-up, or a thumb- down as answer.
Condition: You are in SINGL-mode and you choose 1sec/dev and you want to trigger and everything ist ready and prepared for it. T0 is placed about in the middle.
Now refresh RUN (HOLD -> RUN for it) in SINGL-Mode and the observation time is running.
Produce now for less than 50 sec triggerevents but no longer and wait now 3minutes. If the DS213 is still awaiting triggering, you have the same problem than I have. please tumb-up
otherwise please thumb- down
I have to do it because nobody has confirmed my problem yet !
I have a survey to all:
Please, give me a thumb-up, or a thumb- down as answer.
Condition: You are in SINGL-mode and you choose 1sec/dev and you want to trigger and everything ist ready and prepared for it. T0 is placed about in the middle.
Now refresh RUN (HOLD -> RUN for it) in SINGL-Mode and the observation time is running.
Produce now for less than 50 sec triggerevents but no longer and wait now 3minutes. If the DS213 is still awaiting triggering, you have the same problem than I have. please tumb-up
otherwise please thumb- down
I have to do it because nobody has confirmed my problem yet !
just noticed! in xjtuecho`s firmware too, If I pause and start immediately it freezes, it needs some time I didnt count
Hi all,
I'm a bit late to the party - was using v1.24 on my DS214 that I bought sometime August 2020 and used it now and again until last week i was fixing a laserdisc player and had need of X/Y mode only to discover the DS213 doesn't support it.
Fastforward I now have @xjtuecho 's v20.11.26 flashed and ROLL mode rocks!
So reading further I'm interested in @Tooluserathome 's problem with triggering. I've yet to investigate it but I have a theory with what is going on and I think it's a consequence of having T0 so far into the brown window.
I now found out that the trigger ability does not start with reaching the end of the FiFo, but with the elapsed time, which must be greater than the position of T0 in the planed measurement after RUN has been started. You cannot see the blocking time for the trigger function, and you don't surely want calculate it before.
I think this is because there's a problem with how to deal with accepting a trigger when there's not enough data to fill the gap between the start of the brown window and T0. It waits for the buffer to fill up to T0 before a trigger can work properly otherwise there would be the potential to scroll backwards along the brown window into an area that had no data.
On a grown up scope you'd just have a buffer that kept filling up and the concept of T0 being 50 seconds into a trace would be meaningless. Then you would zoom and scroll to find the trigger point. Ahh yes, Zoom.... Sigh! Then you'd be able to scroll back to the point you started capturing data.
I'm guessing this is the magic of the new ROLL mode but not played with it enough yet to prove my theory...
I suppose the way it appears to be implemented means you have a "hold off" or delay feature so that triggers will be ignored for T0 time which has it's own uses. But as @Tooluserathome says we do not see a countdown or have no idea when hold has finished at all.
Usually I would have T0 in the 1st view of the brown scroll window ie scrolled hard left on a time/div less than 20mS and this would all happen so quickly as to be of no consequence for my day to day uses.
Conclusion: We need zoom to work.
Andy.
@andyjbm:
4096 samples is the maximum memory depth in the DS213. In SINGL mode this number is filled and nothing more is possible. A zoom function here at this point could only go in the direction of -zoom. By scrolling through ~ 12 screen pages you can view all points of the measurement.
There is no software interface between the FPGA and the STM32 that tells the STM32 at which point in the memory the trigger event took place. Then the STM32 could shorten the measuring length and represent this. There is only an PSMPL state there, which tells the STM32 that the pre-range of the measurement is filled. (I add: It seems to be that the FPGA itself supress any triggerevent, as long as PSMPL=0) There is no source code for the FPGA where the interface could possibly be expanded.
A zoom function will therefore not solve the problem.
For me the solution is as I suggested 13 days ago. I hope that the text is displayed there on the screen in the same way as when you e.g. save the settings.
Using xjtuecho`s firmware, 5uS, signal square, 10V, auto/norm mode freezes after signal apears/disappears. Sorry I cant explain it better. My eng is not that good. Every time I am touching by the probe to the mesurement point device freezes, after on/off signal freezes, I need to start stop everytime to reset freezing.
@darkonerakot: I try to repeat it with the V1.27 to see, if this problem is there too. But I have some questions to your experiment (will surely helps the others too):
1. What means freezes auto/norm mode ? Are you sometimes not able to change the mode from auto to norm or from norm to auto ? Or freezes the waveform on the screen ?
2. The 10V, is this the choosen vertical deflection in per division and do you use DC or AC ? The time division is 5uS/div, correkt ? What is the trigger kind and what is the Vtrg value ? (only for norm mode of interest)
3. Do you use the internal frequency at OUT and connect it with CH A (which setting you are used there) or an complete external ? If external, what is the frequency of the square wave signal and the real amplitude in peak to peak you are input in CH A ? Does it have an DC part ?
You can attach pictures or better a little video.
I had sometimes bad contact to the connectors. I prooved the probe and the DS213 side with an magnifying glass. Then I connected again, when I was sure, that the middle parts could match. And after connection with more force, the contact was o.k. and no more a loose contact.
@darkonerakot: I try to repeat it with the V1.27 to see, if this problem is there too. But I have some questions to your experiment (will surely helps the others too):
What means freezes auto/norm mode ? Are you sometimes not able to change the mode from auto to norm or from norm to auto ? Or freezes the waveform on the screen ?
The 10V, is this the choosen vertical deflection in per division and do you use DC or AC ? The time division is 5uS/div, correkt ? What is the trigger kind and what is the Vtrg value ? (only for norm mode of interest)
Do you use the internal frequency at OUT and connect it with CH A (which setting you are used there) or an complete external ? If external, what is the frequency of the square wave signal and the real amplitude in peak to peak you are input in CH A ? Does it have an DC part ?
You can attach pictures or better a little video.
I had sometimes bad contact to the connectors. I prooved the probe and the DS213 side with an magnifying glass. Then I connected again, when I was sure, that the middle parts could match. And after connection with more force, the contact was o.k. and no more a loose contact.
@darkonerakot: o.k. I understand your external signal switches between 0V and +10V and your trigger (rising edge) is nearly in the middle of it at +5V. You use 5uS/div.
Do you use DC ? If you use AC, sometimes you don't reach the Vtrig and this could be the reason of your problem ? To be sure that you can't oversteer the y-range, I need the used y/div you take. What is the measurement frequency and if your DS213 freezes, what was about the pulse/pause ? Or freezes it evertime at the nearly same puls/pause ?
@darkonerakot: o.k. I understand your external signal switches between 0V and +10V and your trigger (rising edge) is nearly in the middle of it at +5V. You use 5uS/div.
Do you use DC ? If you use AC, sometimes you don't reach the Vtrig and this could be the reason of your problem ? To be sure that you can't oversteer the y-range, I need the used y/div you take. What is the measurement frequency and if your DS213 freezes, what was about the pulse/pause ? Or freezes it evertime at the nearly same puls/pause ?
I understood, it is not abou vtrg in previous firmwares it didn’t happen, I mean if you are not reaching Vtrig you just see floating waveform that’s all, but in this case waveform freezes, but in fact signal is there, took me some time to notice that waveform is not moving at all. I used 2V/div. 5v/div. even 1V/div, frequency from 30kHz to 100kHz and it’s happens everytime.
I noticed that it happens when signal appears and disappears:
I connected probes
controller board(CB) in standby
I am looking to waveform and it is flat in middle(zero) position slightly moves as it should be.
scope in auto mode or norm mode(doesn’t matter same thing happens)
Now I am switching on CB and waveform freezes in that position in middle(zero point), then I pause and start and I see my signal as I should from the beginning.
@tooluserathome And it happens when probes in not only to CB, It is happens if I connect it to a driver V, t/div,y/div are same.
@darkonerakot: There are far too many ways to create the problem and I am missing a very simple concrete case that you should explain in a few very concrete steps. Please use a signal from the DS213 generator, then anyone with 2 probes (CH A and Out, both in 1x) can execute it on the table. It thus becomes a portable test case. Define all settings !
The operation of the K1 key (RUN and HOLD), the position of T0 in the intended measurement and that of the zoom window (movable via Xpos) are very important.
My general experience with the DS213: So far I can only work safely with the DS213 in SINGL mode. The others are a bit suspicious to me.
Specifically in V1.27. In AUTO the DS213 only works correctly, if the Xpos window is set on the far left. In NORM the DS213 works at all points of the Xpos window. But it makes sense that you can lays over the T0 point there, because that's where the first recorded trigger point is.
Scrolling through the measurement is not possible in either AUTO or NORM mode. This is only possible in SINGL. That's why I think SINGL is so important, because it offers the highest information content.
What can the xjtuecho software do better here, because I haven't tested it yet?
In my tests, I take a 9 volt battery and do the pulses by hand. The disadvantage of periodic signals is that the beginning and the end of signals are difficult to see. The hand pulses can easily create short or long phases. Unfortunately the DS213 is still a construction site.
@Tooluserathome just did it with using internal generator and it is happens again, I don’t know maybe I am only one who is experiencing this problem with that firmware, maybe there is something that I did wrong? How can I send you an email? I would like to share with video
@darkonerakot: I add my email to my profile, You can take it from there. O.k. you can reproduce it with internal oszillator. You can add an picture with all your settings you start with. Press K4 and K1 together and you make an screen shot. And if you connect via usb to your pc, you can fetch it from there. It's a good way. And you can drop it to your WRITE window here. It's sometimes better to take a view picture and reference it to your text do describe the problem. In the meantime a video should work there too.
@darkonerakot: I had in the meantime problems with my email account, but there was no contact from you to me. Have you now solved your problem or do you nead support ? @xjtuecho : I just saw that you did not adjust the souce files regarding my little forgotten translations (24 days ago). If you make any other significant changes, you will certainly do it. I couldn't edit it there. It could be that I don't know the Github process here.
@darkonerakot: I had in the meantime problems with my email account, but there was no contact from you to me. Have you now solved your problem or do you nead support ? @xjtuecho : I just saw that you did not adjust the souce files regarding my little forgotten translations (24 days ago). If you make any other significant changes, you will certainly do it. I couldn't edit it there. It could be that I don't know the Github process here.
hi, I have merged your translation 28 days ago.
Any compatibility with the DS213?
http://www.miniware.com.cn/product/ds213-mini-oscilloscope/
Other sketchy sources (ebay, banggood.com, etc.) say this has 15MHz Analog Bandwidth. From main website: (link above)
CPU: ARM Cortex M3
FIFO & Control: FPGA
ADC: HWD9288-100
Analog Channels: 2([CH_A] [CH_B])
Digital Channels: 2([CH_C] [CH_D])
Operation Channel: INV [CH_A], INV [CH_B], [CH_A]+[CH_B]、 [CH_A]-[CH_B]、[CH_C]&[CH_D]、[CH_C] | [CH_D]
Vertical Sensitivity: 10mV-10V/div (1-2-5 STEP) (using X1 probe)
Vertical Resolution: 8 bits
Sample Memory Depth: 4 channels, 4*4K
Coupling: DC, AC
Max Input Voltage: ±40Vpp (using X1 probe)
Trigger Types: Ascend/Descend Edge Trigger Mode, Positive/Negative Pulse Trigger, Logic Trigger
Trigger Mode: Auto, Normal, Single, Slow
Trigger Source: [CH_A] [CH_B] [CH_C] [CH_D]
Signal Source: Square Wave: 10Hz to 8MHz, in total 20 shifts and 3 Vpp Signal Sources;
Sine/Triangle/Sawtooth Wave: 10Hz to 20MHz, in total 11 shifts and 3 Vpp Signal Sources
Storage: built in 8M USB disk
File Types: BMP、BUF、CSV
Auto Measurement Types: Signal sequence/cycle/duty ratio, peak voltage/virtual value/max value/min value/average
Cursor Measurement: Time value, Amplitude value
Display Modes: 4 wave lines: Line 1: [CH_A], HIDE
Line 2: [CH_B], HIDE
Line 3: [CH_C], REC_1, REC _2, REC _3, REC _4, HIDE
Line 4: [CH_D], [CH_A]+[CH_B], [CH_A]-[CH_B], [CH_C]&[CH_D], [CH_C] | [CH_D], HIDE
Sampling Mode: Real-time Sampling
Sampling Rate: 100M Sa/s
Battery: 1000mAh
Size: 99.5mmx58.5mmx13.5mm
Weight: 129g (with battery)
Certificate: CE, FCC