Rigol DS1052E zeer trage refresh

Ik ben sinds zaterdag de gelukkig eigenaar van een nieuwe DS1052E met firmware 02.04. Leuke scope, absoluut, maar ik ben nu tegen een vervelende onhebbelijkheid aangelopen. Ik zou graag jullie bevindingen horen, wellicht doe ik het zelf gewoon verkeerd.

Het is zo dat de scope op de 20ms/div een belachelijk slechte update rate van het scherm heeft. Duurt een dikke twee seconden per scherm update. Terwijl hij er bij 10ms/div en 50ms/div totaal geen last van heeft.

Als proef op de som een 50Hz sinus aangeboden op de scope, en op "auto" gedrukt. Scope komt automatisch met 20ms/div met een hopeloze refresh, bij een 100Hz sinus komt ie op 10ms/div met een uitstekende refresh.

Is dit een bug? Wat zijn jullie ideeën?

[edit]
Uiteraard verschillende triggermogelijkheden uitgeprobeerd. Maar ook met geen signaal zie je dat ie er erg lang voor nodig heeft op de 20ms stand.

Meer dan 2 seconden? Ja, als hij op 200ms/div ingesteld staat, maar toch niet bij 20ms/div?

Prosper, yop la boum, c'est le roi du macadam (aldus Maurice Chevalier)

Laat ik het zo zeggen, dat je scoop zijn scherm continue ziet updaten bij elke andere instelling. Echter bij de 20ms/div instelling zie je dat het scherm een tijdje stilstaat...

Bij 200ms (en andere) zie je de update netjes van links naar rechts verschijnen met de juiste snelheid. Als ie rechts is aangekomen gaat ie links weer direct verder. Bij de 20ms/div stand wordt het scherm ge-update. Alles staat stil.... en dan weer een update. Vreemd....

Ik zie inderdaad ook geen snelle refresh. Bij mij springt hij met auto trouwens op 10ms/div. Dan doet hij ongeveer 10 runs in 7 seconden. Met 20ms/div is dat c.a 15 seconden.
Waarschijnlijk komt dit doordat de scoop meer sampled dan in beeld komt te staan. Het "sample window balkje" boven in beeld laat zien dat een veelvoud van het window aanwezig is. Het window zelf duurt al 200ms. Als ik helemaal heen en weer scroll geeft de cursos van -320ms tot + 320ms aan. Dat is dus 640ms. Waarbij 1.5s/run dus nog steeds aan de hoge kant is.
Verander ik de sampling mode van "Real Time" naar "Equ-Time" dan zitten we weer op ongeveer 0.7s/run. Ook weer voor 640ms aan samples. Die overhead valt me dan nog weer mee. Eigenlijk had ik dat van die sample modes net andersom verwacht.

Dag jojo,

Dank voor je reactie. Idd, ik zie hetzelfde. 10 runs op 20ms/div zou wel eens 15 seconden kunnen zijn. Kun je die overlap niet de nek om draaien op de een of andere manier?

Volgens mij is 20ms/div ook de "laatste" stand waar je op kunt triggeren. Daarboven werkt het triggermenu niet meer. Wat verklaart dat het op op 50ms/div wel naar behoren werkt, en op 10ms/div is de scoop gewoonweg sneller bezig.

Ik kan me niet herinneren dat ie op Equ-time sneller is dan bij Real-time. Vanavond eens even kijken. Ben nu op mijn werk namelijk. Kun je die overlap van 640ms niet de nek omdraaien op de een of andere manier?

Met snelle timebase is een beetje overhead niet zo erg.

In trage time base (>50ms/div)zegt de manual:

Slow Scan Mode: This mode is available when the horizontal time base is set to 50ms/div or slower. In this mode, the oscilloscope acquires sufficient data for the left part to the trigger point, then wait for trigger, when trigger occurs, it continues to draw the rest part from the trigger point to the end of the right side. When choosing this mode to view low frequency signals, it is recommended that the channel coupling be set as DC.

Dat is waarschijnlijk de mode waarin je afwisselend "waiting for trigger" en "run" ziet.

En net in het grensgebied (10ms/div en 20ms/div) komen we blijkbaar in een gebied waar we zelf zouden willen kunnen kiezen tussen extra samples en just-fit-on-screen. Ik heb nog geen menu gezien waarin je de samples buiten het scherm kunt reduceren.

Inderdaad. Dat had ik ook gelezen ja, alhoewel ik die functie nog niet "in-het-echt" gezien heb. Vanavond eens even proberen. Wellicht een mooie update om die slowscan functie al eerder beschikbaar te hebben dan 50ms/div.

Ik meen toch gezien te hebben dat trigger is uitgeschakeld in de langzame standen. Maar waarschijnlijk komt die dus weer terug in slowscan mode.

[offtopic]
Gisteren even zitten meten aan een SMPS, en de rimpel stond wel ernstig mooi in beeld. Niks mis mee :).

Zo, gisteren even e.e.a. geprobeerd. En idd is de grootte van het "golfje bovenin" nogal van belang. Ik zag dat ik op 20ms/div naar + en -890ms kan gaan. Dat is 1,78 seconden. Wat dan weer precies klopt met de sampletijd die hij er voor nodig heeft. Ik zou graag een functie vinden in het apparaat om die tijd korter te maken :). Dat kan door de equ-time aan te zetten, en de long-mem, maar dan nog is ie behoorlijk lang. Dat is natuurlijk bij singleshot acties wel weer zalig.

Afijn, ik ben er even uit :).