DS213 Compatibility [Enhancement Request]

[PawxSpec]

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)

                              100mV-100V/div (1-2-5 STEP) (using X10 probe)

Vertical Resolution: 8 bits

Sample Memory Depth: 4 channels, 4*4K

Coupling: DC, AC

Max Input Voltage: ±40Vpp (using X1 probe)

             ±400Vpp (using X10 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

[cyphrsphyr]

@dbuezas Again thanks for the response. Ive waited for each file to load and set. According to the manual i should see (.rdy) following the copying of the (.hex). Im seeing (.err). At this point i believe its the device and not the software

[BlueMax]

Is the trigger bug fixed now and the device finally usable? There are other attractive devices (in this price range) like the FNIRSI-1013D (~20-30MHz, 7" touchscreen, 140$). Not sure what to buy. Open-source would probably win.

[dbuezas]

@cyphrsphyr must be frustrating. I know it sounds like silly, but do try it from a different computer if you can :)

[ztripez]

@cyphrsphyr I had the same issue, but reconnected the usb and tried again and it worked.

[jedwa006]

Im not sure if people still reference this thread but I had the exact same issue @cyphrsphyr faced with your DS213 and in the last couple days I was able to find a way out of it.

For the firmware: Unfortunatly the same advice that worked for people here worked for me, trying different computers. At the end of the day, between a Windows 10 Laptop, w10 desktop, wXP desktop, and w8 desktop, amazingly it was the w8 computer that successfully copied the files and gave the appropriate .rdy and .use extensions when the DS213 rebooted. One thing I did not is every once in a while, I'd get one of the three failing randomly. I was able to simply re-copy the .err file in this case and it would restart and have the correct extension. (I should note I have a DS213, hardware v2.0, DFU 3.73c, now on Firmware 1.27 (official), shipped with f1.22 and the same DFU).

For the file storage: This one was harder to solve. Again, going through multiple combinations of hardware and OS to figure it out. What happened is, at some point, I had formatted the internal drive as FAT on windows 10 (note, in versions past w7, FAT formats to FAT16 natively). The issue ended up appearing when I connected the DS213 to a windows XP system and viewed the device in Disk management. There was an empty, RAW partition of about 1mb that was sitting BEFORE the FAT partition on the drive. Every time I would try to save on the device in this state, I would get ERR or Save Error. Plugging the device into a w8 or w10 computer did not even display this partition existed. Windows XP was unable to remove the partition so I ended up using Disk management on Windows 8 (10 should work too) to delete the FAT partition, leaving me with an "apparently" RAW device when you connected it to usb. Going back to Windows XP then, I was able to use the normal right-click and format as FAT option on the drive and immediately, without a reboot, the scope was able to save files again.

TLDR: For anyone with File Save issues on (especially) a Windows computer, try hooking it up to a Windows XP machine, or a XP virtual machine and see if you have a small partition before your FAT partition on the drive. If you look at the drive on a w8 or up the system, you WILL NOT see this second partition, but you can tell you have this issue if the formatted size of your minidso usb drive is less than approx. 7.8-8.0mb. Cheers everyone! Hope this helps someone in my position.

[cyphrsphyr]

Sorry for not responding to all ive been busy and i didnt realize im the last of the pc generation. We are going to try it this weekend on my brother's Mac. Thanks all for advise

[Tooluserathome]

Hello,

I bought an DS213 V1.22 at 11.09.2020 and found the triggerproblem too. All comments above were helpfull to get a solution, but since the update to V1.27 from 27.07.2020 there are no more informations, if the V1.27 solve this (and other) problems.

I wrote the following questions to "sales@e-design.com.cn", but until now, I havn't get any answer. Can anybody can answer some of these questions I copy hier below ?

####### I have Version 1.22 on my very fresh DS213 (delivered 11. sept 20) and found several updates. The last one is from 2020.07.27 Version 1.27

Now my questions:

Does V 1.27 will solve the Problem triggerproblem above ?

Can I go directly from 1.22 to 1.27 and no software_steps between ?

Make it sense to wait for a newer Version ( I can’t ask the programer, because I can’t write in chinese) ?

Are there hardware dependencies of the DS213 or of the PC (my PC has WIN10 with an USB 2.0-port) ?

In the” DS213 APP 1.27 FPGA018.zip” is a readme which describes 5 steps to do.

Is this in accordance to the flyer V1.0.0 (was in the packaging), how to “Firmware Update”, because the FPGA is to flash too ?

I ask here because in the example of the flyer I have to wait until .hex Change in .rdy, so the D213 writes activ back to confirm. But in the „read 1.27.txt“ is only the hint „then the DFU disk will Restart“

All the questions are only for one reason: I don't want to damage the really very nice device and send it back to the supplier ########

Thanks all for advise.

[roops67]

To @cyphrsphyr and all others that are having problems transferring firmware files to their DS213 in Windows, I had this issue too but found that using the command-line works everytime! example...

1) First find the drive letter your ds213 DFU mode has mounted as 2) Open cmd window in the directory where you've unzipped the firmware files into (easy way is hold down shift-key and right-click mouse over firmware directory window and then click on 'Open command window here' in menu) 3) Type 'copy FPGA_CFG.ADR d:\ ' (change the drive letter to your DFU mounted drive letter!) 4) Wait for DFU to remount drive 5) Do the above 2 steps for remaining files...

Hope this works for all of you's

[roops67]

Websocket oscilloscope running on DS213! Still in beta, not ready for release and public testing, but looks promising!

These are exciting changes @gabonator , any idea when it will be ready for release? If you're making firmware changes, can I please request to add X & Y scope features such as we can see Lissajous waves etc?

[Tooluserathome]

@roops67 unfortunately the discussion at "www.mindiso.com" ends there in a question "Please try APP 1.27" since july 2020.

By making your update-tests, I think you will play the latest update V1.27 with the FPGA018 from 27. july 2020 too. Does the DS213 works with it, and are the functions of the DS213 now better than the V1.22 ?

If V1.27 would be better, I would like to update the DS213 too and would start testing it. I would give possibly findings here back and at mindiso too (with the google translater it should work).

Thanks in advance

[gabonator]

@roops67 I am using the DS203 quite frequently. But mostly through WebUSB interface (I use it during my lectures, DS203 - connected through computer and projector). The integrated oscilloscope application does not offer very rich features, but it can be used for general measurement. Regarding the DS213, I would like to ask you guys - what is the current situation with the new official firmware? What was fixed, what was not? Which modes do not work? And if you want to display just lissajous waves, I can make some very simple application for this - I just do not want to make one single oscilloscope application that does everything, and XY mode is quite specific feature

[roops67]

@Tooluserathome I have only just installed this firmware 1.27 so haven't had a chance to put it through it's full paces yet. What I have noticed in the UI encoder selector wheels are very unresponsive/skippy or sometimes jump in the opposite direction... it's as though they've resorted to software polling instead of interrupts!?! Also noticed the X scrolling is still troublesome or not working! Can't comment on the triggering yet, still have to test. But to date I am not happy at all with what minidso have promised and not delivered, really wish i stuck with the DS203! I think we're better sticking with Corto123's firmware fixes here... http://www.minidso.com/forum.php?mod=viewthread&tid=3397&extra=page%3D1&page=7 @gabonator Yes it will be great if you can incorporate something like the XY mode app. The DS213 firmware problems are still painfully there, I really believe this scope is actually broken but minidso will never admit it, maybe why that's why they haven't yet released the FPGA code? Probably also why nobody have created any third party firmware for this scope but have many choices for the DS203 (like yours and wildcat etc..)?!

[Tooluserathome]

@roops67 thank you for the hints. I found 1.22.f from Corto123 in Mindiso-forum as the last one.

But I hesitate to try it, because Mindiso changed the FPGA software to FPGA018 and I think every further software from Mindiso will based on it. So we are not free in changing between 1.22.x and 1.27. I've not yet done anything changed from V1.22 the device came with, and I hope Mindiso will solve the stucking of the wheels (debounceing by polling is possible too). I 've seen, that you are in the Mindiso-forum too. Please let the developers there know all the problems you've found to get a better software. The trigger problem should actually be solved, how I read in past threats, but they can of couse made it bad again.

aviralpatel whiches to have a zoom capability to see better at the trigger point what happens and I am interesstet to have it too.

@aviralpatel: Do you have experience with the software 1.27 or other software concerning the trigger problem and the zooming.

[gabonator]

Could anyone drop here latest firmware files? Or links where to get them (fpga/bios/app)?

[blchinezu]

Forum thread: [Firmware update] Material Download for DS213 Oscillloscope

Or direct download: 2020.07.27: DS213 APP 1.27 + FPGA018

Sources are not yet released for this version as far as I know.

[roops67]

@Tooluserathome I've highlighted and complained on minidso's forum many times and have eventually given up, believe me I'm not the only one! We get the usual response from minidso 'please wait'! That's why I have a sneaky suspicion that the DS213 scope is faulty hardware that can't be fixed via software updates as it never worked as advertised (not specifically mine but all in production!) and that is maybe why minidso is staying quiet, it could mean they will be liable for refunding all ds213 sold!!

I love the scope design and if it was functional as advertised it would be great and have no complaints

[roops67]

@Tooluserathome okay I had switched from minidso firmware to Corto123's 1.22x and back to latest minidso firmware, so are you saying the FPGA version can not be interchangeable??

[Tooluserathome]

@roops67: it was only my suspect. Now I've compared both FPGA-Files from 1.22.f package and from V1.27 package and they are identical. I suspected differences. Sorry it was my fault. So it is no matter of FPGA_configuration. Everything is o.k.

I will try V1.22.f in the next days with your hint to use the command_console instead of windows.

[darkonerakot]

@roops67 I am using the DS203 quite frequently. But mostly through WebUSB interface (I use it during my lectures, DS203 - connected through computer and projector). The integrated oscilloscope application does not offer very rich features, but it can be used for general measurement. Regarding the DS213, I would like to ask you guys - what is the current situation with the new official firmware? What was fixed, what was not? Which modes do not work? And if you want to display just lissajous waves, I can make some very simple application for this - I just do not want to make one single oscilloscope application that does everything, and XY mode is quite specific feature

XY would be great feature in this device. Thanks a lot for your help to dso213 users

[Tooluserathome]

@roops67 The update from 1.22 to 1.22.f with command line style works good. But here other participiens who has great problems must report. I havn't tried other possibilities. The trigger problem is not solved in 1.22.f. It might be a bit better than V1.22, where nothing after triggerpoint, was shown.

Here my testreport for 1.22.f in details:

The trigger time is marked with the T in the total measurement. This also includes the vertical line that can be moved with T0 in order to determine the position within the total measurement for the next measurement, where the trigger time should be.

This allows the user to decide before a measurement whether he would like to see more of the previous history or more of the post-history later. It is standard to place it in the middle of the total measurement. If the software recognizes in the incoming data in the memory that the trigger condition becomes true, then the memory has to be refilled until the position of T in the total measurement with this data point is reached and is only then stopped.

The reliable detection of this data point is not included in V1.22.f, as many of my measurements show. You don't have to use complicated voltage curves like I used them in the beginning.

It is sufficient to simply set a trigger threshold Vtrg = 2V and the trigger type: Vt> and connect a 9V battery that then exceeds this trigger limit (e.g. SINGL 50msec). It would then have to be triggered immediately and the measurement would have to stop after the delay time has elapsed, and the T line should coincide with the rise at the high level. However, it turns out that in many cases there is no triggering at all.

If you e.g. 3 times just briefly taps the battery terminal, and then it triggers (characterized by the fact that HOLD appears) comes, then you often see 2 impulses that were in the past before the trigger time and on the 3rd it had then triggered. Sometimes you have the impression that you have not contacted properly, but the measurement then clearly shows the unsuccessful attempts and it should have triggered there already.

I deliberately leave out potential for improvement in other functions that I have still found, as this problem has to be solved first, otherwise the DS213 is completely unusable because you cannot rely on it.

I haven't tested V1.27 yet.

Can you give the info to Corto123's in mindiso-forum. May be he has a solution for this.

[roops67]

@Tooluserathome hi did you try with falling/rising edge trigger? Might be more reliable that way

Yes please try your tests on v1.27, will be interesting

If you post your findings on the minidso open source thread to the attention of Corto123, I'm sure he'll want to hear your feedback... http://www.minidso.com/forum.php?mod=viewthread&tid=3397

[Tooluserathome]

@roops67 the trigger problem in (V1.22.f) is in: <Vt; rising or falling edge. I not test the other ones, because I think it's like that everywhere. The problem is not seldom. Seldom ist that it works correctly ! I could imagine 2 reasons for the problem to fetch the trigger:

1. the necessary interrupt routine looks mostly at the wrong data (and not at the real incoming data) to evaluate and therefore miss the triggercondition.
2. the necessary interrupt routine was mostly forbidden, so miss some triggerconditions.

I'm not sure, if I get access to minidso, because it's in chinese and with translation from google nevertheless I have to understand the registration procedure. If you like to transform these important findings to the minidso, I've no problem with it, and I would appreciate it.

I will start testing with V1.27.

[roops67]

@Tooluserathome are you using Chrome Web browser, it does interpretation for you (mobile or pc). Most the posters on the forum threads are posting in English including Corto123, please have a look 🧐, you can post on that thread exactly as you have here. But if you're not comfortable (as I can see English is not your native language 😉 } then sure I'll post for you... (If you haven't registered then yes it is a pain cos the most the sign-up registration is in Chinese, you have to guess which are the right options to press!!)

[Tooluserathome]

@roops67 : I use Firefox and sometimes I have success when goole translates the complete side to english, but the headlines over input fields not.

Now I'm beginning testing with V1.27. Positive is that an recognized trigger will quick write the measurement on the screen (from left to right side), so you know that a trigger happens. The HOLD appears later if the measurement is complete. This is important if you have choose SINGL 1s and the complete measurement needs minutes !

But the trigger problem is still there, how I have described to V1.22.f. I put two pictures from the measurement in the annex, they are from one measurement and I've lost here 3 triggers before finally triggered. The first picture shows the "last lost trigger before triggered" and the second the "triggered at the triggerline". The horizontal doted line is the trigger threshold and here is very much time for the software to recognize it !

The loss of trigger events can of course not be found with periodic signal sources, you have to use single events. I used a capacitor that was charged on an 8.4V battery and discharged in between. There are more than 20 samples above the trigger threshold, so there should have been enough time for triggering. But the DS213 doesn't do it ! The impulse that triggered the DS213 even had fewer samples than than the lost ones !

[darkonerakot]

I would describe my experience with this fws but my English is poor

[roops67]

@roops67 : I use Firefox and sometimes I have success when goole translates the complete side to english, but the headlines over input fields not.

Now I'm beginning testing with V1.27. Positive is that an recognized trigger will quick write the measurement on the screen (from left to right side), so you know that a trigger happens. The HOLD appears later if the measurement is complete. This is important if you have choose SINGL 1s and the complete measurement needs minutes !

But the trigger problem is still there, how I have described to V1.22.f. I put two pictures from the measurement in the annex, they are from one measurement and I've lost here 3 triggers before finally triggered. The first picture shows the "last lost trigger before triggered" and the second the "triggered at the triggerline". The horizontal doted line is the trigger threshold and here is very much time for the software to recognize it !

Sorry but that is not edge trigger you've got selected. Please try with rising edge trigger, even the minidso dev had asked try the tests with edge trigger mode on their forum

Would you like to upload your results onto the minidso forum? It would be useful there

[Tooluserathome]

@roops67: I did variate with <Vt, rising and falling edges and did it with V1.22f and V1.27 too. So you can see the pictures as examples for this problem !

I've been busy now with all kinds of operating states AUTO, SLOW, SINGL, NORM. And here ist my Summary for this: Minidso is very inconsistent between these 4 operating states AUTO, SLOW, SINGL, NORM. SLOW has no trigger problem, because it only writes continuously and does not need a trigger at all.

AUTO, NORM and SINGL require triggering, which unfortunately is still faulty, which must be solved!

AUTO, SLOW and NORM only describe one screen page with 4096 datasets of time and the zoom factor is = 1, because there is no zoom function at all. The display has 400 pixels horizontally, so a zoom factor of a maximum of 12 would be good, so that you can also see individual measuring points without always accessing these values with a * .csv file.

SINGL currently always has a fixed zoom function with a zoom factor of ~12.

It seems to me, that Minidso got a bit confused while programming and does not separate some basic things, but unfortunately mixes them up!

Here is my suggestion at Minidso the extension to do, to get a consistency and to improve the product significantly:

The brown wavy line between the two brown bars always represents the total measurement. The T in it is the trigger position and the white rectangle is the image section that is currently visible in the display. This is how it should be !

A measurement that has been made, should always be displayed on the width of a screen when it is created. This is how it is with NORM, SLOW and AUTO is currently like that and is fine. Since there is currently no zoom function in a measurement, this brown wavy line would not be needed at all at the moment! Only with the development of a zoom function does the brown wavy line and the T and the white rectangle in it make sense.

To introduce this, the white rectangle would first have to take up the entire width up to the two vertical brown borders, because the entire measurement is shown on the screen (zoom factor = 1). That would then be the case with the NORM, SLOW and AUTO functions, because they are currently not zoomable and everything can only be displayed. The white rectangle would become a very long, slim rectangle here, touching the vertical brown lines.

Now the developer makes an exception with SINGL, that a zoom is immediately available and this is at maximum zoom is set. But he cannot push the measurement together again and display it as a whole. This is inconsistent and is definitely not intended!

With the following requirements for expanding the software, everything will be better:

1. It must be possible to set the width of the white rectangle from the full width at the beginning (up to the border lines of the entire measurement), zoom factor = 1, to a minimum width (e.g. up to zoom factor = 12). For this purpose, a zoom factor setting option e.g. 1, 2, ..., 12 is required. The suggestion for the input of this is, that if Xpos is flashing (and thus this function is selected) then press and hold the K3 key. Turning the wheel A is then interpreted as a zoom factor change. The width of the white rectangle then visibly follows this setting.

2. The white rectangle can now be moved horizontally to target the point of interest in the measurement. Since this function is already available and is also quicker if the Fn key is held down, this input can simply be used further.

Now, of course, the screen must also display the data to be displayed updated accordingly. And the horizontal timeline in time / div has to be displayed somewhere. E.g. top right under the generator frequency.

The cursors T1 and T2 should also enable the exact time difference to be measured.

With these changes Minidso get a consistency of all 4 operating modes and you also have a zoom function that is often missing and then for all operating modes available.

@aviralpatel because zooming it's one of your whishes too.

[gabonator]

Hello guys, I put together some applications for DS213, fixed encoder issues and other stuff:

• 98osc.elf - official 1.22 release ported to my OS, unfortunately I do not have newer version of official oscilloscope application
• 58gmini.elf - simple oscilloscope application based on DS203 osc firmware development
• 69webosc.elf - webusb oscilloscope - just attach usb cable to your computer and you can control the device through web interface
• 63ws_ds.elf - WS2812 addressable led testing application (attach the led strip to signal generator output)
• and some other just for fun

ds213_demo1.zip

Installation notes:

• install system_ds213.hex through DFU mode. I had to copy it twice on windows machine, at first the DFU renamed the file to system.err, but the second time it worked
• for mac or linux use dfuload utility from LA104 repository
• after rebooting the system will ask for shell.elf - copy all remaining files from this archive to the device and press F1

Can't wait for your feedback :)

[bradanlane]

Will start testing today. The easiest tests for me will be 58 and 69.

I am assuming I can switch back to official FW after I finish testing?

[gabonator]

@bradanlane, yes you can easily switch back to the offical fw any time

[darkonerakot]

So I tested most important app and it doesn’t play midi, joking aside 58gmini looks pretty good I’ll start testing in later. I can’t believe you did it in few days

[roops67]

Gab your are the MAN. You've given us so much to play with, is like Christmas has come early! I will try as soon as I get the chance, feedback incoming 😀

Just out of curiosity you said you fixed the encoder issue, was the fix something simple you can explain?

[darkonerakot]

Gmini is a simple and XY works good on sin 50hz, in 98osc havnt been any trig issues yet, I don’t get how to use web interface and honestly I didn’t dig it, midi player shows something and freezes. As for me I need only one more thing and it is zoom in/out due pause of measurement, but I convinced that is in FPGA. Gabriel you’ve made really cool work. New colors to the device!

[roops67]

@Tooluserathome that's some intense testing and your efforts are greatly appreciated, I guess now you'll be jumping straight onto @gabonator's updates 😁

But still I'm not sure you've actually tried 'rising/falling edge triggers' in your tests (sorry maybe I'm misunderstand). As what I know '>Vt' or '<Vt' are not edge triggers but are testing for 'larger than' or 'smaller than' voltage trigger. The edge trigger symbols are these:

[gabonator]

There is a whole story behind those encoders. I was using only my firmware all the time and I have tried the original fw just when the device arrived. So I thought this was something related to my own code implemetation why the encoders were behaving so badly. Then someone mentioned here that also the official fw has similar problems, so I decided to spend some time investigating where is the problem. I made simple program that just shows color lines on the screen depending on the logic levels coming from the encoders. I noticed that there is terrible noise (switch bouncing) when the encoders were turning. I wanted to place some capacitors at the encoder signals to prevent this:

and I was lucky, because the engineers at miniware placed there vias on the PCB where the encoders were soldered. After placing 100nF ceramic caps, the signal became perfectly clean. But just to be sure I also implemented simple digital filter to filter out some short term signals which waits until the encoder signal becomes stable for 4 milliseconds: https://github.com/gabonator/LA104/blob/master/system/os_host/source/bios/ds213/imports.c#L105

And then I tried the same algorithm on the second encoder (without caps) and for my surprise, it was working very well even without capacitors. Even better than on LA104 which I was working on last months... Again, software solves hardware problem with ease...

@darkonerakot this took about one year to finish :) Most of the work was already done for the DS203 oscilloscope and I was waiting until miniware fixes their fpga issue before developing for DS213. And I have recently finished one interesting project for LA104 (https://www.youtube.com/watch?v=Gwyi00NKBNg) and was looking for another challenge

[roops67]

This is so cool, thanks for the info. Strange why miniware themselves keep missing this software de-bouncing in their own firmware, sloppy updates!? So you are still waiting for them to fix the fpga!!

[blchinezu]

Noice! I'll give it a try too.

[Tooluserathome]

@roops67 I know rising and faling edges very well and I've tested them. And I've voltage over and voltage under trigger tested. All that triggerkinds have the same problem, how I described !! In the past I had to work with many oscilloscopes in my job (very expensive) and privately with cheaper ones.

I decided myself only for the DS213, because it has some smart trigger options too (TL, TH). I would have needed it in my own project. But in the meantime I have solved it differently. I converted the digital signals into sawtooth voltages using hardware I built by myself. Now I was able to use my very old vellemann DS oscilloscope that only has voltagelevel trigger.

So now I'm angry that I bought the DS213, even it is a nice device. I wanted a working device and I don't want to develop one.

To gabonator's comment I can say. I have any problems with the wheels (encoders). Maybe with the time they might get problems, because my device is new (from sept. 2020) ? And about the software which he provided. I don't understand what it does or it cans and how it can integrate in the device. I'm not a programmer. I'm only interested in an working firmware to use the DS213.

Therefore, I will not deal with his software.

[roops67]

@Tooluserathome ah okay I did misunderstood you, as you said you have tried the edge triggers. I haven't had the opportunity to try @gabonator's updates yet so not sure if he's done any work on fixing the triggers

@gabonator I noticed your installation notes you say: "install system_ds213.hex through DFU mode. I had to copy it twice on windows machine, at first the DFU renamed the file to system.err, but the second time it worked" Tip: in Windows use the command-line 'copy', it works every time

[gabonator]

I was not doing anything with the triggers. I tested only rising/falling edge and they are both working fine. Now I was experimenting with the time interval type triggers. The FPGA does not respond to any change of the trigger width register value (TRIG_WDTH 0x22 in their code). So I tried setting undocumented registers and found out that register 0x28 has something to do with the trigger duration. It needs more research to find out precisely what does it do. Any programmer here who would like to help me (javascript is enough)?

[roops67]

Thanks @gabonator for confirming the edge triggers are working as should be, that's really good to hear!

Wish I could offer as I do have programming experience but I've never touched JavaScript or most the other hi level languages, I'm mostly old school C and assembly (arm and atmega), hoping somebody comes forward and helps you tackle the research needed! You have done more for the ds213 in the past few days than miniware has since the scope had been released!

[Tooluserathome]

@roops67;@gabonator: All the time I'm only working wih Ch A. And as I described I'm loosing trigger events happens with >VT, <VT ;rising and falling edge. I spared myself the others because they certainly won't be better. As I already wrote, the loss is sometimes so sneaky that you think you simply had no contact. But if the 3rd trigger attempt succeeds and a trigger is triggered, you can see the two lost attempts in the past of the measurement.

The occurrence of the problem is more common for me than that it works properly !!!

You can see it in my pictures as an example. So the data really come into the memory, the uP then unfortunately does not manage to recognize this trigger event!

And there is obviously no question of the configuration of a uP port (level or edge triggering).

It is also interesting that the problem occurs even with the largest adjustable time base of 1sec / div. Here the simplest uP in the world would have to find the trigger event in the data even when pollen. But it definitely doesn't see it.

It would help if someone could at least confirm that. Otherwise my device is defective and an isolated case, which I cannot believe.

Thanks for the cooperation so far.

[dbuezas]

I Any programmer here who would like to help me (javascript is enough)?

I think I can help. I made the firmware and web UI for a low specs Arduino based web oscilloscope, so I should have learned a thing or two about triggering https://github.com/dbuezas/arduino-web-oscilloscope (warning, for now it supports lgt8f328p only)

[Tooluserathome]

@roops67;@gabonator: I will give a shorthand version of all of my efforts. The rest and details are available to my other messages:

The DS213 was delivered to me in September 2020 (with V1.22). During operation, I noticed that measurements simply ended in the sreen, where I expected a trigger. I suspected a graphical problem and looked at the * .csv file with Excel. But nothing had been recorded there.

While searching the internet I finally found this forum and also the Minidso forum. There it was said that the problem had been solved in a V1.22.x. Neither this version V1.22.f nor the V1.27 of Minidso solves the problem. It has only improved that there is no longer this break in the picture. But an almost permanent loss of undetected triggers is not a solution either.

Who can say that there is a version that doesn't have this problem? I would then repeat the tests with this version, to confirm this ?

[blchinezu]

Feedback after quickly testing the apps in my DS213:

15chards.elf - Works fine

21mplayd.elf - Has no sound and crashes after a few seconds.

58gmini.elf - This is pretty cool. I think I'll actually use it next time.

61devin.elf - Works fine

63ws_ds.elf - Didn't test it with an actual ledstrip as I don't have an addressable one but the app seems fine.

68webosc.elf

The app starts but the browser says No compatible devices found. when I hit the Connect button. I tried with the latest stable Chrome. I'm on Ubuntu 20.04.1 with kernel 5.8.16-050816-generic (I needed the AMD hardware support so that's why I don't have the kernel normally available in the repos). I suppose this issue is related to my system somehow.

98osc.elf

This one feels a bit strange. There are a few issues:

• First issue would be that your whole system works by navigating with the right wheel and toggling with the left wheel. But while in this app the wheel functions are inverted
• Next one is that the fourth button closes the app. So it can't work as a modifier anymore. It would probably be better as a new menu entry. Don't get me wrong, for a first working port of the app it's great!
• Config is not loaded/saved Probably more but I didn't go further. I'd actually like to still have this app along with the custom firmware.

[blchinezu]

Also some feedback on the unreleased stuff:

29file~1.elf - Obviously fine since it's the current shell and I used it to run everything.

54shell.elf - Looks nice. No actual actions, just dummy GUI but no crashes.

55gosc.elf - Straight up hardfault.

62memvw.elf - Also works fine.

71strm.elf - Crashes at startup with Oh noes: DMA channel 4 transfer error!

[Tooluserathome]

@roops67: I found your entry at minidso-forum, that they should look at this forum here. We can't be shure if they do so.

Yesterday I could registered at minidso-forum, but it was inpossible for me to make an entry there. I think I don't understand the system behind there, although I could translate the chinese in my home language via google translator and the chinese at the switch areas with single translation.

[VICLER]

first off all, @gabonator thank you very much for your work! just tested 69webosc.elf. I installed right drivers with zadig and webOS interface recognizes and connects to ds213, but it does nothing.. just a grey background. On ds213 display I get this message "Function 'Gen::SetWave' not found." And as I wanted to quit the app I got "Image loaded at 0x...." and stucked there

[gabonator]

@VICLER great, so it seems, the webusb communication works. The "Gen::SetWave" error is a bit strange, because I used this non-existing function in previous version, so I probably did not rebuild the applicaction correctly. Unfortunatelly I cannot test it right now, but here is a fresh build to test. If it won't work, I will check it after work (in 6-8 hours) 69webos1.elf.zip

There is a issue with these USB applications - they mess up the USB configuration and cannot exit properly. So you can just turn off/turn to exit

[VICLER]

@gabonator 69webos1.elf won't start. I get "Symbol '_ZN4BIOS3ADC7RestartEi' not found! Assertion failed in ../source/main/Execute.cpp [43 J: dwProcAddr Aplication halted .rel.plt>Matching imports...