Hallo, für ein kleines Studienprojekt (Elektrotechnik, RF-Designs) bräuchte ich eure Hilfe/Empfehlung/Meinung. In ähnlichen Forenbeiträgen bin ich leider nicht fündig geworden. Wir möchten ein Audiosignal über eine kurze Distanz (< 50m) über die Luftschnittstelle übertragen. Am liebsten wäre uns eine digitale Übertragung. Die Abtastfrequenz soll 48k mit einer Quantisierung von 16 Bit betragen, insofern das ganze in digitaler Form erfolgt. Die Nettodatenrate beträgt somit 768kbit/s. In Frage kämen das 868 - und das 2400 MHz Band. Das ganze soll natürlich auf der Lolevelebene aufgebaut werden, d.h. der Einsatz von Mikrocontrollern, Funkmodulen mit bspw. I2S-Schnittstellen zur Anbindung ect. Funkmodule, die ich im Internet gefunden habe haben oft eine zu geringe Datenrate. Könnt ihr mir ein passendes Funkmodul oder einen Händler empfehlen? Danke schonmal, Thomas
Thomas K. schrieb: > Die Abtastfrequenz soll 48k mit einer Quantisierung von 16 > Bit betragen, insofern das ganze in digitaler Form erfolgt. Die > Nettodatenrate beträgt somit 768kbit/s. Soll es denn wirklich HiFi-Qualität haben? Erst mal checken ob es das wirklich braucht. Man muss sich im Klaren sein dass es nicht viel hilft die Abtastrate so hoch zu wählen wenn man die hohen Frequenzen doch nicht hört. Für weniger Datenrate kann ich den (selbst getesteten) NRF24 empfehlen der wohl etwa 50 kBytes/Sekunde erreichen kann. Mit 2MBit/sec vielleicht auch etwas mehr. Allerdings wird das Übertragen eines solchen Streams mit einem "kleinen" Mikrokontroller a la AVR vielleicht etwas schwierig werden. Aber es gibt ja andere.
nRF24L01P mit oder ohne PA. Kann bis zu 2Mbit/s und 1Mbit/s, sollte ausreichen.
Was für ein Delay ist noch ok? Ist es wirklich nur ein Kanal (Mono)? Wie Störverseucht ist die Umgebung? (z.B. 2.4Ghz - WLAN, BT, ...) Woher kommt die Stromversorgung? Wie wird die Datensiucherheit gewährleistet? Sind Unterbrechungen akzeptabel? Wie sieht die Funkstrecke aus? (Hindernisse, Line of Sight, ...) Können kann man alles, die Frage ist, ob es zu der Realität passt...
Mike J. schrieb: > Kann bis zu 2Mbit/s und 1Mbit/s, sollte ausreichen. Du scheinst die Realität nicht zu kennen. Schau dir das Datenblatt an, 2MBit ist die *Roh*-Datenrate. Entscheidend ist was hinten 'rauskommt. Netto-Datenrate, Handshake, Retries ..... Ja ja, einfach mal die Datenrate hinrotzen und schon weiss man alles, gell?
Arduinoquäler schrieb: > Handshake, > Retries ..... Sowas macht man ja auch bei Audioübertragung ... es muss ja unbedingt jedes Paket ankommen.
Mike J. schrieb: > Sowas macht man ja auch bei Audioübertragung ... und Audiodaten kann man ja mit dem NRF24 auch roh übertragen, selbst das kann er ja, gelle?
Wie stellt man im Empfänger eigentlich sicher, dass die Audiodaten wieder zeitrichtig zusammengesetzt werden? Angenommen es gehen Pakete zwischendurch verloren, dann fehlen die ja im Buffer. Retransmits dürften auch ganz schön zeitaufwendig werden. Wenn man fehlende Pakete allerdings ignoriert dann verschieben sich alle Audiosamples ja immer wieder ein bisschen nach vorne, d.h. irgendwann gibts nen Buffer-Underrun.
Also erst einmal danke für die schnellen Antworten. Wie schon erwähnt reicht die Bruttodatenrate von 2 Mbit/s nicht aus. Wir bräuchten bei einer Nettodatenrate von 768kbit/s ca. 3Mbit/s Bruttodatenrate. Arduinoquäler schrieb: > Soll es denn wirklich HiFi-Qualität haben? Für die Weiterentwicklung des Projekts sollte die Qualität weitestgehend erhalten bleiben. Arduinoquäler schrieb: > Allerdings wird das Übertragen eines solchen Streams mit einem > "kleinen" Mikrokontroller a la AVR vielleicht etwas schwierig > werden. Aber es gibt ja andere. Wir werden zur Verarbeitung und Anbindung einen STM verwenden. Blubb schrieb: > Warum nicht den Datenstrom komprimieren? Darüber habe ich mir noch keine Gedanken gemacht, da die Qualität weitestgehend erhalten bleiben soll. Welche Komprimierungsverfahren würden denn in Frage kommen? HF-Werkler schrieb: > Ist es wirklich nur ein Kanal (Mono)? > > Wie Störverseucht ist die Umgebung? > (z.B. 2.4Ghz - WLAN, BT, ...) > > Woher kommt die Stromversorgung? > > Wie wird die Datensiucherheit gewährleistet? > > Sind Unterbrechungen akzeptabel? > > Wie sieht die Funkstrecke aus? (Hindernisse, Line of Sight, ...) Die Latenz sollte 3ms nicht überschreiten und vereinfacht soll ein Monosignal übertragen werden. Die Umgebung hat maximal ein WLANnetz, wobei das System später mit Sicherheit nicht direkt neben einer Fritzbox aufgebaut wird. Der Schwerpunkt liegt darin, einfach mal selbst etwas funktionsfähiges aufgebaut zu haben. Daher auch keine Hindernisse oder ähnliches. Die Stromversorgung wollten wir uns von einem Entwicklungsboard abgreifen. Je nachdem, welches Modul verwendet wird, hat der Rahemenaufbau doch meistens bereits eine CRC-Prüfsumme oder ähnliches oder täusche ich mich da?! Einzelne Unterbrechungen sollten den Ton doch nicht übermässig verzerren, da wir nach dem FIFO Prinzip arbeiten. Paul H. schrieb: > Wie stellt man im Empfänger eigentlich sicher, dass die Audiodaten > wieder zeitrichtig zusammengesetzt werden? Wir wollte nach dem FIFO Prinzip arbeiten. Falls vereinzelt Frames verloren gehen, sollte das doch nicht auffällig sein oder täusche ich mich da?!
Paul H. schrieb: > Wenn man fehlende Pakete > allerdings ignoriert dann verschieben sich alle Audiosamples ja immer > wieder ein bisschen nach vorne, d.h. irgendwann gibts nen > Buffer-Underrun. Nö, warum? anstelle des fehlenden Pakets muss man an dieser Stelle eben eine entsprechend lange Schweige-Millisekunde einlegen oder das letzte Paket nochmal abspielen oder beliebig aufwendig interpolieren. Dann hört sichs ungefähr so an als ob man mit dem Handy durrrr Uunkloch fährrrr rrrrt.......krk.....tüt tüt tüt.
:
Bearbeitet durch User
Arduinoquäler schrieb: > ... und Audiodaten kann man ja mit dem NRF24 auch roh > übertragen, selbst das kann er ja, gelle? Du willst mit dem Modul ein analoges, nicht digitalisiertes Signal übertragen? Dazu musst du dir schon ein anderes Modul suchen. Wenn er 768000 bit/s übertragen möchte, dann ist da doch noch einiges an Luft nach oben. Ich würde einfach den Puffer füllen und es weg schicken. Die Adressen werden eh bei der Initialisierung des Moduls vergeben, also weiß der Empfänger auch von welches Modul er Daten zu erwarten hat. CRC war doch auch schon implementiert wenn ich mich nicht irre. Auto-Ack würde ich abschalten und die Pakete verwerfen wenn sie nicht übertragen worden sind. Wenn man da mal kurz außer Reichweite befindet würde der Puffer ja voll laufen und der Controller versuchen das Paket von vor 5 Minuten zu versenden. Ist aber schon eine veraltete Information und damit sinnlos. Paul H. schrieb: > Wie stellt man im Empfänger eigentlich sicher, dass die Audiodaten > wieder zeitrichtig zusammengesetzt werden? Ist eigentlich nicht notwendig. Man schickt ja die Pakete nacheinander weg und setzt sie auch sofort der Reihe nach wieder zusammen. Wenn ein Paket nicht angekommen ist kann man den fehlenden Teil mit irǵend welchen Daten auffüllen oder einfach weglassen. Man könnte aber zum Beispiel zwei Module nutzen und die Pakete zeitversetzt übertragen, dazu benötigt man dann noch eine Paketnummer, ein richtiger Zeitstempel ist nicht notwendig. Also Das Modul_1 sendet Paket_12 und Modul_2 sendet Paket_13 zu den Empfängern, jeweils auf einer anderen Frequenz. Man steigert die Datenrate so auf 4Mbit/s, belegt aber zwei Frequenzen. Es sollte auch kein Problem darstellen die Pakete wieder richtig zusammen zu setzen.
Hallo, Mike J. schrieb: > Die Adressen werden eh bei der Initialisierung des Moduls vergeben, also > weiß der Empfänger auch von welches Modul er Daten zu erwarten hat. > > CRC war doch auch schon implementiert wenn ich mich nicht irre. Der Rahmenaufbau vom NRF24 hat doch standardmäßig den volgenden Aufbau: 1 Byte Preamble --- 3-5 Byte Adresse --- 9 Bit Control field --- Payload und 1-2 Byte CRC Meinst du ich kann das Adressfeld nach der Initialisierung einfach wegschalten und bei der reinen Audioübertragung weglassen? Dann würde ich automatische eine höhere Datenrate hinbekommen. 2 Empfänger-/Sender-Module zu verwenden müsste ich erst noch absprechen. Was haltet ihr von dem RN171 Modul? http://ww1.microchip.com/downloads/en/DeviceDoc/70005171A.pdf
Hallo! Wie wäre es mit der Kodierung die bei CD oder DVD benutzt wird. Dafür hat die Industrie Chips, die kleinere Fehler korrigieren kann
Moin, Route 6. schrieb: > Hallo! > Wie wäre es mit der Kodierung die bei CD oder DVD benutzt wird. Dafür > hat die Industrie Chips, die kleinere Fehler korrigieren kann Die Idee, extra Daten, die eine Fehlerkorrektur ermoeglichen, mitzuschicken, ist schon OK. aber keine Industrie hat Chips, die "kleine Fehler" korrigieren koennen. Da gibts hoechstens Chips, die eine komplette Signalverarbeitung, Motorsteuerung, Display, Fernbedienung, etc. fuer einen DVD-la haben. Und diese Chips gibts nicht einzeln, und Datenblaetter dazu gibts schon mal ueberhaupt garnicht. Natuerlich ist es etwas unclever, unkomprimiertes und ungeschuetztes Audio ueber einen Funkkanal zu uebertragen. Sowas kriegt man eigentlich im Studium beigebracht. Welche Kompressionsverfahren fuer's Audio und welche Fehlerschutzverfahren fuer die Uebertragung man dann nimmt, ist halt Ermessenssache und haengt von den Randbedingungen wie Kanalkapazitaet, Bitfehlerrate und -verteilung, max. zulaessige Verzoegerung, usw. ab. Kleine Beispiele: DVB-S2/HDTV Uebertragung: Da nimmt man AAC fuer die Audiokompression und fuer den Fehlerschutz einen BCH-Code und danach noch einen LDPC-Code. Bei DVB-S/SDTV ist's halt eher MPEG1Layer2 bzw. Reed-Solomon und Viterbi. Aber das Prinzip ist immer gleich. Gruss WK
Dergute W. schrieb: > Natuerlich ist es etwas unclever, unkomprimiertes und ungeschuetztes > Audio ueber einen Funkkanal zu uebertragen. Er will doch nur dass es funktioniert, mehr hat er nicht angegeben. Wenn er die Daten kompremieren und verschlüsseln will, dann benötigt es einen genügend schnellen ARM-Prozessor. Der TO kann ja mal sagen was er sich genau vorstellt.
Thomas K. schrieb: > Meinst du ich kann das Adressfeld nach der Initialisierung einfach > wegschalten und bei der reinen Audioübertragung weglassen? Nein, denn der Empfänger schaut ja dort rein ob er angesprochen wird oder ein anderes nRF24L01P angesprochen soll welches auf der selben Frequenz arbeitet.
Von Sennheiser gibts das AVX-System, das überträgt digital. An dessen Preis merkst du, dass dein Vorhaben nicht ganz so trivial ist...
Dergute W. schrieb: > Natuerlich ist es etwas unclever, unkomprimiertes und ungeschuetztes > Audio ueber einen Funkkanal zu uebertragen. Sowas kriegt man eigentlich > im Studium beigebracht. Das bei einer Funkübertragung im Normalfall Verschlüsselungs- und Komprimierungstechniken eingesetzt werden ist mir schon bewusst, allerdings geht es hier in erster Linie darum, etwas lauffähiges aufzubauen. Das Projekt kommt ja nicht auf den Markt, sondern dient nur dazu, den Lernprozess anzuregen. Dazu zählt die richtige Hardware auszusuchen, im Team zu arbeiten, Probleme zu erkennen, Lösungen zu entwickeln und das ganze aufzubauen. An Standards müssen wir uns, soweit ich weiß, nur an die Richtlinien der Bundesnetzagentur halten und die gibt keine Kodierungs- oder Verschlüsselungsrichtlinien vor. Um jedoch das richtige RF-Modul zu finden, entscheiden wir uns wahrscheinlich, das ganze zu komrimieren. Produkte von bspw. mouser oder NXP haben einfach eine zu hohe Lieferzeit.
Moin, Aeh - da wurd' ich wohl etwas missverstanden: mit ungeschuetzt meinte ich: nicht gegen Uebertragungsfehler geschuetzt - also ohne Forward Error Correction. Nix mit Verschluesselung. Die brauchts wirklich nicht. Aber ohne FEC - das waere arg gewagt. Thomas K. schrieb: > Das Projekt kommt ja nicht auf den Markt, sondern dient nur dazu, den > Lernprozess anzuregen. Aber grad' beim Lernprozess sollt' man den Leuten keinen Mumpitz beibringen. Wenn man sich mal die Datenrate anschaut: 768kBit/sec fuer ein unkomprimiertes, nicht gegen Fehler geschuetztes Mono Audiosignal. Das uebertraegt keiner so. Wenn da ein hoeherwertiges Bit kippt, dann fliegt dem Lautsprecher die Membran raus. Sogar mit dem ollen MPEG1 Audiocodec kannste sowas eindampfen auf z.B. 192kBit/sec. Also auf 1/4. Und wenns nicht audiophil sein muss, dann noch tuechtig mehr. Damit haettest du dann noch fuer die 3 fache Menge Fehlerkorrektur Platz. Oder du kannst die Bitrate, die du uebertragen musst, massiv reduzieren... Gruss WK
Ja ich verstehe... Wir haben uns jetzt entschieden das ganze zu komprimieren. Aber nicht über ein Standart-Komprimierungsverfahren sondern über einfache IIR Filter. Etwas komplexeren gibt der STM vermutlich nicht her und die Laufzeit wäre zu hoch. Das müsste man testen. Da eine Gitarre zum größten Teil den Frequenzbereich von 15 - 11500 Hz nutzt, werden wir das Signal zuerst mit der besagten Datenrate einlesen, downsamplen (tiefpassfilterung und Abtastrate auf 32kHz oder 24 kHz reduzieren) und evt die Quantisierung ebenfalls auf 12 Bit setzen, übertragen und wieder upsamplen. Im Worst Case hätten wir dann eine Rate von 512 kbps. Das wäre ja schonmal ein guter Ansatz. Vermutlich gehen wir aber mit der Frequenz auf 24 kHz. Bevor wir die Hardware bestellen, werden wir das ganze in Matlab simulieren, um sicher zu gehen das die Qualität noch ausreichend ist. Mit diesem Konzept könnten wir das nrf-modul nehmen.
Noch ein kleiner Tip: Erstmal ohne Funk testen, das ganze rein "digital" aufbauen und testen. Dann in einem möglichen zweiten Schritt einfach mal Aussetzer/Fehler im Datenstrom einbauen und sehen, was passiert. In einer separaten Schiene das Funkmodul mit der Ansteuerung austesten und feste Pakete übertragen. Wenn das dann separat läuft, kann das System leichter zusammengebaut werden. Ob mit dem Aufbau aber wirklich <3ms Delay sicher zu realisieren ist? Das Paket kann ja erst abgesendet werden, wenn das letzte Byte drinnen ist. Und der Empfang des Pakets braucht dann solange, wie noch Bytes "in der Luft" sind. --> Erstmal ausrechnen, was die reine Übertragungszeit ist, und dann noch die Zeit für die Komprimierung und De-Komprimierung draufrechnen. Nur mal so als Gedanke: Bei Bluetooth gibt es ähnliche Ansätze (A2DP), und die Nettobandbreite ist auch ziemlich in der Nähe (zumindest bei EDR). Ich glaube mich zu erinnern, dass die Latency wohl deutlich höher war (so im Bereich >100ms).
HF-Werkler schrieb: > Wenn das dann separat läuft, kann das System leichter zusammengebaut > werden. Danke für die Info. Das wollten wir selbstverständlich so machen. HF-Werkler schrieb: > Ob mit dem Aufbau aber wirklich <3ms Delay sicher zu realisieren ist? Ich habe herausgefunden, das die Wahrnehmungsschwelle nicht bei 3ms, sondern bei 11 ms liegt. Das passt uns sehr gut ins Projekt. Außerdem sind die Bluetooth-Module von Grund auf viel langsamer als die WLAN-Module. Der nrf24 sollte schnell genug sein.
Abend, ob NRF24 oder RFM73 (jetzt eher RFM75) nimmt sich erst einmal nichts. Man kann dort 32 Byte in einem Rutsch übertragen. On Air sieht das dann so aus wie oben schon erwähnt. Der Empfänger kann die Daten automatisch prüfen (an Hand der CRC) und bei Fehler ein Retransmit anstoßen. Von daher kann man auch den Verlust eines Paketes ausgleichen. Was einem bewusst sein muss, das man keine kontinuierliche Datenübertragung hat. Man bekommt also immer maximal 32 Byte und muss dann auf das nächste Paket warten. Die Wiedergabe muss man also irgend wie wieder mit den 48 kHz synchronisieren. Eventuell arbeitet man mit einem kleinen Datenpuffer. Die RFM7x gibt es als RFM7xP Variante(mit Verstärker), nur die würde ich auf der Sendeseite nehmen. Mit den normalen Modulen bekommt man maximal 5-6 m Reichweite, das "P" sollte die 50 m aber schaffen. WLAN stört nach meinen Erfahrungen die RFM Datenübertragung eher nicht. LG Willi
Thomas K. schrieb: > Außerdem sind die Bluetooth-Module von Grund auf viel >langsamer als die WLAN-Module. Der nrf24 sollte schnell genug sein. Naja, WLAN kann auch langsam, wenn der Übertragungskanal gestört oder schlecht ist (z.B. viel Multipath oder zuwenig Pegel). Dann landet man auch mal bei der Funkdatenrate bei 1MBit/s (WLAN). Der nrf24 kann afaik auch nur max. 1 oder 2MBit/s auf der Luftschnittstelle, das kann Bluetooth ebenfalls (BR/EDR). Du wirst für einen ausreichenden Puffer sorgen müssen, um die ev. schwankenden Übertragungszeiten ausgleichen zu können. Alles in allem denke ich, dass selbst "nur" 11ms ev. schwer zu erfüllen sein könnten.
Hallo zusammen, ich wollte mich mal zurückmelden und ein Statement zu dem Projekt abgeben. In dem vorgegebenen Zeitraum haben wir das Projekt leider nicht komplett umsetzen können. Außerdem gab es einige Komplikationen. Es liegt nun an der Hochschule, das Projekt evt. mit anderen Studierenden weiterzuführen. Vielleicht kommt es ja dazu, es würde mich sehr freuen. Wir haben die Aufgabenstellung bei der Planung überschätzt. Eine Audiofunkübertragung haben wir hinbekommen, allerdings nicht wie geplant, mit dem STM32F7 Discovery, sondern dem F4er. Wir hatten absolut keine Erfahrung mit den HAL-Libs und sind deswegen umgestiegen, da der Schwerpunkt auf dem RF-Teil lag. Leider hat die Rechenleistung des Boards nicht ausgereicht, um die Daten in Echtzeit zu verarbeiten. Wir haben eine sehr hohe Latenz. Durch den 48kHz Interrupt verliert das Board zuviel Zeit zum Verarbeiten. Auch bezüglich Programmierung des Boards hat es wohl an Erfahrung gemangelt. Ich denke, das ein erfahrener Embedded-Programmierer das Ganze hinbekommt. Zu der Fehlerrate: Bei 15000 empfangenen Packeten haben wir 63 fehlerhafte in einem nebenläufigen WLAN-Netz gemessen. Die CRC des RFM75P hat das sehr gut selbst geregelt. Trotzdem haben wir von 32 Byte (Payload) nur 24 Byte für die Nutzdaten verwendet, um einen kleinen Platz für andere Daten zu lassen. Bei dem RFM75P messten mir weiterhin eine maximale Brutto-Übertragungsrate von nur 1,5 Mbit/s. Für die Audioübertragung hat das also ausgereicht, obwohl im Datenblatt 2 Mbit/s angegeben sind. Zu den bereitgestellten Audiodaten: Wir haben dafür im RAM einfach 1ms Audiodaten abgelegt, wiederholt übertragen und dann ausgegeben. Bei der Ausgabe über den CS43L22 kam es zu einem unangenehmen Knacken, da der Controller nicht schnell genug arbeitet. Der Buffer besteht aus 400*48*16 Bit Audiodaten. Wir haben das Ganze ohne ACK gemacht. Mit einer maximalen Leistungsabgabe haben wir eine Entfernung von ca. 140 m ohne höhrbaren Verbindungseinbruch erreicht. Zusammenfassend sind wir eig sehr zufrieden. Es hat zwar nicht so geklappt, wie wir es uns am Anfang vorgestellt haben, aber es kann ja noch weiter fortgeführt werden.
Bitte 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.