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.
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.
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.
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.
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.
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.
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.
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.
... 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.
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.
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.
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.
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.
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.
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 ?
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".
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.
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.
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:
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:
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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?
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.
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 ..
Zum Datenformat kann ich später noch was schreiben.
Und dann geriet es wieder in Vergessenheit. Weil mich heute nochmal jemand drauf angesprochen hat, haue ich es jetzt einfach mal raus. Die physische Ebene war ja schon gegeben (3 kHz, Manchester mit 40 Baud, 1=on/off, 0=off/on), hier also noch das Datenformat für den Ei650i:
