==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)[[#References|1]], but deviates significantly from specification.[[#References|2]],[[#References|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):
{| 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
|- bgcolor="#dddddd"
| ???TRIGGER???
| 128
|
| BULK-Out(0x01)
| Trigger the device. I'm assuming it's implemented, need to check.
|}

====DEV_DEP_MSG_OUT====

Consists of a USBTMC DEV_DEP_MSG_OUT header:
{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
!Offset
!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[[#References|4]].

====???TRIGGER???====
Assuming compliance with USB488 subclass but haven't tested it.

===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
#*Whether these two are necessary, or just leftovers from a different device, remains to be seen.
#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==
*[[#Protocol|1]] [http://www.usb.org/developers/defined_class#BaseClassFEh USB.org - Defined 1.0 Class Codes]
*[[#Protocol|2]], [[#Vendor Request 0x09|4]] [http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip USB.org - Approved Class Specification Documents - TMC Specifications] USBTMC 1.00
*[[#Protocol|3]] [http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip USB.org - Approved Class Specification Documents - TMC Specifications] USBTMC-USB488 1.00

Rigol VG1021

2013-04-27T22:56:12Z

Jostikas: Shoud be a working set of protocol. Needs a source for command reference.

Rigol VG1021

2013-04-27T13:58:36Z

Jostikas:

2013-04-14T16:33:25Z

Jostikas:

[[File:Rigol_VS5202D.png|thumb|right|Rigol VS5000 series]]

The [http://rigol.com/ Rigol VS5202D] is a 2 channel analog and 16 channel digital, 200 MHz, USB-based oscilloscope/logic analyzer.

The device is [http://int.rigol.com/prodserv/Discontinued%20products/ discontinued by Rigol], but you can find the basic specs e.g. [http://www.batronix.com/shop/oscilloscopes/Rigol-VS5202D.html here]. Maybe some more info by comparing with the
[http://www.digitalscopes.net/pdf/DS1000%20Programming%20Manual%20%28English%29.pdf DS1000 programming manual].

See [[Rigol VS5202D/Info]] for some more details (such as '''lsusb -vvv''' output) on the device.

== Hardware ==

'''CPU'''
* [http://www.analog.com/static/imported-files/data_sheets/ADSP-BF531_BF532_BF533.pdf Analog Devices ADSP-BF531] Blackfin CPU
* [http://www.skhynix.com/products/consumer/view.jsp?info.ramKind=01&info.serialNo=HY57V281620FTP&posMap=EOL Hynix HY57V281620FTP] 16MB DRAM
* [http://www.spansion.com/Products/Parallel-Flash/Pages/Spansion%20GL.aspx Spansion S29GL032A] 4MB flash

'''Analog acquisition'''
* [http://www.altera.com/devices/fpga/cyclone/overview/cyc-overview.html Altera Cyclone EP1C6] 6000-gate FPGA
* [http://www.altera.com/literature/hb/cfg/cyc_c51014.pdf Altera EPCS] 128Kb flash memory
* [http://www.issi.com/pdf/61vps_lps25636a_51218a.pdf ISSI IS61LPS25636A] 1MB SRAM

'''Logic acquisition'''
* [http://www.altera.com/devices/fpga/cyclone2/overview/cy2-overview.html Altera Cyclone II EP2C5] 4600-gate FPGA
* [http://www.altera.com/literature/hb/cfg/cyc_c51014.pdf Altera EPCS] 128Kb flash memory
* [http://www.issi.com/pdf/61vps_lps25636a_51218a.pdf ISSI IS61LPS25636A] 1MB SRAM

'''Ethernet interface'''
* [http://www.davicom.com.tw/userfile/24247/DM9000EPProductBrief_v1.0.pdf Davicom DM9000EP] 10/100 ethernet controller
* 25MHz oscillator

'''USB interface'''
* [http://www.plxtech.com/products/usbcontrollers/net2272 PLX NetChip NET2272] USB 2.0 controller
* 130MHz oscillator

== Photos ==

<gallery>
File:Rigol VS5202D front.jpg
File:Rigol VS5202D back.jpg
File:Rigol VS5202D PCB top.jpg
File:Rigol VS5202D PCB bottom.jpg
File:Rigol VS5202D CPU.jpg
File:Rigol VS5202D ethernet-USB.jpg
File:Rigol VS5202D analog frontend.jpg
File:Rigol VS5202D analog op-amps.jpg
File:Rigol VS5202D analog.jpg
File:Rigol VS5202D analog EPCS1N.jpg
File:Rigol VS5202D logic.jpg
File:Rigol VS5202D logic EPCS1N.jpg
File:Rigol VS5202D PCB power.jpg
File:Rigol VS5202D PCB detail 1.jpg
File:Rigol VS5202D PCB detail 2.jpg
File:Rigol VS5202D PCB detail 3.jpg
File:Rigol VS5202D PCB detail 4.jpg
File:Rigol VS5202D PCB detail 5.jpg
File:Rigol VS5202D accessories.jpg
File:Rigol VS5202D digital pod.jpg
File:Rigol VS5202D digital pod connectors.jpg
</gallery>

== Protocol ==

'''Work in progress.'''

The Rigol communication protocol only uses the USB control and bulk transfer. Control is for sending setup and request smaller amounts of data. Bulk transfers is returned by the Rigol box with setup and image data.

All control transfers interesting for us has request type set to '''0xc0'''.
The request field in the control packets is what tells us which command
is actually sent.

All descriptions below should have both request type and request set to proper
values, obvious from the headlines what it should be.

=== Packet types ===
This information is completely reverse engineered by hand.

==== Read answer (request = 0x00) ====
Commands ending with a question mark ('?' ASCII 0x3f) returns answer in two control transfers.

First control transfer is to query the size of the data to be returned.
That is done by value set to 0. One byte of data is returned in the data field
by this operation which is the size of the string the Rigol box wants to return.

Second control transfer has value set to 1. The buffer, allocated to the size
just read, is also sent along the command to be filled with the data. The
returned data is an ASCII string.

==== Write command (request = 0x01) ====
Commands from the PC program to the Rigol box is sent as text strings.
Which commands that are available are listed in the [http://www.tequipment.net/pdf/Rigol/VS5000_programming.pdf '''Programming Guide'''] from Rigol.

Each character is sent in a control message with the value set to the ASCII character to be sent. Each ASCII string is terminated with a carriage return (0x0d, '\r'), which terminates the transmission.

==== Request waveform data (Request = 0x04) ====
When waveform data is requested to be retrieved a control message is sent.
The index field of the setup data is a bitmask on which channels to be requested. It is encoded as bit 0 meaning Channel 1, bit 1 meaning Channel 2, bit 2 meaning Logic Channel 0, bit 3 meaning Logic Channel 1 etc.

The 4 byte data field of the control packet sent back as an ack contains number of bytes to be returned by bulk messages. It is encoded LSB first.

After that a series of bulk transfers occurs, with up to 4096 bytes in each transfer, until number of bytes given before is transferred.

==== Unknown control packet (Request = 0x05) ====
This control transfer is unknown, but it occurs when stop ha been pressed and streaming of big bulk blocks is terminated. All encoding in the control transfers are as described by request 0x04 above. The index field is always zero. Seems like some kind of 'flush buffers' command.

==== SETUP DSO? (Request = 0x06) ====
After this control transfer a bulk transfers occurs with 780 bytes of data.
What each byte means is still to be determined, but will occur in a separate description.
Same data is returned in response to undocumented instruction :SETUP:DSO? over TCP/IP.

==== SETUP LA? (Request = 0x0c) ====
After this control transfer a bulk transfers occurs with 260 bytes of data.
What each byte means is still to be determined, but will occur in a separate description.
Same data is returned in response to undocumented instruction :SETUP:LA? over TCP/IP.

==== SETUP ALT? (Request = 0x0d) ====
After this control transfer a bulk transfers occurs with 396 bytes of data.
What each byte means is still to be determined, but will occur in a separate description.
Same data is returned in response to undocumented instruction :SETUP:ALT? over TCP/IP.

=== Transfer sequences ===

==== Turn-on sequence ====
# *IDN?
# :INFO:FPGA?
# :STOP
# SETUP DSO?
# SETUP LA?
# SETUP ALT?

==== Turn-off sequence ====
Nothing special.

==== Start reading waveform data ====
2 analogue channels.
# :CLEARUSB
# :RUN
# SETUP DSO?
# SETUP LA?
# SETUP ALT?
# SETUP DSO?
# SETUP DSO? (waiting for something?)
# Request waveform data.
# The data is started get transferred using bulk transfer.

==== Stop reading waveform data ====
2 analogue channels.
# :STOP
# :CLEARUSB
# Request waveform data, which returns with size 0.
# Unknown transfer, which returns with 8192 bytes of data.
# The 8192 byte of data is bulked up.
# :INFO:EUQP?
# SETUP DSO?

==== Command sequences ====
# Command
# SETUP DSO?
# SETUP LA?
# SETUP ALT?

=== Data blocks ===

==== 260 bytes block ====
{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
!Address
!Description
|- bgcolor="#eeeeee"
| 0
| Logic analyzer off/on
|- bgcolor="#dddddd"
| 1
| Logic analyzer available
|- bgcolor="#eeeeee"
| 2
| Logic analyzer channel 0 off/on
|- bgcolor="#dddddd"
| 3
| Logic analyzer channel 1 off/on
|- bgcolor="#eeeeee"
| 4
| Logic analyzer channel 2 off/on
|- bgcolor="#dddddd"
| 5
| Logic analyzer channel 3 off/on
|- bgcolor="#eeeeee"
| 6
| Logic analyzer channel 4 off/on
|- bgcolor="#dddddd"
| 7
| Logic analyzer channel 5 off/on
|- bgcolor="#eeeeee"
| 8
| Logic analyzer channel 6 off/on
|- bgcolor="#dddddd"
| 9
| Logic analyzer channel 7 off/on
|- bgcolor="#eeeeee"
| 10
| Logic analyzer channel 8 off/on
|- bgcolor="#dddddd"
| 11
| Logic analyzer channel 9 off/on
|- bgcolor="#eeeeee"
| 12
| Logic analyzer channel 10 off/on
|- bgcolor="#dddddd"
| 13
| Logic analyzer channel 11 off/on
|- bgcolor="#eeeeee"
| 14
| Logic analyzer channel 12 off/on
|- bgcolor="#dddddd"
| 15
| Logic analyzer channel 13 off/on
|- bgcolor="#eeeeee"
| 16
| Logic analyzer channel 14 off/on
|- bgcolor="#dddddd"
| 17
| Logic analyzer channel 15 off/on
|}

==== 396 bytes block ====
No information

==== 780 bytes block ====
{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
!Address
!Description
|- bgcolor="#eeeeee"
| 8
| Analogue 1; OFF = 0, ON chan1 = 1, ON chan2 = 2 (bitmask?)\\
|- bgcolor="#dddddd"
| 12
| Analogue 1; OFF = 0, ON = 1
|- bgcolor="#eeeeee"
| 32
| Coupling chan1; DC = 0, AC = 1, GND = 2
|- bgcolor="#dddddd"
| 44
| Bandwidth Limit chan1; OFF = 0, ON = 1
|- bgcolor="#eeeeee"
| 46
| Invert chan1; OFF = 0, ON = 1
|- bgcolor="#dddddd"
| 90
| Analogue 2; OFF = 0, ON = 1
|- bgcolor="#eeeeee"
| 108
| Coupling chan2; DC = 0, AC = 1, GND = 2
|- bgcolor="#dddddd"
| 120
| Bandwidth Limit chan2; OFF = 0, ON = 1
|- bgcolor="#eeeeee"
| 122
| Invert chan1; OFF = 0, ON = 1
|- bgcolor="#dddddd"
| 448
| Acquire type; Normal = 0, Average = 1, Peak = 2
|- bgcolor="#eeeeee"
| 456
| Acquire average; 2 = 1, 4 = 2, 8 = 3, 16 = 4, 32 = 5, 64 = 6, 128 = 7, 256 = 8
|- bgcolor="#dddddd"
| 520
| Trigger mode; Edge = 0, Pulse = 1, Slope = 2, Video = 3, Alternate = ?, Pattern = 5, Duration = 6
|}

=== The image information bulk transfer ===

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Oscilloscope]]
[[Category:Mixed-signal oscilloscope]]
[[Category:Planned]]