WLAN und UDP Datenpakete

    Hallo,


    in der Hoffnung, die Datenpakete des Red Pitaya an besserem Ort zu analysieren, habe ich, da dem Rechner kein Ethernet Anschluss vorhanden ist, die Pakete nicht direkt über das LAN an den Rechner geschickt, sondern über WLAN.


    Hier gelangen es dem Skimmer-Server aber nicht auch nur eine Station zu identifizieren. Die Möglichkeiten der Fehlerquellen sind vielfältig.


    Kann es sein, dass bedingt durch das Protokoll (ungesichert und verbindungslos) und die Länge der Laufzeit, die Pakete so durcheinander ankommen, das eine Dekodierung unmöglich ist?


    Oder konkret: Kann UDP über WLAN überhaupt funktionieren ... oder sollte ich lieber eine andere Lösung suchen?


    73 de Hajo

    Moin,


    was uebertraegst Du denn? Ein Audio-Signal oder Daten?


    Grundsaetzlich funktioniert UDP auch ueber WLAN oder andere Funkverbindungen, VoIP (RTP) nutzt das. Latenzzeit geht vor Sicherheit, bei der Sprachuebertragung ist es nicht so wichtig, dass jedes Paket auch wirklich ankommt. UDP hat geringere Latenzzeiten als TCP, aber eben keine Sicherheit, d.h. verlorene Pakete werden nicht wiederholt.


    Bei Daten koennen verlorene Pakete gravierende Auswirkungen haben, deswegen nimmt man UDP eher nicht, bzw. nur bei kurzen, schnellen Uebertragungen, wie z.B. DNS.


    73, Tom

    Hallo Tom,


    ich bewege mich am Rande meines Wissens: Der Red Pitaya uebertraegt bis zu 6 * I/Q data streams im NF-Bereich. Die Datenrate kann dabei 48, 96, 192, 384 kSPS sein. Es ist ein downgesampelter Datenstrom vom Antenneneingang. Das Protokoll fuer die Daten ist im Metis-Protokoll festgehalten.


    Wenn ich es richtig gelesen habe, ist vorgesehen, dass ein Datenframe, der nicht korrekt empfangen wurde, erneut angefordert werden kann. Der Stream wird dann wohl irgendwo gepuffert und weiter verarbeitet.


    Da es keine natuerliche Sprache ist, bei der durchaus Teile fehlen koennen, sondern Rauschen und eine Vielzahl von Morsezeichen, die erkennt und dekodiert werden muessen macht ein verlorenener Datenframe ( 1024 bytes (2 x 512 byte USB format frames) kein Spass und der SkimSvr bekommt, die Daten nicht mehr zusammen.


    So muss ich mir wohl eine andere technische Loesung ausdenken, bei der der Rechner direkt am Ethernet saugt. (Mit dieser Loesung hatte ich bisher keine Problem, da die Rechner am selben Switch haengen.)


    Zur Erlauterung: Ich wollte den 7" TrekStar recyceln und als graphische Ausgabeeinheit für meine Programme verwenden, aber das Ding ist masslos ueberfordert und geht wieder ins Regal.


    73 und Danke fuers Mitdenken


    Hajo

    Moin Hajo,

    Zitat

    ch bewege mich am Rande meines Wissens: Der Red Pitaya uebertraegt bis zu 6 * I/Q data streams im NF-Bereich. Die Datenrate kann dabei 48, 96, 192, 384 kSPS sein. Es ist ein downgesampelter Datenstrom vom Antenneneingang. Das Protokoll fuer die Daten ist im Metis-Protokoll festgehalten.

    Auf Dein Laufwerk C kann ich nicht zugreifen :P

    Zitat

    Wenn ich es richtig gelesen habe, ist vorgesehen, dass ein Datenframe, der nicht korrekt empfangen wurde, erneut angefordert werden kann. Der Stream wird dann wohl irgendwo gepuffert und weiter verarbeitet.

    Das geht mit UDP nicht. Ausser man legt eine Schicht oben drauf, also wieder ein eigenes Protokoll, dass fuer die Sicherheit der uebertragenen Pakete sorgt.

    Zitat

    Da es keine natuerliche Sprache ist, bei der durchaus Teile fehlen koennen, sondern Rauschen und eine Vielzahl von Morsezeichen, die erkennt und dekodiert werden muessen macht ein verlorenener Datenframe ( 1024 bytes (2 x 512 byte USB format frames) kein Spass und der SkimSvr bekommt, die Daten nicht mehr zusammen.

    Fuer eine Uebertragung ohne Paketverlust ist UDP das falsche Protokoll, egal ob ueber WLAN oder Kabel. Pakete werden bei UDP nicht wiederholt und es gibt keine Sicherheit, dass ein Paket wirklich ankommt.

    Zitat

    So muss ich mir wohl eine andere technische Loesung ausdenken, bei der der Rechner direkt am Ethernet saugt. (Mit dieser Loesung hatte ich bisher keine Problem, da die Rechner am selben Switch haengen.)

    Ich denke, Du wirst daheim auch keinen Switch haben, der da Probleme verursachen koennte, weil er nicht richtig konfiguriert ist ;)


    Aber wie waere es denn ganz simpel mit TCP? Warum nimmst Du ueberhaupt UDP?


    Was ist dieses Metis-Protokoll? Das finde ich im RFC nicht, ist das irgendwas "selbstgestricktes" von der SDR Gilde?


    73, Tom

    Wenn ich das so beim Ueberfliegen richtig verstanden habe, wird das Metis verwendet, um das eigentlich fuer USB gemacht HPSDR ueber Ethernet mit UDP zu uebertragen. Was ich aber nicht gefunden habe, wie die Transportsicherheit ueber UDP gemacht wird ... aber ist schon spaet und um 05:30 klingelt der Wecker.


    73, Tom

    Zitat von dl1sdz

    ich bewege mich am Rande meines Wissens: Der Red Pitaya uebertraegt bis zu 6 * I/Q data streams im NF-Bereich. Die Datenrate kann dabei 48, 96, 192, 384 kSPS sein. Es ist ein downgesampelter Datenstrom vom Antenneneingang. Das Protokoll fuer die Daten ist im Metis-Protokoll festgehalten.


    Ist das WLAN schnell genug dafür?


    Bei 6 I/Q-Streams (mit 2 Byte pro Sample?) und 384 kSPS kommt man immerhin auf eine Nettodatenrate von knapp über 9 MB / s, also etwa 72 MBit/s. Mit 802.11ac geht das, mit 802.11a/b/g/n vermutlich nicht.


    Kannst Du die Anzahl der Streams bzw. die Sampleraten verringern und es dann noch einmal probieren?


    UDP habe ich für ganz ähnliche Anwendungen über WLAN bereits verwendet, allerdings mit niedrigerer Datenrate (ca. 1 MBit/s netto) und damit im kontrollierten Laborumfeld (d.h. kaum andere WLAN-Nutzer in der Nähe) sehr gute Erfahrungen gemacht.

    hallo Hajo,
    ich kenne mich mit den Übertragungsprotokollen nicht aus. Ich nutze aber selber den RedPitaya in Verbindung mit OpenHPSDR über LAN.


    Alle meine Versuche es üer WlAN zu machen, sind wegen der vielen kurzen Unterbrechungen, in der Modulation gescheitert.
    Bereits beim Empfang von SSB Signalen ist das zu hören. Anderen OM s ging es damit nicht besser.


    Vielleicht hilft dir dieser Hinweis weiter.

    Hallo,
    und Dank fuer Eure Antworten.


    Ich folgte dem Vorschlag von Fabian:
    Ich habe alles ausgeschaltet und den RedPit an das LAN angeschlossen.
    Mit nur mit einem Kanal 96 kHz ueber WLAN lies sich die Verbindung einwandfrei herstellen. Ich habe kontrolliert mich auf sechs Kanaele hochgearbeitet und habe keine Unterbrechengen "sehen" koennen.


    Dann ist mit mein gestriger Fehler gedaemmert:


    Ich bin davon ausgegangen, dass der RedPit mit dem UDP-Protokoll arbeitet, wie ein ungerichteter Sender (Broadcast) = Der Sender sendet und jeder, der will, holt sich seine Pakete wie er sie braucht.


    So hatte ich zur Kontrolle parallel auf zwei zsaetzlichen Rechnern jeweils einen Skimmer-Server laufen lassen, um die Ergebnisse vergleichen zu koennen. Hier hatte ich wohl die Grenzen des Metis-Protokolls ausgelotet und die Interaktion unterschaetzt. So kam es zu den Ausfaellen. Weiterhin hatte ich auf allen Rechnern Speichzugriffsprobleme beobachtet, die vorher nicht vorhanden waren.


    Zusammenfassung:
    UDP ueber WLAN geht.
    Man muss die Datenmenge steuern/reduzieren.
    Zumindest bei METIS sollte wohl nur ein Client am Server haengen.


    Wieder eine der grossen Fragen der Menschheit beantwortet.


    73 de Hajo

    Hallo,


    nach der Beseitigung der Kollisionsmoeglichkeiten, habe ich den Trekstor noch einmal herausgeholt.


    Der RedPit liefert die Daten ins Lan.
    Der Trekstor holt sich die Daten aus de WLAN. Der SkimServer dekodiert zur Zeit 2 Kanaele a 96 kHz. Bandmaster zeigt die Stationen an und DX Atlas zeigt die Stationen auf der Karte.


    An dieser Ecke kann ich weiter machen ... auch wenn das Bild nicht preisverdaechtig ist.


    73 de Hajo