Products > Test Equipment

Open source lxi-tools v2.0 released

<< < (18/22) > >>

WaveyDipole:
Sorry, yes, I tested selecting each image format in Save Image->Format:. The result was always the same: Failure handling image format.
I also sent the command manually and it always returned the same header (#9001843254BM6....) regardless of image format selected, in other words, the image size always remained the same at 1,843,254 bytes. I agree, the part specified after the '?' might be an undocumented feature of the command. I hadn't considered that. The MSO5000 programming manual has very little to say on the subject of the DISPLAY:DATA? command and the DS1054Z manual diuscusses the command in more detail but does not mention any parameters.

RoGeorge:

--- Quote from: WaveyDipole on December 22, 2022, 09:35:36 am ---#9001843254BM6....
--- End quote ---

The #9 means the next 9 characters (001843254) will tell the length of the following binary data block.  BM6 are the first bytes from the screenshot (in text representation), BM6 means the picture format is .bmp, which is an uncompressed image format, so it will always have the same length for a given picture size.

If that always stays BM6 no matter the oscilloscope format settings, it means it always sends a .bmp, while the application expects a .png (judging by the SCPI command containing a png request).  Sounds like a bug.

The receiver GUI would be able to detect the encoding by looking at the first data bytes, though I don't know if format detection is the pillow lib's job (or whatever other library the GUI may use), or if the format detection must be dealt with in the GUI code before converting it with a lib.  Maybe the SCPI command for MSO5000 must be changed, too, so the GUI will not assume a PNG, and look at the first bytes of the data to properly identify the format.

Seems clear what is happening, but I'm not familiar with that part of the code so I can not tell the proper fix.  :-\

WaveyDipole:
You appear to be on the right track though. I captured a Wireshark dump of the same command being run on the DS1054Z to determine what actually IS being returned from this scope, as opposed to what the manual says. This is what appears in the output (partial packet contents extracted as printable text):


--- Code: ---#9000031650PNG

IHDR àÒe¢ tEXtAuthorRIGOLÒe¢tEXtSourceDSZ seriesÒe¢)tEXtDescriptionDSZ_Printing equipment outputÒe¢tEXtCopyrightRIGOL TECHNOLOGIESÒe¢z×IDATxí½/¼#W+P A
--- End code ---

So it seems that on the DS1054Z, the 'n,0,png' is valid (as well as apparently undocumented) and does cause the image data to be returned in PNG format. The MSO5000 does not respond to those parameters and is sending the data in BMP format. It would seem that those parameters are either not implemented on the MSO5000 or perhaps take a different form. However, this still does not explain why lxi version 1.21 works...

I have updated the issue that I logged earlier with this additional information. I will also look into whether the format of the data being sent via SCPI can be changed on the MSO5000.

RoGeorge:
My guess is lxi v1.21 properly looks at the answer and detect the format, while the newer ones wrongly assume the returned image is what was requested by the SCPI command, a PNG.  Or maybe the v1.21 is using some older libs format image manipulation, and those older libs were properly detecting the format by looking at the first data bytes, while the newer libs do not autodetect the format.

These are just guesses, only the devs can tell for sure, or yourself if you look at the github sources and compare the two versions.

WaveyDipole:
With the kind support of the lxi-tools developer, this now appears to be fixed and lxi-gui can now grab screenshots from my MSO5074.

https://github.com/lxi-tools/lxi-tools/issues/63

The problem seems to have affected only the flatpak build.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod