Mooi. Ik weet niet of iemand dit al gedaan had maar ik heb ook het formaat van de screendumps. Ultrascope doet eerst een ":HARDCOPY" en vervolgens een ":LCD: DATA?" om een screemdump te maken. Wat de hardcopy precies doet weet ik niet, alleen het LCD data commando lijkt ook te werken maar misschien dat deze dan niet refresht.
De teruggeven data is 74880 bytes, oftewel 1 byte per pixel (320x234). Elke byte heeft RGB data in zich, met 2 bits voor rood en 3 voor blauw en groen:
bit 76 543 210
kleur RR GGG BBB
Dit is bijvoorbeeld met zo'n php scriptje uit te lezen:
<?
$file = fopen("screen_dump", "rb");
$data = fread($file, filesize("screen_dump"));
$img = imagecreatetruecolor(320, 234);
$k = 0;
for ($y=0;$y<234;$y++)
{
for ($x=0;$x<320;$x++)
{
$p = ord($data{$k++});
$r = ($p >> 6) & 0x3;
$g = ($p >> 3) & 0x7;
$b = ($p >> 0) & 0x7;
$r <<= 6;
$g <<= 5;
$b <<= 5;
$c = ($r << 16) | ($g << 8) | $b;
imagesetpixel($img, $x, $y, $c);
}
}
header("Content-Type: image/png");
imagepng($img);
?>
Dit geeft dan zo'n resultaat:
Screendump had ik al getest, zit in het testprogje van mij. De methode
had ik aan rew doorgegeven.
Gebruik jij de bijgeleverde DLL?
[Bericht gewijzigd door williewortel op (15%)]
Op 14 juli 2007 18:11:38 schreef williewortel:
Screendump had ik al getest, zit in het testprogje van mij. De methode had ik aan rew doorgegeven.
Ik wist het commando ook wel, alleen het exacte formaat had ik nog niet gezien hier geloof ik.
Gebruik jij de bijgeleverde DLL?
Ja, dat was even het makkelijkst om te testen. Maar met de setup API en DeviceIoControl/Read/Writefile kan het ook prima.
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
WW, ik had gezien dat je de commandos in mijn wiki had gezet. Ik had ze nog niet begrepen: Ik kreeg het niet zomaar aan de praat. Mogelijk iets met niet eerst "HARDCOPY" doen, voor LCD:DATA?, dat ie het dan voorlopig niet meer doet of zo.
De usb stick (Flash voyager) wordt niet herkend
Is een usb 2.0 ding (geformateerd FAT32 en FAT)
beide doen het niet
Als ik hem aansluit aan de voorkant zegt de rigol wel een usb connected.... maar voor de rest niets
'external' storage wordt niet vrijgegeven.
Welke usb sticks hebben jullie aan de gang gekregen?
Is toch een probleem dat het apparaat niet goed werkt met usb sticks
Wat is hier aan de hand?
[Bericht gewijzigd door The Puma op (18%)]
Dat kan beter in het ervaringen-topic denk ik, maar bij mij werkt een 256MB stickje ook niet terwijl een CF-reader er weer wel in werkt. M'n printer erop trouwens ook niet maar ik weet niet precies wat de eisen daarvoor zijn.
[Bericht gewijzigd door madwizard op (25%)]
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
Op 14 juli 2007 11:26:44 schreef rew:
Agilent heeft kennelijk aan Rigol gevraagd of ze de firmware op bepaalde punten konden aanpassen. Ik gok dat dit is omdat Agilent dan minder aan HUN windows software hoeft aan te passen om de boel aan de praat te krijgen.
het verhaal wat ik gehoord heb (rechtstreeks van een ontwerper van Agilent scoops ):
is dat Rigol ene reeks scoops gemaakt heeft. ( rigol is ene OEM fabrikant geval. zij maken x aantal varianten van een platform en gaan dan zien wie er geinteresseerd is.
Agilent was op zoek naar ene low cost machiene.
Agilent heeft hun keuze gemaakt en geholpen met de firmware ( de firmware en menu systemen komen in grote trekken overeen met de 546xx reeks van agilent . dat ding was ook een 2 + 16 kanaal machiene. ik heb er op het werk zo ene staan naast mij)
de agilent firmware heeft wel een aantal zaken die de 'andere' rigol machienes NIET hebben ( speciaaltjes die gepatenteerd zijn ) maar das allemaal software / fpga code
De andere modellen die niet door agilent geslecteerd zijn om onder hun naam te verkopen, verkoopt rigol nu onder hun eigen merk of onder nog andere merken ( ik heb al iwatsu en wittig gezien )
- einde van het verhaal uit betrouwbare bron -
De rigol is trouwens gebaseerd op een Blackfin processor van analog devices. en altera levert de fpga die het snelle werk moet doen.
heel waarschijnlijk zijn de moederborden in al die scoops identiek. alleen de firmware is anders. de sampler kaart is ook specifiek per machiene.
voor mensen met usb memory stick problemen:
smijt stomweg op die usb stick eens een dom .TXT bestand en ene lege directory. ( houd je aan de 8.3 naamgeving , gebruik geen long filenames. )
tis maar een gedacht ... ik heb ooit zo eens iets gezien onder win2000 met een memorystick die niet gemount kon worden. op een andere computer er een paar files op gezet en het werkte plots wel ...
Op 14 juli 2007 20:41:58 schreef free_electron: De rigol is trouwens gebaseerd op een Blackfin processor van analog devices. en altera levert de fpga die het snelle werk moet doen.
Klopt.
De blackfin is de ADSP-BF531SBSTZ400.
De FPGA's zijn Altera Cylcones EP1C6Q240C8N en EP2C5Q208C8 (LA).
heel waarschijnlijk zijn de moederborden in al die scoops identiek. alleen de firmware is anders. de sampler kaart is ook specifiek per machiene.
Dat denk ik persoonlijk niet. Externe aansluitingen zitten namelijk niet op de zelfde plaats en ze zitten wel rechtstreeks onboard, dus daarom ook ander board.
Er is ook geen aparte samplerkaart in de Rigols. Alles zit op 1 bordje, behalve bediening, voeding en LA.
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Op 14 juli 2007 22:14:42 schreef K-Ray:
FPGA die het snelle werk moet doen.
[...]
De FPGA's zijn Altera Cylcones EP1C6Q240C8N en EP2C5Q208C8 (LA).
Ehh. dat zijn de langzaamste speedgrade die je kunt krijgen van de FPGAs.
Als de scope op 400MHz kan samplen, dan is dat nog lastig met een Cyclone 1. Zeker als je de langzaamste speedgrade neemt. Zou het datapad buiten de altera blijven? Of zou de 400->200 demux in dedicated hardware plaatsvinden?
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
GLOEIENDE......
Als je time/div op 2.5 us per divisie instelt is dan rapporteert hij terug dat ie dat gedaan heeft...
Het display bevat echter de data voor 5us per divisie. Ook met het opvragen van de data via SCPI.
Kan iemand dit reproduceren met de windows software?
Op 1ms/div een "plaatje schieten" (gebruik de aquire toets om te zien dat ie 20Ms/sec heeft gedaan), druk op "run/stop", en zoom in tot 2.5 us/div.
Mogelijk zit die optie (2.5us/div) niet in de stapjes. Kan je in ultrascope een "willekeurige waarde" invoeren? Kan ik een "analoge" aanpassing doen van de timebase? Bij de voltage scale kan ik analoog aan het knopje draaien als ik er 1x op druk, maar bij de timebase gaat ie dan in delayed timebase....
Via de toetsen krijg ik 2.5 us/div niet voor mekaar. Kan je dat in Ultrascope wel selecteren?
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Als je met :TIMEBASE:OFFSET de offset instelt, en daarna met :WAV:DATA? De data uit de buffer opvraagt, dan krijg je de oude data. 500ms wachten is genoeg om de nieuwe data te krijgen. 20ms is niet genoeg. Zucht.
[edit] 23ms is OK, 22ms is niet ok.
peter273
Electronics is more than an art, it's a way of living :-D
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 (60%)]
Jochem
If you want to succeed, double your failure rate.
BLUE Config
I (L) Techno(logy)
@ 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 (40%)]
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
Jochem
If you want to succeed, double your failure rate.
peter273
Electronics is more than an art, it's a way of living :-D
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
peter273
Electronics is more than an art, it's a way of living :-D
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
Jochem
If you want to succeed, double your failure rate.
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.
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
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... 