Difference between revisions of "Rigol VG1021"
Jump to navigation
Jump to search
(The bare bones protocol that maybe should work...) |
|||
| Line 3: | Line 3: | ||
The Rigol VG1021 is a 20Mhz 100MS/s Function/Arbitrary waveform generator. | The Rigol VG1021 is a 20Mhz 100MS/s Function/Arbitrary waveform generator. | ||
Device Class code implies compatibility with USBTMC USB488 (USB Class 0xFE, Subclass 0x03, Protocol 0x01)<sup>[[#References|1]]</sup>, but deviates significantly from specification.<sup>[[#References|2]]</sup> | ==Protocol== | ||
Device Class code implies compatibility with USBTMC USB488 (USB Class 0xFE, Subclass 0x03, Protocol 0x01)<sup>[[#References|1]]</sup>, but deviates significantly from specification.<sup>[[#References|2]],[[#References|3]]</sup>. It fails to heed the "multiple of four" transaction length, sends commands in a nonstandard way and uses reserved bytes that should be zero. Any general purpose USBTMC driver will time out when trying to read an answer from the device, because the command requiring response didn't register as such. | |||
===Packet types=== | |||
This is the anatomy of a command-response cycle as it's done by the bundled software. Compliant with USBTMC unless otherwise noted. | |||
*DEV_DEP_MSG_OUT Bulk-OUT Header has bytes 9-11 set as 0xCDCDCD (should be 0x000000). Header is always sent in its own packet, instead of sending up to wMaxPacketBytes at once. | |||
*Command packet Bulk-OUT contains the command as plaintext, without leading ":". Possibly limited to 64 bytes per packet, though I've yet to see so long a command. | |||
**If the command requires no response, the process ends here. | |||
*REQUEST_DEV_DEP_MSG_IN Bulk-OUT Header has byte 8 set as 0x01 (should be 0x02 (use TermChar from byte 9) or 0x00 (ignore TermChar)). Compliant with USBTMC, MaximumTransferSize is always set at 0x40, TermChar always at 0x0A. | |||
*Unknown Vendor Endpoint from device to host (0xC2) request 0x09, returns with 4 bytes of data (so far always 0x01000000). Currently assuming the first byte to be USBTMC_status described in <sup>[[#References|2]]</sup> | |||
*Same request again, same return. | |||
**Whether these two are necessary, or just leftovers from a different device, remains to be seen. | |||
*DEV_DEP_MSG_IN Bulk-IN Header is (maybe, depending on wMaxPacketBytes) compliant with USBTMC spec. wMaxPacketSize is x, answer is sent in 64-byte packets. No EOM or padding. I currently don't have access to the device, and I forgot to do the sensible thing of exporting the device info. | |||
==References== | ==References== | ||
*<sup>1</sup> [http://www.usb.org/developers/defined_class#BaseClassFEh USB.org - Defined 1.0 Class Codes] | *<sup>[[#Protocol|1]]</sup> [http://www.usb.org/developers/defined_class#BaseClassFEh USB.org - Defined 1.0 Class Codes] | ||
*<sup>2</sup> [http://www.usb.org/developers/devclass_docs USB.org - Approved Class Specification Documents] | *<sup>[[#Protocol|2]]</sup> [http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip USB.org - Approved Class Specification Documents - TMC Specifications] USBTMC 1.00 | ||
*<sup>[[#Protocol|3]]</sup> [http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip USB.org - Approved Class Specification Documents - TMC Specifications] USBTMC-USB488 1.00 | |||
Revision as of 14:54, 27 April 2013
WIP
The Rigol VG1021 is a 20Mhz 100MS/s Function/Arbitrary waveform generator.
Protocol
Device Class code implies compatibility with USBTMC USB488 (USB Class 0xFE, Subclass 0x03, Protocol 0x01)1, but deviates significantly from specification.2,3. It fails to heed the "multiple of four" transaction length, sends commands in a nonstandard way and uses reserved bytes that should be zero. Any general purpose USBTMC driver will time out when trying to read an answer from the device, because the command requiring response didn't register as such.
Packet types
This is the anatomy of a command-response cycle as it's done by the bundled software. Compliant with USBTMC unless otherwise noted.
- DEV_DEP_MSG_OUT Bulk-OUT Header has bytes 9-11 set as 0xCDCDCD (should be 0x000000). Header is always sent in its own packet, instead of sending up to wMaxPacketBytes at once.
- Command packet Bulk-OUT contains the command as plaintext, without leading ":". Possibly limited to 64 bytes per packet, though I've yet to see so long a command.
- If the command requires no response, the process ends here.
- REQUEST_DEV_DEP_MSG_IN Bulk-OUT Header has byte 8 set as 0x01 (should be 0x02 (use TermChar from byte 9) or 0x00 (ignore TermChar)). Compliant with USBTMC, MaximumTransferSize is always set at 0x40, TermChar always at 0x0A.
- Unknown Vendor Endpoint from device to host (0xC2) request 0x09, returns with 4 bytes of data (so far always 0x01000000). Currently assuming the first byte to be USBTMC_status described in 2
- Same request again, same return.
- Whether these two are necessary, or just leftovers from a different device, remains to be seen.
- DEV_DEP_MSG_IN Bulk-IN Header is (maybe, depending on wMaxPacketBytes) compliant with USBTMC spec. wMaxPacketSize is x, answer is sent in 64-byte packets. No EOM or padding. I currently don't have access to the device, and I forgot to do the sensible thing of exporting the device info.