Zou dit kunnen helpen ??
De volledige programmeergids voor de rigol, versie april 2008.....
http://www.rigolna.com/download_programming.aspx
[Bericht gewijzigd door peter273 op zondag 20 december 2009 17:22:04 (60%)
Zou dit kunnen helpen ??
De volledige programmeergids voor de rigol, versie april 2008.....
http://www.rigolna.com/download_programming.aspx
[Bericht gewijzigd door peter273 op zondag 20 december 2009 17:22:04 (60%)
Mooi documentje iig, ik kende hem nog niet..
@ REW
Zou het mogelijk zijn om wat meer info te geven over de door u gegeven files, ivm het gebruik ervan. Graag zou ook ik mn RIGOL via linux willen gebruiken. Maar weet van geen kanten hoe ik uw files kan gebruiken.
--EDIT
Het werkt wel... moet er nog altijd aan wennen... die dingen die niet standaard geinstaleerd staan .
Waneer ik :HARDcopy? uitvoer dan verkrijg ik het volgende :
Writing header len=6
-110 bytes read. Resplen=-1943711080
Segmentatiefout
Wat loopt er fout ?
[Bericht gewijzigd door BLUE Config op maandag 7 juli 2008 18:57:53 (40%)
Overleden
Op 17 februari 2008 11:52:45 schreef The Puma:
Is niemand meer bezig om de data in te lezen (protocol analyzer voor SPI/IC2 data)
Op 18 april 2008 20:51:52 schreef shiptronic:
iemand al iets werkend ? protocol
Iemand al iets verder met de protocollen
Het (eerste) grote probleem lijkt te zijn dat de digitale data niet raw valt in te lezen.
Eindelijk es geslaagd effe tijd te maken.
De LA data valt perfect in te lezen:
Commando is : WAV : DATA? DIGITAL
(opletten, spaties rond ":" enkel om smileys te vermijden)
Respons is dan 4 bytes header + 2048 byte data
Header is 4 byte, vormt gezamelijk "0800" (hex 0800 ofte 2048 decimaal, dus zoals altijd de lengte van het eropvolgende datablok.
Data zelf is 600 bytes gecentreerd rond byte 512.
De data is domweg binaire data georganiseerd als 16bit (2 byte) voor de 16 kanalen tesamen, en elke 2 bytes inhoudelijk voor hetzelfde sampling point in tijd.
Dus:
- byte 1 en 2 is eerste sample voor 16 kanalen
- byte 3 en 4 is tweede sample voor 16 kanalen
... enzovoorts
Bit0 is LA0, Bit15 is LA15.
greetz
Klinkt hoopgevend
Zeker weten....
Met RS232 en vanuit domweg excel heb ik al leuke grafiekjes van elk type data gecreeerd, volledig geautomatiseerd, nu op een weekje tijd voor een huidig project waarvoor enig serieus documentatiewerk nodig is.
Enige wat me (nog) niet lukt is het gehele "long-mode" geheugen tegelijk uit te lezen, de enige optie is (al dan niet automatisch) onscreen expanden en scrollen, dan opvragen.
Probleem is wel dat in stopped mode de scope (DS1062CD, firmware 03.07.01) niet meer reageert op ": RUN" of ": KEY : LOCK DISABLE" eens data werd opgevraagd, alle andere commando's daarentegen blijven deels wel werken.
Wat me nog ontbreekt is een commando om de settings van math en fft expliciet op te vragen (bv ": MATH : SCALE?" en ": FFT : SCALE?" of zoiets). Heb al alles geprobeerd maar geen gevonden.
Het frequentiebereik (H-as) in data van fft is een makkie: 25*(1/timebase) voor de snelste fft timebase-setting, geeft als eerste 4byte header + 5000 punten relevante data (alles na 5000 is rommel). V-as is niet op te vragen. (tragere fft-timebases geven minder data terug, nl 2500, 1000 en 500 byte)
Math geeft 4byte header + 2048 bytes terug waarvan de eerste 600 bytes relevant zijn (alles erna is rommel). Ook de V-as voor math is niet op te vragen.
Omrekening naar exacte amplitudes (behalve LA) is domweg
(125 - databyte) * scale/25
greetz
Het mooiste zou ik iets van een protocol-analyser vinden voor I2C enzo, maar heb er zelf de tijd niet voor..
Op 5 december 2009 15:25:41 schreef peter273:
(opletten, spaties rond ":" enkel om smileys te vermijden)
Gebruik [code][/code] tags.. of mijn smerige manier om de parsing voor de gek te houden (quote mij maar eens en zie hoe ik [code] schrijf zonder dat het een tag wordt...)
:) of smilies.
Peter, ik heb ook geen andere manier gevonden om al het geheugen uit te lezen, anders dan steeds te scrollen. Ik zat deze thread nog wat door te bladeren, en vond een post van die richting van een zekere REW...