How to use the rigol 1042CD

Als ik alvast iets kan testen, zeg maar wat en hoe.

Heb je wat aan de specificaties van de DLL functies? Heb je een programmeertaal waar je vaak in werkt?

edit: Ik heb nu met een fake DLL Ultrascope zo ver dat ie denkt dat er een scope aan hangt en kan een paar gegevens uitlezen. K-Ray: was test1d.txt ook de exacte data van de usb log usbtest1d.txt of waren dit twee verschillende metingen?

[Bericht gewijzigd door madwizard op maandag 2 juli 2007 20:51:24

Even een overzicht van wat ik tot nu toe heb uit de DLL, je kunt deze zo in je eigen code gebruiken als je de DLL functies weet te declareren. Alles onder voorbehoud en op eigen risico uiteraard.

int GetDeviceNum();

Geeft aantal scopes terug.

int ReadUSB(int scopeIdx, int *pLength, char *pBuffer);

scopeIdx: 0-based nummer dat een bepaalde scoop aangeeft.
pLength: Pointer naar een int waar het aantal ontvangen bytes naar geschreven wordt.
pBuffer: Buffer waar de de data weggeschreven wordt (voor zover ik weet geen controle op de lengte hiervan dus moet groot genoeg zijn). Return value is true of false (!0 of 0). De teruggegeven data is alleen de payload. bij een SCPI command krijg je dus alleen het antwoord terug, verder geen headers e.d.

int WriteUSB(int scopeIdx, int function, int sequence, int length, char *pBuffer);

Schrijft data naar de scope. Exacte werking afhankelijk van function.
scopeIdx: zelfde als boven.
sequence: sequence nummer dat steeds opgehoogd wordt. Een ReadUSB telt geloof ik ook als sequence nummer ophoging.
Function: Bij function 1 is het een SCPI command. Hier wijst pBuffer naar een SCPI commando string. Length is de lengte van deze string (zonder terminators of enters).
Bij function 2: dit is een request voor data van de scope af en moet altijd gedaan worden voor een ReadUSB. De functie moet 2 zijn, sequence nummer moet kloppen maar alle overige parameters mogen 0 zijn in dit geval.
Return value is true of false (!0 of 0)

int Vendor_Request_Read(int scopeIdx, int request, int value, int index, int length, char *pBuffer);

Voert een USB vendor request read uit. De request, parameter, value, index en length parameters komen direct uit de USB specs. request is 1 byte (0-255), de overige parameters zijn 2 bytes. pBuffer is een pointer naar een buffer die de data ontvangt en moet minimaal length bytes zijn. Return value is true of false (!0 of 0).
Het enige request dat door ultrascope gedaan wordt is:

Vendor_Request_Read(scopeIdx, 9, 0, 0, 4, pBuffer);

Dit lijkt in de code een soort 'usb init' functie te hebben. De teruggegeven bytes zijn voor zover ik in de logs kon zien altijd 'dc 05 00 04', maar dit zou anders kunnen zijn. Ultrascope controleert in ieder geval of de eerste byte (normaal DC) nul is. Als dat zo is wordt het request nog een keer herhaald totdat het niet meer 0 is. Vreemd genoeg wordt daarna nog 1 keer het request gedaan zonder de output te verwerken (daarom staat dit pakket ook steeds 2 keer in de logs), of dit nodig is weet ik niet. Direct daarna wordt dan een commando uitgevoerd.

Ik weet niet wat de exacte functie is van de usb init request of wanneer deze nodig is maar daar kan wel wat mee geëxperimenteerd worden.

Op 2 juli 2007 18:51:31 schreef K-Ray:
Als ik alvast iets kan testen, zeg maar wat en hoe.

Ik weet niet of je je logs kan opslaan, iig Snoopypro (gebruik 0.22) kan het.
Het gaat hoofdzakelijk om de descriptors.

De logfile mag je mailen (naam.usblog)

@madwizard: ik weet niet meer of ik de export gedaan heb met exact dezelfde data dan ik de usblog genomen heb.
Ergens heb ik een nieuwe meting gedaan, maar ik weet niet meer van welke. Het zou dus goed kunnen dat de data uit de log net iets verschilt van deze van de lijst waarden.
Als je voor alle zekerheid wel een exacte zelfde meting nodig hebt dan kan ik je die wel bezorgen.

Verder zijn onderlinge metingen (data, wave, measure) wel telkens andere metingen. Uiteraard wel dezelfde instellingen en hetzelfde signaal.

@williewortel: De logs heb ik opgeslagen en kan je samen met andere data van een meting van mijn site downloaden: http://k-ray.vranken.org/

Kun je ook nog de output van usbview noteren?

http://www.ftdichip.com/Resources/Utilities.htm

-enable alle drie de opties
-auto refresh
-config descriptors
-location ID's

Mwhaaa, begint het al te kriebelen jongens? Ik heb ze hier op het werk al voorbereid op de komst van m'n pakket... Wordt echt wel ter plekke uitgepakt!

tja, deze week krijgen we ons speeltje denk ik

maar toevallig ben ik vrijdag t/m zondag weg....

[Bericht gewijzigd door Mitchell S op dinsdag 3 juli 2007 12:03:00

Op 3 juli 2007 12:02:34 schreef Mitchell S:
tja, deze week krijgen we ons speeltje denk ik

maar toevallig ben ik vrijdag t/m zondag weg....

Ouders thuis die kunnen ontvangen?

ik hoop dat ze deze week uitgeleverd worden, would be very nice.

Ja, me ouders zijn thuis. Die opdracht heb ik al gegeven

Maar met een beetje mazzel krijgen we het misschien donderdag en kan ik het zelf in ontvangst nemen

Op 26 juni 2007 21:52:40 schreef K-Ray:
@madwizard
Dit is een voorbeeldje van wat er zoal voorbij komt:
: T R I G G E R : S T A T U S ?
: M A T H : D I S P L A Y ?
: F F T : D I S P L A Y ?
: S Y S T E M : D A T A ?
: T R I G G E R : M O D E ?
: T I M E B A S E : F O R M A T
: C H A N N E L 2 : S C A L E ?
: C H A N N E L 2 : O F F S E T
: T I M E B A S E : S C A L E ?
: T I M E B A S E : O F F S E T
: W A V E F O R M : D A T A ?

Helaas vandaag geen tijd om te spelen.
Hopelijk morgen wel om wat bestanden online te zetten waar jullie verder mee kunnen.

Heb je dit ook in een van je logs staan? Kan het zo 1,2,3 niet terugvinden.

Ben regelmatig op de chat te vinden ('s avonds), misschien dat dat
wat makkelijker communiceert.

Op 3 juli 2007 17:08:16 schreef williewortel:
[...]

Heb je dit ook in een van je logs staan? Kan het zo 1,2,3 niet terugvinden.

Ben regelmatig op de chat te vinden ('s avonds), misschien dat dat
wat makkelijker communiceert.

ik zie liever dat het via het forum gaat, dan is het voor een ieder te lezen en blijft het ook staan... die chat (niet van CO) geeft dus geen toegevoegde waarde aan dit topic.

Ok, maakt mij niet uit. Had het idee, dat het teveel vervuiling zou
geven, de berichtgeving tussen mij en k-ray

Heb net de html versie van de logs bekeken en daar staat de data wel in ascii.

BTW zijn dit twee metingen direct achter elkaar?

120 : [65759 ms]  >>>  URB 4 going down  >>> 
121 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
122 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
123 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
124 :   TransferBufferLength = 0000000c
125 :   TransferBuffer       = 00000000
126 :   TransferBufferMDL    = 82355f48
127 :     00000000: 01 44 bb 00 10 00 00 00 01 37 39 39
   ===> 
 D » 
128 :   UrbLink              = 00000000
129 : [65761 ms] UsbSnoop - MyInternalIOCTLCompletion(f88e9db0) : fido=820173d8, Irp=81fb9c58, Context=823380f0, IRQL=2
130 : [65761 ms]  <<<  URB 4 coming back  <<< 
131 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
132 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
133 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
134 :   TransferBufferLength = 0000000c
135 :   TransferBuffer       = 00000000
136 :   TransferBufferMDL    = 82355f48
137 :   UrbLink              = 00000000
138 : [65762 ms] UsbSnoop - DispatchAny(f88e8610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
139 : [65762 ms] UsbSnoop - MyDispatchInternalIOCTL(f88e9e80) : fdo=820a4a60, Irp=81fb9c58, IRQL=0
140 : [65762 ms]  >>>  URB 5 going down  >>> 
141 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
142 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
143 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
144 :   TransferBufferLength = 00000010
145 :   TransferBuffer       = 00000000
146 :   TransferBufferMDL    = 82355f48
147 :     00000000: 3a 54 52 49 47 47 45 52 3a 53 54 41 54 55 53 3f
   ===> : T R I G G E R : S T A T U S ?
148 :   UrbLink              = 00000000
149 : [65763 ms] UsbSnoop - MyInternalIOCTLCompletion(f88e9db0) : fido=820173d8, Irp=81fb9c58, Context=82018508, IRQL=2
150 : [65763 ms]  <<<  URB 5 coming back  <<< 
151 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
152 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
153 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
154 :   TransferBufferLength = 00000010
155 :   TransferBuffer       = 00000000
156 :   TransferBufferMDL    = 82355f48
157 :   UrbLink              = 00000000
158 : [65765 ms] UsbSnoop - DispatchAny(f88e8610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
159 : [65765 ms] UsbSnoop - MyDispatchInternalIOCTL(f88e9e80) : fdo=820a4a60, Irp=82079518, IRQL=0
160 : [65765 ms]  >>>  URB 6 going down  >>> 
161 : -- URB_FUNCTION_VENDOR_ENDPOINT:
162 :   TransferFlags          = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
163 :   TransferBufferLength = 00000004
164 :   TransferBuffer       = 8201d000
165 :   TransferBufferMDL    = 00000000
166 :   UrbLink                 = 00000000
167 :   RequestTypeReservedBits = 00000000
168 :   Request                 = 00000009
169 :   Value                   = 00000000
170 :   Index                   = 00000000
171 : [65769 ms] UsbSnoop - MyInternalIOCTLCompletion(f88e9db0) : fido=00000000, Irp=82079518, Context=821aa100, IRQL=2
172 : [65769 ms]  <<<  URB 6 coming back  <<< 
173 : -- URB_FUNCTION_CONTROL_TRANSFER:
174 :   PipeHandle           = 820b2e98
175 :   TransferFlags        = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
176 :   TransferBufferLength = 00000004
177 :   TransferBuffer       = 8201d000
178 :   TransferBufferMDL    = 82355f48
179 :     00000000: dc 05 00 04
   ===> Ü  
180 :   UrbLink              = 00000000
181 :   SetupPacket          =
182 :     00000000: c2 09 00 00 00 00 04 00
   ===> Â 	 
183 : [65771 ms] UsbSnoop - DispatchAny(f88e8610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
184 : [65771 ms] UsbSnoop - MyDispatchInternalIOCTL(f88e9e80) : fdo=820a4a60, Irp=82079518, IRQL=0
185 : [65771 ms]  >>>  URB 7 going down  >>> 
186 : -- URB_FUNCTION_VENDOR_ENDPOINT:
187 :   TransferFlags          = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
188 :   TransferBufferLength = 00000004
189 :   TransferBuffer       = 821cd000
190 :   TransferBufferMDL    = 00000000
191 :   UrbLink                 = 00000000
192 :   RequestTypeReservedBits = 00000000
193 :   Request                 = 00000009
194 :   Value                   = 00000000
195 :   Index                   = 00000000
196 : [65774 ms] UsbSnoop - MyInternalIOCTLCompletion(f88e9db0) : fido=00000000, Irp=82079518, Context=82018508, IRQL=2
197 : [65774 ms]  <<<  URB 7 coming back  <<< 
198 : -- URB_FUNCTION_CONTROL_TRANSFER:
199 :   PipeHandle           = 820b2e98
200 :   TransferFlags        = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
201 :   TransferBufferLength = 00000004
202 :   TransferBuffer       = 821cd000
203 :   TransferBufferMDL    = 82355f48
204 :     00000000: dc 05 00 04
   ===> Ü  
205 :   UrbLink              = 00000000
206 :   SetupPacket          =
207 :     00000000: c2 09 00 00 00 00 04 00
   ===> Â 	 
208 : [65776 ms] UsbSnoop - DispatchAny(f88e8610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
209 : [65776 ms] UsbSnoop - MyDispatchInternalIOCTL(f88e9e80) : fdo=820a4a60, Irp=81fb9c58, IRQL=0
210 : [65776 ms]  >>>  URB 8 going down  >>> 
211 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
212 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
213 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
214 :   TransferBufferLength = 0000000c
215 :   TransferBuffer       = 00000000
216 :   TransferBufferMDL    = 82355f48
217 :     00000000: 02 45 ba 00 40 00 00 00 01 0a 00 00
   ===>  E º 
218 :   UrbLink              = 00000000
219 : [65777 ms] UsbSnoop - MyInternalIOCTLCompletion(f88e9db0) : fido=820173d8, Irp=81fb9c58, Context=821ca3c0, IRQL=2
220 : [65777 ms]  <<<  URB 8 coming back  <<< 
221 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
222 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
223 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
224 :   TransferBufferLength = 0000000c
225 :   TransferBuffer       = 00000000
226 :   TransferBufferMDL    = 82355f48
227 :   UrbLink              = 00000000
228 : [65779 ms] UsbSnoop - DispatchAny(f88e8610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
229 : [65779 ms] UsbSnoop - MyDispatchInternalIOCTL(f88e9e80) : fdo=820a4a60, Irp=81fb9c58, IRQL=0
230 : [65779 ms]  >>>  URB 9 going down  >>> 
231 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
232 :   PipeHandle           = 81fdde8c [endpoint 0x00000082]
233 :   TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
234 :   TransferBufferLength = 00000040
235 :   TransferBuffer       = 00000000
236 :   TransferBufferMDL    = 82355f48
237 :   UrbLink              = 00000000
238 : [65780 ms] UsbSnoop - MyInternalIOCTLCompletion(f88e9db0) : fido=820173d8, Irp=81fb9c58, Context=821aa100, IRQL=2
239 : [65780 ms]  <<<  URB 9 coming back  <<< 
240 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
241 :   PipeHandle           = 81fdde8c [endpoint 0x00000082]
242 :   TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
243 :   TransferBufferLength = 0000000f
244 :   TransferBuffer       = 00000000
245 :   TransferBufferMDL    = 82355f48
246 :     00000000: 02 45 ba 00 03 00 00 00 01 00 00 00 54 27 44
   ===>  E º 
247 :   UrbLink              = 00000000
248 : [65782 ms] UsbSnoop - DispatchAny(f88e8610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
249 : [65782 ms] UsbSnoop - MyDispatchInternalIOCTL(f88e9e80) : fdo=820a4a60, Irp=81fb9c58, IRQL=0
250 : [65782 ms]  >>>  URB 10 going down  >>> 
251 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
252 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
253 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
254 :   TransferBufferLength = 0000000c
255 :   TransferBuffer       = 00000000
256 :   TransferBufferMDL    = 82355f48
257 :     00000000: 01 47 b8 00 0d 00 00 00 01 37 39 39
   ===> 
 G ¸ 
258 :   UrbLink              = 00000000
259 : [65783 ms] UsbSnoop - MyInternalIOCTLCompletion(f88e9db0) : fido=820173d8, Irp=81fb9c58, Context=8223c220, IRQL=2
260 : [65783 ms]  <<<  URB 10 coming back  <<< 
261 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
262 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
263 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
264 :   TransferBufferLength = 0000000c
265 :   TransferBuffer       = 00000000
266 :   TransferBufferMDL    = 82355f48
267 :   UrbLink              = 00000000
268 : [65783 ms] UsbSnoop - DispatchAny(f88e8610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
269 : [65783 ms] UsbSnoop - MyDispatchInternalIOCTL(f88e9e80) : fdo=820a4a60, Irp=81fb9c58, IRQL=0
270 : [65784 ms]  >>>  URB 11 going down  >>> 
271 : -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
272 :   PipeHandle           = 81fdde6c [endpoint 0x00000001]
273 :   TransferFlags        = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
274 :   TransferBufferLength = 0000000d
275 :   TransferBuffer       = 00000000
276 :   TransferBufferMDL    = 82355f48
277 :     00000000: 3a 53 59 53 54 45 4d 3a 44 41 54 41 3f
   ===> : S Y S T E M : D A T A ?

[Bericht gewijzigd door williewortel op dinsdag 3 juli 2007 18:05:33

Op 3 juli 2007 07:37:57 schreef williewortel:
Kun je ook nog de output van usbview noteren?

Device Descriptor:
bcdUSB: 0x0110
bDeviceClass: 0xFF
bDeviceSubClass: 0xFF
bDeviceProtocol: 0xFF
bMaxPacketSize0: 0x40 (64)
idVendor: 0x0400 (National Semiconductor)
idProduct: 0x05DC
bcdDevice: 0x0100
iManufacturer: 0x01
iProduct: 0x02
iSerialNumber: 0x00
bNumConfigurations: 0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: Full
Device Address: 0x02
Open Pipes: 2

Endpoint Descriptor:
bEndpointAddress: 0x01
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x00

Endpoint Descriptor:
bEndpointAddress: 0x82
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x00

Ok, dan heb ik de logs goed ontcijfert. Mis alleen nog de report
descriptor.

Vond het al apart dat het VendorId van National Semi gebruikt werd

[Bericht gewijzigd door williewortel op dinsdag 3 juli 2007 21:37:34

Die YSTEM : DATA? geeft een zootje binaire data terug, het is geen meting maar een soort status van de scope denk ik, het formaat is me nog niet duidelijk. De meeste commando's gaan gewoon in ASCII over de lijn en komen ook zo terug.

Voor de mensen die een rechtstreekse USB implementatie willen maken (ik weet niet bijzonder veel van de USB details maar dit is het grofweg):

De configuratie bestaat uit 2 endpoints naast het control endpoint (3 totaal dus maar control telt vaak niet mee). Endpoint 1 en 2 zijn respectievelijk down en up-links.

De scope commando's die over USB gaan zijn:
USB init
Dit is een vendor request setup pakket naar het config endpoint.

bmRequestType = 0xC2 (device->host, type=vendor, recp=endpoint)
Request = 9
Value = 0
Index = 0
Length = 4

Je krijgt 4 bytes terug, 'DC 05 00 04' maar het kan misschien ook wat anders zijn. In ieder geval moet de eerste byte niet 0 zijn, dan is er iets mis (wat precies weet ik ook niet).

Write (endpoint 1)
Commando's worden geschreven met een 12 byte header. Het formaat van de header is:

byte    0       1       2       3   
waarde  func    seq     ~seq    00  

byte    4       5       6       7   
waarde  [ length (little endian) ]

byte    8       9       10      11
waarde  A       B       C       D

Func is de uit te voeren functie. Seq is een sequence nummer. A, B, C en D zijn afhankelijk van function.

Function 1 is een SCPI commando. Length is de lengte van het commando. byte A = 1. B, C en D zijn volgens mij ongedefinieerd (don't care) maar lijken in de praktijk altijd op '37 39 39' te staan. Het hele commando wordt dus:

01 SQ NQ 00 L0 L1 L2 L3 01 37 39 39

Dit wordt eerst als USB pakket gestuurd naar endpoint 1, vervolgens wordt het commando zelf erachteraan gestuurd.

Function 2 is een request voor een reply van de scope. Dit wordt gebruikt om bij SCPI queries het antwoord uit te lezen. Hier is length altijd 0x40, A = 1, B = 0x0A, C en D zijn 0. Het sequence nummer moet wel correct zijn. Het commando wordt dus:

02 SQ NQ 00 40 00 00 00 01 0A 00 00

De scope zal hierna reageren met een gelijksoortige header.

Read (endpoint 2)
Als een function 2 request gestuurd is wordt daarna data gelezen uit endpoint 2. De teruggegeven data begint met dezelfde header als het request, maar dan met de werkelijke length van het antwoord, en B is vervangen door 0.

02 SQ NQ 00 L0 L1 L2 L3 01 00 00 00 {data}

Een voorbeeld:

02 06 F9 00 03 00 00 00 01 00 00 00 4F 46 46    ............OFF

De data kan vrij groot zijn, ultrascope/de driver leest het uit in blokken van maximaal 4096 bytes, maar begint eerst met een request van maximaal 0x40 bytes. Hier zit de header al in met de werkelijke lengte en indien nodig worden meer bytes uitgelezen.

De data is over het algemeen een vaste lengte, die logica kan ik in de
logs nog niet ontdekken.
Verder is het niet echt netjes opgezet, gezien het feit dat ze de
VendorId van NS gebruiken en twee aparte endpoints voor in en uit
gebruiken. Endpoint 1 en 2, je kan gewoon een endpoint 1 in en een
endpoint 1 uit hebben.
Doordat de data niet duidelijk is nog, wordt het ontcijferen een
beetje bemoeilijkt nog. Als ik de Report Descriptor heb zal het
makkelijker gaan, maar ik blijf proberen....

edit:

@madwizard, bedankt voor het opfrissen van mijn geheugen. Was ff
vergeten dat met de logger, je ook de header ziet, waarmee je normaal
niks mee te maken hebt in de software (begint ook met een 1).
Report ID 1 is idd SCPI, wat Report ID 2 is weet ik nog niet.
probeer nog iets in elkaar te kleien.

@k-ray kan ik je e-mail adres uit je profiel gebruiken om je
te spammen met test progjes?

[Bericht gewijzigd door williewortel op dinsdag 3 juli 2007 22:17:43

Op 3 juli 2007 22:09:02 schreef williewortel:
De data is over het algemeen een vaste lengte, die logica kan ik in de
logs nog niet ontdekken.

Heb je mijn posts wel gelezen? Ik heb de data vrijwel geheel ontcijfert.

Verder is het niet echt netjes opgezet, gezien het feit dat ze de
VendorId van NS gebruiken

Misschien gebruiken ze gewoon een USB chipje van national? En hebben ze daarvan een VID/PID combo gekregen? Maar misschien ook niet, zou wel erg slordig zijn dan.

en twee aparte endpoints voor in en uit 
gebruiken. Endpoint 1 en 2, je kan gewoon een endpoint 1 in en een endpoint 1 uit hebben.

Ik dacht dat het wel normaal was 2 endpoints voor zoiets te hebben?

Ieder endpoint bestaat in theorie uit een "in" en een "out" gedeelte
deze kunnen een aparte buffer hebben of een gedeelde. Twee aparte
endpoints is eigenlijk overbodig, sommige micro's hebben alleen niet
alle endpoints volledig geimplementeerd, dus misschien dat dat de
reden is geweest.

Dan is er alleen nog de M$ bug, in principe kan je gewoon opgeven
hoeveel data je daadwerkelijk stuurt, maar M$ moet weer afwijken
en wil niet weten hoeveel je stuurt, maar wat het maximaal mogelijke
data grootte kan zijn (Max DataSize), wat tegen de afspraak in is.

[Bericht gewijzigd door williewortel op dinsdag 3 juli 2007 22:23:49

Op 3 juli 2007 22:19:47 schreef williewortel:
Ieder endpoint bestaat in theorie uit een "in" en een "out" gedeelte
deze kunnen een aparte buffer hebben of een gedeelde. Twee aparte
endpoints is eigenlijk overbodig, sommige micro's hebben alleen niet
alle endpoints volledig geimplementeerd, dus misschien dat dat de
reden is geweest.

Dat wist ik niet, ik dacht dat endports of in of out waren, FTDI chipjes hebben er ook twee volgens mij.

Op 3 juli 2007 22:09:02 schreef williewortel:
wat Report ID 2 is weet ik nog niet. probeer nog iets in elkaar te kleien.

Report ID en descriptor klinkt als iets HID device achtigs (ik weet er weinig van), maar volgens mij is het geen HID device.
De data met als eerste byte 2 zijn in ieder geval een SCPI antwoord requests en responses.

Je kan een device meerdere configuraties geven (omslachtig in de praktijk en werkt meestal niet).
Je kan echter ook in de data opgeven voor wie de data is, zo kun je
met 1 endpoint meerdere dingen bedienen. Gebruik de data maar voor
een iets, dan kan de eerste byte -de reportID- 0 worden, je geeft
dan in je descriptor tabel gewoon niks op, stack regelt dat doorgaans
zelf. Wil je echter data kunnen versturen voor b.v een motor en b.v.
een dimmer, dan kan je twee reports in een definieeren.
De eerste byte word dan reportID.
Zo heeft mijn joystick converter maar twee endpoints, terwijl het
een keyboard en 2 joysticks vermeld.

b.v. (van het net geplukt)

0x06,
0xA0, 0x0F, /* Usage Page (vendor defined) */
0x09, 0x01, /* Usage (vendor defined (HIDView lo identifica come Pointer, ma in realta' essendo VENDOR-DEFINED la UsagePage, non e' cosi') */
0xA1, 0x01, /* Collection (Application) */
0x09, 0x02, /* Usage (vendor defined (v. sopra)) */
0xA1, 0x00, /* Collection (Physical) */
0x06,
0xA1, 0xFF, /* Usage Page (Buttons) */
0x09, 0x03, /* Usage */
0x09, 0x04, /* Usage */
0x15, 0x80, /* Logical Minimum (0) */
0x25, 0x7F, /* Logical Maximum (0) */
/* 0x26, 0xFF, 0x00 Logical Maximum a 16 bit */
0x35, 0x00, /* Report Count (3) */
0x45, 0xFF, /* Report Size (1) */
0x85, 0x01, /* Report ID (1) */
0x95, HID_INT_IN_EP_SIZE-1, /* report count (8) (fields (= bytes)) */
0x75, 0x08, /* Report Size (8) bits */
0x81, 0x02, /* input (data, variable, absolute) */
0x09, 0x05, /* Usage Page (vendor defined (v.sopra)) */
0x09, 0x06, /* Usage (vendor defined (v.sopra)) */
0x15, 0x80, /* logical minimum (-128) */
0x25, 0x7F, /* Logical Maximum (127) */
/* 0x26, 0xFF, 0x00 Logical Maximum a 16 bit */
0x35, 0x00, /* physical minimum (0) */
0x45, 0xFF, /* physical maximum (255) */
0x85, 0x02, /* report id (2) */
0x95, HID_INT_OUT_EP_SIZE-1, /* Report Count (8) fields=bits */
0x75, 0x08, /* report size (8) (bits) */
0x91, 0x02, /* output (data, variable, absolute) */
0xC0, 0xC0};/* End Collection,End Collection */

Wat zou een leuk scpi commando kunnen zijn?
Iets dat alleen stuurt en geen antwoord terug verwacht.

Ik weet niet of dit commando een herkenbare reaktie geeft, zodat
je weet dat de scope het commando heeft geaccepteerd?:

801 : 00000000: 3a 4d 45 41 53 55 52 45 3a 53 4f 55 52 43 45 20
===> : M E A S U R E : S O U R C E
802 : 00000010: 43 48 41 4e 4e 45 4c 31
===> C H A N N E L 1

Op 3 juli 2007 22:31:55 schreef williewortel:
Je kan echter ook in de data opgeven voor wie de data is, [...]

Maar is dit niet specifiek voor de HID class? Want zo te zien valt de scope daar niet onder (device class = 0xFF, vendor specific).

Wat zou een leuk scpi commando kunnen zijn?
Iets dat alleen stuurt en geen antwoord terug verwacht.

Misschien:

:KEY:LOCK ENABLE

Ik denk dat dit de toetsen op de scope blokkeert, maar zeker weten doe ik het niet (wordt in ieder geval wel gebruikt door ultrascope).
Of:

:LA:DISPLAY ON

Zou de logic analyser actief moeten zetten (ook niet getest, heb geen scope he ).

Als je een reply wilt probeer:

*IDN?

Dit zou iets terug moeten geven in de trant van:

RIGOL TECHNOLOGIES,DS1042CD,DS1042000000284,02.03.04

Ik zal de LA optie ook implementeren

Report ID's zijn niet HID specifiek.

[Bericht gewijzigd door williewortel op dinsdag 3 juli 2007 23:51:34

Op 3 juli 2007 22:23:17 schreef madwizard:
[...]
Dat wist ik niet, ik dacht dat endports of in of out waren, FTDI chipjes hebben er ook twee volgens mij.

[...]
Report ID en descriptor klinkt als iets HID device achtigs (ik weet er weinig van), maar volgens mij is het geen HID device.
De data met als eerste byte 2 zijn in ieder geval een SCPI antwoord requests en responses.

alleen endpoint 0 is bidirectioneel. de andere zijn ofwel in of out.

en voor een scpi commando

*RST : dit reset de machiene

zou duidelijk zichtbaar moeten zijn

Op 3 juli 2007 22:13:54 schreef madwizard:Misschien gebruiken ze gewoon een USB chipje van national?

Het is eentje van Philips (heb ik al ergens gepost).