Add simple voltmeter mode with auto-range selection

Dedicated mode:
Analog Display/Bargraph.
Huge numbers.
Auto Range for Voltage.
Min/Max/Avg/RMS Display.

Activate through button combination? (V/Div + Trigger)

My vertical position is off. All ranges are set to about 1.5 Div higher.
The old firmware said to hold the V/DIV button for 3 seconds to Autocal.
How do we do it with this firmware?

In pic time base set for 0.2ms/div and I have 1KHz test signal connected. You can count about 1.5mS/period and not 1.0ms like 1KHz should have. The cursors calculate correctly and Stats overlay are correct. I even re-flashed latest OEM firmware ( 113-15001-120) and it shows correct horizontal scaling. The Vertical voltage scaling seems correct, only the x-axis scaling seems to be off. I did the Initialization with OK-power-on and did AUTOCAL twice

Should add longer time-base and at slow sampling rates display should scroll (Add data to end of FIFO) instead of replacing the data.

Ok.. I loaded the atollic true studio thing.
I downloaded this project.
I imported the project.
I went to build project and it take two seconds with no bin or hex generation. I really think it's not building everything! Here is the console output:
12:04:34 **** Rebuild of configuration Debug for project dso_150 ****
Info: Internal Builder is used for build
arm-atollic-eabi-gcc -c -mthumb -mcpu=cortex-m3 -std=gnu11 -D__weak=attribute((weak)) -D__packed=attribute((packed)) -DUSE_HAL_DRIVER -DSTM32F103xB -I../Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -O1 -ffunction-sections -fdata-sections -fno-strict-aliasing -g -fstack-usage -Wall -o Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_hal_gpio_ex.o ..\Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_hal_gpio_ex.c
arm-atollic-eabi-gcc -c -mthumb -mcpu=cortex-m3 -std=gnu11 -D__weak=attribute((weak)) -D__packed=attribute((packed)) -DUSE_HAL_DRIVER -DSTM32F103xB -I../Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -O1 -ffunction-sections -fdata-sections -fno-strict-aliasing -g -fstack-usage -Wall -o Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_hal_dma.o ..\Drivers\STM32F1xx_HAL_Driver\Src\stm32f1xx_hal_dma.c
Info: Parallel threads used: 2

12:04:34 Build Finished (took 485ms)

I'm sure I'm missing something stupid... this is version 9.3.0 of the truestudio.

Just compiled last version, and if i set free running, after power up the display appears wit no line. Pressing trigger a few times get it back.

I'd like to do some dev/debugging on the board, and own an ST-Link V2, but am not sure what pins I should use to connect (did the mod to update the FW using an USB/UART converter, and know it's not the same pins). Which ones should I use ?

Actually, current code is not for F103C8T6 STM32 which is used in DSO150.

Anyway, it can be easily changed.

I've downloaded the latest version, compiled and flashed the firmware on my DSO 150, and am Learning to use it. During my tests (don't know what I'm dooing, so keep trying different things), I've found out that I don't see GUI updates when switching from AC to DC and back. Switches from/to GND seem to update though.

Limit Range of Trigger position to visible range so Trigger-Icon does not end up off-screen

What about this new two channel device?
https://jyetech.com/wave2-2-channel-portable-oscilloscope/

Not only it has two analog channels, but at the bottom there are some pins which look like they can be used for digital inputs. At least few of them. Checked the schematics and most of them are not suitable, but some are.

I like the features of this firmware but it seems like it's very heavy on my dso150.
the refresh rate is low, sometimes it's stuck and not response to any button and sometimes the screen not cleared from the previous draw and continued to drew new lines on top.
I don't know if this behaviour is normal.
my unit working fine with the official firmware.

Hi,
I was trying to build this to try on my DSO138.

I commented out the following defines in global.h:
#define DSO_150
#define ADD_AN2
#define ADD_D3
#define USE_ENCODER

... then built, and I got a number of build errors, most centering around variables that are defined for DSO150, but not for DSO138 (eg RNG_20V,RNG_10V, RNG_5mV), yet they're used elsewhere.

I did confirm that the original options for DSO150 would build, before I made changes to global.h, so I believe I've got the right board and libraries selected (STM32F103C8). Also, I'm able to build from the project you forked (ardyesp/DLO-138).

Do you see anything wrong with my assumptions, or is it just the case that building your code for DSO138 is currently untested, and will need some fixes?

Thanks!

Instead of scrolling trough menu items just show "Menu" at the bottom and when activated open dedicated menu screen with options.

The V1 and V2 values seem to be Absolute Voltages from the Top of the Graph and Vd is the correct value, but why are V1 and V2 not relative to GND ref, Hence, instead of V1=2.61V (in pic) it would be 3.36V and instead of V2=5.98V it would be 0V and still Vd would be the difference (3.36V)

After flashing your firmware, the display orientation is 90 degree clockwise shifted. How to solve this problem?

I search in the issues and through the code. I can't find any reason/comments why the 10us/div
isn't supported. I vaguely remember seeing something about interleave mode or something (not necessarily here), But I can't find anything.
Why can't we have 10us/div mode? The stock scope has it?

Otherwise FANTASTIC software! Thanks again!

Can you please output waveform to sigrok / pulseview software over serial port?
https://sigrok.org/wiki/Supported_hardware

It's awesome piece of opensource software and it would be really great to have sigrok mode in open-dso-150. It can be used for protocol decoding, timing analysis and much more. pulseview is sigrok GUI and it can even be used to control the devices, set scope to running mode or set triggers.

There has been talk about issues with rotary encoder has software debounce been implemented into the code?
MX_TIM16_Init Does the debouncing of the rotary encoder and decrements the timeout value. This timer is normally OFF and only started when there is movement detected on the rotary encoder. This movement detection is done via EXTI interrupts on the GPIO connected to the rotary encoder. When running, this timer produces 1000 interrupts per second. When the timeout reaches zero this interrupt routine disables itself and re-enables the EXTI interrupts.

MX_GPIO_Init Sets several GPIO as input and output and takes care of enabling the EXTI on some inputs.

Hello,

There is an open source data logging project here for the DSO150 - https://github.com/rudi48/dso150-110-plot/wiki#dso150-110-plot

So I was just wondering if this firmware can work with that, and provide the necessary data export functionality ?

Encoder and button performance on DSO-150 is pretty bad. The underlying issue is the dual use of GPIOB for display data output for thw display and encoder/button input.

Toggling IRQ's on/off when the display is using the lines kind of works. (And could be improved by linking it directly to the CS line enable/disable by the display driver).
It is also possible to try to just set a flag in the display driver code when accessing the data lines and just branching out of the IRQ routine while the display is using the lines.
(HW will trigger IRQ's on GPIO lines if enabled independently if they are set to input or output...)

None of this though will prevent user interactions to get lost.

For the encoder this is not that problematic as the user just continues to operate the encoder until the desired action happens. (Reducing the dead-time will improve loss of signal codes/transitions and response...)

For buttons this is a bigger problem. If the IRQ is disabled while the button is pressed/released the event is lost as all interrupts are edge-triggered. This leads to either lost key events or key presses getting registered as long presses as the short release pulse is missed.

Therefore currently buttons are polled which allows the level of the line to be monitored at the polling time and not rely on edge transitions but this causes issues when the timebase gets longer as the acquisition routine blocks polling. Switching to DMA for the data acquisition might improve this.

Automatically scale range of voltage selection.
Increase Gain based on min/max so waveform fits into range
Decrease gain if at range limits until min/max is below range.

Mark Trigger Position in X-Direction with Line in Waveform Drawing

Currently data acquisition is done by polling the ADC's which will block buttons and limits the maximum sampling rate. A lot of those limitations could be resolved by using DMA driven ADC data collection.
Digital Input should still be possible by using ADC IRQ to trigger digital line storage.
Acquisition mode could probably be improved by using continuos mode into a buffer and then use the trigger to stop ADC capture after 1/2 buffer size (So we have data from before the trigger in the Buffer...)

ADC StartConversion() Routine

1. Setup ADC Analog Settings/Capture Mode
2. Setup Timer1 as external ADC Trigger Source
3. Setup Timer2 as Timeout Timer
4. Link Timer2 IRQ to Trigger IRQ Routine
5. Setup ADC Analog Settings/Capture Mode
6. Setup DMA Address/Conversion Length
7. Set Start Address for Digital Input Capture Array
8. Link ADC Conversion Complete IRQ to Input Capture IRQ Routine
9. Link DMA complete IRQ to DMA IRQ Routine

Trigger IRQ Routine

1. Disable Trigger IRQ
2. Start ADC External Trigger Timer

Input Capture IRQ Routine

1. Store IO Register in Array
2. Increase Array Pointer

DMA IRQ Routine

1. Disable Input Capture IRQ
2. Disable Timer1

Should make it easier to relate actual trigger-level to incoming data (And draw level at right places in UI...)

UI becomes annoyingly unresponsive with longer timebase. One solution is to use timer to trigger sampling...

Hi. I just flashed my dso and my screen is rotated by 90 degrees. When I tried yesterday's version, my screen was rotated 180 degrees. This is probably caused by recent support of ST7789 display.

Unfortunately, I have no idea what model my display is.

Allow Triggering on Raising/Falling/Changing Edge on Digital Lines. Not sure why it is not working (Should just be in interrupt) but I seem to be unable to trigger that IRQ routine.

When compiling I am getting 20 warnings (see below). I did not try flashing yet. Is this normal or something is wrong.

I just got a clone of the DSO 150. I didn't do my home work before I purchased it! :-(
With the current firmware (V62) I can't display correctly @ 20us and 10us/div.
I can see it triggered, but I get no waveform on the display.
I was going to try this open DSO 150 thing but I can't seem to save the original firmware.
It seems to be protected. I have to erase everything. So...
Will this open DSO fix my triggering issues?
Is there a pre-compiled hex to load?
Is there anyway to go back to the clone V62 firmware if the open DSO doesn't work for me?

Thanks,

Jim

So, I'd like to know if it could be possible to get some basic installation instructions.
This firmware looks really interesting but, after about 2-3 hours of tests, I can't figure out how to get it on my scope. I do not own an st-link adapter so I need to flash the firmware with a usb-serial adapter.
I downloaded and installed truestudio. I imported this project in truestudio and enabled the output of a hex file in the build settings. When I try to compile the project, only the debug build compiles. When I set the active build to release, the build fails with an error message (..\Src\Adafruit_GFX/../TFTLib/Adafruit_TFTLCD_8bit_STM32.hpp:16:27: fatal error: stm32f1xx_hal.h: No such file or directory
#include "stm32f1xx_hal.h")
If I flash the hex file obtained from the debug build to the scope using the basic method described by jyetech, the flashing of the firmware is successful but, even after removing the bridges on jp1 and jp2, powering the scope only leaves me with a blank white screen.
Do you have any idea of what I am doing wrong?

Add Cursors for X/Y Positions for measurements

Essentially in that mode each rotation should move the curser to the next pos like just pushing the rotary dial does so one can move to a different location faster....

../Src/stm32f1xx_it.c:228:2: warning: implicit declaration of function 'HAL_GPIO_TRIG_IRQHandler'; did you mean 'HAL_GPIO_EXTI_IRQHandler'? [-Wimplicit-function-declaration]

Is it ok to ignore this? Firmware appears to work

Yes, I can open an issue !

My DMM can only output 5Khz and it worked fine. Do Digital inputs show more than 200kHz?

Great little tool. I have a AD584LH precision voltage reference did an AUTOCAL and meter set to LOOP and VOLTMETER mode on.
Fed 2.500V, displayed 2.28V, fed 5.000V, displayed 4.57V, fed 7.500V displayed 6.85V, fed 10.000V displayed 9.09V.
Would a 2 point voltage calibration work better?

We need this !

To keep track of what is same / missing, and so it can be updated incrementally. When either one or the other gets updated / improved.

Sec/div is not working correctly, some settings of the sec/div don't change anything.

Hi. This weekend I've flashed OpenDSO150 to my scope and, after struggling with display rotation (#44) have a working device. There are severe issues that I am having at the moment. I am posting them all as one issue for the time being, because there is a possibility that I am missing some small but important step during setup and all the issues might be resolved with one action.

1. I cannot boot without holding OK button. If I boot without pressing OK button, the program hangs somewhere on C++ DSO screen (in printConfig, to be precise). Does the program stores settings if it resets them, or do I need to save them manually?
2. Analog readings are completely broken:
   • zero values are not at zero: if I short + and - probes, I get the reading equal to my voltage scale (at 1V I get readings around 0.96V, at 5V somewhere around 5.2V etc).
   • slopes are somewhat too smooth, but cannot compare it consistently with stock firmware.
3. Rotary encoder is inverted for timescale: if I turn CW, it decreases the time period. Is it supposed to work this way? Stock firmware had it the other way around.
4. It is also not reliable - sometimes it changes the value in opposite direction, sometimes does not change at all. It happens with all values, not only timescale.

So, is this known behavior? Can I fix it?

hi everyone, is it possible to upload a bin file for dso150 ?

Hello, from what I see, you have very similar code to DLO-138, when it comes to dumping samples to Serial...

I am writing GUI for displaying data from DLO-138.

Would you be willing to test it with 150?

I do not have hardware...

For now, it is just CLI, parsing output...

If it does parse, then, it will work with GUI also...

I just want to thank you for your spirit to have this working, i was not ale to compile the dlo-138 as the bin file is about 70K and when I switch to stm32f10cb i just get black white screen, I just compiled your code and upload it to dso-138m yes it boots fine teh screen comes with a square signal then i see the HOLD is on , I have DSO-150 and will try that next weekend, again thank you alot, be always blessed.

There seems to be sometimes an issue that the scope is stuck in GND mode (No signal) no matter what the switch position is.
Or maybe this is something else, needs to investigate....

Save and load waveforms from/to eprom

Currently there is no good way to calibrate the system to show the actual voltage of the incoming signal at gains differential the unity.
Need to find a way to better calibrate this either with external voltages or internally....

Add times X probe pre-gain settings to deal with x1,x10,x25 Probes

Calibrate Trigger values so that trigger level can be referenced in Voltage in UI and correspond with UI of sampled values

Thank you for the great work with this firmware.
I've just flashed it on my scope and I noticed a weird behavior where the red and blue color channels seems to be swapped. Nothing too fancy and (probably) easily fixable but worth mentioning.

I took a look at the code and in global.h the analog line should actually be yellow:

// display colours
#define AN_SIGNAL1    ILI9341_YELLOW
#define DG_SIGNAL1    ILI9341_RED
#define DG_SIGNAL2    ILI9341_BLUE
#define DG_SIGNAL3    ILI9341_GREEN

As expected the ILI9341_YELLOW is defined in the Adafruit library:

#define ILI9341_YELLOW      0xFFE0      /* 255, 255,   0 */

Maybe a change with the new LCD controller?