New 2ch pocket DSO+SG - Zeeweii DSO2512G

[Dry]

Found a solution for the DC measurement balance issue. There is a possibility of manual calibration DC offset and gain by opening Meas in Menu, then shortly pressing CH1CH2 button (the green 2 appears) and then hold V to enter the offset calibration mode or hold mV to enter gain calibration mode. The calibration is made by pressing vertical arrows for the channel 1 (in both modes) and horizontal arrows for channel 2. NB: offset calibration is set for each vertical scale value separately, but the gain value is one for all diapasons on each channel. So to make the calibration rapidly and correctly you need to start with offset for each diapason (the appropriate vertical scale should be chosen before entering the calibration mode, it cannot be changed when calibrating), then chose the vertical scale value where the DC values are median and use it to set the gain. I managed to set the DC measurement accuracy pretty within 1% (see photos, CH2, the true value is 8,25 V). Before the max spread (at 20 V / div) was up to 15%!

[REWEREWE]

... I managed to set the DC measurement accuracy pretty within 1% (see photos, CH2, the true value is 8,25 V). Before the max spread (at 20 V / div) was up to 15%!

Thanks for the detailed description of calibration. I would like to draw your attention to the fact that if we calibrate different vertical ranges of the scale using the same voltage, we will get a fairly large error for voltages typical for each scale.

[Dry]

... I managed to set the DC measurement accuracy pretty within 1% (see photos, CH2, the true value is 8,25 V). Before the max spread (at 20 V / div) was up to 15%!

Thanks for the detailed description of calibration. I would like to draw your attention to the fact that if we calibrate different vertical ranges of the scale using the same voltage, we will get a fairly large error for voltages typical for each scale.

May be not, because the gain is the same for the whole set of scale ranges, you can adjust on each range only the 0 (DC offset). In fact I used the same voltage to calibrate my device (and combined probes gain x1-x10 and device sensitivity x1-x10), but after that I have no sign. error with real voltages.
PS: The DC measurements are much more accurate in two channel mode, I have no idea why.

[chemary]

I have noticed that some measurements change when switching from normal mode to single mode, is like if it adds an offset. It's happening for certain signals on AC and DC mode. If I keep switching from normal to single at some point it gets fixed. I have restarted multiple times and keeps happening. To reproduce I only have to power-up the unit, click auto and then single. Maybe somebody can explain what is happening looking at the screenshots.
The hardware version is V9.15 and the firmware v1.3.0C

[Update] while testing to write this post, with the same signal (well is a joule thief output and has slightly changed) I can no longer reproduce the problem, but I used an other signal (joule thief input "attachment sample3.jpg") and it happens again, I also checked with a better oscilloscope and the normal mode values are correct.
[Update2] It happens even with the integrated FG, to reproduce I set 1Khz sinusoidal, I click "auto" then I decrease vertical scale with "V" and press "single" and that's it I get incorrect measurements.

[Dry]

I tried to reproduce the issue when measuring in AUTO and in SINGLE mode, and got the same strange results - regardless of number of waves on the screen and trigger position. But since I changed the waveform (in built-in generator), the measurements became correct, and stay correct after on-off procedure and with all waveforms. But! I noticed that the incorrect values are displayed when I move the waveform up and down (only in SINGLE mode indeed), however when switching between AUTO and SINGLE no more issue is observing.

[chemary]

Thanks @Dry for confirming that is not only my device. It seems there is a software bug, the problem is that the vertical displacement is not took into account in single mode, it adds the offset to the measurements. I have sent a message to Zeeweii support and I'm still waiting their response, I hope they release a fix. What seems strange to me is that there are no more reports of this issue as it seems pretty easy to replicate, maybe only affects last firmware revision.

This is the refined way to replicate the problem:
1. Connect the integrated Function Generator to CH1
2. Configure the integrated Function Generator to 1Khz square wave
3. Click "Auto"
4. Go to "Measurements" menu and enable "Mean" "Min" "Max" (all absolute voltages are affected)
5. Check that "normal" and "single" mode display correct measurements (clicking "Run" and "Single" alternatively)
6. Move signal up with up arrow "^" for instance 500mV
7. Check that "single" mode display invalid measurements (measurements are increased by 500mV)

It would be great if the Vertical/Horizontal offset is displayed somewhere when you move the signal around as most oscilloscopes do, it would have helped to spot the problem.

[Dry]

It would be great if the Vertical/Horizontal offset is displayed somewhere when you move the signal around as most oscilloscopes do, it would have helped to spot the problem.

In fact there is no vertical offset, the waveform is displayed correctly in SINGLE mode as well as in AUTO. Only the measured values are incorrect, but where is the zero used for that miscalculation - that is the mystery. The waveform position is automatically set in AUTO mode; when using the built-in generator this zero in far below the central line and it seems be used for every position of the waveform on the screen in SINGLE mode. Afaik the only way to measure the waveform correctly in SINGLE mode is to use the cursor lines (see below).

[Aldo22]

Yes, this seems to be a bug.
However, there is a simple workaround on my device.
After you have moved the offset, press "Run/Stop" once (from the "Auto" state).
This also seems to update the offset values for "Single", so the correct values should be displayed afterwards when using "Single".
Simply repeat after each time you move the offset.

[chemary]

Yes, this seems to be a bug.
However, there is a simple workaround on my device.
After you have moved the offset, press "Run/Stop" once (from the "Auto" state).
This also seems to update the offset values for "Single", so the correct values should be displayed afterwards when using "Single".
Simply repeat after each time you move the offset.

Thanks @Aldo22, I tried and it works, not ideal but at least we have a way to get correct readings.

[peter__s]

It should also be possible to read/write the SPI flash chip via USB "FEL" mode but only if you can insert a microSD card into the microSD slot, so you can enter USB FEL mode, which is impossible to do since the battery connector is in the way 

Some thoughts about solving this issue:
While cutting SIM cards from Mini to Micro or Nano was popular, judging by pictures from the WWW from data recovery specialists, it seems to be a bad idea to shorten microSD cards so that they can be forced into this slot. Likewise, trimming the PCB-side battery connector is certainly an easy mod, but it would remove the bits that keep the battery-side connector in place. https://www.reichelt.de/raspberry-pi-microsd-verlaengerung-flexibel-15cm-rpi-msd-fl15-p223611.html should also work... or:

• One option seems to be to add a new (micro)SD card socket (e.g. a microSD to SD adapter) connected with wires, without changing anything else. One could even orientate it sideways and dremel the housing allowing easy access.
• I considered unsoldering the bottom two pads of the microSD card socket and tilting it a few mm up, allowing the card to bypass the battery connector. I happened to have some chinese device with the same microSD card socket that I decided to experiment with. It turns out, that the release mechanism contains a small but powerful spring. The card socket's housing has two pins sticking out of its bottom surface into matching holes in the PCB to help protect the solder pads from mechanical stress.
  While careful handling would allow occasional card insertion or removal and hot glue or epoxy could be used to fill the gap and secure the socket in its new position, removing the spring requires unsoldering the remaining two pads of the socket's top and further exposing its innards along with abandoning its ejection mechanism.
  Replacing the socket with a top-loading or short alternative like Molex 105162-0001 seems more favourable but involves more soldering and risks.
• Another approach would be to unsolder the battery connector from the PCB and either replacing it with one that faces up and offers more clearance or using its pieces to achieve something similar.

Has anybody solved that yet?
What are your thoughts?

I was likely to try the third option soon. But upon writing this post, I astarted thinking that simply trimming the top with sharp scissors is the quickest of all quick-and-dirty approaches, allowing to insert a card at an angle and bypassing the battery connector. After trying that with my donor socket mentioned above, I decided to carefully bend the oscilloscope's microSD socket top up with a small screwdriver instead, allowing me to insert and remove cards after unplugging the battery without further modding.
Please note that the nineth contact of the microSD card socket (allowing to detect whether a card is present or not) is not connected to the F1C100s (while all others are). Hotplugging is probably a bad idea.

BTW, I have PCB V9.15 with FW 1.3.0C

[chemary]

• Another approach would be to unsolder the battery connector from the PCB and either replacing it with one that faces up and offers more clearance or using its pieces to achieve something similar.

Soldering the battery directly to the PCB seems quite easy, just remember you have done it to avoid ripping the contacts if you pull the cables. If the battery last for some years you can apply hot glue to avoid it.

[timschuerewegen]

I was likely to try the third option soon. But upon writing this post, I astarted thinking that simply trimming the top with sharp scissors is the quickest of all quick-and-dirty approaches, allowing to insert a card at an angle and bypassing the battery connector. After trying that with my donor socket mentioned above, I decided to carefully bend the oscilloscope's microSD socket top up with a small screwdriver instead, allowing me to insert and remove cards after unplugging the battery without further modding.
Please note that the nineth contact of the microSD card socket (allowing to detect whether a card is present or not) is not connected to the F1C100s (while all others are). Hotplugging is probably a bad idea.

BTW, I have PCB V9.15 with FW 1.3.0C

FYI. A few weeks ago I desoldered the battery connector and replaced it with a compatible connector that had red/black wires attached to it, so I could insert a microSD card without having to mod/replace the microSD card socket. I tried that special "jump to FEL mode" SD card image but it did not work. Either I did something wrong or the microSD socket is not wired up fully/correctly for the F1C100s bootrom to detect/read from the microSD card

[marcs18]

Hi
could anybody offer to download the mos recent  DSO2512G firmware compatible for the pcb v 9.15?
I'm also have a problem with the channel 1.   the offset  it is starting with 5VRMS . It looks  any internal reference is damaged. Did anyone have this problem? if yes , is it a HW problem or  just FW update could fix the problem?

[Tomasieel2024]

Hello friend, I would like to join your discord server, and also know how you linked the oscilloscope in that way through the java app to widnows, greetings

[marcs18]

I actualy , tested the channel 1 and noted  the imput is not working. The equipment is not measuring anything. When i connect the osciloscope - input 1 to the signal generator , the osciloscope doesnot measures , in fact i feel it is instable, like the signal isnot going to the measuremet circuit. the offset also  set to -5V RMS. Does anyone have any idea about the origin of this problem? I suppose the input 1 burned. I do not have the schematics of DSO2512G, so , any information would be helpful.
Detal: Channel 2 is working properly , only channel 1 has this strange behavior......

[Aldo22]

I do not have the schematics of DSO2512G, so , any information would be helpful.

Jebem posted schematics:
https://www.eevblog.com/forum/testgear/new-2ch-pocket-dsosg-sigpeak-dso2512g/msg4886369/#msg4886369

[chemary]

The input circuity of ch1 and ch2 is mirrored, if channel2 works fine something between input and the ADC may have burn. Remove the shielding and you will see components are duplicated,
inject the same signal to both channels, then use a multimeter compare at some points to see at which point the input is different.
I suggest to start checking transistors, diodes and ICs close to the input (well do first a visual inspection to see if the burned component is evident).

[Dry]

I actualy , tested the channel 1 and noted  the imput is not working. The equipment is not measuring anything.
...
Detal: Channel 2 is working properly , only channel 1 has this strange behavior......

Check the probes by swapping them (I doubt it's them, just to be sure).

[marcs18]

Thank you for the schematics. I noticed they are draft, so some details are missing, anyway they are very helpful . Thank youso much

[marcs18]

Thank you. it makes sense. i removed the shield and realy both circuits (ch 1 and ch2) are similar. I will follow your suggestion . Thank you again

[Defischer]

what a nice work, can i join your Discord server?

[Heatsink]

Hello, has anyone tried to implement nicer looking fonts? I am quite satisfied with this scope, but the fonts, especially with an external screen, remind me of my Atari from the 80s.

[Swift Tester]

Received my DSO2512G. HW 9.15 FW 1.3.0C
Picked this model after researching this thread, final decision was made when I learned about mod and PC app by @timschuerewegen.
Nice work, Tim! ZEEWEII owes you at least one more sale
I'll ask some questions in Discord.

[timschuerewegen]

Hello, has anyone tried to implement nicer looking fonts? I am quite satisfied with this scope, but the fonts, especially with an external screen, remind me of my Atari from the 80s.

The font data is 1-bit so this is as good as it gets without changing the font drawing routines to use 2/3/4-bit font data with anti-aliasing but that would also introduce other problems, so not an easy change.

[latcakir]

can't save XY mode