DSO 112 with JYE LAB

Color oscilloscope with touch panel
Gero
Posts: 1
Joined: Thu Feb 19, 2015 2:08 am

DSO 112 with JYE LAB

Post by Gero »

Good day,
I have now bought the DSO 112.

Now I would like to use the Ossziloskop with the program "JYE Lab".

It also builds a connection.
The display of DSO112 will "USB Scope Mode" is displayed.

In "JYM Lab" is also connected display.
In "Model" is only "DSO"

In the text line "Device model: Unknown '

So, if I were to "Capture - Run" click, nothing happens.

When will the DSO112 works with the software "JYE LAB"?

Or what am I doing wrong?

It would be great if the software would work with the DSO.

I beg your reply,

many greetings and a nice new year celebration

Gero
jye1
Posts: 1228
Joined: Wed Feb 20, 2013 4:58 pm

Re: DSO 112 with JYE LAB

Post by jye1 »

No, you didn't do anything wrong. For this feature the firmware on DSO112 side has pretty much done, although not fully tested. The problem is at jyeLab, which does not support 112 yet. jyeLab needs grade to support 112. But this won't be very soon in our current schedule.
pulsar85
Posts: 1
Joined: Sun Jul 05, 2015 8:43 pm

Re: DSO 112 with JYE LAB

Post by pulsar85 »

jye1 wrote:No, you didn't do anything wrong. For this feature the firmware on DSO112 side has pretty much done, although not fully tested. The problem is at jyeLab, which does not support 112 yet. jyeLab needs grade to support 112. But this won't be very soon in our current schedule.
Hello.
You wrote that support of work of DSO112 for jyeLab will be not soon. And when approximately it is planned, this year, within 2 years, 5 years. At least very much approximately, what terms?
Very tempting device, I plan it to buy. Among pluses, that it portable. Among minuses that it is impossible to connect to the computer and to use from it.

For comparing I tore up at the friend to use this: http://oscill.com/eng/oscilloscopes/usb/usbdata.html instrument. From pluses, the big frequency of selection, bigger input voltage and normal connection to the computer and rather convenient to a software. From minuses, not independent, problems with delivery and purchase, well and actually, the self-made oscilliscope made on knees.
I think, opportunity to use a portable osilograf as is autonomous and as the connected USB device for the computer, would be very big plus in case of a choice. Especially in case of such rather low price.
virtmax
Posts: 3
Joined: Tue Oct 06, 2015 5:36 pm

Re: DSO 112 with JYE LAB

Post by virtmax »

Hello,
Did you thought to open the source code of the JYELab, for example on GitHub? I think you could reach much more people with open software. And I'm sure some people will help with the software development.
The same with the firmware development. You could invest your free resources in building better hardware.
jye1
Posts: 1228
Joined: Wed Feb 20, 2013 4:58 pm

Re: DSO 112 with JYE LAB

Post by jye1 »

Thanks for the suggestion. We will put jyeLab on gitHub very soon.
mwm
Posts: 44
Joined: Fri Jun 24, 2016 2:35 pm

Re: DSO 112 with JYE LAB

Post by mwm »

So I found it on github (https://github.com/JYEtech/jyeLab) but it doesn't look like anything has happened to it. No more commits since the first day, and nobody has forked it on github. On the other hand, comparing it to the documented protocol for the DSO112A (good job publishing those!), it might be as simple as adding the appropriate entries to the table of devices. Doing that ought to get at least partial functionality.

This is built with Borland C++ Builder, which I don't use to run on Windows, which I only use when absolutely pressed to (and yes, I'd at least look at jyelab if it worked with my DSO112A). So, is there someone out there who cloned it from the command line (which wouldn't show on github) who maybe has it building? Someone who uses Borland C++ who'd take a look at it? And I've already reached out to some hacker friends of mine who might be able to do this.

Personally, I think I'd rather have support for it in sigrok, which is cross-platform so runs on my desktop. Having the source available is liable to be really useful for that.

Are there still DSO112 users interested in this functionality? If so, I need to know it's reply to the query command. Can you either provide the correct string, or verify that it's

Code: Select all

0xFE 0xE2 13 '()' 5 'D' 'S' 'O' '1' '1' '2' 0 0
smallfreak
Posts: 3
Joined: Sun Sep 03, 2017 11:36 am

Re: DSO 112 with JYE LAB

Post by smallfreak »

Hello everyone ;)

I decided not to complain, but to take the challenge and work through the source code. Thanks for sharing.

Well, I now know why Jye takes so long to make some small changes to the program to display some data after the connect. The program is just not suited to fit the DSO112A. It obviously was made for one specific model and later patched up to support another one with similar characteristics. A good couple of things are simply hard coded in default although I found some hints that someone thought about the fact and defined some rudimentary properties - that never got any use in the code, so setting them right would not change anything.

But I don't judge anyones coding. If someone reads MY code, he certainly would invent some bad new vocabulary.

What progress did I make in the last few days?
  • The model is determined correctly, but the name is not read from the return frame, but hard coded
  • vertical position and trigger level on the device follows the on screen readings. This was done by applying a 256/300 correction on the value and binding the trigger level to the Y position instead of using signed displacement
  • second channel is deactivated in the program, when DSO112 is connected
  • data frames are processed when in RUN mode
  • I did not understand the concept of trippling the data points and values in the display buffer, even if it then fits 1:1 to the pixels of the fixed sized screen area - in case it is one of the two supported models
  • which assumes a fixed 10 samples per division, whereas the 112A seemingly has 25 samples per div, for which I had to apply a 10/25 correction in the X direction
  • which exhausts the sample buffer near the end of the much bigger screen area when using the default 512 samples (that corresponds so the trippled 1536 record length in the software), which looks quite wrong beyond that. Instead of rolling over to the beginning, as it was defined internally I decided to cut it there. You can change the setting to 3072 (1024 samples) to get the screen right - and the panorama view even wronger.
  • The buffer window display is wrong, since it still assumes 10 samples per div.
  • the vertical resolution is wrong too and I had to apply some magic numbers to fit this, like subtracting a fixed value of 9 and then scale it to 4/10 to make it look right in size and (almost) vertical position. This part is still a mystery to me, what range of values I have to expect for a given signal in a given sensitivity and probably vertical position.
  • one can change the time frame and most of the time the scope (values) change accordingly on screen in RUN mode. Sometimes it takes 10 seconds or longer before I get values fitting the new setting, sometimes this is simply ignored, sometimes I enter a wait-until-doomsday loop and sometimes the program crashes due to some command buffer overrun.
  • one can change the sensitivity, but this has NO effect on the running signal. If I terminate the connection from the device, I can see, that all the setting changes get sent to the device, as it swiches correctly. The problem is just in connected RUN mode. I assume, the device is just too busy to respond to the commands reliably, when connected. If you want to change the sensitivity, you have to STOP, DISCONNECT, CONNECT, SET, RUN. Sometimes it needs a second turn, and be sure to wait until the green light is off before connecting again, or you will get doomed.
2017-09-05_18-41-43.jpg
For now, I can see "something" and I can play around a little, but it definitely is not of ANY use. Maybe it is necessary to automatically disconnect before sending new settings and maybe I try that one too, but I'm confident that most of the remaining stability problems are due to some glitch in the device and I'm not ready to debug that one.

I will copy my work on a shared drive and post the link, in case someone else might be interested in further investigation, but I'm pretty much through with the idea to make it work right. I will not clone the GIT to a "work in progress" as I don't expect any progress on that.

Having said that, I'm still in love with this nifty little scope :D

So: Here is the Link https://1drv.ms/f/s!ApHNWu0vSEmQhU78alXEbGWC1P4T
dulloa
Posts: 2
Joined: Wed Sep 06, 2017 7:26 pm

Re: DSO 112 with JYE LAB

Post by dulloa »

Thanks smallfreak! At least it's possible to store the buffer on the computer and analyze it later.

Is it possible to disable the function that sends base time and volts/div when it starts the communication?

did you get the start sequence to establish communication? before seeing your post i was trying to read raw data but i was getting nothing, then i tested your build and saw that there was a message on the dso saying USB Mode, i got back to Putty and there was data, but the baudrate, parity, control sequence wasn't right by default because i was getting gibberish.

My idea was to log the raw data using python and then saving it to csv.

Daniel.
smallfreak
Posts: 3
Joined: Sun Sep 03, 2017 11:36 am

Re: DSO 112 with JYE LAB

Post by smallfreak »

If you do not send a set of new parameters to the device, it will stay on whatever was active when USB mode was requested. "Connecting" does not change anything, it just turns on streaming the data frames.

I didn't touch the low level serial communication procedures. I just fiddled around with the high level "buffer received" and "send buffer" routines. However, if you have a "FE" byte anywhere within your data, you must follow it with an additional "00", otherwise this would be interpreted of a "start new data frame" character and possibly blast your device ;-)

The sequence to set the device into USB mode is outlined in the user manual. The default bitrate is set to 115200, N,8,1. No matter what bitrate you set, you must send

Code: Select all

FE E1 04 00 C1
The "FE" is the sync character that precedes every command, "E1" is the Frame-ID for "connection command", "0004" is the total frame length (counting from the "E1"), "C1" is idontknow?
This "should" trigger an "identify" response frame

Code: Select all

FE E2 0D 00 'O' 05 'DSO112A' 00 00
The "O" identifies it as "oscilloscope", model 5, named "DSO112A".

This response did not arrive, the hell knows why. So I sent another frame after the "connect", one of type "Query"

Code: Select all

FE E2 04 00 00
which finally resulted in the expected "identify" response to reveal the model.

It was primarily the model number 5 that prevented Jye Lab from doing anything useful with the now streaming "data frames". There was simply no procedure that processed frames in case of "model 5".

Once you are connected, the data streams in constantly, usually a full buffer of values at once. You get 25 samples per div and 25 counts per div vertically. To judge the true voltage, you have to know the sensitivity setting and the vertical position of the baseline, as the values are 0-255 spanning 10 vertical divs where 128 should match the center line - which it does not, at least not mine. I have a small offset, but overall that are the parameters.

The current settings can be requested too. And you can send new settings to the device (see manual). However, the sensitivity seems to be ignored when "connected" i.e. when data are streaming in. The whole communication also works without setting the device to USB mode. The connect/disconnect seem to define whether the data is displayed on screen or whether it is sent to the PC. Without this you can still operate the scope remotely and get status responses, just no measurements.

The rest is all about processing the data, as well as send and receive settings, but this is the part that paints everything on screen and doing all the math to get all the lines and points scaled properly into the display area.

Unfortunately parameters like setting the trigger level or the sensitivity seem to be ignored while "connected", whereas trigger-edge, buffer size or time base values are honored.
dulloa
Posts: 2
Joined: Wed Sep 06, 2017 7:26 pm

Re: DSO 112 with JYE LAB

Post by dulloa »

Thanks, now I understand how to send commands and set parameters :D

Image
Post Reply