Should the repo be renamed?

[KOLANICH]

Hello. Since this lib is useful for the oscilloscopes other than ds1054z, I guess it's a bit strange to keep this name. Should it be renamed? (I have almost implemented some abstractions I hope useful to add support of more oscilloscopes).

[pklaus]

Hi @KOLANICH, thanks for raising this question. I guess there are different options. One would be to rename the repo (do you have a good name); also it would be helpful to see your code to decide about that. Another one would be to fork the project and put your abstractions on top under a new name. Which additional scopes do you plan to support?
Best regards,
Philipp

[KOLANICH]

Which additional scopes do you plan to support?

D-series. And since the same standardized protocol is used for other similar devices, not only rigol ones and not only oscilloscopes, I guess my abstractions are helpful to bring their support too.

The abstractions is the code creating callables from commands + some metadata from the database (I guess in it is a folder of JSON files in source form and in the compiled one it is an archive with them, each file is hierarchy, leaves are method/property metadata). Because I saw no standardized command to get device capabilities, and some incompatible commands cause the connection be reset, so we have to have a DB and I prefer the DB be in data form, not the code. Some commands are common subset among all the devices, some are not, so some inheritance is needed. In an ideal case to add a new device a user only needs to take the pdf with commands available and create a json. I have some regex helpful for that.

[scottprahl]

Hi @KOLANICH,

I have just finished a series of kaitai struct files for .wfm files for various Rigol scopes at

https://github.com/scottprahl/RigolWFM

You might find them useful. Any feedback on improving the .ksy files would be much appreciated!

[KOLANICH]

Nice! Thank you, though I'm not sure that the scope I use uses any of them. It has very old PC software (which is also a piece of shit because the ones writing it had not cared to make sure that the samples from both channels are synchronized, so instead of a line one gets a curve with hysteresis with random shifts depending on random delays caused by OS scheduler) and very buggy firmware (if a SCPI command errors, I have to restart the whole scope, and the program interacting to it also hangs, because the VISA impl used is shit). And the worst of all it doesn't support scpi events (if I tried to use it, the scope hangs). Instead the software uses :WAV:PARAmeter command, the scope responds with a binary answer which format is completely undocumented, the command is just briefly mentioned in the manual. When I just query the waveform immediately after requesting it being captured, it is truncated. I guess the result of PARAmeter must contain some number out of which the time PC needs to wait must be computed (and no number in the blob looks like the time, I guess multiplication to some constant is needed). All the impls on GH wait arbitrary amount of time, but IMHO it is not correct. Do you know anything about the format of output of that command?

[scottprahl]

Oh, I misread. I thought you had the DS1054Z. Which scope do you have? From my skimming, it looks like the early Rigol Oscilloscope programming guides are pretty sparse. The later ones get better (I seem to remember the DS1000Z programming guide as the best of the lot).