Difference between revisions of "Rigol VG1021"

From sigrok
Jump to navigation Jump to search
(The bare bones protocol that maybe should work...)
 
(10 intermediate revisions by one other user not shown)
Line 1: Line 1:
==WIP==
==Overview==


The Rigol VG1021 is a 20Mhz 100MS/s Function/Arbitrary waveform generator.
The Rigol VG1021 is a 20Mhz 100MS/s Function/Arbitrary waveform generator.
Line 7: Line 7:


===Packet types===
===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.
Packets seen so far (note that details differ from USBTMC specification):
{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
!Name
!MsgID or bRequestType
!bRequest
!Endpoint or wIndex
!Description
|- bgcolor="#eeeeee"
| DEV_DEP_MSG_OUT
| 1
|
| BULK-Out(0x01)
| Prepare for a device dependent command. Header includes command length.
|- bgcolor="#dddddd"
| Command
|
|
| BULK-In(0x82)
| Write a command.
|- bgcolor="#eeeeee"
| REQUEST_DEV_DEP_MSG_IN
| 2
|
| BULK-Out(0x01)
| Request a response for the previous command that requires one.
|- bgcolor="#dddddd"
| DEV_DEP_MSG_IN
| 2
|
| BULK-In(0x82)
| Read the response for the previous command that requires one.
|- bgcolor="#eeeeee"
| Vendor Request 0x09
| 0xC2
| 0x09
| CTRL_MSG
| Unknown vendor endpoint request, wLength = 0x04. So far always returns 01 00 00 00
|}


*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.
====DEV_DEP_MSG_OUT====
**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.
Consists of a USBTMC DEV_DEP_MSG_OUT header:
*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>  
{| border="0" style="font-size: smaller"
*Same request again, same return.
|- bgcolor="#6699ff"
**Whether these two are necessary, or just leftovers from a different device, remains to be seen.
!Offset
*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.
!Field
!Value
!Description
|- bgcolor="#eeeeee"
| 0
| MsgID
| 1
| Identifies as DEV_DEP_MSG_OUT.
|- bgcolor="#dddddd"
| 1
| bTag
| Number
| Per USBTMC specification, bTag is incremented by host every time a USBTMC message is sent. Rolls over from 255 -> 1.
|- bgcolor="#eeeeee"
| 2
| bTagInverse
| Number
| Per USBTMC specification, bTagInverse is the one's complement of bTag.
|- bgcolor="#dddddd"
| 3
| Reserved
| 0x00
| Must be 0x00.
|- bgcolor="#eeeeee"
| 4-7
| TransferSize
| LSByte first
| Length of command without header or alignment bytes.
|- bgcolor="#dddddd"
| 8
| bmTransferAttributes
| 0x01
| EOM, indicating that the last message byte (excluding alignment bytes) in the transfer is the last byte of the message (used for USBTMC Split messages that use multiple transfers. Yet to see one on this device, don't know if it supports them. Probably not.)
|- bgcolor="#eeeeee"
| 9-11
| Reserved
| 0xCDCDCD
| According to USBTMC spec, must be 0x000000. I interpret as Command Data to follow.
|}
 
 
====Command====
Consists of a BULK-Out transfer with command without header, leading ":", newline or alignment bytes. Does not follow the PacketSize = n*4 bytes requirement.
 
 
====REQUEST_DEV_DEP_MSG_IN====
Consists of a USBTMC REQUEST_DEV_DEP_MSG_IN header to BULK-Out(0x01) endpoint. The command is not sent with this packet or message, instead, the command is sent using the DEV_DEP_MSG_OUT and Command packets. This packet only requests the response.
Consists of a USBTMC Message DEV_DEP_MSG_OUT header:
{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
!Offset
!Field
!Value
!Description
|- bgcolor="#eeeeee"
| 0
| MsgID
| 2
| Identifies as REQUEST_DEV_DEP_MSG_IN.
|- bgcolor="#dddddd"
| 1-3
| bTag, bTagInverse, Reserved
| Number
| See [[#DEV_DEP_MSG_OUT]]
|- bgcolor="#eeeeee"
| 4-7
| TransferSize
| LSByte first
| Maximum response data bytes. Only seen 0x40.
|- bgcolor="#dddddd"
| 8
| bmTransferAttributes
| 0x01
| According to USBTMC spec, should be 0x02 (use TermChar from byte 9) or 0x00 (ignore TermChar))  
|- bgcolor="#eeeeee"
| 9
| TermChar
| 0x0A
| See USBTMC spec. For this device, not important.
|- bgcolor="#dddddd"
| 10-11
| Reserved
| 0x0000
| As specified.
|}
 
 
====DEV_DEP_MSG_IN====
Compliant with USBTMC, assuming wMaxPacketLength is 64. Header and data from BULK-In(0x82). If more than 52 bytes of data (plus 12 header) is needed, then rest of the data is sent in following packets without header or alignment bytes, compliant with USBTMC.
{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
!Offset
!Field
!Value
!Description
|- bgcolor="#eeeeee"
| 0
| MsgID
| 2
| Identifies as DEV_DEP_MSG_IN.
|- bgcolor="#dddddd"
| 1-3
| bTag, bTagInverse, Reserved
| Number
| See [[#DEV_DEP_MSG_OUT]]
|- bgcolor="#eeeeee"
| 4-7
| TransferSize
| LSByte first
| Length of returned data without header or alignment bytes.
|- bgcolor="#dddddd"
| 8
| bmTransferAttributes
| 0x01
| See USBTMC Specifications.
|- bgcolor="#eeeeee"
| 9-11
| Reserved
| 0x0000
| As specified.
|}
 
 
====Vendor Request 0x09====
 
Vendor Endpoint In control message, always returns 0x01000000.
*bmRequestType = 0xC2
*bRequest = 0x09
*wValue = 0x00
*wIndex = 0x00
*wLength = 0x04
 
Assuming first byte of response to be USBTMC_Status byte<sup>[[#References|4]]</sup>. If left out from command sequences, the device will occasionally return the same answer packet to the next query.
 
====TRIGGER====
Not implemented, uses standard command sending method with command "<nowiki>*</nowiki>TRG"
 
===Transfer sequences===
 
Transfer sequences as performed by bundled software.
 
 
====Command sequence====
#DEV_DEP_MSG_OUT
#Command
#*If the command requires no response, the process ends here.
#Vendor Request 0x09
#Vendor Request 0x09
#REQUEST_DEV_DEP_MSG_IN
#DEV_DEP_MSG_IN
 
====Startup sequence====
Here commands are in '''bold''' and responses from device in ''italics''. Commands can be abbreviated to uppercase portions (per VISA specifications). Commands are sent and responses read using [[#Command sequence]]
 
 
#'''*IDN?''' - ''RIGOL TECHNOLOGIES,VG1021, <nowiki><serial>,<firmware></nowiki>
#'''SYSTem:BEEPer:STATe ON'''
#'''VOLTage:RANGe:AUTO ON'''
#'''OUTPut:LOAD INFinity'''
#'''OUTPut:POLarity NORMal'''
#'''PHASe 0'''
#'''OUTPut OFF'''
#'''OUTPut:SYNC OFF'''
#'''FREQuency 1000'''
#'''VOLTage 5Vpp'''
#'''VOLTage:OFFSet 0V'''
#'''FUNCtion:SQUare:DCYCle 50'''
#'''FUNCtion::SYMMetry 50'''
#'''PULSe:DCYCle 50'''
#'''FUNCtion:USER EXP_RISE'''
#'''AM:SOURce INTernal'''
#'''AM:DEPTh 100'''
#'''AM:INTernal:FREQuency 100'''
#'''AM:INTernal:FUNCtion SINusoid'''
#'''FM:SOURce INTernal'''
#'''FM:DEViation 100'''
#'''FM:INTernal:FREQuency 100'''
#'''FM:INTernal:FUNCtion SINusoid'''
#'''FSKey:SOURce INTernal'''
#'''FSKey:FREQuency 100'''
#'''FM:INTernal:RATE 100'''
#'''PM:SOURce INTernal'''
#'''PM:DEViation 100'''
#'''PM:INTernal:FREQuency 100'''
#'''PM:INTernal:FUNCtion SINusoid'''
#'''SWEep:SPACing LINear'''
#'''FREQuency:STARt 100'''
#'''FREQuency:STOP 1000'''
#'''SWEep:TIME 1'''
#'''TRIGger:SOURce IMMediate'''
#'''BURSt:NCYCles 1'''
#'''BURSt:PHASe 0'''
#'''TRIGger:SOURce IMMediate'''
#'''BURSt:INTernal:PERiod 0.01'''
#'''TRIGger:DELay 0'''
#'''COUNter:COUPling AC'''
#'''COUNter:HFRState OFF'''
#'''COUNter:SENSitivity HIGH'''
#'''FUNCtion SINusoid'''
#'''FREQuency 1000'''
#'''VOLTage 5Vpp'''
#'''VOLTage:OFFSet 0V'''
#'''AM:STATe?''' - ''OFF''
#'''FM:STATe?''' - ''OFF''
#'''FSKey:STATe?''' - ''OFF''
#'''PM:STATe?''' - ''OFF''
#'''SWEep:STATe?''' - ''OFF''
#'''BURSt:STATe?''' - ''OFF''
#'''FUNCtion SINusoid'''




==References==
==References==
*<sup>[[#Protocol|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>[[#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|2]], [[#Vendor Request 0x09|4]]</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
*<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
[[Category:Device]]
[[Category:Signal generator]]

Latest revision as of 18:26, 27 September 2014

Overview

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

Packets seen so far (note that details differ from USBTMC specification):

Name MsgID or bRequestType bRequest Endpoint or wIndex Description
DEV_DEP_MSG_OUT 1 BULK-Out(0x01) Prepare for a device dependent command. Header includes command length.
Command BULK-In(0x82) Write a command.
REQUEST_DEV_DEP_MSG_IN 2 BULK-Out(0x01) Request a response for the previous command that requires one.
DEV_DEP_MSG_IN 2 BULK-In(0x82) Read the response for the previous command that requires one.
Vendor Request 0x09 0xC2 0x09 CTRL_MSG Unknown vendor endpoint request, wLength = 0x04. So far always returns 01 00 00 00


DEV_DEP_MSG_OUT

Consists of a USBTMC DEV_DEP_MSG_OUT header:

Offset Field Value Description
0 MsgID 1 Identifies as DEV_DEP_MSG_OUT.
1 bTag Number Per USBTMC specification, bTag is incremented by host every time a USBTMC message is sent. Rolls over from 255 -> 1.
2 bTagInverse Number Per USBTMC specification, bTagInverse is the one's complement of bTag.
3 Reserved 0x00 Must be 0x00.
4-7 TransferSize LSByte first Length of command without header or alignment bytes.
8 bmTransferAttributes 0x01 EOM, indicating that the last message byte (excluding alignment bytes) in the transfer is the last byte of the message (used for USBTMC Split messages that use multiple transfers. Yet to see one on this device, don't know if it supports them. Probably not.)
9-11 Reserved 0xCDCDCD According to USBTMC spec, must be 0x000000. I interpret as Command Data to follow.


Command

Consists of a BULK-Out transfer with command without header, leading ":", newline or alignment bytes. Does not follow the PacketSize = n*4 bytes requirement.


REQUEST_DEV_DEP_MSG_IN

Consists of a USBTMC REQUEST_DEV_DEP_MSG_IN header to BULK-Out(0x01) endpoint. The command is not sent with this packet or message, instead, the command is sent using the DEV_DEP_MSG_OUT and Command packets. This packet only requests the response. Consists of a USBTMC Message DEV_DEP_MSG_OUT header:

Offset Field Value Description
0 MsgID 2 Identifies as REQUEST_DEV_DEP_MSG_IN.
1-3 bTag, bTagInverse, Reserved Number See #DEV_DEP_MSG_OUT
4-7 TransferSize LSByte first Maximum response data bytes. Only seen 0x40.
8 bmTransferAttributes 0x01 According to USBTMC spec, should be 0x02 (use TermChar from byte 9) or 0x00 (ignore TermChar))
9 TermChar 0x0A See USBTMC spec. For this device, not important.
10-11 Reserved 0x0000 As specified.


DEV_DEP_MSG_IN

Compliant with USBTMC, assuming wMaxPacketLength is 64. Header and data from BULK-In(0x82). If more than 52 bytes of data (plus 12 header) is needed, then rest of the data is sent in following packets without header or alignment bytes, compliant with USBTMC.

Offset Field Value Description
0 MsgID 2 Identifies as DEV_DEP_MSG_IN.
1-3 bTag, bTagInverse, Reserved Number See #DEV_DEP_MSG_OUT
4-7 TransferSize LSByte first Length of returned data without header or alignment bytes.
8 bmTransferAttributes 0x01 See USBTMC Specifications.
9-11 Reserved 0x0000 As specified.


Vendor Request 0x09

Vendor Endpoint In control message, always returns 0x01000000.

  • bmRequestType = 0xC2
  • bRequest = 0x09
  • wValue = 0x00
  • wIndex = 0x00
  • wLength = 0x04

Assuming first byte of response to be USBTMC_Status byte4. If left out from command sequences, the device will occasionally return the same answer packet to the next query.

TRIGGER

Not implemented, uses standard command sending method with command "*TRG"

Transfer sequences

Transfer sequences as performed by bundled software.


Command sequence

  1. DEV_DEP_MSG_OUT
  2. Command
    • If the command requires no response, the process ends here.
  3. Vendor Request 0x09
  4. Vendor Request 0x09
  5. REQUEST_DEV_DEP_MSG_IN
  6. DEV_DEP_MSG_IN

Startup sequence

Here commands are in bold and responses from device in italics. Commands can be abbreviated to uppercase portions (per VISA specifications). Commands are sent and responses read using #Command sequence


  1. *IDN? - RIGOL TECHNOLOGIES,VG1021, <serial>,<firmware>
  2. SYSTem:BEEPer:STATe ON
  3. VOLTage:RANGe:AUTO ON
  4. OUTPut:LOAD INFinity
  5. OUTPut:POLarity NORMal
  6. PHASe 0
  7. OUTPut OFF
  8. OUTPut:SYNC OFF
  9. FREQuency 1000
  10. VOLTage 5Vpp
  11. VOLTage:OFFSet 0V
  12. FUNCtion:SQUare:DCYCle 50
  13. FUNCtion::SYMMetry 50
  14. PULSe:DCYCle 50
  15. FUNCtion:USER EXP_RISE
  16. AM:SOURce INTernal
  17. AM:DEPTh 100
  18. AM:INTernal:FREQuency 100
  19. AM:INTernal:FUNCtion SINusoid
  20. FM:SOURce INTernal
  21. FM:DEViation 100
  22. FM:INTernal:FREQuency 100
  23. FM:INTernal:FUNCtion SINusoid
  24. FSKey:SOURce INTernal
  25. FSKey:FREQuency 100
  26. FM:INTernal:RATE 100
  27. PM:SOURce INTernal
  28. PM:DEViation 100
  29. PM:INTernal:FREQuency 100
  30. PM:INTernal:FUNCtion SINusoid
  31. SWEep:SPACing LINear
  32. FREQuency:STARt 100
  33. FREQuency:STOP 1000
  34. SWEep:TIME 1
  35. TRIGger:SOURce IMMediate
  36. BURSt:NCYCles 1
  37. BURSt:PHASe 0
  38. TRIGger:SOURce IMMediate
  39. BURSt:INTernal:PERiod 0.01
  40. TRIGger:DELay 0
  41. COUNter:COUPling AC
  42. COUNter:HFRState OFF
  43. COUNter:SENSitivity HIGH
  44. FUNCtion SINusoid
  45. FREQuency 1000
  46. VOLTage 5Vpp
  47. VOLTage:OFFSet 0V
  48. AM:STATe? - OFF
  49. FM:STATe? - OFF
  50. FSKey:STATe? - OFF
  51. PM:STATe? - OFF
  52. SWEep:STATe? - OFF
  53. BURSt:STATe? - OFF
  54. FUNCtion SINusoid


References

Retrieved from "https://sigrok.org/w/index.php?title=Rigol_VG1021&oldid=9774"