New Zoyi multimeter+oscilloscopes - ZT-70xS, up to 50MHz/250MSps (nov 2022)

[indman]

I wonder what is the refresh rate for this arrow in your firmware? If it's the same frame rate like in the original (afair 3fps), it's just not worth to spend resources at, and it's better to throw these CPU cycles for something more useful

If this arrow is updated with the frequency of renewal of digits, still very often the arrow is more convenient. I do not need to peer the digits and quickly look at the position of the arrow. In addition, ajar171 makes it disconnected. Who does not like her will just turn it off.

[tol]

The algorithm was:
1. I discharged the oscilloscope.
2. Connected it to the power supply via device for measuring mAh.
3. And charged oscilloscope until it become full.
Final capacity was 2580mAh

You measured the energy used to charge the battery, but not it's capacity. You charged it with 5V while the battery is approximately 3.7V, you should convert mAh to mWh to compare. Besides, the oscilloscope has to convert 5V to the battery  charging voltage that also incurs power losses sometimes up to 10-15%. The energy required to charge the battery is always higher than the energy that the battery can give back, so your measurements are not correct. The correct method is to completely charge the battery, remove the battery from the oscilloscope and discharge it using some li-pol discharger like my iMaxRC B606, it will tell you the true battery capacity. You can try to discharge it through your Keweisi using approx. 0.5-1A load, it may also give acceptable results if this meter supports voltages lower than 5V. You will have to make adapters for it of course. Just for information, I had such keweisi but I gave up using it because it had bad usb contacts and reduced the charging current a lot, maybe it can work better but the usb plug and socket have to be replaced, I was lasy to do it and bought a different model.

[ajar171]

I wonder what is the refresh rate for this arrow in your firmware? If it's the same frame rate like in the original (afair 3fps), it's just not worth to spend resources at, and it's better to throw these CPU cycles for something more useful I've got a Victor multimeter, it has a graph that refreshes MUCH faster than the numbers, and it may be useful sometimes to catch fast changes, but when the refresh rate of the graph is the same as the refresh rate of the numbers, what can it be used for?

It does not matter how often You get new data from the DMM chip, when there is only a single frame buffer.
Step 1: the data arrives, it is prepared for rendering, here you have almost 1/3 of a second. Life is good, code readability is number 1 priority
Step 2: preparations are finished, now we have to wait for the screen banking period (interrupt driven)
Step 3: the interrupt fires, render quickly everything into the framebuffer, before the screen starts displaying the first line. Now this is the tight spot (the screen is refreshed with about 30Hz and the blanking is only a small part). You have to put everything into the framebuffer before the visible stuff gets sent to the display. Everything You see on the screen has to be there in this blanking period. The "needle" or the graph plot is drawn by the CPU only, no DMA help there. (DMA could be used, but that eats more RAM. RAM is reserved for scope stuff at the moment)

All of the above does not matter, because it works and to be honest, I also like it It can also be switched off, so everyone can customize the screen to his liking.

I don't really know at this point in time, how much RAM I will need for the features, that I want to implement. This is the reason, why I am so strict about MCU resources.

Now back to the scope stuff

[ajar171]

You measured the energy used to charge the battery, but not it's capacity. You charged it with 5V while the battery is approximately 3.7V, you should convert mAh to mWh to compare. Besides, the oscilloscope has to convert 5V to the battery  charging voltage that also incurs power losses sometimes up to 10-15%. The energy required to charge the battery is always higher than the energy that the battery can give back, so your measurements are not correct. The correct method is to completely charge the battery, remove the battery from the oscilloscope and discharge it using some li-pol discharger like my iMaxRC B606, it will tell you the true battery capacity. You can try to discharge it through your Keweisi using approx. 0.5-1A load, it may also give acceptable results if this meter supports voltages lower than 5V. You will have to make adapters for it of course. Just for information, I had such keweisi but I gave up using it because it had bad usb contacts and reduced the charging current a lot, maybe it can work better but the usb plug and socket have to be replaced, I was lasy to do it and bought a different model.

Correct and also, the LDOs in the meter need some overhead, so the meter has to be switched off at approx. 3.3V battery voltage. The battery could go lower, but the LDOs dont.

[indman]

Now back to the scope stuff

Yes!

[tol]

All of the above does not matter, because it works and to be honest, I also like it It can also be switched off, so everyone can customize the screen to his liking.

It just came to my mind that the performance is not extremely required in the DMM mode as there are not so many "useful" measurements to do there, and the speed of the MCU should be more than enough to do them all. So, yes, we can probably implement some auxiliary stuff such as jumping arrows It's the oscilloscope mode where all the MCU power should be used for the required "useful" calculations only but not for the neat graphics rendering, font smoothing, etc.

[chebo]

Correct and also, the LDOs in the meter need some overhead, so the meter has to be switched off at approx. 3.3V battery voltage. The battery could go lower, but the LDOs dont.

For the most complete use of the battery, it would be best to use a step-up converter so that it would output +5 V to the circuit at any battery voltage. And the battery itself would be disconnected by the controller at 2.5...3 V. But such a DC-DC converter can produce pulse interference, which will need to be eliminated somehow.

[ajar171]

I found something I cannot understand at all:

The start address of the flash in the MCU is 0x0800 0000.

The reset vector of the Zoyi firmware points to 0x0802 0381, wich is outside of the advertised 128kBytes of flash (0x2 0000) this MCU should have.
If I try to write data to say 0x080F 0000 (way outside the 128k), the data gets written, and can be read back.
Even if I dump the entire 1Mbyte of flash bank starting from 0x0800 0000, there is no wraparound, the test data written before is clearly at the right address, and can only be found once in the dump.

The same goes for flash bank 2 (another 1Mbyte of flash).

WTF is going on here?

Edit: only the STM32H7B3 and A3 have 2Mbytes of flash, but B0 can be seen on my chip (they have lasered it away pretty poorly on my meter, so it can be sort-of read)

[tol]

Edit: only the STM32H7B3 and A3 have 2Mbytes of flash, but B0 can be seen on my chip (they have lasered it away pretty poorly on my meter, so it can be sort-of read)

Computer history knows a lot of cases when more expensive chips were remarked and sold as less expensive chips just for marketing reasons. Sometimes the only thing that makes cheap stuff differ from expensive stuff is a simple limitation flag in firmware

[guyincog]

If this translated to English accurately, you are not the first person to notice that the B0 chips (at least some, possibly all to that point) have 2MB of flash:
https://www.armbbs.cn/forum.php?mod=viewthread&tid=110883

[ajar171]

If this translated to English accurately, you are not the first person to notice that the B0 chips (at least some, possibly all to that point) have 2MB of flash:
https://www.armbbs.cn/forum.php?mod=viewthread&tid=110883

Thanks, I was already thinking, that I messed something up.

Pretty brave from Zoyi relying on an undocumented feature for a commercial product. This also explains, why their bootloader tries to flash an update firmware 3 times, before failing. The B0 chips are maybe binned B3s, that failed factory flash testing above the 128k limit.

Now we have two options:
- concentrate on dumping their bootloader (and RE), so we can flash the alternative firmware using their bootloader and make switching between firmwares easy
- ignore this, and continue with alternative BL (already programmed with the 128k limit in mind ) and loose the ability to go back to stock firmware, but don't rely on undocumented features. I am executing the program from RAM, which is of course much faster, then flash.

[Koleman]

Hi all,
I've had the Zoyi ZT-703S for a week, and after trying almost everything, I can't get the signal generator to work. It only works with the default one (square wave). The other three waveforms (pulse wave, sine wave and sawtooth) don't work with any parameter (frequency, VPP, Duty), and the output signal is 0 V.
I have the latest firmware 1.5.7 installed.
I've tried reinstalling an older firmware with the same result.
Other functions, both the oscilloscope and the multimeter, work fine.
Any ideas?
Thanks.

[bffargo]

Did you check both versions of the siggen? One is off the menu buttons, the other is within the MoreAPPs folder. Could one be overriding the other?

[OLderDan]

That is a great suggestion,  the more apps sig gen won't output if you leave the app, and also there is a 100us limitation if you change the internal sig gen output from default 1khz square wave.

[Koleman]

Yes, I have tested both versions of signal generator.
The one form the main menu works only with continious square wave, the others no output at all.
In the the apps menu the same, only generate output signal form square wave, freq+/- and Duty+/- also works. The other signals sin, triangle, half, full, sawtooth no output (0 Volts).
I can switch on and off the signal generator presing menu key but when I leave the apps siggen off and exit and enter again the apps siggen is on again.
Really extrange for me.
 

[Koleman]

That is a great suggestion,  the more apps sig gen won't output if you leave the app, and also there is a 100us limitation if you change the internal sig gen output from default 1khz square wave.

Yes, I know the 100us limitation but the issue is that thare are no output signal rather than the default scuare pulse.

[ajar171]

The apps/signal generator is literally a separate piece of software. If You open it, the oscilloscope software stops running. If You close it (and return to the scope) it stops outputting the waveform.
This is a hardware limitation and there is no way around it (there goes the missing FPGA again).

The technical part:
The square wave is coming from a PWM output pin in scope mode and the signal generator output comes from a DAC pin.
The PWM output is generated by a timer, and does not need DMA or the CPU to do its job. The DAC needs DMA and the scope input too and they would need to share the same bus (would be a very bad idea).
Only triangle wave and noise output can be generated by the DAC in hardware without DMA and I have no idea, why Zoyi did not allow at least those 2 signals, while running the scope.

TBH, the two could work together, but only at very low sample rates, it is not worth the effort.

[Koleman]

Tested with a professional oscilloscope Tektronix TDS 220 definitely signal generator doesn't work. Probably my ZT-703 came damaged internally. You can check it in this video.

https://youtu.be/WDzrVXKuBy4

[ajar171]

Tested with a professional oscilloscope Tektronix TDS 220 definitely signal generator doesn't work. Probably my ZT-703 came damaged internally. You can check it in this video.

https://youtu.be/WDzrVXKuBy4

Sorry, I have misunderstood You! That is a defective output. Since the square-wave gets out of the meter, the output op-amp is at least working.

Try to send the unit back to the seller, if it does not work, maybe I can help You with a repair.

[Phb]

You can check it in this video.

https://youtu.be/WDzrVXKuBy4

Based on this video...

I agree with ajar171, I would conclude that there is something gravely off wif your unit.

For the Sig Gen using "F4", I am sure what you are seeing is not what I am seeing on my unit.

For the "More Apps" Sig Gen, I am less sure, as I dont have another scope to view its output.

[tol]

Now we have two options:
- concentrate on dumping their bootloader (and RE), so we can flash the alternative firmware using their bootloader and make switching between firmwares easy
- ignore this, and continue with alternative BL (already programmed with the 128k limit in mind ) and loose the ability to go back to stock firmware, but don't rely on undocumented features. I am executing the program from RAM, which is of course much faster, then flash.

The first option is more preferable in the initial stages of the new firmware development. I think I don't have enough skills to resolder STM32. While the new firmware is not completely ready, I'm not sure that I want to overwrite the original bootloader and spoil the possibility to upgrade to new official releases, and I still hope that they will fix this never-ending trigger issue some day and the oscilloscope will become useful as it is At the other hand, the second option allows unlimited further improvements of the firmware and adding new features that Zoyi will never implement. So, you are the developer and it's up to you to decide. If it's possible to start the development using the 1st option so that many users could test it safely. And then, when the firmware proves to be reliable and better than the original, redesign the code for option 2. If this is not much extra work to do, this would be a great solution. In any way, it's up to you to decide because nobody knows how far you are going to climb with it. If you have tons of plans to implement, this 128 kb limit will be a problem of course.

[wedgehog]

Anyone got a link to ver 1.55 please?

1.55 - https://drive.google.com/file/d/1xgdgFe6GohxC1WyyIX2O0uyEkZHiOHiv/view
1.56 - https://drive.google.com/file/d/12Gxb3DFtqoraxpqkC3cRqKC9haMOEV1Y/view

Thank you, much appreciated

[LinuxGuy123]

I knew it was only a matter of time before someone hacked the firmware on this device.   I was thinking of buying one (as a desk MM/Scope) but now I will for sure.   I'm super excited to see decoding is planned to be worked on.

I've done a fair bit of STM32 development.  I'd love to jump into this project but I already have too much on the go.

Keep up the good work.  Reach out if I can be of help.

[Phb]

If you are on the latest (1.57 at time of post) try going to the output menu and watch for the weird glitch where the wave select box briefly flashes yellow then back to red the first time you select it.

Thanks OlderDan, credit to you.

I decided to make a video on the "glitch".

https://www.youtube.com/shorts/y7THPaNuFa0

[Koleman]

If you are on the latest (1.57 at time of post) try going to the output menu and watch for the weird glitch where the wave select box briefly flashes yellow then back to red the first time you select it.

Thanks OlderDan, credit to you.

I decided to make a video on the "glitch".

https://www.youtube.com/shorts/y7THPaNuFa0

Same "glitch" in my case.
Have you check if the signal generator really works?
Not for me, You can see may last post and the video