How to use the rigol 1042CD

@Jochem_S:
Zowel de Rigol software voor DS1000, DS5000 als de Agilent software voor de 3000 reeks lijken als druppels water op elkaar. Echter werken ze blijkbaar enkel voor een specifiek toestel. Ik ben er niet lang mee bezig geweest, maar enkel bij de Ultrascope voor DS1000 vind het programma een usb-device.

@madwizard:
Ik gebruik sniffusb 1.6, maar waar ik die vandaag heb weet ik niet meer. Het is blijkbaar een afgeleide van snoopy usb en is intussen alweer door andere ontwikkelaars onder handen genomen. Google eens op sniffusb. Je komt vast wel een recenter exemplaar tegen. Ik zie niet meteen functioneel verschil in de versies, dus blijf ik maar voortdoen met mijn oude versie.
Wat hij uitspuwt snap ik echter niet veel van. Ik ben geen usb-kenner. Uit de hex-data heb ik wel al wat bruikbare info gehaald zoals de SCPI commando's en de sample-data.

Zo ziet de log eruit na een initialisatie:
[0 ms] UsbSnoop compiled on Jan 18 2003 22:41:32 loading
[0 ms] UsbSnoop - DriverEntry(f88b2c40) : Windows NT WDM version 1.32
[16 ms] UsbSnoop - AddDevice(f88b2f50) : DriverObject 82016998, pdo 820a4a60
[16 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (0x00000018)
[16 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (0x00000018)
[17 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (IRP_MN_QUERY_RESOURCE_REQUIREMENTS)
[17 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (IRP_MN_QUERY_RESOURCE_REQUIREMENTS)
[17 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (IRP_MN_FILTER_RESOURCE_REQUIREMENTS)
[17 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (IRP_MN_FILTER_RESOURCE_REQUIREMENTS)
[17 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (IRP_MN_START_DEVICE)
[17 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (IRP_MN_START_DEVICE)
[170 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[170 ms] UsbSnoop - MyDispatchInternalIOCTL(f88b1e80) : fdo=820a4a60, Irp=82326e28, IRQL=0
[170 ms] >>> URB 1 going down >>>
-- URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE:
TransferBufferLength = 00000012
TransferBuffer = f89879a4
TransferBufferMDL = 00000000
Index = 00000000
DescriptorType = 00000001 (USB_DEVICE_DESCRIPTOR_TYPE)
LanguageId = 00000000
[174 ms] UsbSnoop - MyInternalIOCTLCompletion(f88b1db0) : fido=00000000, Irp=82326e28, Context=81ff4e18, IRQL=2
[174 ms] <<< URB 1 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 820b2e98
TransferFlags = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000012
TransferBuffer = f89879a4
TransferBufferMDL = 821244e8
00000000: 12 01 10 01 ff ff ff 40 00 04 dc 05 00 01 01 02
00000010: 00 01
UrbLink = 00000000
SetupPacket =
00000000: 80 06 00 01 00 00 12 00
[174 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[174 ms] UsbSnoop - MyDispatchInternalIOCTL(f88b1e80) : fdo=820a4a60, Irp=82326e28, IRQL=0
[174 ms] >>> URB 2 going down >>>
-- URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE:
TransferBufferLength = 00000400
TransferBuffer = 81e17448
TransferBufferMDL = 00000000
Index = 00000000
DescriptorType = 00000002 (USB_CONFIGURATION_DESCRIPTOR_TYPE)
LanguageId = 00000000
[179 ms] UsbSnoop - MyInternalIOCTLCompletion(f88b1db0) : fido=00000000, Irp=82326e28, Context=82337730, IRQL=2
[179 ms] <<< URB 2 coming back <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = 820b2e98
TransferFlags = 820b2e9b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000020
TransferBuffer = 81e17448
TransferBufferMDL = 821244e8
00000000: 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 fe 03
00000010: 01 05 07 05 01 02 40 00 00 07 05 82 02 40 00 00
UrbLink = 00000000
SetupPacket =
00000000: 80 06 00 02 00 00 00 04
[179 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[179 ms] UsbSnoop - MyDispatchInternalIOCTL(f88b1e80) : fdo=820a4a60, Irp=82326e28, IRQL=0
[179 ms] >>> URB 3 going down >>>
-- URB_FUNCTION_SELECT_CONFIGURATION:
ConfigurationDescriptor = 0x81e17448 (configure)
ConfigurationDescriptor : bLength = 9
ConfigurationDescriptor : bDescriptorType = 0x00000002
ConfigurationDescriptor : wTotalLength = 0x00000020
ConfigurationDescriptor : bNumInterfaces = 0x00000001
ConfigurationDescriptor : bConfigurationValue = 0x00000001
ConfigurationDescriptor : iConfiguration = 0x00000004
ConfigurationDescriptor : bmAttributes = 0x000000c0
ConfigurationDescriptor : MaxPower = 0x00000001
ConfigurationHandle = 0x00000000
Interface[0]: Length = 56
Interface[0]: InterfaceNumber = 0
Interface[0]: AlternateSetting = 0
[212 ms] UsbSnoop - MyInternalIOCTLCompletion(f88b1db0) : fido=00000000, Irp=82326e28, Context=821e1b28, IRQL=0
[212 ms] <<< URB 3 coming back <<<
-- URB_FUNCTION_SELECT_CONFIGURATION:
ConfigurationDescriptor = 0x81e17448 (configure)
ConfigurationDescriptor : bLength = 9
ConfigurationDescriptor : bDescriptorType = 0x00000002
ConfigurationDescriptor : wTotalLength = 0x00000020
ConfigurationDescriptor : bNumInterfaces = 0x00000001
ConfigurationDescriptor : bConfigurationValue = 0x00000001
ConfigurationDescriptor : iConfiguration = 0x00000004
ConfigurationDescriptor : bmAttributes = 0x000000c0
ConfigurationDescriptor : MaxPower = 0x00000001
ConfigurationHandle = 0x822390c8
Interface[0]: Length = 56
Interface[0]: InterfaceNumber = 0
Interface[0]: AlternateSetting = 0
Interface[0]: Class = 0x000000fe
Interface[0]: SubClass = 0x00000003
Interface[0]: Protocol = 0x00000001
Interface[0]: InterfaceHandle = 0x820f4438
Interface[0]: NumberOfPipes = 2
Interface[0]: Pipes[0] : MaximumPacketSize = 0x00000040
Interface[0]: Pipes[0] : EndpointAddress = 0x00000001
Interface[0]: Pipes[0] : Interval = 0x00000000
Interface[0]: Pipes[0] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[0]: Pipes[0] : PipeHandle = 0x820f4454
Interface[0]: Pipes[0] : MaxTransferSize = 0x00001000
Interface[0]: Pipes[0] : PipeFlags = 0x00000000
Interface[0]: Pipes[1] : MaximumPacketSize = 0x00000040
Interface[0]: Pipes[1] : EndpointAddress = 0x00000082
Interface[0]: Pipes[1] : Interval = 0x00000000
Interface[0]: Pipes[1] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[0]: Pipes[1] : PipeHandle = 0x820f4474
Interface[0]: Pipes[1] : MaxTransferSize = 0x00001000
Interface[0]: Pipes[1] : PipeFlags = 0x00000000
[212 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
[212 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
[213 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
[213 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
[213 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
[213 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
[213 ms] UsbSnoop - DispatchAny(f88b0610) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[213 ms] UsbSnoop - MyDispatchPNP(f88b2ee0) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)

[Bericht gewijzigd door K-Ray op woensdag 27 juni 2007 22:36:44

Die SniffUSB heb ik gevonden, ik ken ook maar globaal wat van USB maar misschien genoeg om het wat te analyseren. In ieder geval is hier mijn verhaal op basis van de software, ik hoop met de scope wat meer info te krijgen:

Rigolusb.sys
De device driver voor windows. Gemaakt met DriverWorks van Compuware, denk een oude versie ofzo (1998) want volgens mij is het tegenwoordig van NuMega. DriverWorks is een toolset/API om snel drivers te ontwikkelen, er is weinig gratis documentatie van omdat je er natuurlijk voor moet betalen.

Rigolusb1000_UI.dll (system32)
Een user mode interface DLL om het eenvoudiger te maken de driver aan te spreken, ook hier is een deel van de code door DriverWorks voorzien.

Ultrascope.exe
De software zelf, geschreven in visual basic 6. Deze gebruikt Rigolusb1000.dll als interface naar de scope toe, de driver wordt voor zover ik weet niet anders benaderd.

---

De device driver zelf kan ik weinig over zeggen omdat ik gewoon weinig weet van de exacte werking van drivers. Ook heb ik het apparaat nog niet en kan ik geen USB packet logs bekijken, dat zou wel een hoop schelen.

De interface DLL is duidelijker, hier zitten de volgende (stdcall) functies in:

GetDeviceNum
ReadUSB
WriteUSB
Class_Request_Read
Class_Request_Write
Vendor_Request_Read
Vendor_Request_Write

De functies doen niet heel veel, ze roepen uiteindelijk allemaal ReadFile, WriteFile of DeviceIOControl aan op de driver, dat zijn ook zo'n beetje de drie standaard manieren om een driver te sturen.

int GetDeviceNum();
Heeft geen parameters en geeft simpelweg het aantal scope devices terug dat aangesloten is. In de meeste gevallen geeft dit dus gewoon 0 of 1 aan, tenzij je het geluk hebt meerdere scopes te hebben . De scopes worden ook geidentificeerd met een nummer van 0 t/m aantal-1 in de andere functies, dus als je een scope hebt is dat scope nummer 0, en geeft GetDeviceNum 1 terug.

Class_Request_*, Vendor_Request_*
Hier heb ik nog geen details van uit gezocht maar het lijkt erop dat dit iets met USB class en vendor control packets doet.

Als je bij ultrascope connect wordt er eerst GetDeviceNum aangeroepen om te kijken of er scopes aangesloten zijn. Zoja dan wordt een Vendor_Request_Read gedaan. Wat deze precies doet weet ik niet omdat ik dat niet kan testen zonder scope, maar Ultrascope lijkt niet bijzonder geinteresseerd in het resultaat. Misschien een soort reset ofzo. Vervolgens wordt een WriteUSB aangeroepen:

bool WriteUSB(int device, int func, int sequence, int length, char *pData);
device = scope index (0,1,2 etc.)
func = functie code, functie 1 lijkt hierbij een SCPI command te zijn, ander nummers zijn nog onbekend.
sequence = lijkt een sequence nummer, wordt bij opvolgende commando's opgehoogd.
length = lengte van de data waar pData naar wijst
pData = data pointer naar SCPI command. Eerste commando is ":KEY:LOCK ENABLE"

De WriteUSB functie roept twee keer WriteFile aan naar de driver toe. De eerste keer is een vaste serie van 12 bytes. Deze serie verschilt per functie, maar is voor functie 1 als volgt:

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  1       0       0       0

De 12 bytes zijn dus het functie nummer, gevolgd door het sequence nummer en de one's complement van het sequence nummer. Dan vast een 0 byte, de lengte van de data in 4 bytes (little endian) en tot slot de byte serie '1,0,0,0'. De laatste drie 0's lijken overigens niet hard op 0 gezet te zijn dus het zouden ook don't care's kunnen zijn maar 0 is in ieder geval goed.

Deze 12 bytes worden via WriteFile naar de driver gestuurd. Vervolgens wordt direct daarna het commando (pData) als raw data met WriteFile weggeschreven, gewoon 'length' bytes, geen 0 terminator erachter.

Eigen software zou gebruik kunnen maken van de WriteUSB functie zodat bovenstaande verder niet gebruikt hoeft te worden maar het is wel handig te weten wat er mee gebeurd. Ook weet ik nog niet hoe dit vertaald wordt naar USB requests, maar ik vermoed dat het er erg op lijkt.

ReadUSB
Nog onbekend, later meer als de scope eris.

Kunnen we geen aanvraag doen bij Rigol om oa SPi, i2c protocollen te kunnen onderzoeken via de software?

[Bericht gewijzigd door The Puma op woensdag 27 juni 2007 23:15:45

Het is sowieso wel handig eigen software er voor te kunnen schrijven, als je dan toevallig iets specifiek nodig hebt kun je dat gewoon zelf.

K-Ray: zou je ook nog eens een stukje dump van wat later in de logfile kunnen maken, bijvoorbeeld wanneer je een commando uitvoert? Nu zie je alleen de setup die door windows/driver gedaan wordt en dat is niet zo erg belangrijk.

@madwizard, zou je de DLL van Agilent ook eens willen bekijken?

Ik weet niet of de applicatie van Agilent ook I2C en SPI analyse biedt (zo niet, dan hoeven we ook niets meer met die Agilent software te proberen), maar anders is het misschien interessant om te kijken of die Agilent software met de Rigol driver aan de slag kan. Misschien is het slechts een kwestie van de GID van de driver-interface gelijk te maken, als die meuk toch allemaal door Rigol is gemaakt dan heb je goed kans dat dat werkt.

Ik kan er wel even naar kijken, wordt wel maandag op z'n vroegst want tot dan kan ik niet bij m'n eigen PC.

hoe bekijk je zo'n dll ?

Met een hele set tools. Voor een snel overzicht van de gebruikte DLLs en hun functienamen heb je dependency walker. Maar veel meer kan je daar niet uithalen. Je kan de DLLs disassemblen met W32Disassembler en IDA, en natuurlijk de programma's gewoon draaien en debuggen met OllyDbg of een andere debugger.

is "libusb" ook onder windows beschikbaar?

Ik zou als eerste even een tooltje maken dat connect met de scope, en dan de hier "writeUSB" genoemde functie namaken. Ik vind de naam zo slecht dat ik hem zou hernoemen. "writerigol" of zo.

Dan doet het tooltje dus iets van:

  int seq;
  char buf[1024];

  while (1) {
     gets (buf);  // Let op als je fgets gaat 
                  // gebruiken moet de newline 
                  // er nog af. Of is dat bij gets ook al?
     len = strlen (buf);
     writerigol (0, seq++, len, buf); 
     // Kunnen we de replies terug lezen???
  }

De lol is dan dat je makkelijk, zeker als je een read/dump reply hebt, met de hand dingen kunt proberen!

Onder Linux kan je dan eventueel in een GUI achtige app zelfs een pipe naar dit programma openen, en dit simpele programma de basis communicatie laten verzorgen, terwijl de GUI z'n handen vrij heeft om GUI te zijn. Kan dat tegenwoorig ook onder Windows?

Een commandline tool dat argumenten heeft om samplespeed, range, etc etc in te stellen, en dan een capture kan doen, is dan ook handig. Kan je de boel mee automatiseren.

De Rigol heeft toch een diepe buffer? Ik dacht dat ie orde grootte een Mb was. Ik zie iedere keer een wimpy 2k of minder puntjes langs komen.

Op 29 juni 2007 11:50:37 schreef rew:
is "libusb" ook onder windows beschikbaar?

Dat wel maar free_electron is hier eens mee bezig geweest en toen bleek de library niet eens buffer overflows te checken op kernel niveau waardoor een user level programma BSOD's kan genereren. Dus die library laat ik mooi links liggen. Waarschijnlijk kan je ook totaal je hele systeembeveiliging omzeilen zodra je die library installeert, ik vertrouw het echt niks.

In windows kun je beter gewoon de driver van Rigol gebruiken, dat is de windows manier om zoiets te doen. Makkelijker is waarschijnlijk de DLL te gebruiken, dat scheelt nog wat extra verwerking. Als je direct de driver wilt aanspreken is het een kwestie van 4 standaard functies uit Windows aanroepen, dan heb je alleen verder de driver (.sys) nodig en gaat alles helemaal volgens de windows standaard. Maar omdat de driver toch alleen in het Ultrascope pakket zit kan je net zo goed de DLL gebruiken, dat is makkelijker.

Ik zou als eerste even een tooltje maken dat connect met de scope, en dan de hier "writeUSB" genoemde functie namaken. Ik vind de naam zo slecht dat ik hem zou hernoemen. "writerigol" of zo.

De naam is niet per se slecht, het schrijft waarschijnlijk gewoon naar een USB endpoint. Zomaar die data schrijven werkt misschien ook niet, kan goed zijn dat er eerst initialisatie nodig is.

Maar zoiets ben ik wel van plan, ik wil alleen eerst wat meer data onderzoeken als ik de scope heb voordat ik er zelf mee ga klooien. Ik weet ook niet of er nog gevaarlijke commando's zijn zoals een firmware update ofzo die je niet per ongeluk moet uitvoeren.

Voor linux heb je natuurlijk niets aan die DLLs en zal je op USB niveau moeten werken. Daar ga ik sowieso nog even naar kijken ook om beter inzicht te krijgen in hoe de DLL functies zich vertalen in USB pakketten. Maar met linux ga ik verder niets doen, ik heb daar totaal geen programmeerervaring mee en ook geen behoefte daaraan. Dus dat laat ik aan iemand anders over, ik kan natuurlijk wel helpen met het achterhalen van het protocol.

Onder Linux kan je dan eventueel in een GUI achtige app zelfs een pipe naar dit programma openen, en dit simpele programma de basis communicatie laten verzorgen, terwijl de GUI z'n handen vrij heeft om GUI te zijn. Kan dat tegenwoorig ook onder Windows?

Tuurlijk kan dat, je kunt een service maken en een losse GUI met pipes ertussen of een andere IPC methode. Maar je kunt net zo goed gewoon de GUI en aansturing combineren, de tijd dat je maar 1 thread hebt is al lang verlaten. Enige voordeel is dat je andere software ook gebruik kan laten maken van een gemeenschappelijke applicatie, maar dan kan je ook een library maken.

Een commandline tool dat argumenten heeft om samplespeed, range, etc etc in te stellen, en dan een capture kan doen, is dan ook handig. Kan je de boel mee automatiseren.

Ook makkelijk ja.

De Rigol heeft toch een diepe buffer? Ik dacht dat ie orde grootte een Mb was. Ik zie iedere keer een wimpy 2k of minder puntjes langs komen.

Ja dat leek me ook wat vreemd, omdat die RS232 baudrate ook zo laag is zou de hele buffer echt heel lang duren, misschien dat ze daarom maar delen van de buffer sturen. Maar het zou wel handig zijn de hele buffer te hebben.

Ik volg dit topic niet actief, maar wat is precies de bedoeling met de USB communicatie?
Kan eventueel wel wat reverse engineren, daarvoor heb ik wel de scoop
zelf nodig (nog een weekje geduld! )....

Het idee is de details van het protocol te achterhalen om eigen software te schrijven waarmee je niet meer vast zit aan de beperkingen van ultrascope.

Willie, het idee is om software te schrijven zodat de scope ook onder Linux aan te sturen is... Ik heb geen windows. Wil dat eigenlijk ook zo houden.

1 van de dingen die hier ter sprake is gekomen is om de Logic Analyser data te proberen te pakken te krijgen, en dan daar een I2C, one-wire en SPI decoders voor te schrijven, zodat je makkelijk je (digitale) bus signaaltjes kan debuggen.

madwizard, die naam is wel slecht gekozen: Hij doet niet alleen een write naar USB, maar formatteerd de data ook nog eens zoals de rigol dat kennelijk wil hebben. Dus ik vind dat ie beter "writeRigolScope" kan heten of iets dergelijks. "libusb" heeft een usb_bulk_write functie. Die doet niks aan datamassage, en stuurt gewoon de data die je hem geeft.

Ok, dus:

-Screendumps overbrengen (handig voor de linux versie)
-Logic Analyzer uitlezen

Voor wat de linux zijde betreft, ik weet niet of het handig is
om de screendumps te integreren met sane(scanner) of gphoto (digitale camera) functionaliteit. Op die manier ben je niet aan een specifiek
programma gebonden, maar kun je je eigen favo scanner/foto programma
gebruiken.

Als ik de scoop volgende week binnen heb zal ik proberen de data
te tracen. USB qua linux-software zijde is nog nieuw voor me, dus
ik zal in lib-usb e.d. moeten duiken. Voor de windows zijde kan
ik denk ik het beste de standaard drivers gebruiken en direct met
de scoop gaan communiceren.
USB communicatie onder Windoze heb ik al eerder gedaan.

Ik ben bezig om van een aantal standaard metingen alle mogelijke data te verzamelen om zo het een en ander te achterhalen. Ik heb er echter zeer weinig tijd voor.
Hulp is dus welkom!
Ik heb een eerste reeks data gebundeld en een artikeltje bij geschreven op mijn site. Meer volgt nog vanavond of morgen.
Voor degene die niet kunnen wachten tot het artikel af is:
http://k-ray.vranken.org/

Bij de connect ziet de verzonden data er in ieder geval hetzelfde uit als wat de DLL naar de driver stuurt. Ik denk dat de driver weinig meer doet dan de data gewoon doorsturen op de USB kanalen.

edit:
Ik zie in de logs ook writes met functie code 2, ik had het formaat daarvan ook al uit de DLL gehaald en die klopt precies met de USB data. Het formaat is weer 12 bytes maar eigenlijk is alleen het sequence nummer steeds anders:

02 S1 S2 00
40 00 00 00
01 0A 00 00

Deze functie lijkt een request voor data van de scope af, want elke keer na zo'n request wordt direct een pakket terug gestuurd met ongeveer hetzelfde formaat. De 2e groep van 4 bytes is meestal een lengte, hier lijkt het vast 0x40 te zijn ook al wordt er geen data van PC->scope gestuurd, misschien is dit een maximum voor de terug te sturen data. Na het request stuurt de scope een soortgelijke serie bytes terug, de functie en sequence zijn exact hetzelfde. De lengte is echter de lengte van de terug gestuurde data, die direct achter de 12 bytes mee komt. De 0A is ook vervangen door 00. De data is meestal een losse waarde of stukjes tekst, zoals 'DC' (AC/DC?) of '799', alles in tekstvorm. Waarschijnlijk zijn dit settings van de scope.

edit 2:
Tot nu toe (heb niet alles bekeken) heb ik alleen functie 1 en 2 pakketten gezien, met daar tussendoor een vendor setup request die steeds dezelfde vier bytes terug geeft. Het zou goed kunnen dat dit request een soort trigger is om de verzonden commando's uit te voeren, dus dat er eerst een serie commando's gegeven wordt en vervolgens een pakket om ze daadwerkelijk uit te voeren. Dat kan wel getest worden door het pakket weg te laten en later uit te voeren.

[Bericht gewijzigd door madwizard op zaterdag 30 juni 2007 16:33:36

Ik heb even snel een php scriptje gemaakt dat de log files van USBsnoop een beetje verwerkt en er een html file van maakt met kleurtjes en commentaar. Niet alle gegevens worden meegenomen dus het is geen volledig geheel maar laat wel duidelijk het patroon zien. Hier is een zipje met de logs van K-Ray als html en het php scriptje ook (geen mooi script, gewoon iets snels).
rigol_html.zip

Bij functie 2 is de 0x40 inderdaad een maximum lengte. In de DLL had ik al gezien dat er iets gesplitst werd in blokken van 4096 (0x1000) bytes. Dat wordt namelijk als buffer grootte gebruikt. Functie 2 lijkt zo te werken:
- standaard functie 2 request met een length van 0x40
- scope stuurt een functie 2 reply terug inclusief data direct erachteraan, maar knipt af op 0x40 bytes. De volledige lengte staat wel in de header.
- De PC leest de lengte uit het pakket en doet extra USB requests (zonder data te sturen deze keer) in groepen van 4096 bytes (of minder) totdat alle data ontvangen is.

Bestaan er usb terminal programma's of zo zodat ik commando's kan testen?
Of zijn er andere methodes om over usb te 'spreken' zonder een eigen programma te moeten schrijven.
Of een vrijwilliger die een interface wil schrijven om de rigol-driver aan te spreken zodat we kunnen experimenteren.

Een terminal zou niet volstaan voor USB, het is een veel ingewikkelder protocol dan RS232.

Je zou de DLL functies kunnen gebruiken, die kun je met elke behoorlijke programmeertaal wel aanroepen. Maar ik weet alleen de parameters van de GetNumDevices en WriteUSB functies. De andere kan ik pas zien als ik de scope heb.

Als ik de USB logs zie is het misschien nog wel net zo makkelijk direct de driver aan te spreken omdat de data die naar de driver gaat redelijk overeenkomt met de USB data. De DLL doet geen hele ingewikkelde dingen, je bent dan af van de afhankelijkheid van de DLL en de linux mensen hebben er meer aan omdat die geen driver hebben.

die rigol babbelt gewoon SCPI. dus open de usb port in serial mode ( als een seriele poort ) en stuur daar SCPI naar toe en tis opgelost. je hebt helemaal geen gerommel nodig met drivers.
SCPI is stomme ascii text. je kan het zelfs met hyperterminal desnoods.

als je dit stuurt: *IDN?
moet de scoop antwoorden met fabrikant model en serienummer.

opgelet SCPI is CR only ! geen linefeeds sturen !
probeer stomweg deze ook eens :

ISP:TEXT 'Hello World'

2 mogelijkheden : het komt op het scherm te staan of de scoop biept ( foutmelding )

in de manual staan normaal gezien alle commanods. je kan ook traces oversturen. kies daar voor de snelheid de binary mode.

Op 2 juli 2007 13:53:16 schreef free_electron:
die rigol babbelt gewoon SCPI. dus open de usb port in serial mode ( als een seriele poort )

En hoe doe je dat? De USB verbinding laat zich niet als seriele poort zien hoor. Of is daar een instelling voor op de scope?

als je dit stuurt: *IDN?
moet de scoop antwoorden met fabrikant model en serienummer.

Dat klopt, dat gaat ook over USB. Maar niet 'a la seriele poort'.

opgelet SCPI is CR only ! geen linefeeds sturen !
probeer stomweg deze ook eens :

Sterker nog over de USB lijn gaat ook geen CR of LF. Er gaat eerst een header pakket over de lijn met de lengte van het commando. Dit is te zien in de dumps.

Zou mooi zijn als SCPI gebruikt kan worden, nog een paar daagjes en de
scoop is er, dan zal ik het uitproberen.

SCPI wordt absoluut gebruikt, de vraag is alleen nog hoe je dit over de USB lijn krijgt. Via de seriele verbinding kan het waarschijnlijk direct maar serieel is ouderwets

Het "hoe over de USB lijn" vind ik niet zo zorgwekkend, heb alleen
fysiek het apparaat nodig, anders is het niet te doen.

Op 2 juli 2007 17:39:41 schreef williewortel:
Het "hoe over de USB lijn" vind ik niet zo zorgwekkend, heb alleen
fysiek het apparaat nodig, anders is het niet te doen.

nog ff