Auslesegeschwindigkeit virtueller Com-Port

Hey,

ich arbeite ferzeit an einem RDS-Reader, der die RDS-Informationen eines Tuner via USB über einen virtuellen Com-Port ausliest. Das Tool arbeit eigentlich mittlerweile zu meiner vollsten Zufriedenheit, jedoch habe ich ein echtes Problem mit der Datenrate.
Zur Information, als Datenstrom werden RDS-Nachrichten, die immer 72 Bit lang sind verschickt. Davon werden ungefähr 11,4 in der Sekunde veschickt. Leider liest mein Tool nur geschätzte 3-4 Nachrichten aus. Dadurch gehen natürlich enorm viele Informationen verloren, was noch ginge, wenn manche Dinge nicht aus mehreren NAchrichten bestehen würde und deshalb letztendlich unvollständig angzeigt werden.
Meine Frage dabei wäre einfach nur, woran sowas liegen kann? Mit einem Terminaltool erhalte ich einen, wahrscheinlich, vollständigen Datensatz. Kann das am Umfang des Tools liegen oder ist die VISA-Schnittstelle nicht geeignet für diese Datenraten, was ich mir nicht vorstellen kann?

Irgendeiner eine Idee, woran sowas liegen könnte? Ist schon ziemlich wichtig, da das sonst ziemlich umprofessionell aussieht, wenn ich 30 Sekunden auf einen vollständigen Radiotext warten muss oder ich sogar wichtige Flags verpasse.

Vielen Dank schonmal und diesemal glücklicher Weise keine Array-Frage^^

Bis dann

Anzeige

' schrieb:ist die VISA-Schnittstelle nicht geeignet für diese Datenraten, was ich mir nicht vorstellen kann?

Nein, das Visa-Tool ist definitiv schnell genug.

72Bit * 12/sec ? => 120Byte in der Sekunde? 12 Pakete zu je (max) 10 Byte pro Sekunden? Das ist ja lansamer als langsam.

Da musst du mal deinen Algorithmus überprüfen - oder hier einstellen.

Welchen denn? Nur denn Part mit dem Auslesen oder wie? Der Rest ist denn doch schon etwas ausgewuchert mit Subvis und so.
Ich werd mal nen Tool schreiben, dass nur das Auslesen macht, genau wie der RDS-Reader, und sonst nichts, wenn das auch so langsam ist, stell ichs mal ein und dann könnt ihr mir mal auf die Finger hauen.

EDIT: Vielleicht könnt ich das ganze ja messen lassen? Kann man das direkt machen oder muss ich nen Counter setzen? Und wie vorallem?

' schrieb:Welchen denn? Nur denn Part mit dem Auslesen oder wie? Der Rest ist denn doch schon etwas ausgewuchert mit Subvis und so.

Was soll dein Programm denn machen? RDS nur auslesen und anzeigen? Oder auslesen, anzeigen und steuern?
Wenn nur auslesen, anzeigen und ggf. noch speichern - dann hast du irgendwo einen Konzeptfehler.

Zitat:Ich werd mal nen Tool schreiben, dass nur das Auslesen macht, genau wie der RDS-Reader, und sonst nichts, wenn das auch so langsam ist, stell ichs mal ein

Das ist doch schon mal ein Anfang.

Zitat:EDIT: Vielleicht könnt ich das ganze ja messen lassen?

Sehe ich jetzt keinen Nutzen drin. Dass es langsam geht, siehst du ja auch ohne genauen Zeitwert.

Ja klar aber wir sprechen hier von 12 Nachrichten in der Sekunde. Wenn nur 9 ankommen, kann ich da bestimmt keinen Unterschied mehr erkennen aber die Datenfehlen dann teilweise immernoch.
Also das Tool liest den Datenstrom aus und wertet diesen dann aus (zerlegen, vergleichen, jede Menge Cases und Subvis). Später soll noch getraced werden. Aber daran scheints erst mal nicht zu liegen, da das einfach Tool, auch etwas langsam ist (schätzungsweise 3-4 Nachrichtem/s, kanns aber nicht genau sagen).

Irgendwie kann ich heute von Arbeit nichts hochladen, werd ich dann von zuhause machen. Aber generell hatte ich mich an ein Beispiel von LabVIEW gehalten.

Naja ich liefer das Programm dann nach!

So hat doch länger gedauert :-(

Aber hier das Programm: LabVIEW 7.0

Anzeige

Mach mal ne While schleife um deine Casestruktur und den button der sie umschaltet.
ne kleine wartezeit von ca 10ms mit in die Whileschleife.

Weil:
Wenn du das programm laufem läst, sieht das für mich so aus das du das über dauerausführen machst.
Da du dann in jeder schleife den Port neu Öffnest und schliesst verzögert das die lesere natürlich.
Wenn nachrichten fehlen kann das daher kommen das du den port ständig neu öffnest und schliesst.

Grüße
Achimedes

Hmm joa, hab das Problem verstanden, aber wie sage ich denn dass er warten soll?
Ich habs jetzt einfach mal mit einer Konstaten "true" belegt und siehe da, da kommen die Nachrichten nur so angeschossen.
Also ich hab die Case-Struktur gelöscht und eine While-Schleife drum gemacht, die permanent auf True steht. Könnte es mit einer solchen Lösung zu Probleme oder Schwächen kommen?

' schrieb:aber wie sage ich denn dass er warten soll?

Warten auf was? Einfach so? Dafür gibt es auf der Timer-Palette diverse VI's.

Zitat:Könnte es mit einer solchen Lösung zu Probleme oder Schwächen kommen?

Im Prinzip nicht. Oder: Man kann es immer so programmieren, dass es einwandfrei läuft.

Eine While-Schleife kann man beendbar machen z.B. mit einem Abbruch-Button.

In einer While-Schleife muss eine Zeitverzögerung drinnen sein. Entweder durch ein explizites Warte-VI oder indirekt durch ein Lese-VI (von DaqMX, VISA etc), das intern einen Timeout etc hat. Ohne diese Zeitverzögerung kann es bei Volllast der While-Schleife zu Problemen mit dem Refreshen des FP kommen.

Hmm also bisher habe ich keine Probleme diesbezüglich feststellen, aber leider auch noch nicht das enstprechende VI für Warten finden können. Das Warten das in der Toolbar zu finden ist, gibt ja nur einen Wert zurück... Naja nicht so dringend solange das nicht kracht^^

Wichtige wäre mir die Möglichkeit bei Signal das Ganze Frontpanel zu löschen. Also alle eingetragenen Werte in Anzeigen und Array löschen, damit von vorn mit dem beschreiben begonnen werden kann! gibts das was generelles oder muss man sich da für jede Anzeige etwas einfallen lassen?
Szenario ist, dass ich die Sender wechsle aber zum Beispiel weiterhin alle alternativen Frequenzen des alten Senders plus die neuen habe. Oder noch den alten Radiotext usw.