continuouse reading of IQ-data

[LVFan]

Im trying to use a 5600+5620 to demodulate an FM radio packet.

1. Whats the difference between finite and continuous acquisition. I tried to configure continuouse mode, initiate the acquisition and then fetch the IQ data repeatedly in a while loop. That should ensure a gapless sampling.

But after the first loop, no data is fetched anymore. (See appended VI.)

I didn't find a VI that makes use of the continous mode.

2. In difference to the example VI, the 5620 doesn't support analog edge triggering.

If I try to use this trigger mode (or any other analog trigger mode) I get a NIScope failure code:

   Driver Status:  (Hex 0xBFFA0010)
Invalid value for parameter or property.

Analog triggering is only supported in normal acquisition mode.

[Jochen]

I have just talked to our RF specialist. He can provide a complete FM demodulation demo. Unfortunately he won't be in the office until Wednesday next week but he will contact you then.

I hope this timeframe is ok for you.

Best regards,

Jochen Klier
National Instruments Germany

[Jochen]

Sorry for the delay. Here is a full demo for FM demodulation.
I hope that helps.

Jochen Klier
National Instruments Germany

[LVFan]

Danke für das Beispiel.

Leider verfüge ich nicht über das Sound&Vibration-Toolkit, aber ich habe es auch so zum Laufen bekommen.

Das man das NIScope in Softwaretriggermode setzen muss ohne den Softwaretrigger auszulösen muss man natürlich erst einmal wissen.

Ich hatte angenommen das macht der RFSA-Treiber selbst wenn man ihm den Continous-Modus abfordert.

Stellt man jedoch die Bandbreite auf höhere Werte (>400kHz) kann es trotzdem noch vorkommen das die Übertragung mit folgenden Fehler abbricht:

Fehler -1074118632 ist bei Error occurred at:  niScope Fetch Cluster.vi aufgetreten

Mögliche Gründe:Driver Status:  (Hex 0xBFFA4018)

Vermutlich

[LVFan]

Nochmal die komplette Antwort:

Danke für das Beispiel.

Leider verfüge ich nicht über das Sound&Vibration-Toolkit, aber ich habe es auch so zum Laufen bekommen.

Das man das NIScope in Softwaretriggermode setzen muss ohne den Softwaretrigger auszulösen muss man natürlich erst einmal wissen.

Ich hatte angenommen das macht der RFSA-Treiber selbst wenn man ihm den Continous-Modus abfordert.

Stellt man jedoch die Bandbreite auf höhere Werte (>400kHz) kann es trotzdem noch vorkommen das die Übertragung mit folgenden Fehler abbricht:

Fehler -1074118632 ist bei Error occurred at: niScope Fetch Cluster.vi aufgetreten

Mögliche Gründe:Driver Status: (Hex 0xBFFA4018)

Vermutlich läuft der Buffer über weil er nicht schnell genug ausgelesen wird. Kann man das abstellen?

Ich verwende einen PXI der über eine MXI4-Schnittstelle mit einem 3Ghz PC verbunden ist. Möglicherweise liefert dieses System eine andere Performance als ein PXI mit eingebautem Controller.

Unglücklicherweise muss ich gerade mit einer großen Bandbreite und damit Samplerate arbeiten weil ich ein kurzes Telegramm demodulieren will, das Daten mit 100kBit bis 1MBit überträgt. Das würde sicherlich weniger Probleme bereiten wenn der RFSA an sich auf die Powerramp triggern könnte und man nicht kontinuierlich die Daten auslesen und softwaremäßig nach dem Telegrammbegin suchen müsste. Gibt es dafür eine Lösung? Den Analog Edge Trigger vom NIScope habe ich bereits ausprobiert, der wird aber im DDC-Betrieb nicht unterstützt.

[Jochen]

Hallo,

grundsätzlich stellt die MXI-4 Bridge keinen signifikanten Flaschenhals für die Übertragungsbandbreite dar. Ein integrierter PXI-Controller würde also wohl auch keine anderen Ergebnisse liefern.
Ich werde recherchieren, welche Möglichkeiten Ihnen zur Verbesserung der Performance zur Verfügung stehen.
Bitte haben Sie ein Wenig Geduld.

Jochen Klier
National Instruments Germany

[LVFan]

Hallo,

ich habe in Ihrem Beispiel eine Abfrage des Properties NI_Scope:FetchBacklog eingefügt.

Wenn ich das VI dann laufen lasse kann man zusehen wie die Anzeige kontinuierlich hochzählt, bis dann bei etwas über 8MSamples keine Ausgabe mehr erfolgt. Je höher die Bandwith (Samplerate) eingestellt ist desto schneller geht das.

Der verwendete RFSA verfügt über 32MByte Speicher, für die Erfassung von IQ-Daten sollte der Puffer also 16MSamples umfassen. Offensichtlich liegt das Problem nicht darin das das Abfragen des Puffers zu langsam erfolgt, sondern das die Pretriggerdaten allmählich den Puffer zumüllen. Darum habe ich den Wert für Pretriggersamples=0 (Reference Position=0) gesetzt, dies brachte jedoch keine Verbesserung.

Mir ist immer noch unklar wieso ich das NIScope auf Softwaretrigger stellen muss, ohne jedoch einen Softwaretrigger auslösen zu müssen. Wieso erhält man dann mit dem Fetchbefehl trotzdem Daten?

[LVFan]

Hallo,

Ich habe den RFSA als Einzelgerät in einen PXI-1000B eingebaut und über eine MXI4 mit einem anderen Rechner verbunden, der etwas leistungsfähiger als mein Entwicklungsrechner sein sollte.
Unverändert bekomme ich aber dennoch nach einiger Zeit die Fehlermeldung Fehler -1074118632 occurred at: niScope Fetch Cluster.vi.

Die Vermutung das der Speicher durch nicht abgerufene Pretriggerdaten zugemüllt wird ist aber offensichtlich falsch.
Ich habe anschließend das Beispiel-VI "ni Scope EX Fetch Forever.vi" ausgeführt. Bei einer Samplerate von 5MSamples läuft das Beispiel problemlos. Erst bei höheren Sampleraten steigt der Backlog an bis die Fehlermeldung -1074118632 auftritt. Die Daten werden also ausreichend schnell von der Karte eingelesen.

Daraufhin habe ich mal den Profiler verwendet um mir das Timing von den RFSA-VIs anzusehen (Das abgewandelte Beispiel). Der größte Zeitanteil wird von "MT convert IF to IQ.vi" verbraucht (siehe Anhang).
Könnte man dieses VI zerlegen, um die Verarbeitung zu parallelisieren oder Teile ganz aus der Messchleife zu nehmen oder muss jedes SubVi gezwungenermaßen nach jedem Fetch durchgeführt werden?

LVFan

[Jochen]

Hallo,

das angeführte Beispiel, mit dem Sie bis zu 5 MS/s arbeiten können, ist natürlich deutlich weniger rechenintensiv als Ihre eigentliche Anwendung. Daher könnte der Ansatz, die CPU-Last zu reduzieren durchaus zum Erfolg führen. Bevor wir aber damit anfangen, die Applikation zu zerlegen, noch zwei Fragen:

1. Sehen Sie in Ihrer Applikation ebenfalls das Ansteigen des Scan-Backlogs?
2. Wie ist die CPU-Last bei Ihrer Anwendung?

Jochen Klier
National Instruments Germany

[CGI]

Hallo,

ich habe gerade das Beispiel auf einem vergleichbaren System getestet und kann auch sehen, dass bei 400kHz Bandbreite der Fetch-Backlog ansteigt.
Bis 390kHz funktioniert es problemlos, aber daruber schaltet der Digitizer auf 1MS/s Erfassungsrate um und der Backlog steigt.
Vermutlich liegt es in den Parametern zur Erfassung (Samples to fetch etc.)
Mit dem PXI-5660 kann bis zu 1,25MHz Bandbreite kontinuierlich erfasst werden.
Ich werde das Beispeil so umbauen, dass die 1,25MS/s erreicht werden und hier posten.

Allerdings kann man die Erfassung einer bestimmten Bandbreite (z.B. 5MHz) mit RF Signalanalyzer und Digitizer nicht direkt vergleichen.
Erfasst man mit einem Digitizer 5MHz so stellt man eine Abtastrate von mindestens 10MHz (->Nyquist) ein. Man spricht auch von einem Signal im Basisband.
Wenn mit einem RF Signalanalyzer ein 5 MHz Bereich erfasst wird, also z.B. 97,5 bis 102,5Mhz, dann mischt der Downconverter die 5MHz auf eine Zwischenfrequenz
von 15MHz herunter, so dass ein Bereich von 12,5 bis 17,5MHz mit dem nachgeschlteten Digitizer erfasst werden muss. Das Spektrum kann nicht ganz auf 0 bis 5 MHz
heruntergemischt werden, weil sonst prinzipbedingt (soweit ich weiss arbeiten alle HF Analysatoren so)  hohere Harmonische das Signal verfälschen.
Ber einer max. Frequenz von 17,5 MHz ist also mindestend 35MHz abtastrate notwendig.