Hallo miteinander, Wir sind auf der Suche nach einem schnellen Funkmodul für ein Wifi-"Oszilloskop". Momentan haben wir mit dem esp32 eine Funkstrecke aufgebaut, welche per UDP eine Abtastrate von 500KHz ermöglicht. Leider hat sich das UDP-Protokoll nach einigen Tests als zu fehleranfällig herausgestellt (war ja zu erwarten). Das TCP-Protokoll ist mit dem ESP32 aber einfach zu langsam. Genauer geschildert liefert die (Vom Hersteller bereitgestellte) Testsoftware für TCP eine Geschwindigkeit von >=6mbps, was bei 16 Bit-Werten eine Abtastrate von 375 KiloSamplesPerSecond ermöglicht (6.000.000 / (16Bit/1Sample) = 375.000 Samples). Wir benötigen keine große Reichweite, es kommt uns nur um die Nettoübertragungsrate an. Daher sollte unser nächstes Modul wohl am besten im 5GHZ-Bereich unterwegs sein. Dort ist die Reichweite wohl eingeschränkter, was aber auch bedeutet, dass es weniger andere Geräte in Reichweite gibt. Das momentane Konzept arbeitet mit einem 14 Bit DA-Wandler. (16 Bit ist später angestrebt). Der AD-Wandler wird von einem FPGA bedient. Das FPGA stellt dem esp32 die 14-Bit Werte seriell an den io-Pins zur Verfügung. Hier liegt auch die 14-Bit-Begrenzug; der ESP hat bei uns schlicht nur 14 Pins zum Einlesen im ersten Register zur Verfügung. Der ESP32 (STA/Transmitter) speichert die Werte in Paketen zusammen und schickt diese dann zu einen anderen ESP32 (AP/Receiver). Dort werden sie dann bei Empfang wieder euseinandergedröselt und seriell in 14-Bit-Werten an ein weiteres FPGA übergeben, welches die Werte dann Taktgenau an einen DAC weitergibt. Das Konzept hatte hier sehr gut funktioniert, auch wenn der ESP32 schon beim Einlesen der seriellen Zustandswerte an seine Grenzen kommt. Nun suchen wir einen anderen Chip, welcher sich am besten ähnlich komfortabel programmieren lässt wie der ESP32 (das liegt glaube ich daran, dass freertos sich um einiges kümmert) und im 5GHz Bereich eine höhere Übertragungsrate erlaubt. Dabei ist mir auch noch nicht so ganz klar, was so machbar ist. Wir wären am liebsten im MSPS-Bereich unterwegs und das per TCP. Wenn dabei noch Bandbreite für Steuersignale übrig wäre, würde das auch nicht stören. Also das RS9110-N-11-03 erwähnt im Datenblatt beispielsweise unterschiedliche Stromverbräuche in Abhängigkeit zum verwendeten Protokoll und WLanModus,... Dabei wird sowohl für den 2,4Ghz und den 5Ghz Modus eine Übertragungsrate von 22 Mbps sowohl für TX, als auch RX erwähnt. (22.000.000 Bit / s) / (16 Bit / Wert) = 1.375.000 Werte/s. Klingt also, als wären MegaSamplesPerSecond generell möglich. Klingt auch so, als wäre (hier) die Nettoübertragungsrate nicht unbedingt von der Sendefrequenz abhängig, auch wenn es oft so hin gestellt wird. Was habt ihr für Erfahrungen? MgG, der Rico
Es ist aber schon klar, dass auch ein Ozilloskop bei hohen Geschwndigkeiten nie kontinuierlich arbeitet, sondern 99% der moeglichen Trigger verwirft. Sinnvollerweise macht man im Oszilloskop schon ein Preprocessing, und uebertraegt nur die relevanten Daten. Also das FPGA und restlichen Schlunz alles vorne einbauen, und nur das Display am anderen Ende der Funkstrecke. Mehr als vielleicht 10 Updates kann man eh nicht anschauen.
Das mit dem Oszi war nur eine Versinnbildlichung. Der Empfänger ist angeschlossen an ein sehr leistungsfähiges Datenanalysegerät, welches am liebsten noch höhere Datenströme zur Analyse hätte. Wir benötigen dorthin einen kontinuierlichen und vor allem konstanten Datenstrom. Uns ist es auch wichtig, dass die Sendeplatine so klein wie nur irgendwie möglich gehalten bleibt. Der ESP ist ein geniales Teil, aber er ist uns einfach eine Ecke zu langsam per TCP.
Rico L. schrieb: > Momentan haben wir mit dem esp32 eine Funkstrecke aufgebaut, welche per > UDP eine Abtastrate von 500KHz ermöglicht. > Leider hat sich das UDP-Protokoll nach einigen Tests als zu > fehleranfällig herausgestellt (war ja zu erwarten). > Das TCP-Protokoll ist mit dem ESP32 aber einfach zu langsam. Bist du sicher, dass das am UDP liegt? Die ESP-Funkstacks verwerfen/verlieren auch mal Pakete oder hängen sich sogar für einige ms auf. Das hat nix mit UDP zu tun. Für wirklich kontinuierliche Datenerfassung wirst du eigentlich nur per Kabel wirklich glücklich, besonders bei höheren Datenraten und wenn es um geringe Timeouts geht. Rico L. schrieb: > Wir wären am liebsten im MSPS-Bereich unterwegs und das per TCP. Da hast du wieder das Problem des Pufferns, und dass TCP auch mal eben länger hängen kann. Mein Credo: Fehlertolerante UDP-Kommunikation aufbauen. Dafür gibt's schon ne Menge gut etablierter Protokolle. Ich streame hier z.B. laufend Video über RTP/UDP ohne relevante Paketverluste. Wenn die Leitung natürlich voll ist, isse voll..
Martin S. schrieb > Bist du sicher, dass das am UDP liegt? Nein, nicht absolut. Wir haben unseren Prototypen aber kürzlich auf einem Messegelände ausprobiert und hatten Datenabrisse. Auch hier im "Labor" haben wir keine 100%ige Übertragungssicherheit. Martin S. schrieb > Die ESP-Funkstacks verwerfen/verlieren auch mal Pakete oder hängen sich > sogar für einige ms auf. Das hat nix mit UDP zu tun. Für wirklich > kontinuierliche Datenerfassung wirst du eigentlich nur per Kabel > wirklich glücklich, besonders bei höheren Datenraten und wenn es um > geringe Timeouts geht. Also schonmal zumindest nicht mit dem Esp32. > Da hast du wieder das Problem des Pufferns, und dass TCP auch mal eben > länger hängen kann. In diesem Fall würden wir einen ausreichenden Puffer bereitstellen. Martin S. schrieb > Mein Credo: Fehlertolerante UDP-Kommunikation aufbauen. Dafür gibt's > schon ne Menge gut etablierter Protokolle. Ich streame hier z.B. laufend > Video über RTP/UDP ohne relevante Paketverluste. Wir sind leider absolut nicht fehlertolerant. Da wir Im Hauptgerät den Datenstream absolut auseinandernehmen, um unterschiedliche Analysen darauf anzuwenden, müssen die Daten konsistent sein. Martin S. schrieb >Wenn die Leitung natürlich voll ist, isse voll.. Wir werden am Ende eventuell tatsächlich das geringste Übel auswählen müssen. Jedoch wollen wir uns vom ESP abwenden, da andere Hardware mit mehr Leistung scheinbar da draußen ist. Ich wollte gern wissen, was andere Menschen dort draußen für Ergebnisse mit Ihrer Hardware erziehlen konnten.
Rico L. schrieb: > Da wir Im Hauptgerät den Datenstream absolut auseinandernehmen, um > unterschiedliche Analysen darauf anzuwenden, müssen die Daten konsistent > sein. Dann scheidet halt UDP aus, aber dafür ist ja TCP gedacht.
Da kann man auch andere Geschütze auffahren und gleich über einen Raspberry PI o.ä. setzen. Den ADC per I2S oder per USB anbinden und dann geht es gleich viel schneller. Für Wland zudem einen von den besseren Wlansticks mit mehreren Antennen und beiden Frequenzbändern verwenden. Zudem kann man Daten auch puffern um kurze Unterbrechungen auszubügeln.
Es gibt noch eine kleine feine, recht elegante Lösung mit dem Mediatek chipsatz (mt 7688). Aber auch da hat man prinzipiell das Problem mit WLAN-Resends und allfälligem längeren Stocken der Verbindung, auch bei UDP, wenn viele Nodes im Aether rumplärren.
Erstmal Thx für die Antworten Leute! SchnickSchnack schrieb > https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol? > > oder was Ähnliches? Dankeschön! Das ist natürlich sehr interessant und ich werde mich damit beschäftigen. Wenn (falls) damit konsistenz zu erreichen ist, werden wir es evtl nutzen. Schreiber schrieb > Da kann man auch andere Geschütze auffahren und gleich über einen > Raspberry PI o.ä. setzen. Schreiber schrieb Der ist leider definitiv zu groß. Wenn man mir nun aber erklärt, dass der Netzwerkdurchsatz maßgeblich von der Rechenleistung des Prozessors abhängt, dann wäre das ein Anhaltspunkt, geeignete Hardware auszuwählen. Wie schnell ist denn der Pi bei TCP? > Den ADC per I2S oder per USB anbinden und dann geht es gleich viel > schneller. Das wäre momentan auch machbar, jedoch sind die GPIOs nicht unser Flaschenhals, sondern die Funkstrecke. Sonst würden wir den Einlesevorgang optimieren. Wir können allerdings aktuell mit c.a 5MHz 14Bit samplen. Daher haben wir uns beim ESP für die parallele Methode entschieden. > Für Wland zudem einen von den besseren Wlansticks mit mehreren Antennen > und beiden Frequenzbändern verwenden. Ich bin eher auf der Suche nach einer Lösung, welche optimaler Weise ohne Antenne theoretisch auf einem Fingernagel Platz hätte. Eine Streichholzschachtel ist auch noch akzeptiert, sobald eine Endlösung dahinter steht ;D Der Empfänger muss auch definitiv ein analoges Signal ausgeben, um Kompatiblität zum momentanen Vorgang zu ermöglichen. > Zudem kann man Daten auch puffern um kurze Unterbrechungen auszubügeln. Das tun wir natürlich. Wir setzen auf einen FiFoSpeicher. Diesen würden wir später auch auf externe Chips auslagern. Es ist allerdings so, dass schon die TCP-Testsoftware des ESP nur 6Mbit/s durchreicht. Das genügt uns nicht. ,...Die 22Mbit/s des im Eingangspost erwähnten Funkmoduls wären viel interessanter für uns (Es dauert ja auch, so ein Konzept aufzubauen). Daher wären ebend extern erfahrene Erfahrungen mit anderen Chips interessant. Ich habe eine ganze Weile am ESP32 gesessen und das würde ich wieder tun, falls sich ein Chip findet, für den sich die Lebenszeit lohnt, weil schon jemand anderes damit hohe Datenraten erreichen konnte. Kann ja sein, dass interessante Datenraten nur mit "echten" Prozessoren zu erreichen sind. Dann muss so ein echter Prozzi ebend auf unsere Platine. Es scheint aber so, als hätten einige Hersteller im Zuge des InternetOfThings ganz tolle Chips entwickelt.
:
Bearbeitet durch User
Sapperlot W. schrieb: > Es ist aber schon klar, dass auch ein Ozilloskop bei hohen > Geschwndigkeiten nie kontinuierlich arbeitet, sondern 99% der moeglichen > Trigger verwirft. Sapperlot W. schrieb: > Mehr als vielleicht 10 Updates kann man eh > nicht anschauen. Das trifft nicht ganz zu. Moderne DSOs verarbeiten mehrere Trigger zu einem Bild und stellen oft getroffene Spannungen heller als die nicht so oft getroffenen dar. Zum Beispiel hat das Keysight DSO7034A: http://www.keysight.com/de/pd-1293624-pn-DSO7034A/oscilloscope-350-mhz-4-analog-channels?nid=-32453.753488&cc=DE&lc=ger Unter "Engineered for the best signal visibility", Industry’s-fastest uncompromised update rate of up to 100,000 waveforms/sec displays infrequent events Hier werden 100000 Waveforms pro Sekunde aufgezeichnet und dargestellt, auch wenn das Display wahrscheinlich nur 60 Hertz hat. Das ist oft sehr hilfreich.
Rico L. schrieb: > Für Wland zudem einen von den besseren Wlansticks mit mehreren Antennen > und beiden Frequenzbändern verwenden. > > Ich bin eher auf der Suche nach einer Lösung, welche optimaler Weise > ohne Antenne theoretisch auf einem Fingernagel Platz hätte. Eine > Streichholzschachtel ist auch noch akzeptiert, sobald eine Endlösung > dahinter steht ;D Ohne vernünftige Antennen kann man jede Art von Funk leider in die Tonne hauen. Und der Tipp mit dem zweiten Frequenzband und mehreren Antennen war auch begründet. Streichholzschachtelgröße, Funk, bezahlbar und zeitkritisch ist mindestens eine Anforderung zu viel. Das wird nix.
Rico L. schrieb: > .Die 22Mbit/s des im Eingangspost erwähnten Funkmoduls ... sind die Bruttodatenrate, also mitnichten die erzielbare Nutzdatenrate, die liegt deutlich darunter. Du wirst möglicherweise nicht darum herumkommen, Deine unrealistischen Vorgaben an die Realität anzupassen. Ein Raspberry Pi Zero W ist nun auch nicht gerade riesig, und enthält alles, was Du für WLAN benötigst. https://www.raspberrypi.org/products/raspberry-pi-zero-w/
https://esp32.com/viewtopic.php?t=839 da geht's zumindest Richtung > 20 MBit/s nach etwas Optimierung Und was heißt "keine große Reichweite"? 1 cm, 10 cm, 1 m, 10 m, 100 m, 1 km? Ein paar Zentimeter -> Toshiba TransferJet www.toshiba-transferjet.com WLAN 2,4 GHz und 5 GHz Module u.a. WL1807 von TI (soll 80 Mbps TCP und 100 Mbps UDP schaffen) oder Laird 60-SIPT https://www.lairdtech.com/products/60-sipt-wi-fi-module
Vielleicht noch uBlox ODIN-W2 Dual-Band Module. Die haben 20MBit/s angegeben. Auf jeden Fall haben die Dinger eine ausgereifte Software und werden deshalb auch gerne in professionellen Produkten verbaut. Die haben auch noch weitere ähnliche Module.
Rufus Τ. F. schrieb: > Du wirst möglicherweise nicht darum herumkommen, Deine unrealistischen > Vorgaben an die Realität anzupassen. > > Ein Raspberry Pi Zero W ist nun auch nicht gerade riesig, und enthält > alles, was Du für WLAN benötigst. Ungeachtet dessen ist bei "WLAN", "hohe Datenrate" und "zuverlässig" ein Attribut zuviel. Wähle zwei.
Rico L. schrieb: > Wir sind leider absolut nicht fehlertolerant. Dann darfst du aber auch nur etwa die Hälfte der durchschnittlich erreichbaren Datenrate ausnutzen. Sobald nämlich zwischendurch mal ein Frame flöten geht, kannst du den Verlust nie wieder aufholen und dein Puffer - egal wie groß du den machst - wird irgendwann überlaufen.
Felix U. schrieb: > Rico L. schrieb: > Wir sind leider absolut nicht fehlertolerant. > > Dann darfst du aber auch nur etwa die Hälfte der durchschnittlich > erreichbaren Datenrate ausnutzen. ...und immer daran denken, dass Lieschen Müller mit ihrem chinesischen Video-Babyphon gleich Mal das halbe 2,4GHz-Frequenzband für sich reserviert hat. Im 5GHz-Band ist es nicht das Babyphone, sondern das Wetterradar. Wenn das sendet hat dein WLAN Pause...
Ich bedanke mich noch einmal sehr für die vielen hilfreichen Hinweise und Anregungen. Schreiber schrieb: > Ohne vernünftige Antennen kann man jede Art von Funk leider in die Tonne > hauen. Okay, verstehe. Ich war der Annahme, dass man die Antenne idR irgendwie unter bekommt. Eine Lambda "1" Antenne z.B. hiermit berechnet,... http://www.sengpielaudio.com/Rechner-wellenlaenge.htm ,...und fertig sei die Ätzbahn. Ich sehe immer so kleine Antennen auf den Modulen, dass mich das nicht beunruhigt hatte. > Und der Tipp mit dem zweiten Frequenzband und mehreren Antennen war auch > begründet. Ich muss zugeben, dass ich das erst im Nachhinein verstanden hatte. > Streichholzschachtelgröße, Funk, bezahlbar und zeitkritisch ist > mindestens eine Anforderung zu viel. Das wird nix. Wir werden es versuchen. Rufus Τ. F. schrieb: > Ein Raspberry Pi Zero W ist nun auch nicht gerade riesig, und enthält > alles, was Du für WLAN benötigst. Die Idee finde ich gerade recht interessant, auch wenn ich mir etwas unsicher bin, weil ich gelesen hatte, dass ein RealTimeOperatingSystem (freertos) gewisse Vorteile bringt und es leider auf dem RPIZero nicht so ohne weiteres verfügbar ist. Ich habe auf dem Gebiet noch wenig Erfahrung. Auf dem ESP ist es ja recht einfach, Aufgaben auf die Kerne zu verteilen. Ich denke, dass dies ein großer Pluspunkt für das Projekt war. Wie sieht es denn mit Multitasking auf dem SingleCore aus? Stört das OS den Ablauf eventuell? Arc N. schrieb: > https://esp32.com/viewtopic.php?t=839 da geht's zumindest Richtung > 20 > MBit/s nach etwas Optimierung Das wir hatten auch zeitweise höhere Datenraten als nun. Wir hatten einige unterschiedliche Boards getestet und sehr unterschiedliche Performance in unseren Tests. Wir gehen aber davon aus, dass der ESP das absolute Minimum für unser Vorhaben darstellt; wir streben nur leider das Optimum an. Das NodeMCU Development Board, ich glaube "V1" hatte die beste Performance. Unser eigenes Board dahinter. Das Widora hatte nicht so gut abgeschnitten, jedoch war es gut dokumentiert, führte alle Pins raus und war gut zu handlen. > Und was heißt "keine große Reichweite"? 1 cm, 10 cm, 1 m, 10 m, 100 m, 1 > km? Ca 1m bis 20m wäre die angestrebte Reichweite. >WL1807 von TI (soll 80 Mbps TCP und > 100 Mbps UDP schaffen) oder Laird 60-SIPT > https://www.lairdtech.com/products/60-sipt-wi-fi-module Harald schrieb: > Vielleicht noch uBlox ODIN-W2 Dual-Band Module. Die haben 20MBit/s > angegeben. Auf jeden Fall haben die Dinger eine ausgereifte Software und > werden deshalb auch gerne in professionellen Produkten verbaut. Das werde ich die Tage nachrecherchieren. Vielen Dank! Das wäre sehr fein! Felix U. schrieb: > Dann darfst du aber auch nur etwa die Hälfte der durchschnittlich > erreichbaren Datenrate ausnutzen. Sobald nämlich zwischendurch mal ein > Frame flöten geht, kannst du den Verlust nie wieder aufholen und dein > Puffer - egal wie groß du den machst - wird irgendwann überlaufen. Ist dies ein Mathematisch-logischer Zusammenhang? Mit flöten gehen meinst du, dass er als verloren erkannt wird und erneut gesendet und verarbeitet werden muss? Mein Kopf sagt mir, dass die Länge des benötigten Speichers linear von der Aufholgeschwindigkeit des Systems abhängt und ich schätze Machbarkeit ab. Die vielen Bedenken von einigen höre ich auch oft in meinem Umfeld und nehme sie ernst. Wir wollen es hier aber versuchen und ich bin mir auch ziemlich sicher, dass wir ein funktionierendes, gutes Konzept aufstellen werden. Es gibt einige Hürden zu überwinden und das wird kein Lötkolbenbastelwochenende. Deswegen bin ich für alle hilfreichen Ratschläge sehr dankbar.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.