Rigol VG1021

From sigrok
Jump to: navigation, search

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