Well, I have noticed that VPOS changes as I move the cursor, so I assumed it was set and I just needed to know how to interpret it.
Just to be clear, the information I need ins't currently available, and I need to wait for a firmware update for that to appear?
Thanks.
DSO112A serial interface docs?
Re: DSO112A serial interface docs?
BTW, if you're doing to be tweaking the firmware for this, any chance you could add a firmware version to the Configuration information? I'd like to be able to let users know that it won't work rather than just have things fail!
Re: DSO112A serial interface docs?
I worked out the appropriate scale & offset values for V/Div = 1V, just so I could get data into it to work with while workingg on other things. I now have more questions/requests.
In particular, I'm having issues with reliability switching into and out of USB Scope mode. It would be nice if I could get some sort of acknowledgement from the disconnect command other than data not stopping. Similarly for the connect command, but not quite as urgent. I expect the Set command (which is my next task) will have the same kind of problems.
Also, any chance the DSO112 will get an upgrade so this software could work with it as well? I'm also curious about the other USB-capable DSO's. Do any of them have the protocol documented beyond the jyelab sources?
Thanks,
Mike
In particular, I'm having issues with reliability switching into and out of USB Scope mode. It would be nice if I could get some sort of acknowledgement from the disconnect command other than data not stopping. Similarly for the connect command, but not quite as urgent. I expect the Set command (which is my next task) will have the same kind of problems.
Also, any chance the DSO112 will get an upgrade so this software could work with it as well? I'm also curious about the other USB-capable DSO's. Do any of them have the protocol documented beyond the jyelab sources?
Thanks,
Mike
Re: DSO112A serial interface docs?
From use poine of view after DSO112A is connected to a host the scope parameters, which include VPOS, are set by the host. So there is no need to get it from DSO112a. Similarly for VPOS offset which is to compensate vpos setting error. Host should be able to work it out once it takes control. Not sure if sigrok/pulseview can work like this. I'd like to hear you opinion.
With VPOS pending for the new firmware we are going to add:
1 ) Return "command done" message once a command is successfully executed.
2 ) Firmware version within the confirmation message.
Are there any other mods that you think are appropriate to make?
Thank you.
With VPOS pending for the new firmware we are going to add:
1 ) Return "command done" message once a command is successfully executed.
2 ) Firmware version within the confirmation message.
Are there any other mods that you think are appropriate to make?
Thank you.
Re: DSO112A serial interface docs?
Yes, I can set VPos in the software, but sigrok has no way to let the user specify it during the capture. So I'd just set it to zero, which may mean that when I turn it off the signals goes out of range. Not good. Once I've figured out how VSen affects things, VPos was easy to do, so I did it.
A "comnand done" would be an immense help. Most of the commands I use have a response, even if it's shutting off the captured data. But settings don't, and that failing before I start a capture could cause the capture to be worthless.
And yes, I have one more suggestion for this: please add an option to make it not power off when it's plugged into USB power. Not noticing that it's turned off is another way to make a capture not happen.
Looking forward to it.
A "comnand done" would be an immense help. Most of the commands I use have a response, even if it's shutting off the captured data. But settings don't, and that failing before I start a capture could cause the capture to be worthless.
And yes, I have one more suggestion for this: please add an option to make it not power off when it's plugged into USB power. Not noticing that it's turned off is another way to make a capture not happen.
Looking forward to it.
Re: DSO112A serial interface docs?
And today I found something else I'd like to see: the sample rate. Turns out I need to feed that to the library in order for it to render the results properly. That's in the CSV file, so I can use that for now, but that's not very robust.
Re: DSO112A serial interface docs?
Please see attachment for the revised firmware. The changes were:
1 ) Added "command done" message
Format: 0xFE, 0xE6, 0x04, 0x00, 0x00
The last byte do not have meaning and is reserved for checksum when required.
This message is returned for all commands sent to the scope that do not require a return by themselves if successfully completed.
2 ) Added firmware version to the confirm message.
Format:
Offset --- Field --- Size --- Value
---------------------------------------------
-1 --- SynCh --- 1 --- 0xFE
0 --- FID --- 1 --- 0xE2
1 --- FrameLen --- 2 --- 0x1A
3 --- DevType --- 1 --- 'O'
4 --- Model ID --- 1 --- 0x05
5 --- ModelName --- 10 --- "DSO112A"
15 --- FW ver --- 10 --- "11201-XXX"
25 --- Reserved --- 1v --- 0x00
(sorry it's hard to get the texts properly formated)
Please let me know if the changes work for you. Any further suggestions are appreciated.
Answers to some of your questions:
1 ) About VPos
By design 0V input is corresponding to binary 0x80 at ADC output when VPos is zero. When VPos is not zero a DC voltage is generated which shifts 0V level up (when VPos > 0) or down (when VPos < 0). In real circuit, due to component error, VPos = 0 does not mean 0V input must product binary 0x80. There are always some small mismatch. This is where the VPos offset comes in play. It corrects the errors. Because the errors varies among different sensitivity settings DSO112A firmware correct the errors individually for each sensitivity setting.
2 ) Sampling rate
The following is sampling rate vs timebase table. The unit is sample/second
U8 SamplingRate[TBMax - TBMin + 1][9] = {
{"0.5"}, // TB_50s,
{"1.25"}, // TB_20s,
{"2.5"}, // TB_10s,
{"5"}, // TB_5s,
{"12.5"}, // TB_2s,
{"25"}, // TB_1s,
{"50"}, // TB_05s,
{"125"}, // TB_02s,
{"250"}, // TB_01s,
{"500"}, // TB_50ms,
{"1250"}, // TB_20ms,
{"2500"}, // TB_10ms,
{"5000"}, // TB_5ms,
{"12500"}, // TB_2ms,
{"25000"}, // TB_1ms,
{"50000"}, // TB_05ms,
{"125000"}, // TB_02ms,
{"250000"}, // TB_01ms,
{"500000"}, // TB_50us,
{"1250000"}, // TB_20us,
{"2500000"}, // TB_10us,
{"5000000"}, // TB_5us,
{"12500000"}, // TB_2us,
{"25000000"}, // TB_1us,
// TB_max
};
3 ) Sensitivity true value
The following table can be used to calculate sensitivity true value
U16 VsenResolution[13] = {
// In unit of 0.02mV
40000, // VS_20V -- 800mV/LSB
20000, // VS_10V,
10000, // VS_5V,
4000, // VS_2V,
2000, // VS_1V,
1000, // VS_05V,
400, // VS_02V,
200, // VS_01V,
100, // VS_50mV,
40, // VS_20mV,
20, // VS_10mV,
10, // VS_5mV,
4 // VS_2mV -- 0.08mV/LSB
};
4 )The current firmware already has the feature that to disable auto power off when USB power is connected and its voltage reaches certain level.
1 ) Added "command done" message
Format: 0xFE, 0xE6, 0x04, 0x00, 0x00
The last byte do not have meaning and is reserved for checksum when required.
This message is returned for all commands sent to the scope that do not require a return by themselves if successfully completed.
2 ) Added firmware version to the confirm message.
Format:
Offset --- Field --- Size --- Value
---------------------------------------------
-1 --- SynCh --- 1 --- 0xFE
0 --- FID --- 1 --- 0xE2
1 --- FrameLen --- 2 --- 0x1A
3 --- DevType --- 1 --- 'O'
4 --- Model ID --- 1 --- 0x05
5 --- ModelName --- 10 --- "DSO112A"
15 --- FW ver --- 10 --- "11201-XXX"
25 --- Reserved --- 1v --- 0x00
(sorry it's hard to get the texts properly formated)
Please let me know if the changes work for you. Any further suggestions are appreciated.
Answers to some of your questions:
1 ) About VPos
By design 0V input is corresponding to binary 0x80 at ADC output when VPos is zero. When VPos is not zero a DC voltage is generated which shifts 0V level up (when VPos > 0) or down (when VPos < 0). In real circuit, due to component error, VPos = 0 does not mean 0V input must product binary 0x80. There are always some small mismatch. This is where the VPos offset comes in play. It corrects the errors. Because the errors varies among different sensitivity settings DSO112A firmware correct the errors individually for each sensitivity setting.
2 ) Sampling rate
The following is sampling rate vs timebase table. The unit is sample/second
U8 SamplingRate[TBMax - TBMin + 1][9] = {
{"0.5"}, // TB_50s,
{"1.25"}, // TB_20s,
{"2.5"}, // TB_10s,
{"5"}, // TB_5s,
{"12.5"}, // TB_2s,
{"25"}, // TB_1s,
{"50"}, // TB_05s,
{"125"}, // TB_02s,
{"250"}, // TB_01s,
{"500"}, // TB_50ms,
{"1250"}, // TB_20ms,
{"2500"}, // TB_10ms,
{"5000"}, // TB_5ms,
{"12500"}, // TB_2ms,
{"25000"}, // TB_1ms,
{"50000"}, // TB_05ms,
{"125000"}, // TB_02ms,
{"250000"}, // TB_01ms,
{"500000"}, // TB_50us,
{"1250000"}, // TB_20us,
{"2500000"}, // TB_10us,
{"5000000"}, // TB_5us,
{"12500000"}, // TB_2us,
{"25000000"}, // TB_1us,
// TB_max
};
3 ) Sensitivity true value
The following table can be used to calculate sensitivity true value
U16 VsenResolution[13] = {
// In unit of 0.02mV
40000, // VS_20V -- 800mV/LSB
20000, // VS_10V,
10000, // VS_5V,
4000, // VS_2V,
2000, // VS_1V,
1000, // VS_05V,
400, // VS_02V,
200, // VS_01V,
100, // VS_50mV,
40, // VS_20mV,
20, // VS_10mV,
10, // VS_5mV,
4 // VS_2mV -- 0.08mV/LSB
};
4 )The current firmware already has the feature that to disable auto power off when USB power is connected and its voltage reaches certain level.
Re: DSO112A serial interface docs?
I thought I replied to this, but don't see it. Apologies if this is a duplicate.
I've updated the software to take advantage of these changes. It seems much more reliable.
I accidentally read the FG085 docs; problems with working on to many things at once. I could swear my DSO112A was shutting off when it had USB power, but it's not done it since. Possibly I was confused, in which case apologies for spreading it here.
The two tables are flexible, but since both relations are linear with the values the parameters represent - i.e. actual volts or seconds - it's simpler to just multiply those values by the appropriate number. I was already doing this for the sampling rate. I added the code to do the same for volts. Oddly enough, they both involve multiplication by 25.
Two further requests:
1) Any chance of getting a sequence number on sample packets? I suspect I'm dropping them, but can't really tell. Pretty much anything will do, but my temptation would be 16 bits unsigned, restarting at 0 with each acquisition, rolling over when you get 65536 packets.
2) It would be nice if the ACK confirmation packet let me know what command it was responding to. This would allow sync operation in the future (assuming the firmware supported it). However, figuring out how to denote the packet is a pain because the Frame ID 0xC0 is used for multiple commands.
Thanks.
I've updated the software to take advantage of these changes. It seems much more reliable.
I accidentally read the FG085 docs; problems with working on to many things at once. I could swear my DSO112A was shutting off when it had USB power, but it's not done it since. Possibly I was confused, in which case apologies for spreading it here.
The two tables are flexible, but since both relations are linear with the values the parameters represent - i.e. actual volts or seconds - it's simpler to just multiply those values by the appropriate number. I was already doing this for the sampling rate. I added the code to do the same for volts. Oddly enough, they both involve multiplication by 25.
Two further requests:
1) Any chance of getting a sequence number on sample packets? I suspect I'm dropping them, but can't really tell. Pretty much anything will do, but my temptation would be 16 bits unsigned, restarting at 0 with each acquisition, rolling over when you get 65536 packets.
2) It would be nice if the ACK confirmation packet let me know what command it was responding to. This would allow sync operation in the future (assuming the firmware supported it). However, figuring out how to denote the packet is a pain because the Frame ID 0xC0 is used for multiple commands.
Thanks.
Re: DSO112A serial interface docs?
Seems that it doesn't send the ACK/confirmation packets when set to a timebase of 50ms/division or more - meaning it's sending a single value in each frame.
Is this a bug, or have I overlooked something?
Is this a bug, or have I overlooked something?
Re: DSO112A serial interface docs?
No problem for the two requests. Since I am leaving for vocation soon I'll add them after I am back.
For the no confirmation issue did you mean you see the issue when you set timebase to 50ms (or higher) or AFTER timebase had been set to 50ms (or higher)?
For the no confirmation issue did you mean you see the issue when you set timebase to 50ms (or higher) or AFTER timebase had been set to 50ms (or higher)?