Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the repo be renamed? #12

Open
KOLANICH opened this issue Oct 17, 2018 · 5 comments
Open

Should the repo be renamed? #12

KOLANICH opened this issue Oct 17, 2018 · 5 comments

Comments

@KOLANICH
Copy link

KOLANICH commented Oct 17, 2018

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).

@KOLANICH KOLANICH changed the title Should the repo be renamed Should the repo be renamed? Oct 17, 2018
@pklaus
Copy link
Owner

pklaus commented Oct 19, 2018

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
Copy link
Author

KOLANICH commented Oct 19, 2018

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
Copy link

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
Copy link
Author

KOLANICH commented Mar 2, 2020

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
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants