I'm working on adding support for the DSO112A to sigrok, and recently ran into problem with the serial interface documentation.
The frame ID's for all the frames after the disconnect frame are 0xC0. I'm pretty sure that's not right. Any chance there's an updated version of the manual somewhere? Possibly just a list of correct frame IDs? Or confirmation that the frame IDs used in the JYELab sources are correct for the DSO112?
DSO112A serial interface docs?
Re: DSO112A serial interface docs?
The frame ID's are listed in this document http://www.jyetech.com/Products/LcdScop ... l_112A.pdf . Can you let me know any specific information you are looking for?
Re: DSO112A serial interface docs?
That's the document I've been looking at, and it doesn't look right. The frame ID for all the frames types after the disconnect frame is 0xC0. Those frames aren't even ask the same type. Those look more like copy/paste errors than a wire protocol.
Re: DSO112A serial interface docs?
Please see the byte at offset 0x03. This byte indicates different function of frames.
Re: DSO112A serial interface docs?
Except of course for the frame type where it's part of the data. If it weren't for that case, you wouldn't need the frame ID at all, as that byte can determine the frame type, in spite of it not having a consistent name, or in some cases a name at all.
Looking things over, it begins to make sense. This protocol has what we call an "organic"design. Meaning it wasn't designed so much as grew, and otherwise resembles a biproduct of life. Apparently the product of a committee that whose members weren't on speaking terms.
Looking things over, it begins to make sense. This protocol has what we call an "organic"design. Meaning it wasn't designed so much as grew, and otherwise resembles a biproduct of life. Apparently the product of a committee that whose members weren't on speaking terms.
Re: DSO112A serial interface docs?
Got distracted last week, but got back to this. I'm working on adding support to sigrok (an open source dmm/osc/logic analizer/etc. toolset) for the DSO112. I can read & parse the query result, configuration information and parameters. I think I've got a handle on that.
But...
I'm seeing packets that aren't documented. The Frame ID is always 0xD0. The byte at #3 (which I was told is used to distinguish between the various 0xC0 frame types) is either 0x41 or 0x61. With a timebase of 50ms, these frames have a length of 18 bytes, but are followed by what looks like the test signal: long strings of bytes with values near 170 alternating with similar length strings with values near 84.
With a timebase of 20ms, the frame length is 516 bytes if the record length is 512, and 1023 if the record length is 1024, with five bytes of what looks like samples between each record. The jyelab sources say this is a FID_DataFM, and processes it as if it were a buffer of data (frame ID 0xC0 data type 0x32 in the dso112A docs). Which actually makes sense for the lengths I'm seeing for the 512 point buffer, and for the 1024 point buffer if you included the five bytes that aren't in the record.
Could I get documentation for the frames with frame ID 0xD0?
But...
I'm seeing packets that aren't documented. The Frame ID is always 0xD0. The byte at #3 (which I was told is used to distinguish between the various 0xC0 frame types) is either 0x41 or 0x61. With a timebase of 50ms, these frames have a length of 18 bytes, but are followed by what looks like the test signal: long strings of bytes with values near 170 alternating with similar length strings with values near 84.
With a timebase of 20ms, the frame length is 516 bytes if the record length is 512, and 1023 if the record length is 1024, with five bytes of what looks like samples between each record. The jyelab sources say this is a FID_DataFM, and processes it as if it were a buffer of data (frame ID 0xC0 data type 0x32 in the dso112A docs). Which actually makes sense for the lengths I'm seeing for the 512 point buffer, and for the 1024 point buffer if you included the five bytes that aren't in the record.
Could I get documentation for the frames with frame ID 0xD0?
Re: DSO112A serial interface docs?
Please replace the firmware with the attachment here (113-11201-211). You are probably running an old version . 0xD0 is the old frame ID for captured data. It was changed to 0xC0 in the new version. The document reflects the new version.
Re: DSO112A serial interface docs?
Yup, that got it. Thanks.
Re: DSO112A serial interface docs?
Ok, now I need to figure out what the byte-long values showing up in the captured data output. The only description of how to compute voltages is in the section "Output of measurements". It's not clear it applies, as it says "All voltages are expressed in 16-bit signed integer.", which isn't true for the data in captured frames.
I suspect the information I need is in the parameters list, but there doesn't seem to be any documentation on getting from there to voltage values in the captured data.
I suspect the information I need is in the parameters list, but there doesn't seem to be any documentation on getting from there to voltage values in the captured data.
Re: DSO112A serial interface docs?
Yes you are right. "16-bit signed integer" only applies to the measured voltages. The captured data output are in plain 8-bit binary.
It did miss something here for calculating true voltage that the captured data represent. The Line 9 in CSV format output contains a "V/LSB" value. This value should also be provided here. Another parameter missed is VPos offset. We need to modify the code to fix. Please give us some time.
It did miss something here for calculating true voltage that the captured data represent. The Line 9 in CSV format output contains a "V/LSB" value. This value should also be provided here. Another parameter missed is VPos offset. We need to modify the code to fix. Please give us some time.