The SDS1104X-E decodes what is in the screen, so if you are pushing the i2c start condition out of the screen, it will not decode.
The SDS1104X-E decodes what is in the screen, so if you are pushing the i2c start condition out of the screen, it will not decode.
Strange.
I tried again and my .bmp files are around 750 KByte.
In .jpg format they are 120kByte. Both formats are 800 x 480.
I try to send the 3 screenshots in .jpg format.
I hope things are going well now
P60 seems still broken, so...
I posted roughly the following on page 60 of this thread:
With the recent onslaught of new firmware versions for Siglent equipment, most notably the sds1xx4X-E and the sdg2000X, Siglent's published User Guides (and Service Manuals) have become inaccurate in some respects and parts, and in a few cases just wrong
Is anyone working on documenting these changes, perhaps updating manuals or writing addendi?
Is Siglent addressing this issue?
Strange.
I tried again and my .bmp files are around 750 KByte.
In .jpg format they are 120kByte. Both formats are 800 x 480.
I try to send the 3 screenshots in .jpg format.
I hope things are going well nowFYI not all file types can be uploaded directly to the forum:
Allowed file types: doc, gif, jpg, jpeg, pdf, png, txt, zip, tar, c, h, hex, bas, xls, odt, asm, wav, aiff, wma, mp3, flac, asc, ods, xlsx, py
Many file types can be converted to the allowed types with various programs like MS Paint or uploaded with a false file extension like .txt and add a note to remove the .txt so they can be used in their native/correct format.
All SDS****X-E models export screenshots in .png to USB and are only some 30-70 KB depending on the scope settings.
If your scope settings have been changed and now not exporting screenshots in .png use the Default button to return it to factory settings.
Later so to not have similar issues use the Save/Recall menu to change/set the behavior of the Default button where you can set your own default settings like V/div, active channels, timebase etc, etc.
You can also reset the Default to factory settings if you make some mistake or change your personal default settings later.
No big issue but after pressed the Default button and saved the same scope screenshot with all the possible extensions:
.png 751kB
.bmp 1501kB
.jpg 43kB
A very big difference in size.
No big issue but after pressed the Default button and saved the same scope screenshot with all the possible extensions:
.png 751kB
.bmp 1501kB
.jpg 43kB
A very big difference in size.To USB stick ?
Tip, use the blue Print button to save directly to a USB stick. Much faster than using the Save/Recall menu path.
No big issue but after pressed the Default button and saved the same scope screenshot with all the possible extensions:
.png 751kB
.bmp 1501kB
.jpg 43kB
A very big difference in size.To USB stick ?
Tip, use the blue Print button to save directly to a USB stick. Much faster than using the Save/Recall menu path.
No I saved it via USB and EasyScopeX on my PC. Then in the Virtual Panel right-click and Save As --> the png is 750kByte
But your suggestion 'blue Print button to save directly to a USB stick' did it!
Now the .png file is only 26kB.
Again: no big issue but rather odd and this big EasyScopeX .png perhaps caused the upload problems on page60?
While it should not be the case, does the behavior change if you reduce your sample memory size?
Am I the only one seeing this behavior?
Thanks for the explanation, Performa01! It's good to know that it's not something wrong with my scope.
From an ignorant users standpoint, the behavior does look like a bug to me. I can definitely understand that it's processing a lot of data, and presenting that data will not always be real time. But as I could clearly see, presenting the data is not a bottleneck in itself, as it's quite fast when the memory length is shorter.
So the fact that the trace lags when updating measurements makes it look like the classic "doing background work on the ui thread" issue. Usually solved by doing time consuming work in the background and updating the ui when done. There could be good reasons for doing it the current way, including technical difficulties or complexity, accuracy (though since it only updates once a sec anyway it's not really representing any current state), or they don't worry about it since no one has complained.
Thanks for the explanation, Performa01! It's good to know that it's not something wrong with my scope.
From an ignorant users standpoint, the behavior does look like a bug to me. I can definitely understand that it's processing a lot of data, and presenting that data will not always be real time. But as I could clearly see, presenting the data is not a bottleneck in itself, as it's quite fast when the memory length is shorter.
So the fact that the trace lags when updating measurements makes it look like the classic "doing background work on the ui thread" issue. Usually solved by doing time consuming work in the background and updating the ui when done. There could be good reasons for doing it the current way, including technical difficulties or complexity, accuracy (though since it only updates once a sec anyway it's not really representing any current state), or they don't worry about it since no one has complained.