Just to close my case : i finally bought the CGR-101 from Syscomp. Cheap, linux-compatible and GPL software (wine not needed), great manual.
syscompdesign.com
After many attempts, I got some results with Virtualbox in Linux. But I had to install XP in it ! Now the blue led of my PCSGU250 is on ! and the setting was performed. I am finishing my electronic circuit for more testing.
Hello,
I have a university course project on operating systems, and I’m considering a possibility of killing two birds with one stone — revive Linux PCSGU250 driver development (so I wouldn’t need a virtual machine for my oscilloscope) and make a course project (to write a kernel module for Linux is one of possible options for this project). I would like to ask for a copy of specs for me. My email is nikoamia, which is on gmail.com. Thanks in advance!
Hello again,
Sorry for bumping this thread again. Unfortunately, I have some deadlines, so I should know whether I can start it or not. I have my old project, which is based on USB sniffing, but I only managed to load firmware into oscilloscope and set some parameters, with many problems because of having no knowledge of communication protocol. I cannot take reverse-engineering communication protocol as one of tasks for course work because it will involve quite some time and we have strict deadlines. So I’m asking for some answer if I should wait for specs or get some another project.
BTW, here is my plan for now:
- Write an abstract library for talking with oscilloscope, setting it and receiving data from it.
- Write kernel module which will expose /dev interface and will make use of that library.
- Write graphical front-end (on Qt, I suppose), which will use that interface.
- After my main project is done, maybe make a libusb-1 version so it will be platform-independent.
Of course, it will be an open source project. Libraries will be written in plain C89, with GUI on something more high-level, such as C++ or maybe Python. This project will be aimed only on PCSGU250, because I have only this piece of hardware, but if there is interest and necessary documentation, I will consider making another back-ends and I will generally try to make this project as device-independent as possible.
I’m sorry, no document in English is available.
The document made for klaine8 was very draft
Hm, this is a pity. But can I take a look on it? I think it might be of some help, and I can reverse-engineer remaining info if things go well. To tell the truth, I’ve seen that document for klaine8 from his website some years ago (when my project was already abandoned) and AFAIR there was a well-documented configuration packet (with all flags, even brightness of LED) and some data on how to read from oscilloscope and write to generator, and I’m looking primarily for this one. Unfortunately, klaine8’s website is down and I cannot find this document anymore. If we are talking about the same document, I would like to ask a copy of it, please.
OK - Here is the link to the document: box.com/s/cxybc16r7o5kqb65u6ct
You may try Google Translate with “Detect language option”… 
Yes, that’s exactly the same document — I’ve remembered myself understanding it though variable names. Thank you, I’ll try to get a simple prototype working, get an approval from my supervisor and report my success (or failure).
For now I’ve translated big parts of that document into English (Google Translate is awesome) and wrote simple prototype in Python/PyUSB which can configure oscilloscope, generator and dump data from oscilloscope. I have a mercurial repository: bitbucket.org/abbradar/scope, where I’ll storage all my source code (for now it is empty, I will polish complete parts of translation and will make some commits then). I’ve received some missing information on protocol though USB sniffing. For now I have a question without answer — the PCLab2000LT sends command 0F at the end of configuring the device, after which it receives 64 bytes of data. My question is “what is this?”, it is not mirrored in the document. It would be very cool to get an answer from a developer, even in Finnish (^_^), but it’s not critical for my work.
I’ll get in touch with my supervisor this week and present my work, after which I will be allowed or denied to continue this project as course work.
Very nice work indeed!
[quote]For now I have a question without answer — the PCLab2000LT sends command 0F at the end of configuring the device, after which it receives 64 bytes of data. My question is “what is this?”, it is not mirrored in the document.[/quote] Yes, the command 0F is not necessary for the operation of the PCSGU250.
This commend is used to request the firmware version number.
The first bytes of the returned data are: 31 2E 30 31 0D
i.e. “1.01”.
[quote=“VEL255”]Yes, the command 0F is not necessary for the operation of the PCSGU250.
This commend is used to request the firmware version number.
The first bytes of the returned data are: 31 2E 30 31 0D
i.e. “1.01”.[/quote]
Thanks a lot!
I’ve received permission to do this project as course work, so I’ll continue, maybe next week.
[quote=“Mopster”]i found this link here TclVI Home Page
maybe it helps?[/quote]
Not really, sorry, PCSGU250 has different protocol and it’s simpler for me to rewrite everything from scratch.
On the progress: I’ve got more time for my work and managed to finish the translation. There were lots of misunderstandings and some typos, and USB sniffering helped me a lot to understand the protocol, but overall the manual was very helpful, thanks! I’ve also have nearly finished a prototype which implements all the functions in the manual (but not things like calibration, XY plot or Fourier transform for frequency analysis). There are some questions that I’d like to ask:
- There is enable_sweep bit in generator settings. The manual states that it enables or disables sweep mode, but it looks like resetting it will just disable the generator. The official software always sets it to 1 and sets SWEEP INCREMENT register to zero if sweep needs to be disabled. So, can I use this as “enable generator” bit or it is something else?
- There are sel_f (generator frequency range) and relay_state bits in generator settings. The manual states that they should be always zero and are not avaliable for setting, but official software sets them to 1. What is the correct behaviour?
- How were filter values calculated? This is mainly curiosity question.
- When reading data from scope, the manual states that after 09 0B, scope should send 4E until trigger occurs. In practice, however, it sometimes sends 64 bytes of junk data (looks like data from channels) before sending 4E or 44. What should I do with it?
Thanks in advance! When I clear my prototype up a bit, I will push all my work to the repository, including translated documentation.
[quote]1. There is enable_sweep bit in generator settings. The manual states that it enables or disables sweep mode, but it looks like resetting it will just disable the generator. The official software always sets it to 1 and sets SWEEP INCREMENT register to zero if sweep needs to be disabled. So, can I use this as “enable generator” bit or it is something else?[/quote]You are right, the enable_sweep bit enables everything. You can use it as you suggested.
[quote]2. There are sel_f (generator frequency range) and relay_state bits in generator settings. The manual states that they should be always zero and are not avaliable for setting, but official software sets them to 1. What is the correct behaviour?[/quote]These bits are not connected in the PCSGU250 hardware. You may keep them 0 or 1. (The manual says you may keep them zero.)
[quote]3. How were filter values calculated? This is mainly curiosity question.[/quote]The filter values are experimental. Based on tests how to get ‘clean’ wave.
[quote]4. When reading data from scope, the manual states that after 09 0B, scope should send 4E until trigger occurs. In practice, however, it sometimes sends 64 bytes of junk data (looks like data from channels) before sending 4E or 44. What should I do with it?[/quote] I think you can ignore this data.
Sorry for the long absence, I was busy with other university courses. I’m near the finish of my “term project” part of the work, and I’ve pushed existing work to the repository.
A question: is there some rule by which I can predict when scope will send junk 64 bytes of data after 0B (scope trigger)?
A nice picture of a working GUI app! http://i.imgur.com/PN9bJk6.png
I would be able to complete my work after my exams. Until that, you can use it by building a kernel module (from /module directory), insmod’ing it, and building and running userspace app from /userspace (written in C++/Qt). Also, sorry for Russian captions in the app — rules of our term projects state that our applications should be in native language where possible.
I’m also waiting for answer on the previous question; for now, it is implemented not nearly pretty or right; I just try somehow to work around USB overflow errors.
I will rewrite my app to use libusb (without any modules), fix remaining errors, translate it and so on, but after my exams, in the summer.
Also, about this 64-byte-sized junk — I’ve managed to solve it ‘partially’ by reading 64 bytes after 0B on the second and further trigger requests. The first trigger request is the request just after sending configuration. But sometimes this doesn’t work and I don’t have a grasp of a rule by which this happens.
[quote]A nice picture of a working GUI app! i.imgur.com/PN9bJk6.png[/quote] Nice work indeed!
[quote]A question: is there some rule by which I can predict when scope will send junk 64 bytes of data after 0B (scope trigger)?[/quote]Sorry, no known solution to this problem.
Hello
I just saw the draft from Mr Abbradar, and my dream is to use my own PCSGU250 under Ubuntu
If you need a beta tester, I’d be very interested in the Linux version
Hope it’s done soon !
Very good idea
Hello,
Thanks for your interest. I’ve successfully finished “course work” part of the project and will finish passing my exams soon. After this, I think I will rewrite my work to use libusb instead of kernel module, and it will be much more usable. I don’t have an Ubuntu, but I will provide some instructions for building and testing later, after exams. Until then, you can try and build it from my repository by yourself (both module and Qt GUI, then insmod a module, plug a scope in, open a GUI and choose /dev/scope%d file), if you want.
Hello again
Thanks , i try to compile and tell you what happens after
Good luck for your exam