mikrocontroller.net

Forum: HF, Funk und Felder Datenfunk: wav, was ist das?


Autor: Wiesel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir jemand sagen um welches Telegramm es sich hier handelt.
FSM, ZVEI und POCSAG scheiden hier aus, da kein Decoder darauf reagiert.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moment, ich analysiere das mal mit samplitude...

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hört sich nach AFSK an, es gibt 2 Frequenzen, die digital umgetastet 
werden, nämlich eine bei etwa 2kHz und eine bei etwa 1kHz.

Auf welcher Frewuenz hast du das mitgehört?

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab vielen Dank für die Infos.
War im 2m Band, keine BOS-Frequenz.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Baudrate ist relativ niedrig, so wie ich das jetzt sehen kann. Es 
wird irgendwas um die 150 Baud sein. Ein Bit dauert etwa 7ms, kann mich 
aber auch irren, es ist relativ schwierig, das auszuzählen, wenn man die 
verwendeten Frequenzen nicht genau kennt. Es könnten auch 300 Baud sein.

Vielleicht kann man ein altes Packet-Radio-Modem dazu bringen, das zu 
decodieren.
Einfach mal so eine Schaltung bauen:

http://service.alan-germany.de/CB/AE8000/Packet-Pl...

und an den Oszi anschließen.
Die ist zwar für 1200 Baud gedacht, der TCM 3105 ist ein FSK Modem von 
Texas Instruments, lässt sich aber auf andere Baudraten umkonfigurieren. 
Ich kann mir auch vorstellen, dass er niedrigere Baudraten, die 
ganzzahlige Teiler von 1200 Baud sind auch mit der 1200 Baud-Einstellung 
decodieret.

Hier noch das Datenblatt:
http://pdf1.alldatasheet.com/datasheet-pdf/view/28...

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

ich versuche das gerade auf Softwarebasis per Soundmodem
http://www.baycom.org/~tom/ham/soundmodem/

Das kann afsk, fsk, fskpsp pam psk newqpsk und p3d :)

Bekomme aber nur Buchstabensalat heraus, kann aber auch daran liegen,
dass das Signal nicht sauber ist. Kommt aus'm Kopfhörerausgang eines 
Scanners. Hilft hier ggf. solch ein Diskriminator? Frrequenz ist 150.250 
MHz.

Grüße und Danke
Christian

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besonders viel Information steckt auch nicht drin in dem File. Hättest 
du vielleicht eine Sequenz, bei der länger gesendet wird, also nicht nur 
kurz irgendwelche Steuerzeichen?

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Info:
Die Pakete werden von einem zivilen Movitalk 118 gesendet.
Das Ding soll per G2D senden, aber Decoder gibts dafür nicht, da keine 
Standarts existieren...

Wo setze ich am besten an, um aus dem Krach ASCII Zeichen zu bekommen?

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter es gibt auch größere Pakete, ich schau mal, ob ich eins einfangen 
kann.

Autor: Wiesel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist jetzt ein packet bei mit etwas mehr Daten.
Viel größer werden die dann auch nicht.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke, ich schau mir die mal eben an.

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab vielen lieben Dank Peter, bist wirklich eine große Hilfe für mich.
Und das um die Uhrzeit... Ich werd mich heut noch 3h Schlaf gönnen
und mich erstmal verabschieden.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, es handelt sich mit ziemlicher Sicherheit um AFSK, Frequenz0 = 
1200Hz, Frequenz1 = 1800Hz und während der Datenübertragung 1200 Baud. 
Der Header bzw. das Acknowledge ist wohl langsamer (150 Baud).

Laut Frequenzdatenbank ist das eine Taxifrequenz, ein Movitalk 118 hat 
ein eingebautes Modem für FMS, das spricht auch für die obigen Daten. 
Der Datenrahmen hält sich wohl an kein bekanntes AFU System, deswegen 
habe ich mit der Decodierung noch Probleme.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich dem Binäroutput von dem Softwaresoundmodem glauben soll, 
handelt es sich nicht um ASCII Zeichen, denn jedes ASCII Zeichen beginnt 
binär mit einer 0. Es gibt im Telegramm mit keiner Startposition eine 
lange Folge von Zeichen, die für eine ASCII-Decodierung in Frage kommen. 
Ich gehe davon aus, dass das Binärdaten sind, die eventuell sogar 
verschlüsselt worden sind. Oder das Programm kann die Daten nicht sicher 
decodieren, weil sie zu viel Rauschen enthalten.

Vielleicht finde ich noch eine bessere Möglichkeit, das audio zu 
decodieren, eventuell schreib ich schnell was für einen DSP.

Ich wollte eh schon immer mal FSK auf einem DSP demodulieren.

Viele Grüße,

Peter

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr beiden,

ich habe mir das gerade mal angehört: seid ihr euch sicher das es sich 
nicht einfach um FMS handelt? Das lange ist dann ein Datentelegramm. Den 
genauen Aufbau gibt es bei Wikipedia (Funkmeldesystem).


Martin

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FMS ist es definitiv nicht, dafür sind die Telegramme zu lang. Auch die 
Frequenz spricht dagegen. Ich tippe auf Taxi-Funk. Das man nichts 
sinnvolles decodieren kann, bedeutet m. E. nur, dass die Daten in 
irgendeiner Form verschlüsselt sind. Das kann im einfachsten Fall eine 
simple Verschachtlung der Daten sein.

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Guten Morgen, Du schläft wohl nie?
Ja, ich gehe davon aus, dass ich hier die Taxidaten höre.
Ein Blick ins Cockpit brachte das MT 118 zum Vorschein.
Google meinte, dass nur 2 Systeme verschlüsseln, Heedfeld und irgendwas 
anderes.
Die Übertragung hat sich eine Firma Namens Plettac vor zig Jahren 
ausgedacht,
ist jedoch 2003 Pleite gegangen. Dokus gibts keine im Netz.

Ich werd nochmal die AFSK Software-Modems mit deinen Parametern füttern,
mal schaub ob sie geprächiger werden. Ggf. hast du auch mit dem Rauschen 
Recht.
Da werd ich mal draussen eine Aufnahme machen und hoffe die Qualli ist 
besser.

@Martin Das war emine erste Überlegung, da das MT 118 in bestimmten 
Modell ein FSM Modem besitzt. Es gibt auch selche die FFSK sprechen...
Zumindest hat keiner der mir bekannten FSM Decoder etwas entschlüsseln 
können.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Data Carrier Detection funktioniert mit meinen Einstellungen - und 
wohl nur mit diesen - korrekt. Dass es ein FMS ist, glaub ich auch 
nicht, bei der Telegrammlänge, aber es würde sich anbieten das Modem mit 
der gleichen Einstellung zu fahren, wenn es das bereits im Gerät gibt. 
Und es spricht wohl alles dafür, dass es 1200Hz und 1800Hz sind, das 
habe ich mittlerweile auch phasengenau nachgeprüft in Samplitude.

Jetzt ist noch die Frage, wie das mit den Start und Stop Bits ist. Ein 
Startbit muss es geben, aber ist es 0 oder 1? Haben wir ein oder 2 
Stopbits, sind sie 0 oder 1?

Handelt es sich überhaupt um 8 bit Übertragung? Wenn ja, was ist es für 
eine Codierung?

Übrigens muss man bei der Software immer zwischen verschiedenen 
Ansichten (Projektname und Channel) wechseln, bevor die eingegebenen 
Daten auch richtig übernommen werden, ist wohl ein Bug. Im 
commandline-Fenster sieht man beim Öffnen vom Modem dann, ob die 
richtigen Einstellungen drin sind oder nicht.

>Du schläft wohl nie?

Bin erst 10 Std wach.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kennt eigentlich jemand einen AFSK Demodulator mit Soundkarteneingang, 
der nur die Rohdaten auswirft? Bei dem Programm, mit dem ich jetzt 
arbeite, kann man die Daten nicht aus dem Fenster rauskopieren oder 
irgendwie abspeichern.

Autor: Peter Diener (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier könnt ihr mal anschauen, was ich aus dem langen Telegramm aus 
daten2.wav bisher gemacht habe.
Ich hab es zunächst um einen Faktor 2500 saturiert verstärkt, dann die 
linke Spur auf 8 bit runtergesampled und im unsigned 8 bit PCM als 
Rohdaten in das File clipped.raw geschrieben. Mit einem Hexeditor (HxD) 
kann man jetzt die Waveform digital sehen. FF bedeutet, waveform ist 
high, 00 bedeutet, waveform ist low. Jetzt muss man die Anzahl der 
Samples, die high sind und die der Low-Samples abzählen  und abschätzen, 
um welche Frequenz es sich jeweils handelt. Das ganze asynchron auf 1200 
Baud aufsynchronisieren und dann die binären Rohdaten der FSK-Modulation 
erstellen.

Bin noch ne Weile beschäftigt, bis es dann die Daten gibt, so wie sie 
vor dem Modem waren...

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WOW, Peter ich bin echt froh Dich hier getroffen zu haben.
Um solche Erkenntnisse zu erziehlen hätte ich Monate benötigt!
Ich werde noch ein paar große möglichst rauschfreie Mitschnitte 
besorgen.
Wir aber sicher erst heute Abend was werden, wenn die Familie genug von 
mir hat :)

Autor: Peter Diener (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt gibts weitere Daten.
Ich habe gerade ein Programm geschrieben, das aus den Audiorohdaten 
zunächst ein menschenlesbares Testfile erzeugt, in dem highSamples mit 1 
und lowSamples mit 0 codiert werden. Diese Datei heißt dann binary.txt

Aus der binary.txt wird anschließend bestimmt, wie lange die Halbwellen 
des Audiosignals gedauert haben, es wird für jede Halbwelle eine Zahl in 
eine Datei geschrieben. Die Zahlen werden mit Strichpunkten getrennt. 
Diese Lengencodedatei heißt lengthcodefile.txt

Und hier ist das Programm.

Ihr müsst es im gleichen Ordner ausführen, wo sich Clipped.raw befindet.

Aus der Lauflängencodierung werde ich jetzt die FSK-Demodulation 
erzeugen.
Dauert aber noch etwas...

Autor: Wiesel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab hier noch 2 große Telegramme...

Autor: Wiesel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und das Zweite...

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde mal versuchen einen Diskriminatorausgang anden Scanner zu 
löten, nicht dass all deine Bemühungen dank eines undeutlichen Signals 
umsonst sind...

Autor: Peter Diener (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt kann das Programm die Frequenz der Audiofunktion schätzen. Es 
wird eine Datei demodulation.txt erzeugt, dabei steht jede Ziffer für 
ein Sample, also eine 1/44100 Sekunde. Eine 1 bedeutet hohe Frequenz, 
also 1800Hz, eine 0 bedeutet niedrige Frequenz, also 1200Hz.

Dieses File muss nun von einer Art Softwareuart synchronisiert und 
decodiert werden.

Mal sehen, ob ich das auch hinbekomm...

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter, ich hoffe Du schläft nun endlich :)
Ich bekomme am 31. einen Diskriminatorausgang und eine bessere Antenne.
Damit werde ich mich dann nach draußen und näher zur Quelle begeben und 
dir dann ein sauberes Signal liefern.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich versuch dann mal eine bessere Demodulation zu basteln, das was 
ich jetzt habe, liefert nämlich einfach nur Unsinn. Die Bits sind viel 
zu kurz, teilweise nur ein Drittel der Länge, die sie mit 1200 Baud 
haben sollten, außerdem sind lange Zeiten nur Einser drin, also über 
mehrere Zig Bit, das verwundert mich etwas.
Es war eben wohl keine so gute Idee, die Frequenz nur durch Messen der 
Zeit der Halbwellen zu bestimmen...
Also schreib ich eben doch einen richtigen, linearen Demodulator.
Außerdem möchte ich, dass mein Programm direkt die Audiofiles 
verarbeiten kann, ohne, dass ich sie vorher mit samplitude bearbeiten 
muss.
Das oben genannte soundmodem kann leider die Audiofiles nicht richtig 
einlesen, ich bekomme immer Fehler, dass nicht alle Chunks gelesen 
werden konnten.

Viele Grüße,

Peter

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier einen schönen Thread gefunden, wo negaH ein paar 
konstuktive Ansätze liefert. Zwar für Delphi gedacht, aber sicher auch 
auf andere Sprachen anwendbar. 
http://www.delphipraxis.net/topic91803,0,asc,0.html

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde parallel zu deiner Entwicklung das ganze versuchen in Delphi 
umzusetzen, hab zwar seit ein paar Jahren nichts mehr damit gemacht, 
aber ich komm da schon wieder rein. Im ersten Schritt werde ich mir die 
Samples aufarbeiten, die per wav oder Soundkarte reinkommen.

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist kein Problem, ich hab auch Delphi. Ich werds mir mal bei 
Gelegenheit ansehen, hab nur im Moment etwas wenig Zeit.

Guten Rutsch in neue Jahr,

Peter

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

ich hab mit viel googlen und copy&paste das Programm inzwischen soweit, 
dass mir die 44kHz Samples in'nem Buffer vorliegen. Verarbeiten kann ich 
den Soundkarteninput und wav Dateien. Nun müßen daraus Nullen und Einsen 
@ 1200 Baud werden. Da hoffe ich mal, dass mir obiger Link helfen wird. 
Der Code von negaH soll wesentlich efizienter sein als z.B. FFT.

Dir wünsche ich ebenfalls einen guten Rutsch und nochmal vielen Dank für 
deine kompetente Hilfe!

Christian

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manchester  Halbbitformat?

H/L=1 L/H=0 ?

Autor: Wiesel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gesundes Neues euch allen!

Angestimmte Antenne und einen Diskriminatorausgang hab ich jetzt 
rangebastelt. Das Ergebnis hier als wav File.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klingt wie PSK31

Autor: Martin (Gast)
Datum:
Angehängte Dateien:
  • preview image for 1.JPG
    1.JPG
    33,6 KB, 268 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mal diskdaten.wav mit FMS grafisch verglichen: oben diskdaten, 
unten FMS.


Martin

Autor: Martin (Gast)
Datum:
Angehängte Dateien:
  • preview image for 2.JPG
    2.JPG
    66,5 KB, 263 Downloads

Bewertung
0 lesenswert
nicht lesenswert
und nochmals ein ganzes FMS Telegramm: oben diskdaten und unten FMS - 
komisch das die Länge gleich ist.
diskdaten ist übrigens immer noch recht verrauscht.
@Wiesel: aus welchem Bundesland kommst du bzw willst du auch die Stadt 
verraten wo du das aufgenommen hast?


Martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

eins muss noch gesagt sein: auch ich kann es nicht als FMS direkt 
dekodieren - das kann aber passieren wenn CRC und die Bit CRC nicht 
direkt stimmt - soll heissen wenn die Modulation und Telegrammlänge 
gleich ist aber ein anderer Inhalt/ Aufbau benutzt.


Martin

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

deine Bilder bestätigen meinen Versacht, dass die Taxis das integrierte 
FMS-Modem in deren Geräten nurzen. Vielen Dank dafür.
Komme aus Sachsen / Chemnitz.
Woher hast du solch lange FMS-Telegramme? Das Telegramm in diskdaten 
geht doch knapp eine Sekunde, die FMS Nachrichten bei BOS hingegen nur 
einen Bruchteil.
Die Modulation ist mit FSM identisch, jedoch hat der Zeichensatz / das 
Protokoll damit nichts zu tun. Ich versuche gerade einen FMS Decoder zu 
bauen, der mir die Rohdaten gibt. Leider spucht dieser bei jedem 
abspielen ein anderes Ergebnis aus, bleibe aber dran.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wiesel,

FMS kann auch sehr lang sein ;-) Es gibt einmal die kurzen Stati der 
Fahrzeuge bzw der Leitstelle (zB Einsatz übernommen). Die haben eine 
Länge von 55ms (18Bit + 48Bit = 66Bit/ 1200baud = 0,055s). Dann werden 
da noch richtige Texte übertragen: Dauer max ca 1.5s.
Das deckt sich ziemlich mit dem was du dort unter diskdaten aufgenommen 
hast: erst ein kurzes Telegramm ca 55ms und dann ein längeres von 1.5s.
Komisch nur das die "gängigen" Dekoder für FMS damit nichts anfangen 
können.

Martin

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

wäre es möglich, dass du mir das abgeänderte, lauffähige Delphiprojekt 
mal schickst? Ich habe es bisher nur in C++ geschafft, audiosamples von 
einer Soundkarte einzulesen. Es würde mich interessieren, wie das in 
Delphi funktioniert.
Mit der Decodierung der waves bin ich bisher nicht weitergekommen, ich 
bekomme einfach noch keinen sinnvollen Rohdatenstrom zusammen.

Hauptproblem ist das Erkennen des ersten Bits (Startbit) von jedem Byte, 
dafür habe ich noch keinen vernünfitigen Algorithmus.

Viele Grüße,

Peter

Autor: Wiesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

klar, kann ich machen.
Ich verwende die bass.dll um mit der Soundkarte zu kommunizieren,
ein Tutorial findest du unter 
http://www.michaelgaedtke.de/SubMenu_Messen/BASS-T...

Meine Sourcen kann ich dir per Mail schicken.

Grüße
Christian

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

wenn du dich anmeldest, hast du Zugang zu meiner Emailadresse. Aus 
Spamgründen möchte ich sie hier nicht direkt hinschreiben. Die BassDLL 
erscheint mir aber auch schon sehr hilfreich, ich brauche eventuell 
keinen zusätzlichen Code, außer du hast bei der Decodierung schon 
erhebliche Fortschritte erzielt.

Viele Grüße,

Peter

Autor: Christian S. (daswiesel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

zur Decodierung kannst du dir mal die C++ Sourcen eines FMS-Decoders 
anschaun. http://monitord.de/?article=5
Die MonitorModuleFMS.cpp ist sehr interessant, jedoch ohne C-Kenntnisse 
schlecht zu interpretieren.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, das werd ich mir mal ansehen.

Peter

Autor: Jan Dergehtkeinenwasan (jw1hal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts hier neue Erkenntnisse?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jan,

die Diskussion ist irgendwann eingeschlafen. Aber schau dir das mal an:
http://sourceforge.net/projects/taxidecoder/


Martin

Autor: Jan Dergehtkeinenwasan (jw1hal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da werden zwar Nullen und Einsen ausgegeben, aber ansonsten wüsste ich 
nicht, wie man damit die eigentlichen Nachrichten lesen kann. Hmmm ...

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Bin durch Zufall auf Eure Diskussion gestoßen.
Hab hier zwei Datenfunkdisplays von Heedfeld; ein HE4000 und ein 
HE5000S. Aufgrund einer Beschreibung eines Funkamateurs eines anderen 
Forums habe ich mit einem Universaldemudolator das PTT-Telegramm in 
Einsen und Nullen datgestellt. Es ist der selbe Aufbau, wie 
ZVEI-Digital, welches in BOSCH Funkgeräten zu finden ist. Bis auf eine 
Telegrammart, die das HE5000S aussendet kann ich das gesendete leider 
nicht in den anderen Funkgeräten zur Anzeige bringen.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

was für einen Universaldemudolator hast du denn benutzt?


Martin

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin!


Die Software heisst HOKA GOLD.
Hab noch etwas herumexperimentiert. Der Grund, warum meine BOSCH Geräte 
das Telegramm nicht anzeigen liegt daran, das die CRC anders berechnet 
wird.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.