## Ausgangslage Im Beitrag Beitrag "Re: Arndoino programmieren mit Ipad" meinte ich, eventuell könnte man bei einem iPad einen Arduino per PWA über einen Audio Anschluss programmieren, wenn man dafür einen eigenen Bootloader schreibt. Nun will ich das mal versuchen. Bisher habe ich weder mit Bootloadern, noch mit Analoger Signalverarbeitung / DFTs, etc. etwas gemacht, da kann ich also noch viel lernen. Fürs erste habe ich mal auf dem PC 2 Programme geschrieben. Binärdaten -> Audio Samples, und Audio Samples -> Binärdaten, mittles DFTs: https://github.com/Daniel-Abrecht/d2s2d Ich habe diverse Parameter (Lautstärke / Samples pro Byte) zwar mal am PC simuliert, aber noch nicht in der Praxis getestet. Es ist definitiv nicht perfekt, je nach eingestellter Signalstärke usw. funktioniert die Kalibrierung nicht immer, aber ich hoffe es ist gut genug. ## Fragen Ich bin nun an Feedback interessiert. Was haltet ihr von den 2 Programmen, ist der Ansatz / das Protokoll so in Ordnung? Habt ihr sowas schonmal gemacht? Wisst ihr, ob ein iPad solche Audio Daten genau genug abspielen kann, oder ob man da noch was beachten muss? Und dann noch zu den AVRs. Da müsste ich ja mit dem ADC das Audio Signal samplen. Gibt es da was, das ich beachten muss? Kann ich da einfach einen Timer nehmen, und dann alle paar us das nächste Signal verarbeiten? Ausserdem habe ich 9 Sinus, 1 acos2, und diverse float Berechnungen im momentanen Programm. Nun sind solche Berechnungen ja recht aufwendig. Wenn ich den AVR mit 8MHz laufen liesse, und das Audio Signal 44.1kHz hat, dann müsste irgendwas um die ~180 Takte pro Sample haben, um es zu verarbeiten. Reicht das aus? Ansonsten, was könnte man da Optimieren?
Du bist wahrscheinlich zu jung. Früher hat man das viel einfacher gemacht. Google mal nach dem "Kansas City Standard" von 1975 als Einführung. Letztendlich war das alles FSK, wo Rechtecksignale erzeugt wurden. Die Auswertung beim Laden geschah durch Zählen der Nulldurchgänge. Mehr konnten die Kassetteninterfaces auch nicht. Da gab es keine ADCs/DACs etc. 1 Bit musste reichen. KCS waren nur 300bps. Später kamen 1200bps hinzu, und am Ende der Entwicklung gab es dann irgendwelche Fastloader etc. Und was damals funktioniere, sollte heute auch noch gehen. fchk PS: So hats der C64 gemacht: http://tech.guitarsite.de/datassette_enc.html
Hallo Daniel, ich bin noch gar nicht ganz sicher, wo ich überhaupt anfangen soll. Fangen wir mal beim Signalverarbeitungsteil an. 1.) Du versuchst dich an einer DFT (diskrete Fourier-Transformation). Du hast recht, das ist aufwendig. Ob das für deine Plattform zu aufwendig ist, ist von dieser abhängig. Mein Tipp: FFT mal ansehen. Durch die Butterfly-Strukturen wird das deutlich effizienter. 2.) Am Arduino sind die ADCs nicht dafür bekannt besonders toll zu sein. Qualitativ würde ich da also keine Wunder erwarten. Auch für deine (gewünschte?) Abtastfrequenz von 44.1 kHz ist das eventuell nicht die richtige Wahl. 3.) Ich verstehe nicht, wie du "Daten per Audio" übertragen willst. Bisher hast du Binärdaten in Audio gewandelt. Die Struktur dieser Daten entscheidet aber maßgeblich über die Signalform. Geht es dir darum Daten hörbar zu machen? Oder willst du sie wirklich übertragen? Bei Übertragen wäre ein Modulationsverfahren anzuraten. 4.) Dein Code ist unfassbar schwer zu lesen. Kommentare schaden nie. Sie erleichtern auch das Auffinden von Fehlern. Hast du das irgendwo herkopiert (nicht böse gemeint, jeder schaut nach wie andere das machen) oder selber gemacht? In jedem Fall solltest du ranschreiben, was die Sachen machen. Und zum Schluss eine Idee: Für deinen Einsatzzweck solltest du dir mal Bela Boards ansehen. Ich weiß nicht, ob es sie noch gibt, aber das waren exzellente Lernplattformen für digitale Signalverarbeitung. Echtzeitlinux und Programmierung in C im Browser. Ich weiß nicht, wie das am iPad geht, aber da hast du schonmal viel mehr vorhanden, als wenn du das mit dem Arduino zu Fuß von Beginn an probierst.
Moin, Hab' nicht in deinen src geguckt, moppere aber trotzdem einfach mal so drauflos: Obwohl der gute Elm Chan da wohl schon FFT auf AVRs hat laufen lassen, bin ich persoenlich kein grosser FFT-Fan. Was ich heutzutage fuer so ne (Audio)uebertragung machen wuerde, waere irgendeine Art von FEC (forward Error correction). Und dann ist natuerlich floating point und Trigonometrie aufm AVR keine gute Idee, wenns pressiert. Vor zig Jahren hatte ich mal ein wenig "digitale Signalverarbeitung" aufm AVR hier gepostet: Beitrag ""LED-Spectrumanalyzer"software ohne Fouriertransformation" Beitrag "VU-Meter mit Attiny13a statt LM3916" Gruss WK
Frank K. schrieb: > KCS waren nur 300bps. Später kamen 1200bps hinzu, und am Ende der > Entwicklung gab es dann irgendwelche Fastloader etc. > > Und was damals funktioniere, sollte heute auch noch gehen. Eventuell versuche ich das noch, falls mein momentaner Versuch nicht geht. Ich wollte es möglichst schnell haben. Meine Überlegung war, wenn ich 8 Bit in 9 Sinus Signalen kodiere, brauche ich zu deren Erkennung mindestens 2×9+1=19 Samples pro Byte. Mit KCS bräuchte ich ja 1 Kurzes und 1 Langes Rechtecksignal, also mindestens 6 Samples pro Bit (Kurz 2 Samples, 10, Lang 4, 1100). Das wären dann also 6×8 = 48bit, also etwa 2.5x mal länger. Owe W. schrieb: > Fangen wir mal beim Signalverarbeitungsteil an. > 1.) Du versuchst dich an einer DFT (diskrete Fourier-Transformation). Du > hast recht, das ist aufwendig. Ob das für deine Plattform zu aufwendig > ist, ist von dieser abhängig. > Mein Tipp: FFT mal ansehen. Durch die Butterfly-Strukturen wird das > deutlich effizienter. Werde ich machen. Eigentlich hatte ich mir die schon mal angesehen, blicke da aber noch nicht so ganz durch. Das muss ich mir nochmal ansehen. Die DFT verstehe ich mittlerweile hingegen schon recht gut. Ausserdem, bei der DFT kann ich einfach nach jedem Sample das Signal mit dem Sinus / Cosinus vergleichen (Multiplizieren), und dann zum Zwischentotal Addieren. Aber bei der FFT müsste ich glaub ich erst mal alle Werte zwischenspeichern? Da müsste ich definitiv einiges umbauen / anders machen. > 2.) Am Arduino sind die ADCs nicht dafür bekannt besonders toll zu sein. > Qualitativ würde ich da also keine Wunder erwarten. Auch für deine > (gewünschte?) Abtastfrequenz von 44.1 kHz ist das eventuell nicht die > richtige Wahl. Ist der AVR dafür nicht schnell genug, oder worin besteht das Problem bei der Sample Rate? Die 44.1 kHz sind einfach eine übliche Sample Rate bei Audio Dateien. Das muss nicht exakt passen, mein Algorithmus ist da relativ Tolerant ausgelegt, solange genug Samples da sind, sollte es eigentlich passen. > 3.) Ich verstehe nicht, wie du "Daten per Audio" übertragen willst. > Bisher hast du Binärdaten in Audio gewandelt. Die Struktur dieser Daten > entscheidet aber maßgeblich über die Signalform. Geht es dir darum Daten > hörbar zu machen? Oder willst du sie wirklich übertragen? Bei Übertragen > wäre ein Modulationsverfahren anzuraten. Ich will effektiv nur Daten übertragen, einfach per Audio Kabel. Und ich versuche das einigermassen Tolerant gegenüber Wiedergabegeschwindigkeit und Lautstärke zu machen. Aber ich werde da keine Lautsprecher und Mikrophone aufstellen, das wäre nochmal eine Nummer komplexer. > 4.) Dein Code ist unfassbar schwer zu lesen. Kommentare schaden nie. Sie > erleichtern auch das Auffinden von Fehlern. Hast du das irgendwo > herkopiert (nicht böse gemeint, jeder schaut nach wie andere das machen) > oder selber gemacht? In jedem Fall solltest du ranschreiben, was die > Sachen machen. Habe ich alles zu 100% selbst geschrieben. Beim Kopieren lernt man ja nichts. Die Funktionsweise ist so. Ich habe N Samples. Die Enthalten bis zu 9 ganze Sinus wellen. Eine Perioden von der niedrigsten Frequenz, 2 von der zweitniedrigsten, 3 von der drittniedrigsten, usw. Die Niedrigste Frequenz verwende ich für mehrere Dinge: * Am Anfang ermittle ich damit ungefähr, wie viele Samples die Welle Lang ist, und welche Periode sie hat. * Ich nutze die Phase, um ein paar Samples zu überspringen, so das ich am Anfang des nächsten Signals / Bytes mit der DFT anfange. Ausserdem mache ich da eine Feinjustiereung, um die Samples pro Periode genauer zu bestimmen. * Wenn keine weiteren Daten mehr kommen, fällt die Frequenz weg, das ist mein EOF signal. Die Daten fangen an, sobald ich das Byte 0x3E '>' detektiere. > Und zum Schluss eine Idee: Für deinen Einsatzzweck solltest du dir mal > Bela Boards ansehen. Ich weiß nicht, ob es sie noch gibt, aber das waren > exzellente Lernplattformen für digitale Signalverarbeitung. > Echtzeitlinux und Programmierung in C im Browser. Ich weiß nicht, wie > das am iPad geht, aber da hast du schonmal viel mehr vorhanden, als wenn > du das mit dem Arduino zu Fuß von Beginn an probierst. Das mag schon nett sein, aber ich mag die Challenge. Sonst könnte ich ja auch einfach einen PC oder einen RPI nehmen. Und die (sowie die RPIs), hab ich bereits herumliegen.
Frank K. schrieb: > Letztendlich war das alles FSK... Nicht nur für Audio-Kassetten, die guten alten Modems/Akustikkoppler haben ihre Daten ja auch im (eingeschränkten) Audiobereich übertragen. - https://de.wikipedia.org/wiki/Akustikkoppler - https://de.wikipedia.org/wiki/Modem#Telefonmodem - https://de.wikipedia.org/wiki/Frequenzumtastung Versuche sowas auf einem µC zu bauen findet man in iNet genug. Z.b. die erst besten Treffer: - http://unsigned.io/website/micromodem/ - https://unsigned.io/openmodem/ - https://m0agx.eu/bell-202-modem-for-avr-and-other-mcus.html
Frank K. schrieb: > Du bist wahrscheinlich zu jung. Früher hat man das viel einfacher > gemacht. Google mal nach dem "Kansas City Standard" von 1975 als > Einführung. > > Letztendlich war das alles FSK, wo Rechtecksignale erzeugt wurden. Die > Auswertung beim Laden geschah durch Zählen der Nulldurchgänge. Mehr > konnten die Kassetteninterfaces auch nicht. Da gab es keine ADCs/DACs > etc. 1 Bit musste reichen. > > KCS waren nur 300bps. Später kamen 1200bps hinzu, und am Ende der > Entwicklung gab es dann irgendwelche Fastloader etc. > > Und was damals funktioniere, sollte heute auch noch gehen. > > fchk > > PS: So hats der C64 gemacht: > http://tech.guitarsite.de/datassette_enc.html Bevor man stinkende alte Standards nachprogrammiert: Wirf einen Blick auf die Manchesterkodierung*. Die braucht weder DFT/FFT noch eine aufwendige Dekodierung. Die ist so einfach, dass man sie selbst in Hardware mit wenigen ICs der 70er Jahre aufbauen koennte. Und die Geschwindigkeit liegt deutlich ueber obigen FSK-Verfahren. *) Wird gelegentlich auch "Conditioned Diphase" benannt.
Motopick schrieb: > Wirf einen > Blick auf die Manchesterkodierung*. Die braucht weder DFT/FFT noch > eine aufwendige Dekodierung. Die ist so einfach, dass man sie > selbst in Hardware mit wenigen ICs der 70er Jahre aufbauen koennte. > Und die Geschwindigkeit liegt deutlich ueber obigen FSK-Verfahren. Und mit 2 Sample pro Bit / 16 Sample pro Byte, ist es sogar noch etwas effizienter als was ich mir ausgedacht hatte. Scheint auch das zu sein, was bei Sherlock 🕵🏽♂️ schrieb: > https://github.com/orukusaki/avr-audio-bootloader verwendet wird. Ich muss jetzt erst mal ein paar Sachen ausprobieren.
Frank K. schrieb: > Du bist wahrscheinlich zu jung. Macht ja nix, dann erfindet er nochmal den Akustikkoppler. SCNR
Motopick schrieb: > Wirf einen Blick auf die Manchesterkodierung*. ... und wenn man jetzt noch Audio übertragen will, oder irgendwas per Audio, dann gelangt man eigentlich unweigerlich zu S/PDIF, sozusagen der Schwester von Manchester. Für S/PDIF gibt es massenhaft Chips. Wenn man es ganz fett machen möchte, könnte man sogar PAM damit betreiben und z.B. 8 Signallevel codieren.
Daniel A. schrieb: > Arduino per PWA über einen Audio Der Cheepit Sparrow koennte das. https://www.b-kainka.de/Sparrowbuch.html
Daniel A. schrieb: >> 2.) Am Arduino sind die ADCs nicht dafür bekannt besonders toll zu sein. >> Qualitativ würde ich da also keine Wunder erwarten. Auch für deine >> (gewünschte?) Abtastfrequenz von 44.1 kHz ist das eventuell nicht die >> richtige Wahl. > > Ist der AVR dafür nicht schnell genug, oder worin besteht das Problem > bei der Sample Rate? Wie willst du das abtasten? Die AVR-ADCs, die ich kenne, sind bis etwa 15 kSamples/s spezifiziert, maximal 200 kHz ADC-Takt und 13 Takte pro Wandlung. Die kann man zwar wohl deutlich übertakten, aber dann verlieren sie an Genauigkeit. Das musst du halt bedenken.
Florian schrieb: > Wie willst du das abtasten? Gloecklicherweise reicht ein Komparator, der die Nulldurchgaenge detektiert, zum Abtasten einer Manchesterkodierung aus. Man wird auch keine "Chips" brauchen, die S/PDIF dekodieren. Das konnte selbst ein leistungsarmer Z80 schon ganz allein. Man muss nur das "Rezept" kennen, wie er das tut.
Florian schrieb: > Wie willst du das abtasten? Die AVR-ADCs, die ich kenne, sind bis etwa > 15 kSamples/s spezifiziert, maximal 200 kHz ADC-Takt und 13 Takte pro > Wandlung. Die kann man zwar wohl deutlich übertakten, aber dann > verlieren sie an Genauigkeit. Das musst du halt bedenken. Naja, die Frage ist halt die benötigte Genauigkeit. 8 Bit reichen vollkommen. Damit wurde z.B. DTMF unzählige Male erfolgreich umgesetzt. Das sind 16 zu unterscheidende Frequenzen. Und bei 8 Bit Auflösung kommst du mit auch mit den ADCs der "klassischen" AVR8 auf ca. 40kHz Samplefrequenz. Ist aber nicht mal nötig, denn DTMF funktioniert auch schon bei nur 8kHz Samplefrequenz. Spielt sich schließlich vollständig im Sprachband ab, also unterhalb ca. 3,5kHz. Dass aber das ganze Unternehmen des TO völlig sinnlos und dumm ist, ist davon unabhängig Fakt. Ansätze wie das FSK der klassischen Dateninterfaces über Audio-Strecken oder auch Manchester-Encoding sind sehr viel sinnvoller. Viel einfacher zu implementieren und viel weniger anspruchsvoll bezüglich der benötigten Rechenzeit.
Ob S. schrieb: > denn DTMF funktioniert auch schon bei nur 8kHz Das ergibt aber eine extrem geringe effektive Datenrate, weil jeder Ton zunächst eine Weile anstehen muss, um sicher dekodiert werden zu können. Das gilt besonders bei asynchronem Betrieb. Die DTMF sind meines Wissens quasi-Rechtecksignale, die auf der Leitung stark gedämpft werden. Es muss also ein deformiertes Signal erkannt werden. Aus meiner Sicht wenigstens 3x die Grundwelle. Bei 60 Hz unterster Frequenz (Sprachband angenommen) wären das 50ms pro Symbol. Abtasteffekte -> 20 Symbole je Sekunde. Bei einer unstabilen Leitung bekommst du maximal 4 Bit hin, eher nur 3-> 60 bps. Dann lieber Akustikkoppler von 1980.
Hallo, Rolf schrieb: > Die DTMF sind meines Wissens > quasi-Rechtecksignale, die auf der Leitung stark gedämpft werden. Nein, ein DTMF-Ton besteht aus der Addition zweier Sinus-Signale. rhf
Roland F. schrieb: > ein DTMF-Ton besteht aus der Addition zweier Sinus-Signale Danke ich wurde unsicher, hielt diese Aussage aber für Märchen Rolf schrieb: > Die DTMF sind meines Wissens > quasi-Rechtecksignale ist auch meiner Kenntnis nach falsch!
Rolf schrieb: > Ob S. schrieb: >> denn DTMF funktioniert auch schon bei nur 8kHz > > Das ergibt aber eine extrem geringe effektive Datenrate, weil jeder Ton > zunächst eine Weile anstehen muss, um sicher dekodiert werden zu können. Das ist so, ja. Mit ungefähr so 10 Symbolen/s (immer 50ms Ton und 50ms Pause) ist man auf der Sicheren Seite. Also effektiv etwa 5 Byte/s. Das ist natürlich sehr wenig. Dafür geht es dann aber halt auch über 'zig Kilometer einfache verdrillte Strippe und das selbst, wenn starke Störer einwirken (z.B. wenn die Leitung entlang von Bahngleisen verläuft). Und es ist recht einfach (also mit wenig Rechenleistung) zu erzeugen und zu empfangen. > Die DTMF sind meines Wissens > quasi-Rechtecksignale Nein. Jedes DTMF-Symbol ist die Summe zweier Sinustöne.
Es gibt einen Audio-Bootloader für den Attiny85. Dieser kann auch in die Arduino-IDE eingebunden werden: https://github.com/ATtinyTeenageRiot/TinyAudioBoot Die schnelle Programmiergeschwindigkeit wird durch die Anbindung über den Digitaleingang statt des ADC erreicht. Im Anhang der Programmiersound, bei dem man sehr gut die hohen Frequenzen für die schnelle Datenübertragung hören kann.
:
Bearbeitet durch User
Mit diesem Ding Beitrag "MSK Minimum Shift keying transceiver in C" kann man 2400 Bit/s über einen Audiokanal übertragen. Cheers Detlef
Evtl. kann man sich was von alten Floppy-Laufwerken abschauen. Vielleicht von der Commodore VC1541 und verwandten, die sind sehr gut dokumentiert. Disketten sind ja quasi nichts anderes als Tonband/Audio, was sich 5 mal pro Sekunde wiederholt (bei 300 U/min).
>kann man 2400 Bit/s über einen Audiokanal übertragen.
Passt das in die 1KB des Bootloaders ?
Christoph M. schrieb: >>kann man 2400 Bit/s über einen Audiokanal übertragen. > Passt das in die 1KB des Bootloaders ? Achso, nein. Hättichmadenganzenthreadgelesen. Cheers Detlef
Christoph M. schrieb: >>kann man 2400 Bit/s über einen Audiokanal übertragen. > Passt das in die 1KB des Bootloaders ? Ein Manchesterdekoder braucht auf einem Z80 je nach Komplexitaet :) etwa 20 bis 30 Zeilen Assembler. Das ist beim 6502 etwa auch so. Passt der Dekoder doch in den eigentlich fuer den Dateinamen vorgesehenen Bereich des (C64-)RAMs. Das waren dann die "Turbo-Versionen" bei denen man nicht noch extra ein "TurboTape" vorher laden musste... Die Initialisierung der Peripherie kostet natuerlich noch extra. Wie tief muss man eigentlich geistig sinken, um DTMF vorzuschlagen? Floppy MFM ist immerhin den Manchestercodes recht nahe verwandt. GCR wie bei den Commodorefloppies dagagen ueberhaupt nicht. "Group Code Recording".
Angehängte Dateien:
-
usbaudiodongle.jpg
34 KB
Motopick schrieb: > Wie tief muss man eigentlich geistig sinken, um DTMF vorzuschlagen? Auch das Niveau der Post von 1980 :-) Motopick schrieb: > Ein Manchesterdekoder braucht auf einem Z80 je nach Komplexitaet :) > etwa 20 bis 30 Zeilen Assembler. Das ist beim 6502 etwa auch so. So ist es, wobei man natürlich im Auge haben muss, mit welcher Rate die Daten kommen. Ich hatte weiter oben nicht umsonst S/PDIF vergeschlagen, weil man das mit vielen Soundkarten direkt erzeugen kann und dabei die Frequenz verlgiechsweise tief setzen kann. Z.B. Mono 8000kHz. Auch mit USB geht das noch gut. So ein kleiner Chinadekoder kann zumindest runter bis 11kHz -> ~700kHz. Das geht also ohne umständliches Bauen direkt auch vom PC zu schreiben und zu lesen, zumindest, um es zu testen. Man könnte Audio auch symmetrisch übertragen.
Beitrag #7810739 wurde vom Autor gelöscht.
Hier ein Programm, das ich 2011 schrieb, um einen ATMega über die Sound-Karte des PCs zu flashen: SOUNDRX Der Hardware-Aufwand ist minimal, siehe Artikel. Thread zum Thema: Beitrag "SOUNDRX - Datenübertragung/Bootloader PC -> µC über PC-Soundkarte"
:
Bearbeitet durch Moderator
Daniel A. schrieb: > Habt ihr sowas schonmal gemacht? Ich habe vor einigen Jahren das AudioLINK-Protokoll von Ei Electronics analysiert, das in deren Rauchwarnmeldern (z.B. Ei650i) und anderen Warngeräten verwendet wird, um den Zustand des Geräts über den ohnehin vorhandenen Piezo-Schallwandler an eine App zu übertragen. Das Ergebnis war ein Programm, das diese Telegramme sowohl empfangen und auswerten als auch (re)produzieren kann. Falls Interesse besteht kann ich das bei Gelegenheit mal in einen Artikel gießen.
Frank M. schrieb: > Hier ein Programm, das ich 2011 schrieb, um einen ATMega über die > Sound-Karte des PCs zu flashen: SOUNDRX > > Der Hardware-Aufwand ist minimal, siehe Artikel. > > Thread zum Thema: Beitrag "SOUNDRX - Datenübertragung/Bootloader PC -> µC über PC-Soundkarte" Sehr schoen. :) Wer gerade kein Visual Studio zur Hand hat, Mann kann es auch mit dem GCC uebersetzen: >gcc -o sndtx.exe main.c sndtx.c -l winmm >sndtx usage: sndtx [-c] [-s samples] file [outputfile.wav] >sndtx sndtx.exe buffer size: 25484 wave size: 455939 time: 00:10 speed: 2548 bytes/sec TIME: 00:07 ETC: 00:03 70% gcc version 3.4.5 (mingw-vista special r3)
:
Bearbeitet durch User
von Frank M. (ukw) (Moderator) >Hier ein Programm, das ich 2011 schrieb, um einen ATMega über die >Sound-Karte des PCs zu flashen: SOUNDRX Das Verfahren von hier ist aber besser, weil es kein Poti zum Justieren des Audiolevels benötigt, sondern das Interface aus zwei Widerständen und einem Kondensator beseht: https://github.com/ATtinyTeenageRiot/TinyAudioBoot SOUNDRX hat den Nachteil, dass je nach Daten sich der Mittenlevel verschiebt. Beim TinyAudioBoot gibt es diesen Effekt durch die Verwendung des Manchester Verfahrens nicht und die Datenübertragung ist deutlich zuverlässiger. Motopick (motopick) >Sehr schoen. :) >Wer gerade kein Visual Studio zur Hand hat, Mann kann es auch >mit dem GCC uebersetzen: Das geht beim TinyAutoBoot auch und zwar mit avr-gcc und make file: https://github.com/ATtinyTeenageRiot/TinyAudioBoot/tree/master/bootloaderbuild Den Sender braucht man nicht zu übersetzen, weil er in Java programmiert ist und auf allen Betriebssystemen läuft.
:
Bearbeitet durch User
Christoph M. schrieb: > von Frank M. (ukw) (Moderator) >>Hier ein Programm, das ich 2011 schrieb, um einen ATMega über die >>Sound-Karte des PCs zu flashen: SOUNDRX > > Das Verfahren von hier ist aber besser, weil es kein Poti zum Justieren > des Audiolevels benötigt, sondern das Interface aus zwei Widerständen > und einem Kondensator beseht: > https://github.com/ATtinyTeenageRiot/TinyAudioBoot > SOUNDRX hat den Nachteil, dass je nach Daten sich der Mittenlevel > verschiebt. Beim TinyAudioBoot gibt es diesen Effekt durch die > Verwendung des Manchester Verfahrens nicht und die Datenübertragung ist > deutlich zuverlässiger. > > Motopick (motopick) >>Sehr schoen. :) >>Wer gerade kein Visual Studio zur Hand hat, Mann kann es auch >>mit dem GCC uebersetzen: > > Das geht beim TinyAutoBoot auch und zwar mit avr-gcc und make file: > https://github.com/ATtinyTeenageRiot/TinyAudioBoot/tree/master/bootloaderbuild > > Den Sender braucht man nicht zu übersetzen, weil er in Java programmiert > ist und auf allen Betriebssystemen läuft. Ich habe mir Franks (PC-)Software auf Manchesterkodierung umgefrickelt. Die AVRs interessieren mich dabei auch nur ganz am Rande. Einen Manchesterdekoder kann man recht einfach in Hardware bauen. Oder mit wenigen Zeilen Assembler auf einem Mikrocontroller. Dabei ist es dann schon huelfreich, wenn man den Koder selbst uebersetzen kann, und die vollstaendige Kontrolle ueber die Kodierparameter hat.
Motopick (motopick) >Dabei ist es dann schon huelfreich, wenn man den Koder selbst >uebersetzen kann, und die vollstaendige Kontrolle ueber die >Kodierparameter hat. Kannst man im Java-Code von TinyAudioBoot auch. Man muss im Source nur den "wavCreator" anpassen. Die Syntax unterscheidet sich da nur begrenzt von C. Apropos Apple Geräte, die hier ja explizit erwähnt wurden: Bei neueren Geräten kann es passieren, dass Softwareseitig ein Fade-In verwendet wird, was dazu führen kann, dass man die Präambel verlängern muss. Eventuell eingeschaltet Sound-Enhancer-Filter sind auch schlecht.
Christoph M. schrieb: > Motopick (motopick) >>Dabei ist es dann schon huelfreich, wenn man den Koder selbst >>uebersetzen kann, und die vollstaendige Kontrolle ueber die >>Kodierparameter hat. > Kannst man im Java-Code von TinyAudioBoot auch. Man muss im Source nur > den "wavCreator" anpassen. Die Syntax unterscheidet sich da nur begrenzt > von C. Den Java-Code hatte ich mir angesehen, und fand ihn fuer meine Zwecke wenig einladend fuer Aenderungen. Das ging schon bei ganz grundsaetzlichen Dingen los: Ein Manchester codierter Datenstrom braucht keine Start- oder Stopbits. Wenn man Pruefsummen braucht oder will, kann man sie einfach mit in die Payload schreiben, und nach dem Dekodieren auswerten. Eine Protokollebene hoeher gewissermassen. Eine Signalinversion muss man nicht unbedingt in der Software erkennen. Ein XOR-Gatter und ein Schalterchen tun es auch. Pausen zwischen Datenbloecken brauche ich auch nicht. Mein Ziel ist dabei immer, die Dekodierung moeglichst einfach zu halten. > Apropos Apple Geräte, die hier ja explizit erwähnt wurden: Bei neueren > Geräten kann es passieren, dass Softwareseitig ein Fade-In verwendet > wird, was dazu führen kann, dass man die Präambel verlängern muss. > Eventuell eingeschaltet Sound-Enhancer-Filter sind auch schlecht. Das Fade-In kommt vom Strom sparen. :) Wenn Audio nicht gebraucht wird, legt man es schlafen. Das trifft auch x86/x64 Hardware. Man muss auch nicht die Praeamber verlaengern, sondern den "Trailer" vor der Uebertragung. Die Praeambel ist das "Kennwort", dass den Beginn des Datenblocks anzeigt.
Motopick schrieb: > sondern den "Trailer" vor der Uebertragung Ähm, nein. Normalerweise ist es so: Preamble = Übertragungsebene, oft vor den Daten Header = Daten vor dem Payload Payload = Die Nutzdaten Trailer = Daten nach dem Payload
Frank M. schrieb: > siehe Artikel Ist eine Korrektur nach so langer Zeit noch möglich? C2 ist C1 und NF sind hoffentlich nF
Daniel A. schrieb: > Motopick schrieb: >> sondern den "Trailer" vor der Uebertragung > > Ähm, nein. Normalerweise ist es so: > > Preamble = Übertragungsebene, oft vor den Daten Da es die Praeambel ist, die bei synchronen bitorientierten Protokollen den Beginn des Datenblocks anzeigt, ist es nicht fakultativ sie vor den Nutzdaten zu senden, sondern obligatorisch. Auf den Gedanken eine Praeambel "in" einem Datenblock zu senden, koennen nur Informatiker kommen. Wenn man es wirklich kompliziert haben will, geht das natuerlich auch. Die Praxis jedenfalls (SDLC/HDLC) belegt das nicht. > Header = Daten vor dem Payload > Payload = Die Nutzdaten > Trailer = Daten nach dem Payload Wenn du weisst was gemeint ist, ich weiss es auch. :) Vllt haette ich "Pilotton" schreiben sollen... Ein Trailer ist aber im allgemeinen "datenlos", und nur dazu da, dass Uebertragungsmedium gloecklich zu machen.
Motopick (motopick) >Das ging schon bei ganz grundsaetzlichen Dingen los: >Ein Manchester codierter Datenstrom braucht keine Start- oder Stopbits. Die Präambel besteht dort aus 40 gleichen Bits und dann einem Bitwechsel als Startbit. Die 40 Bits werden gebraucht, damit sich die Mittelspannung am Kondensator einstellen kann. Ohne darauf folgendes Startbit wäre keine Synchronisation möglich. Wahrscheinlich müsste man das besser beschreiben.
Motopick schrieb: > Ein Trailer ist aber im allgemeinen "datenlos", und nur dazu da, > dass Uebertragungsmedium gloecklich zu machen. Bei HTTP z.B. kann man im Trailer weitere HTTP "Header" mitsenden: https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Trailer#beispiele (Das ist jetzt terminologisch etwas ungünstig, dass die HTTP Header so genannt werden). Da kommt es wohl darauf an, ob man sich auf die Protokoll, oder die Übertragungsebene bezieht.
:
Bearbeitet durch User
ich würde das auch nicht über den ADC machen, einfach einen Pin mit Flankeninterrupt. Als Code würde ich einen IR Code nehmen. Pause zwischen den Bits immer gleich lang und dann 3 verschiedene Pulslängen. Eine längere fürs Startbit und dann noch 2 kürze für 0 oder 1. Der DAC verwäscht das dann zwar etwas am Empfänger sollte man aber trotzdem die steigenden Flanken detektieren können.
Bei den genannten Beispielen SoundRX und TinyAudioBoot wird eine elektrische statt akkustische Kopplung verwendet. Dadurch sind mit einer einfachen, digitalen Modulation Datenübertragunsraten von 10-20KBit/s möglich. Eine Interessante Frage ist, welche Verfahren wären für eine akkustische Kopplung notwendig und welche Datenübertragungsraten sind möglich. Als erstes lohnt sich hier ein Blick auf die historischen Akkustikkoppler: https://en.wikipedia.org/wiki/Bell_103 300 Baud, FSK sender: mark 1,270 Hz space 1,070 Hz receiver: mark 2,225 Hz space 2,025 Hz. https://en.wikipedia.org/wiki/Bell_202 1200 baud mark: 1200 Hz space: 2200 Hz Telefonleitungen generell nur das Frequenzband von 300 Hz bis 3400 Hz
Christoph M. schrieb: > Bei den genannten Beispielen SoundRX und TinyAudioBoot wird eine > elektrische statt akkustische Kopplung verwendet. Dadurch sind mit einer > einfachen, digitalen Modulation Datenübertragunsraten von 10-20KBit/s > möglich. Ersetze den Begriff Modulation durch Kodierung. Der Empfaenger muss das Signal nicht demodulieren, sondern nur dekodieren. Genau daraus resultiert die Einfachheit. > Eine Interessante Frage ist, welche Verfahren wären für eine akkustische > Kopplung notwendig und welche Datenübertragungsraten sind möglich. > Als erstes lohnt sich hier ein Blick auf die historischen > Akkustikkoppler: > > https://en.wikipedia.org/wiki/Bell_103 > 300 Baud, FSK > sender: > mark 1,270 Hz > space 1,070 Hz > receiver: > mark 2,225 Hz > space 2,025 Hz. > > https://en.wikipedia.org/wiki/Bell_202 > 1200 baud > mark: 1200 Hz > space: 2200 Hz > > Telefonleitungen generell nur das Frequenzband von 300 Hz bis 3400 Hz Ohne ein "Helferlein", wie den TCM3105 wird es deutlich komplexer. Und Duplex legt da noch eine ordentliche Schippe drauf. Aber es wird dich sicher keiner davon abhalten, es selbst einmal zu probieren, einen FSK-Modulator/Demodulator zu schreiben. (Alte) Appnotes dazu, findet man z.B. bei TI reichlich. Schoenen Sonntag
von R. M. (rmax) 16.01.2025 23:51 >Ich habe vor einigen Jahren das AudioLINK-Protokoll von Ei Electronics >analysiert, das in deren Rauchwarnmeldern (z.B. Ei650i) und anderen >Warngeräten verwendet wird, > .. > Falls Interesse besteht kann ich das bei > Gelegenheit mal in einen Artikel gießen. Leider habe ich Deinen Beitrag erst jetzt gelesen. Ich wäre sehr daran interessiert. Es muss nicht unbedingt ein Artikel sein. Ein paar Informationen wie Modulationsverfahren und Bitrate wären sehr interessant.
Daniel A. schrieb: > Habt ihr sowas schonmal gemacht? Disnayland Animatronics! Die wurden vor Jahrezhnten ppoer Audisosignal gesteuert.
Für den Use-Case des TO, nämlich Arduino mittels Ipad programmieren, frage ich mich warum es unbedingt Audio sein muss. Vor ein paar Monaten oder so hab ich Mal was gelesen wo einer an ein sehr kleines uC Board keinen extra Stecker zum Flashen machen wollte. Deshalb hat er eine Photozelle o.ä. auf Bottom gemacht. Mit der wurde das neue Programm empfangen. Sender war eine Website. Bin-File in der Site hochladen und der Monitor hat dann das Programm rausgetackert. Fand ich ganz elegant weil man kein Kabel und nichts brauchte. Finde aber den Artikel nicht mehr sonst hätte ich ihn hier Mal verlinkt.
:
Bearbeitet durch User
N. M. schrieb: > Für den Use-Case des TO, nämlich Arduino mittels Ipad programmieren, > frage ich mich warum es unbedingt Audio sein muss. > > Vor ein paar Monaten oder so hab ich Mal was gelesen wo einer an ein > sehr kleines uC Board keinen extra Stecker zum Flashen machen wollte. > Deshalb hat er eine Photozelle o.ä. auf Bottom gemacht. Mit der wurde > das neue Programm empfangen. > Sender war eine Website. Bin-File in der Site hochladen und der Monitor > hat dann das Programm rausgetackert. > Fand ich ganz elegant weil man kein Kabel und nichts brauchte. > Finde aber den Artikel nicht mehr sonst hätte ich ihn hier Mal verlinkt. Ja rechnen wir doch einmal nach. Fuer ein Bit wird man, da man die "Flackerfrequenz" und das Nachleuchten des Monitors nicht kennt, sicher 100 ms veranschlagen. Mit einem Startbit vorneweg, und einem Stopbit dahinter, braucht ein winziges Byte eine ganze Sekunde. In einer Stunde schafft so eine Mimik knapp 4 kByte. Das ist nun nicht elegant, das ist laecherlich... Haette "wo einer" ein wenig draufgehabt, haette er auf sein Board einen IRDA-Re(Trans-)ceiver getackert. Selbst die Normalausgabe schafft ohne Muehe 115 kbit/s und oft auch 230 kbit/s und mehr. Auf der "Website" war bestuemmpt auch noch Werbung, und das Ganze ist die uebliche Web-AI-Klautmoppelkotze. Edith: Alternativ gibt es z.B. von ST, RFID-Tag-ICs, die sich auch ueber I²C lesen und befuellen lassen. Und besonders gross, muss man die Antenne nicht machen.
:
Bearbeitet durch User
N. M. (mani) 20.01.2025 22:02 >Für den Use-Case des TO, nämlich Arduino mittels Ipad programmieren, >frage ich mich warum es unbedingt Audio sein muss. Hier kommt es auf die Menge der Daten und der Zeit an, in der programmiert werden soll. Die Programmierung des Attiny85 mit seinen 8kByte funktioniert sehr angenehm und flott. Der Attiny ist in unter 10 Sekunden programmiert. Das Handling ist fühlt sich fast angenehmer an als mit einem ISP. Motopick (motopick) >Haette "wo einer" ein wenig draufgehabt, haette er auf sein Board >einen IRDA-Re(Trans-)ceiver getackert. Selbst die Normalausgabe >schafft ohne Muehe 115 kbit/s und oft auch 230 kbit/s und mehr. Der Grund für die Entwicklung des TinyAudioBootloader war das Vorhandensein eines Audioausgangs an quasi jedem Gerät (PC, Laptop, Smartphone). Selbst mit einem MP3 Player konnte man programmieren (AttinyAudioBoot hat eine automatische Baudratenerkennung und bei entsprechender Kompressionseinstellung funktioniert das sogar). Heutzutage dürfte eine IRDA Schnittstelle eher selten zu finden sein. Noch besser wäre die akustische Datenübertragung, weil fast jedes Gerät Töne produzieren kann. Dort wird eine hohe Datenrate aber sehr schwierig bis unmöglich. Der Hardware- und Softwareaufwand steigt beträchtlich. >Alternativ gibt es z.B. von ST, RFID-Tag-ICs, die sich auch ueber >I²C lesen und befuellen lassen. Und besonders gross, muss man die >Antenne nicht machen. Eine interessante Idee. Dort stellt sich aber die Frage nach dem Softwareaufwand und die Möglichkeit einen Treiber zu schreiben. Beim AttinyAudioBoot war das Design-Ziel Hardwareaufwand und Kosten. Der Hardwareaufwand sind dort zwei Widerstände, der Koppelkondensator und die Anschlussbuchse. Teuer und mit viel Hardware kann jeder, kostengünstig und minimalistisch fast niemand.
Christoph M. schrieb: > N. M. (mani) > 20.01.2025 22:02 > >>Für den Use-Case des TO, nämlich Arduino mittels Ipad programmieren, >>frage ich mich warum es unbedingt Audio sein muss. > > Hier kommt es auf die Menge der Daten und der Zeit an, in der > programmiert werden soll. Die Programmierung des Attiny85 mit seinen > 8kByte funktioniert sehr angenehm und flott. Der Attiny ist in unter 10 > Sekunden programmiert. Das Handling ist fühlt sich fast angenehmer an > als mit einem ISP. > > Motopick (motopick) >>Haette "wo einer" ein wenig draufgehabt, haette er auf sein Board >>einen IRDA-Re(Trans-)ceiver getackert. Selbst die Normalausgabe >>schafft ohne Muehe 115 kbit/s und oft auch 230 kbit/s und mehr. > > Der Grund für die Entwicklung des TinyAudioBootloader war das > Vorhandensein eines Audioausgangs an quasi jedem Gerät (PC, Laptop, > Smartphone). Selbst mit einem MP3 Player konnte man programmieren > (AttinyAudioBoot hat eine automatische Baudratenerkennung und bei > entsprechender Kompressionseinstellung funktioniert das sogar). > Heutzutage dürfte eine IRDA Schnittstelle eher selten zu finden sein. > Noch besser wäre die akustische Datenübertragung, weil fast jedes Gerät > Töne produzieren kann. Dort wird eine hohe Datenrate aber sehr schwierig > bis unmöglich. Der Hardware- und Softwareaufwand steigt beträchtlich. Mich musst du da nicht ueberzeugen. Es ging mir darum festzustellen, dass ein generischer Computermonitor ein deutlich schlechteres Ausgabegeraet fuer Bitdaten ist. Die weitaus schnellere Alternative zur "Photozelle", verbunden mit einer einfachen schaltungstechnischen Handhabung, ist aber der IRDA-Transceiver. Ich habe vor vierzig Jahren fuer die Softwareentwicklung fuer einen Zilog Z8 einen EPROM-Emulator gebaut, der per Manchestercode geladen wird. Der braucht am Host eben nur ein Bit zur Anteuerung. Und man kann ihn auch von einem Taperecorder laden. Oder ueber ein Audiolineout. >>Alternativ gibt es z.B. von ST, RFID-Tag-ICs, die sich auch ueber >>I²C lesen und befuellen lassen. Und besonders gross, muss man die >>Antenne nicht machen. > > Eine interessante Idee. Dort stellt sich aber die Frage nach dem > Softwareaufwand und die Möglichkeit einen Treiber zu schreiben. > Beim AttinyAudioBoot war das Design-Ziel Hardwareaufwand und Kosten. Der > Hardwareaufwand sind dort zwei Widerstände, der Koppelkondensator und > die Anschlussbuchse. > Teuer und mit viel Hardware kann jeder, kostengünstig und minimalistisch > fast niemand. Ich kenne da Controller die u.a. von I²C booten koennen. :) Leider sind die I²2-RFIDs von ST nur in kleinen Groessen verfuegbar.
Christoph M. schrieb: > Eine interessante Idee. Dort stellt sich aber die Frage nach dem > Softwareaufwand und die Möglichkeit einen Treiber zu schreiben. Das geht mit den entsprechenden (I²C-)Interfacen recht einfach. Z.B. der Buspirate, der "Serial Analyzer" von Microchip, oder ein USB/I²C/2.4GHz-Link von Cypress. Davon gibt es sicher noch viele viele mehr. :) Frueher™ haette man das auch mit Bitwackeln am Parallelport machen koennen.
>Das geht mit den entsprechenden (I²C-)Interfacen recht einfach.
Ich meinte mit die SmartPhone Seite. Ich könnte mir vorstellen, dass die
Benutzung der RFID Schnittstelle des Smartphones nicht ganz einfach ist,
insbesondere wenn man ein eigenes Protokoll zur Programmierung eines
Mikrocontrollers fahren will.
Angehängte Dateien:
-
Bell103Orig_Spectrum.png
290 KB
Hier mal zurück zur Akustik. Im Anhang der nachgebildete Ton eines 300Baud Modems mit erst konstanter Bitfolge, dann alternierender Bitfolge und dann wieder konstanter Folge. Ergebnis: Das mit mit Audacity erstellte Spektrum sieht nett aus, aber man sieht die Frequenzen nicht. Das liegt natürlich an der zu lang gewählten Fensterlänge. Problem: wenn man die Fensterlänge sehr kurz wählt, ist die Frequenzauflösung zu niedrig. Weiß jemand, nach welchen Kriterien die damaligen Tonfrequenzen der Bell 103 Norm optimiert wurden?
https://de.wikipedia.org/wiki/Datasette Früher gab es bei den CDs auf Keys oder Keyboard - Heften auch eine Audio-Datenspur. (https://archive.steinberg.help/wavelab_elements/v9.5/de/wavelab/topics/writing_operations/audio_cd_writing_cd_extra_c.html) (https://de.wikipedia.org/wiki/Compact_Disc_Digital_Audio)
Angehängte Dateien:
Ich habe mir mal die Signale des Rauchmelders von Ei-Elektronik angeschaut: https://www.youtube.com/watch?v=7uf2WcxupBA Hier meine Analyse. Es ist quasi wie morsen: * Carrier Frequency 3kHz * Modulation: ON/OFF Keying * Low: duration 50ms, 25ms ON, 25ms OFF * High: duration 100ms, 50ms ON, 50ms OFF Die durchschnittliche Bitrate wäre also ca. 14 Baud.
Christoph M. schrieb: > Hier meine Analyse. Es ist quasi wie morsen: > * Carrier Frequency 3kHz Korrekt. > * Modulation: ON/OFF Keying Korrekt. > * Low: duration 50ms, 25ms ON, 25ms OFF > * High: duration 100ms, 50ms ON, 50ms OFF Das stimmt nicht ganz, was ich Dir neulich per PM geschickt hatte, war aber auch falsch, da hatte ich meine Aufzeichnungen nicht richtig gelesen. Die Bits sind manchester-codiert: Jedes Bit hat die gleiche Länge von 50 ms und besteht je zur Hälfte aus einer Pause und einem Pieps. Bei der 0 kommt zuerst die Pause, bei der 1 der Pieps. Nach meinem Verständnis wären das 40 Baud und 20 Bit/s. Zum Datenformat kann ich später noch was schreiben.
:
Bearbeitet durch User
R. M. (rmax) >Die Bits sind manchester-codiert: Jedes Bit hat die gleiche Länge von 50 >ms und besteht je zur Hälfte aus einer Pause und einem Pieps. Bei der 0 >kommt zuerst die Pause, bei der 1 der Pieps. >Nach meinem Verständnis wären das 40 Baud und 20 Bit/s. Super, vielen Dank. >PM geschickt hatte Oh, sorry, die geht momentan leider nicht mehr ..
Die Datenübertragungsrate beim Audio-Tracking von Smartphones wäre auch interessant: https://www.haptic.ro/defence-against-unwanted-audio-tracking-by-acoustic-cookies/
Christoph M. schrieb: > Der Grund für die Entwicklung des TinyAudioBootloader war das > Vorhandensein eines Audioausgangs an quasi jedem Gerät (PC, Laptop, > Smartphone). Ist aber seit Jahren im Rückzug begriffen. Apple hat damit angefangen, andere folgen mehr und mehr. IMHO ist es nur noch eine Frage der Zeit, bis man fast nirgendwo mehr einen analogen Line-Out hat.
Der LTC-Timecode passt in einen Audiokanal und kann 2400 Baud. https://en.wikipedia.org/wiki/Linear_timecode Kann man sehr einfach mit einem Mikrocontroller erzeugen. Grüße, Brt
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.