Moin, ich bin beim Suchen nach neuen Ideen auf den ESP8266 gestoßen. Zuvor hatte ich schon ein paar Projekte mit dem Arduino Mega/Uno/Nano. Ich habe also schon ein paar Grundkenntnisse, was das Programmieren angeht. Bei meinem neuen Projekt möchte ich gerne das Audiosignal vom Pc abgreifen und mit einem Tiefpass, die tiefen Frequenzen herausfiltern. Das gefilterte Signal möchte ich dann auf einen ESP8266(NodeMCU V3.3) führen, welches ein virtuelles WLAN erstellt. Über das WLAN-Netz möchte ich die aufgenommenen Daten (Amplituden des Signals), an zwei weitere ESP8266 (D1 Mini) verschicken. Dies sollte möglichst in Echtzeit passieren, da die gesendeten Daten später WS2812b LED‘s ansteuern, welche zum Bass der Musik blinken sollen. Ich wollte gerne ein eigenes WLAN-Netzwerk erstellen und mich in kein vorhandenes WLAN-Netzwerk einloggen. Die Schaltung mit dem Tiefpassfilter habe ich schon fertig, bräuchte also nur noch etwas Hilfe bei der Verbindung der ESPs. Ich habe im Internet schon nach so einer ähnlichen Schaltung geguckt, konnte aber leider keine finden, welche meine Anforderungen erfüllt. Zwar konnte ich die beiden ESPs miteinander verbinden, nur leider war eine Verzögerung von etwa 2sec. vorhanden. In einem anderen Beitrag habe ich gelesen, dass das http Protokoll zu langsam sei und man es mit dem TCP-Protokoll, wie z.B. WebSocket, versuchen soll, aber dazu habe ich leider nicht gefunden, was mir hätte weiterhelfen können. Nun wollte ich Fragen, ob mir einer erklären/zeigen kann, wie ich eine Verbindung zwischen zwei ESPs in etwa Echtzeit hinbekommen könnte. Über Lösungsvorschlage würde ich mich sehr freuen. :-) LG Johann
Wegen der normal zu erwartenden Verzögerung im WLAN brauchst du dazu mehr Pufferspeicher, als die ESP8266 haben. Suche Dir für diese Chips eine einfachere Anwendung. Eine Verbindung ist Echtzeit gibt es bei WLAN jedenfalls nicht. Am schnellsten und für diese Anwendung am besten geeignet ist UDP. Siehe http://stefanfrings.de/esp8266/index.html#atudp http://stefanfrings.de/esp8266/index.html#udpsketch
Johann B. schrieb: > Moin, > Nun wollte ich Fragen, ob mir einer erklären/zeigen kann, wie ich eine > Verbindung zwischen zwei ESPs in etwa Echtzeit hinbekommen könnte. Über > Lösungsvorschlage würde ich mich sehr freuen. :-) Wenn Du es Dir leisten kannst, nimm die kaum teureren ESP32 und verwende Bluetooth. Das ist für Deine Zwecke deutlich geeigneter.
Danke für die vielen Antworten. Sollte mein Projekt scheitern, würde ich mir den ESP32 nochmal genauer angucken. Ich wollte es aber eigentlich mit dem ESP8266 schaffen. Aus verschiedenen Codes konnte ich mir einen Code zusammenbasteln. Ich kann, wenn ich den Taster betätige, HIGH und LOW übertragen. Nur habe ich häufig Verbindungsschwierigkeiten. Dann will der Empfänger keine Verbindung zum Sender aufbauen. Des Weiteren kann ich meine WS2812b nicht ansteuern. Wenn ich den Taster drücke, erkennt mein Empfänger dies und schreibt eine Ausgabe in den Seriellen Monitor, aber es werden die WS2812b nicht angesteuert. Zumindest leuchten diese nicht. Das Datenkabel der LEDs habe ich an Pin D2 angeschlossen. Vielleicht kann mir einer von euch sagen, was genau am Programmcode falsch ist. Ich habe die beiden Codes hier hochgeladen.
Johann B. schrieb: > aber es werden die WS2812b nicht angesteuert. > Zumindest leuchten diese nicht. Das Datenkabel der LEDs habe ich an Pin > D2 angeschlossen. und was wundert dich wenn du die Datenblätter mißachtest? Ein WS Stripe muss keine 3,3V Pegel aus einem ESP beachten! schaue einfach in das Datenblatt was der WS für ein high Signal wünscht! (ich tippe 99,9% aller Anleitungen dazu sind nun mal falsch)
:
Bearbeitet durch User
Johann B. schrieb: > in Echtzeit Johann B. schrieb: > WLAN-Netzwerk passen nicht zusammen. Vergiß den ganzen Ansatz einfach.
Andreas B. schrieb: > Johann B. schrieb: >> in Echtzeit > > Johann B. schrieb: >> WLAN-Netzwerk > > passen nicht zusammen. Vergiß den ganzen Ansatz einfach. Ach was, ein paar UDP Pakete kommen auch über WLAN meistens innerhalb von wenigen ms am Ziel an. Bei der Anwendung dürften etwas Jitter und ein paar Ausreißer zu verkraften sein. Viel schlimmer ist der Versuch WS2812b mit 3,3V Logikpegel anzusteuern und generell das Konzept LEDs passend zum Bass per Tiefpass leuchten lassen zu wollen. Das sieht in de Realität nämlich immer scheiße aus.
nicht so schrieb: > Andreas B. schrieb: >> Johann B. schrieb: >>> in Echtzeit >> >> Johann B. schrieb: >>> WLAN-Netzwerk >> >> passen nicht zusammen. Vergiß den ganzen Ansatz einfach. > > Ach was, ein paar UDP Pakete kommen auch über WLAN meistens innerhalb > von wenigen ms am Ziel an. Bei der Anwendung dürften etwas Jitter und > ein paar Ausreißer zu verkraften sein. ms sind Welten, wenn man von Echtzeit spricht. Und als Lichtorgelanwendung ist schon ein oberer ms Bereich ziemlich daneben. > > Viel schlimmer ist der Versuch WS2812b mit 3,3V Logikpegel anzusteuern Das stimmt allerdings. > und generell das Konzept LEDs passend zum Bass per Tiefpass leuchten > lassen zu wollen. > Das sieht in de Realität nämlich immer scheiße aus. Da sind die Geschmäcker wohl verschieden, mit genug Alkohol im Blut geht das. ;-)
Joachim B. schrieb: > und was wundert dich wenn du die Datenblätter mißachtest? Im Datenblatt steht, für VDD= 3,5-5,5V. Für den Input volate level steht für ein Highpegel min. 0,7*VDD und für ein Lowpegel max. 0,3*VDD. Da ich die WS mit 4,5V betreibe, sehe ich keinen Grund, warum diese nicht Leuchten sollten. Aber vielleicht fällt dir was anderes auf, warum das bei mir momentan nicht funktioniert. Trotzdem vielen Dank für deine Hilfe. nicht so schrieb: > Viel schlimmer ist der Versuch WS2812b mit 3,3V Logikpegel anzusteuern > und generell das Konzept LEDs passend zum Bass per Tiefpass leuchten > lassen zu wollen. > Das sieht in de Realität nämlich immer scheiße aus. Auf die 3,3V Logigpegel bin ich eben ja schonmal drauf eingegangen, wie ich mir das vorgestellt habe. Und jetzt nochmal zu dem Tiefpass und dem Versuch die LEDs zum Bass blinken zu lassen. Ich hatte schon mehrere kleine und große Projekte, wo ich die LEDs zum Bass habe blinken lassen. Falls sich einer ebenfalls mal überlegt sowas zu machen, kann ich den Baustein msgeq7 sehr empfehlen. Dieser hat 7 integrierte Bandpässe und kann somit das Audiosignal in 7 Frequenzbänder einteilen. Ich bin zumindest von den Ergebnissen begeistert und sieht meiner Meinung nach nicht scheiße aus, aber Geschmäcker sind ja bekanntlich verschieden.
Johann B. schrieb: > sehe ich keinen Grund, warum diese nicht > Leuchten sollten. Ich aber: Ein ESP liefert nicht unbedingt 3.3V am Ausgang. Mit 3V würde ich höchstens rechnen. Also eher Vdd=4.2V, besser 4V
Andreas B. schrieb: > Ich aber: Ein ESP liefert nicht unbedingt 3.3V am Ausgang. Mit 3V würde > ich höchstens rechnen. Also eher Vdd=4.2V, besser 4V Ich hab die WS jetzt einmal mit 4V und einmal mit 3,5V betrieben, aber bei beiden Spannungen haben die Leds nicht geleuchtet. Könnte der Fehler vielleicht doch woanders liegen? Könntet ihr vielleicht mal den Code anschauen, vielleicht habe ich da ja was übersehen.
Vereinfache dein Programm. Fange z.B. Damit an, erstmal nur eine LED abwechselnd rot grün und blau leuchten zu lassen. Dann machst du das mit vielen LED. Und dann baust du Schritt für Schrott die Sachen wieder ein, die haben wolltest. So findest du heraus, welcher Schritt das Programm kaputt gemacht hat. Das macht es auch uns sehr viel einfacher, zu helfen. Selbst wenn schon der erste Schritt scheitert.
Johann B. schrieb: > Könntet ihr vielleicht mal den Code anschauen, vielleicht habe ich da ja > was übersehen. Hast Du: D7 definiert, aber an D2 angeschlossen
Andreas B. schrieb: > Hast Du: D7 definiert, aber an D2 angeschlossen Hab's wieder auf D2 geändert, aber funktioniert immer noch nicht :(
Andreas B. schrieb: > ms sind Welten, wenn man von Echtzeit spricht. Echtzeit ist nunmal subjektiv, 15ms Verzögerung wird bei der Anwendung keiner bemerken und ist im lokalen Netzwerk leicht drin, auch drahtlos. Für die, die das nicht einschätzen können: 15ms sind etwas weniger als 1 Frame Verzögerung bei 60fps. Andreas B. schrieb: > Und als Lichtorgelanwendung ist schon ein oberer ms Bereich ziemlich > daneben. Ich sprach ja auch von "wenigen" ms, hier bitteschön, nochmal präzisiert: 15ms. Wenn du in deinem WLAN Paketlaufzeiten im "oberen" (also hunderte?) ms Bereich hast, dann ist es wohl hoffnungslos überlastet.
nicht so schrieb: > Wenn du in deinem WLAN Paketlaufzeiten im "oberen" (also hunderte?) ms > Bereich hast, dann ist es wohl hoffnungslos überlastet. Was in Großstädten der Regelfall ist.
nicht so schrieb: > 15ms. Mit dem ESP? Es darf mal gelacht werden. Davon: Stefan ⛄ F. schrieb: > nicht so schrieb: >> Wenn du in deinem WLAN Paketlaufzeiten im "oberen" (also hunderte?) ms >> Bereich hast, dann ist es wohl hoffnungslos überlastet. > > Was in Großstädten der Regelfall ist. mal ganz abgesehen. Da kannst Du Dich glücklich schätzen, überhaupt in den 2-stelligen Bereich reinzukommen.
Ich hab jetzt den Fehler endlich gefunden. Es lag an dem Ledstreifen, der war defekt. Habe einen neuen Ledstreifen angeschlossen und dann hat es funkltioniert. Aber wie hier schon einige geschrieben haben, ist die Verzögerungszeit so groß, dass man das Übertragungsverfahren nicht für meine Anwendung verwenden kann. Mein nächster Ansatz wäre, die Daten über Bluetooth zu übertragen oder hat vielleicht einer von euch noch einen anderen Vorschlag? Falls einer trotzdem auf die Idee kommt, Daten über das Übertragungsverfahren senden zu wollen, poste ich hier die beiden Codes herein.
Nimm RFM12, RFM69 oder so etwas in der Art. -> https://www.mikrocontroller.net/articles/%C3%9Cbersicht_Funkmodule
:
Bearbeitet durch User
Ob Bluetooth wirklich besser geht? Immerhin teilt es sich das Funknetz mit WLAN und meine Stereoanlage hat satte 300ms Verzögerung bei Bluetooth Audio. Wohl weil sie damit üppige Puffer füllt, so viel Speicher musst du erst mal in deinen kleinen Mikrocontrollern zur Verfügung haben.
Stefan ⛄ F. schrieb: > Ob Bluetooth wirklich besser geht? Nö, sicher nicht. Da hast Du auch den ganzen Protokolloverhead.
Johann B. schrieb: > Ich hab jetzt den Fehler endlich gefunden. Es lag an dem Ledstreifen, > der war defekt. das hätte man schnell mit der LIB testen können https://github.com/adafruit/Adafruit_NeoPixel
Stefan ⛄ F. schrieb: > Was in Großstädten der Regelfall ist. Mag sein, wo TO wohnt weiß bisher nur er selbst, bei mir im Kleinkaff sieht das so aus: Ping statistics for 192.168.2.1: Packets: Sent = 100, Received = 100, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 82ms, Average = 7ms
Auf dem 5G Band sieht's sogar noch etwas besser aus, aber das dürfte
hier irrelevant sein:
Ping statistics for 192.168.2.1:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 11ms, Average = 4ms
Stefan ⛄ F. schrieb: > Ob Bluetooth wirklich besser geht? Immerhin teilt es sich das Funknetz > mit WLAN und meine Stereoanlage hat satte 300ms Verzögerung bei > Bluetooth Audio. Wohl weil sie damit üppige Puffer füllt, so viel > Speicher musst du erst mal in deinen kleinen Mikrocontrollern zur > Verfügung haben. aptx hat eine Latenz von 32ms. https://de.wikipedia.org/wiki/AptX Mit BLE kommt er auf 3ms. Er will ja nur die Daten für die LEDs übertragen, da fällt nicht viel Verkehr an.
Hyperion macht u.a. genau das gewünschte. LED-Helligkeiten per WLAN übertragen (Ambilight-Ersatz). Sie verwenden dazu ein ganz einfaches UDP-Protokoll. Ich habs ausprobiert, es funktioniert in der Praxis gut. Also sollte einfach die Daten per UDP rausschicken auch bei diesem Projekt funktionieren. Wenn nicht ist vermutlich was anderes faul. Insbesondere sollte man die Zeit für das Updaten des LED-Streifens nicht außer Acht lassen. 30µs pro LED + 300µs fix sind bei einem typischen 300 Pixel Steifen schon 9.3ms (ohne Overhead). Zum Vergleich hier die Pingstatistik zwischen meinem PC (5 GHz WLAN) und einem ESP8266 (2.4GHz WLAN): rtt min/avg/max/mdev = 2.097/5.215/23.661/5.401 ms Also im Schnitt nur halb so lange wie das Aktualisieren des Streifens dauert. Tatsächlich sind hier aber 4 WLAN Übertragungen drin: PC->Router Router->ESP ESP->Router Router->PC Die tatsächliche Latenz für eine UDP-Übertragung in eine Richtung sollte also ~1ms sein. Das merkt absolut niemand. Update: Hab gerade noch in den Code vom OP reingeschaut. Ich würde erst mal anfangen alle Serial.print rauszuwerfen. Die kosten viel Zeit. Ansonsten würde ich noch das Adafruit Neopixel durch NeopixelBus https://github.com/Makuna/NeoPixelBus/ ersetzen. Das erledigt die Ansteuerung per DMA und lässt damit Rechenleistung für das WLAN frei. Die LEDs müssen dazu aber an den RXD/GPIO3 Pin angeschlossen werden.
:
Bearbeitet durch User
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.