mean00 / DSO_STM32Duino

Alternative firmware for DSO150/DSOShell scope
GNU General Public License v3.0
32 stars 8 forks source link

Buglist 1.0.6 #4

Open belotv opened 3 years ago

belotv commented 3 years ago

Hello,

Finally took the time to install 1.0.6 with rotary encoder mod at 128Mhz.

I am really happy with the firmware so far. I also found some bugs I am reporting below: 1) In 5us mode (10kHz test signal with 1V UP trigger), the selector switches between GND and DC constantly, clearing the selection and preventing to go somewhere else in the UI or to revert to another timescale 2) 10Khz test signal is weird with timescale >1ms (2ms, 5ms, etc...) -> looks like <1khz signal 3) 100Khz test signal is weird with timescale >100uS (200us, etc...) -> looks like <1khz signal 4) Frequency calculation is really off. It is based on one period only ? 100Khz at 10uS varies +/- 25khz. 5) Non working functions :

Apart from that, I attach a picture so you can use it in the README. For the firmware to be more widely used you have to polish a little bit the "commercial" side and the picture on the main page is not really appealing :)

belotv commented 3 years ago

IMG_20210125_141145

mean00 commented 3 years ago

2 & 3 are aliasing due to lack of oversampling. Stroboscopic effect. It's better with the GD32 due to its hw oversampling

mean00 commented 3 years ago

6 is fixed

mean00 commented 3 years ago

1- is a conflict about adc2 used for 5us/div and coupling detection. should work, does not.

belotv commented 3 years ago

Maybe a stupid question but aren't you running DMA twice on the same ADC ? return adc->prepareFastDualDMASampling(DSO_INPUT_PIN,set->rate,set->prescaler); ADC is already using PA0 (DSO_INPUT_PIN), shouldn't the other pin be PA5 to use ADC2 ?

mean00 commented 3 years ago

in fast interleaved mode, both ADCs are sampling the same input pin. They start sampling 7 cycles apart, every 14 samples, so you have 7 cycles/samples i.e. twice the speed of a single ADC. The 2nd ADC is also used to sample coupling select There is a conflict on that, i did a crude workardound, but the good way it to inject a sample, need some time to do it

FiusRa commented 3 years ago

Good day. Dear developer. I am unable to compile the project. I just don't understand how to do it. I have a progromator. But how to upload your file with permission. elf. I had no experience with stm32 and DSO STM32 duino. I'm stumped. I have read your entire wiki. Read your entire blog. Also read a small thread on JYETECH. But since I speak another language. This all happens through a translator. And a lot of the main things are missing. Sometimes, when translating, it is not clear what you are writing)))). For example the translator translates me about the compilation elf into bin rfr (turn the elf into a trash can). Could you. Submit or upload a file with permission. bin. With processor overclocking to 128. And which program to use. for the processor firmware. There are many points for the translation to be of better quality. Thank you in advance. R.A I will add windows

mean00 commented 3 years ago

This is the zip file for STM32@72Mhz without usb modification

st-flash write Dso150STM32F103_vanilla.bin 0x8000000

should do the job

If it works, i'll upload the 128Mhz one

Dso150STM32F103_vanilla.bin.zip

You'll need this : https://github.com/stlink-org/stlink/releases/tag/v1.6.1 to get st-flash take the stlink-1.6.1-x86_64-w64-mingw32.zip version if you have a recent windows

belotv commented 3 years ago

For compilation instructions wiki is not 100% up-to-date, the easiest way is basically:

  1. Install Arduino IDE
  2. Download and unzip https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases
  3. git clone https://github.com/mean00/DSO_STM32Duino --recurse-submodules
  4. Edit platformConfig.cmake in the downloaded git files to point
    • the toolchain bin folder extracted on 2): SET(PLATFORM_TOOLCHAIN_PATH "XXXX/xpack-arm-none-eabi-gcc-10.2.1-1.1/bin")
    • the objcopy bin file extracted on 2): SET(CMAKE_OBJCOPY "XXXX/xpack-arm-none-eabi-gcc-10.2.1-1.1/bin/arm-none-eabi-objcopy")
  5. cmake -DMCU_SPEED=128000000 -DUSE_VANILLA_HW=True
  6. make

bin and elf files will both be generated automatically.

Note that if you try to compile again with different flags (like rotary encoder mod) it will not work. You will have to reclone the repository or to comment out the following lines in CMakeLists.txt (seem like a small bug in the compilation process, because we are not even compiling for GD32):

APPLY_PATCH_IF_NEEDED(patched gd32_patch.diff              "add gd32f303 support") 
APPLY_PATCH_IF_NEEDED(patchedm4 m4_activate_fpu.diff       "activate m4 fpu (gd32f303)") 
FiusRa commented 3 years ago

and with the ST-LINK Utility it is possible to do the same as you have just written. that is, I can flash the bin file without arduino dino

mean00 commented 3 years ago

If you use the .bin file directly , you just need st link utilites, no need for anything else

FiusRa commented 3 years ago

ST-LINK Utility firmware has been spilled. the device otkolibrovals. Right now I will transfer the encoder to the pins. Thank you. You can try the overclocked firmware. )))) Thank you.

mean00 commented 3 years ago

Here is the latest version with 128 Mhz clock + fixes for the bugs spotted by belotv Dso150STM32F103_vanilla_128Mhz_head.zip

FiusRa commented 3 years ago

with the second firmware hung on set input to dc processing, on the first the encoder is disabled only by pressing. cut the tracks. soldered wires to 14 and 15.

mean00 commented 3 years ago

If you modified the rotary encoder you need this firmware : Dso150STM32F103_usb.bin.zip (v1.0.6 @ 72 Mhz)

FiusRa commented 3 years ago

the latest firmware is good. the encoder is working. What's with firmware at 128. Why did it hang. I'd like to check the speedy. thank you

belotv commented 3 years ago

Here is 128Mhz / Rotary encoder mod version pre fixes does this one work for you ? dso150_pre1.0.6_128mhz.bin.zip

Maybe some issue with sample injection in the current master.

FiusRa commented 3 years ago

the firmware is working. what is the maximum frequency it can display without spikes. I tried to blow a signal of 100 kHz. test. he shows ka 97-98 -102 that is, unstable.

mean00 commented 3 years ago

The frequency meter is not very accurate at high frequency + the 5us/div range is a bit buggy If you can try using 10u/div, it should be better

FiusRa commented 3 years ago

You tried to fix the frequency. which he reproduces without error. on these firmwares. I do not have a signal generator over 22 kHz. It's very interesting. capabilities of this firmware. And is it possible to record a video of your modifications. for youtube. With links to your sources.

FiusRa commented 3 years ago

horror translator. wrote one translated another. processor 103 has a maximum frequency. indications. frequency. and. what is the maximum frequency possible. see. on a 303. processor. it makes sense to switch to 303. except for the processing speed.

mean00 commented 3 years ago

Not sure i got the point, but The GD32F303 can go up to 120 Mhz, but it's not needed. It has several difference compared to the STM32F103 :

The GD32F303 is between a STM32F1 and a STM32F4. It is cheap (~$2.2), but hard to get at the moment.

FiusRa commented 3 years ago

I agree. transfer. google It's funny. I'll try it differently. manufacturer. declared. characteristics. 200 kHz. signal. maximum. in fact. maximum 100 kHz. shows ok. this is with the official firmware. question. as on your firmware. the device records the readings. what frequency. Maximum. and. Is it possible. replacement of the processor. improve the readings of the device. 303. will improve or not. processing speed. need not. accuracy of readings is necessary.

mean00 commented 3 years ago

The problem is the bandwidth of the analog parts (opAmp in particular) Increasing the CPU clock will not help

It works above 100khz, but the signals get weaker and weaker For example, a 3v signal at 150 khz will be "seen" as ~1v

FiusRa commented 3 years ago

if you replace it with a more sensitive one from the ad8605 or mcp633 or mcp601 series. they are much better than tl084. in my case is tl082

FiusRa commented 3 years ago

Mcp 6022

FiusRa commented 3 years ago

Dso finirsi pro opamp OPA356

mean00 commented 3 years ago

for info this is the latest firmware compiled with the rotary change (better to use the one a few posts below, the calibration bug is fixed)

I'm not sure improving the bandwidth is worth the effort. We are borderline on every aspect. If you have the opamp and the skill to change it, it'd be interesting to see if it really improves things. My fear is that there are over bandwidth limiter elsewhere.

FiusRa commented 3 years ago

it's already night for me. experience is. huge. tomorrow I'll see what are at work. I'll put it. I will write about the result.

belotv commented 3 years ago

Ok just tested last version and it works quite well. Would it be possible to also calibrate ADC2 during the calibration process ? Signal seems to oscillate between 3.05 and 3.3V in 5uS mode. I guess ADC1 and ADC2 need slightly different coefficients ? Honestly if you can fix that, 5uS mode is almost perfect ! You could almost integrate a 2uS mode ;) !

mean00 commented 3 years ago

They are both calibrated but have an offset (and not all the times) i dont know really why

belotv commented 3 years ago

Hmm turns out calibration is broken on master branch. It stays forever on -processing-. Actually I cannot boot my unit anymore as I cannot get past this screen. I will have to revert to previous version.

mean00 commented 3 years ago

indeed fixed Dso150STM32F103_usb_128Mhz_head2.zip

mean00 commented 3 years ago

For the ADC2 vs ADC1, the last commit seems to improve things a lot (not in the binary above) Could you give it a go ?

belotv commented 3 years ago

Ok compiling and testing

belotv commented 3 years ago

Normal calibration works again it master branch, good job :). On my DSO no significant improvement for ADC1 vs ADC2 with last fixes unfortunately, still 0.2V offset between the two, maybe fine calibration would help ? However, fine calibration seems broken on master. I cannot do any action in the menu (or maybe I am not using it properly ?) PS: the half-step support for the encoder is a real pleasure to use ! It greatly improved responsiveness.

mean00 commented 3 years ago

That's weird I tested it with STM32 & GD32 With GD32 , same thing as before with STM32, it's almost flawless if the signal frequency is high enough (>=10khz)

belotv commented 3 years ago

Indeed weird issue. Maybe you were lucky during your recalibation ? Any root cause regarding fine calibration not working ?

mean00 commented 3 years ago

not checked it yet

FiusRa commented 3 years ago

latest firmware. sine wave shows good up to 21 kHz. miander up to 3.5 kHz. saw up to 5.5 kHz. It is not clear how many kilohertz are in the firmware. i.e. if a signal of 3.450 khz is acceptable. readings will be as 3 kHz. This is bad. exact display is necessary. not abbreviated.

mean00 commented 3 years ago

It was just a display issue, this should fix it Dso150STM32F103_usb_128M_head4.zip

FiusRa commented 3 years ago

accidentally shorted. the process was fried.))) respite. experiment. ordering a new processor. sadly

mean00 commented 3 years ago

Sure it's the STM32 and not a voltage regulator or something ?

mean00 commented 3 years ago

Careful, the tracks around the MCU are very thin, it's easy to rip them out (i destroyed one board like that)

FiusRa commented 3 years ago

I already changed. It is good to solder with a hairdryer.

belotv commented 3 years ago

Regarding frequency, I think it would make much more sense to base its calculation on the trigger value rather than local maximums. Basically what we need to do is:

It would be much more accurate, although processing would take a bit more time. We could limit the detection to the X first UP triggers to have adequate precision without impacting performance too much in case of really "unzoomed" signal.

Regarding triggers one huge improvement that could be done is fixing the 1-pixel shifting issue. Even at very slow rate the signal is moving back and forth one pixel. In small time division I can understand it happens but in division like 1ms it should be possible to avoid this (the vertical red line is also moving).

mean00 commented 3 years ago

First one : The problem is that it does not work when you dont use trigger. The 2nd one is partially due to approximation for speed reason , maybe something better can be done

belotv commented 3 years ago

For first one, it does not have to be real triggers, you can determine frequency based on the crossing of (vmax-vmin)/2, that should work too.

belotv commented 3 years ago

Another option is to use CMSIS DSP library for that if there is enough room for it. You can also show signal FFT for example

mean00 commented 3 years ago

The issue was probably mostly the truncated display. It's not that bad with the current master.