Forum: Digitale Signalverarbeitung / DSP / Machine Learning Daten per Audio übertragen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Daniel A. (daniel-a)


Lesenswert?

## 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?

von Frank K. (fchk)


Lesenswert?

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

von Owe W. (ow3)


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

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

von Daniel A. (daniel-a)


Lesenswert?

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.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

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

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?


von Motopick (motopick)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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.

von Frank O. (frank_o)


Lesenswert?

Frank K. schrieb:
> Du bist wahrscheinlich zu jung.

Macht ja nix, dann erfindet er nochmal den Akustikkoppler.
SCNR

von J. S. (engineer) Benutzerseite


Lesenswert?

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.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Daniel A. schrieb:
> Arduino per PWA über einen Audio

Der Cheepit Sparrow koennte das.

https://www.b-kainka.de/Sparrowbuch.html

von Florian (flori_n)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?


von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Rolf (audiorolf)


Lesenswert?

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.

von Roland F. (rhf)


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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!

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Christoph M. (mchris)


Angehängte Dateien:

Lesenswert?

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
von Detlef _. (detlef_a)


Lesenswert?

Mit diesem Ding

Beitrag "MSK Minimum Shift keying transceiver in C"

kann man 2400 Bit/s über einen Audiokanal übertragen.
Cheers
Detlef

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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).

von Christoph M. (mchris)


Lesenswert?

>kann man 2400 Bit/s über einen Audiokanal übertragen.
Passt das in die 1KB des Bootloaders ?

von Detlef _. (detlef_a)


Lesenswert?

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

von Motopick (motopick)


Lesenswert?

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".

von J. S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von R. M. (rmax)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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 Christoph M. (mchris)


Lesenswert?

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
von Motopick (motopick)


Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> siehe Artikel

Ist eine Korrektur nach so langer Zeit noch möglich?
C2 ist C1 und NF sind hoffentlich nF

von Motopick (motopick)


Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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
von Thomas (kosmos)


Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

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

von Motopick (motopick)


Lesenswert?

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 Christoph M. (mchris)


Lesenswert?

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.

von Benedikt L. (Firma: Dem Ben seine Leiche) (dembenseineleiche) Flattr this


Lesenswert?

Daniel A. schrieb:
> Habt ihr sowas schonmal gemacht?

Disnayland Animatronics! Die wurden vor Jahrezhnten ppoer Audisosignal 
gesteuert.

von N. M. (mani)


Lesenswert?

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
von Motopick (motopick)


Lesenswert?

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
von Christoph M. (mchris)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

>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.

von Christoph M. (mchris)


Angehängte Dateien:

Lesenswert?

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?

von Rbx (rcx)


Lesenswert?


von Christoph M. (mchris)



Lesenswert?

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.

von R. M. (rmax)


Lesenswert?

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
von Christoph M. (mchris)


Lesenswert?

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 ..

von Christoph M. (mchris)


Lesenswert?

Die Datenübertragungsrate beim Audio-Tracking von Smartphones wäre auch 
interessant:
https://www.haptic.ro/defence-against-unwanted-audio-tracking-by-acoustic-cookies/

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Bert (brt)


Lesenswert?

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

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
Noch kein Account? Hier anmelden.