mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MSP430 Probleme mit UART- Daten erkennen


Autor: Armin G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich stehe vor folgendem Problem. Ich habe hier zwei MSP430. Diese 
kommunizieren miteinander per rs232, allerdings nicht direkt, sondern 
dazwischen sind zwei Funmodule.

Die Kommunikation an sich funktioniert schon prima. Nun wollte ich 
einmal testen, wie schnell ich Daten übertragen kann der auch wieviel 
Daten auch richtig ankommen. Dazu lasse ich den einen Mikrocontroller 
einfach ununterbrochen, so schnell wie eben geht, 0xFF senden. Der 
zweite Controller soll diese Daten empfangen und zählen. Wenn ein 0xFF 
empfangen wird, wird eine Variable hochgezählt, sollte etwas anderes 
empfangen werden, wird eine andere Variable raufgezählt. Damit will ich 
halt richtige von falsch empfangene Daten trennen. Beim Empfänger läuft 
ein Timer mit. Alle 10 Sekunden wird die Zählung gestoppt und die Zahlen 
auf einem Display ausgegeben.. Danach startet das wieder für 10 
Sekunden. Das Programm läuft auch soweit.

Ich habe nur das Problem, dass anscheinend die 0xFF nicht ekannt werden 
oder auch andere Daten, wenn ich mal etwas anderes sende. Die Daten 
werden immer als falsch gezählt. Die Daten werden aber richtig gesendet. 
Das habe ich mit Hyperterminal getestet, da wird immer fleißig 0xFF 
angezeigt. Somit muss meiner Meinung nach der Fehler irgedwo im 
Empfängerprogramm liegen, denke ich.

Wäre klasse, wenn mir da jemand vielleicht auf die Sprünge helfen 
könnte.

Ich habe hier einmal meine ISR des UART:
#pragma vector=UART0RX_VECTOR
__interrupt void usart0_rx (void)
{                
    if(StringReady == 0)
    { 
        if(RXBUF0 == 0xFF)         
        {
            if(zaehl < 50000)
                zaehl++;
            else
                zaehl_next++;
        }/* if(RXBUF0 == 0xFF)) */
        else
        {
            bad++;
        }
    }/* if(StringReady == 0) */
}/* __interrupt void usart0_rx (void) */

Wie gesagt, wäre klasse, wenn mir da jemand auf die Sprünge helfen 
könnte.
Wenn ch noch Code posten soll, einfach mal bescheid sagen.

Grüße Armin

Autor: Jörg S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann setz doch mal einen Breakpoint in der ISR und schau was im Buffer 
wirklich drin steht.

Autor: Armin G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ditsch Hätte ich mal selbst drauf kommen können. Da hab ich wohl ein 
Brett vorm Kopf gehabt. ;)

Wie es scheint, werden die Zeichen einzeln beim Empfänger eingelesen. 
Wenn ich also 0x45 z.B. senden lasse, steht beim Empfänger im Buffer 
immer 0, x, 4 oder 5. Die Zeichen werden also alle einzeln erkannt. Dann 
ist ja auch klar, dass die Zeile  " if(RXBUF0 == 0x45) " keine wirkung 
hat, bzw. die Bedingung nicht erfüllt ist.

Nun ist mir aber allerdings noch keine Lösung dazu in den Sinn gekommen.

Hat jemand vielleicht eine Idee, wie ich die Daten senden und beim 
Empfänger die empfangen Daten auswerten, also zählen kann. So wie ich es 
bisher versucht habe scheint es ja nicht zu funktionieren, da in dem 
Buffer nicht die kompletten gesendeten Daten drin stehen, sondern die 
einzelnen Zeichen.

Wäre klasse, wenn jemand eine Idee oder einen Vorschlag hat.

Vielen Dank.

Grüße
Armin

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm? Wie sieht denn deine Sendefunktion aus?
Brauchst doch nur TXBUF0 = 0xFF; machen, dann sendet der genau 1 Zeichen 
(0xFF, 255).
Mir scheint, du hast da was mit printf() drinne.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Armin G. wrote:
> ich stehe vor folgendem Problem. Ich habe hier zwei MSP430. Diese
> kommunizieren miteinander per rs232, allerdings nicht direkt, sondern
> dazwischen sind zwei Funmodule.

Funkmodule mögen in der Regel keine DC-Signale.
Deshalb wird üblicher Weise Manchester Code gesendet (0-1 bzw. 1-0 
Paare). Diesen muß man aber in SW erzeugen und dekodieren, mit der UART 
geht das nicht.

Im Hobbybereich sieht man manchmal nen ähnlichen Code über die UART. Bei 
ungestörter Übertragung scheint er gleich gut wie Manchester zu sein.

Bei Störungen kommt er aber leicht aus dem Takt und synchronisiert nur 
schwer.
Grund ist, daß nur auf das Startbit synchronisiert werden kann und nicht 
auf jedes Bit wie bei Manchester.
Bei Störungen kann also leicht jede 1-0 Flanke als Startbit wirken und 
dann ist die Synchronisation weg und es kommt nur Müll beim Empfänger 
an.

UART ist also generell wesentlich störempfindicher als Manchester.

Ein anderer neben Manchester gebräuchlicher Funkcode ist 
Frequenzumtastung (1,2/2,4kHz).


Peter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger (peda)

>Funkmodule mögen in der Regel keine DC-Signale.
>Deshalb wird üblicher Weise Manchester Code gesendet (0-1 bzw. 1-0
>Paare). Diesen muß man aber in SW erzeugen und dekodieren, mit der UART
>geht das nicht.

Naja, man kann auch per UART eine gleichstromfreies Signal erzeugen, 
einfach jedes Byte in Nibbles zerhacken und immer normal und invertiert 
in einem Byte senden.

>Bei Störungen kommt er aber leicht aus dem Takt und synchronisiert nur
>schwer.
>Grund ist, daß nur auf das Startbit synchronisiert werden kann und nicht
>auf jedes Bit wie bei Manchester.

Man muss aber zwischen Modulation/Demodulation im Funkmodul und 
Zeichenerkennung im Controller unterschieden.

>Ein anderer neben Manchester gebräuchlicher Funkcode ist
>Frequenzumtastung (1,2/2,4kHz).

AHHHH! Bitte mal nicht Modulation mit Kodierung in einen Topf werfen!

MfG
Falk

P.S. So einen Test macht man aber nicht mit konstanten Mustern sonden 
Pseudozufallsfolgen, meist mit LFSR generiert.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

> Naja, man kann auch per UART eine gleichstromfreies Signal erzeugen,
> einfach jedes Byte in Nibbles zerhacken und immer normal und invertiert
> in einem Byte senden.

Das Senden ist überhaupt kein Problem, sondern das Empfangen!
Die UART kann nicht auf ein Bit neu synchronisieren.

> Man muss aber zwischen Modulation/Demodulation im Funkmodul und
> Zeichenerkennung im Controller unterschieden.
...
> AHHHH! Bitte mal nicht Modulation mit Kodierung in einen Topf werfen!

???

Von Modulation war nirgends nie die Rede!

Es geht immer nur um die Kodierung/Dekodierung der digitalen Daten.
Frequenzumtastung wurde gerne beim Kassettenrekorder als Datenspeicher 
verwendet, weil sie polungsunabhängig ist.
Manchester besteht aber auch aus 2 Frequenzen.

Wie nun die Funkgeräte dieses Signal auf den Träger modulieren (AM, FM), 
ist ne völlig andere Baustelle.


Peter

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger (peda)

>Das Senden ist überhaupt kein Problem, sondern das Empfangen!
>Die UART kann nicht auf ein Bit neu synchronisieren.

Schon klar, aber es braucht immer zwei zum Tango tanzen. UNd wenn der 
Sender ein gleichstromfreise Signal sendet (nit invertierten Nibbles), 
hat's der Empfänger leicher (genauer der Funkempfänger).

>Von Modulation war nirgends nie die Rede!

DOCH! DU hast davon in verdrehter Weise gesprochen!

"Ein anderer neben Manchester gebräuchlicher Funkcode ist
Frequenzumtastung (1,2/2,4kHz)."

Funkcode (Kodierung) und Frequenzumtastug (Frequenzmodulation, digital 
als FSK bekannt)

>Es geht immer nur um die Kodierung/Dekodierung der digitalen Daten.
>Frequenzumtastung wurde gerne beim Kassettenrekorder als Datenspeicher

Und schon wieder haust du die zwei Sachen in einen Topf.
Peter, lass dir einfach mal sagen, dass Kodierung und Modulation zwei 
verschiede Dinge sind. Und NEIN, der Unterschied ist KEINE akademische 
Sache.

>verwendet, weil sie polungsunabhängig ist.

>Manchester besteht aber auch aus 2 Frequenzen.

Für so einen Satz würdest du als Student dir eine schallende Ohrfeige 
vom Professor einfangen. Zu Recht! Manchesterkodierung hat mit 
Frequenzmodulation erstmal GAR NICHTS zu tun.

>Wie nun die Funkgeräte dieses Signal auf den Träger modulieren (AM, FM),
>ist ne völlig andere Baustelle.

Ja, eben. Nur du vermischst es unzulässig!

ManchesterKODIERUNG = Kodierung
AM/FM = Modulation

MFG
Falk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man, Du stellst Dich heute aber auch an.

Denk dir mal die Modulation weg, die ist hier völlig fehl am Platze und 
außer Dir hat nie jemand davon geredet.

Wenn Du am Klavier sitzt und 2 verschiedene Töne spielst, ist das noch 
lange keine Modulation.

Erst wenn diese NF auf den Sender geht, wird die HF damit moduliert.


So und nun zurück zur Kodierung:

Sowohl Manchester als auch Frequenzumtastung bestehen aus genau 2 
Frequenzen (gibs mal auf nen Spektrumanalysator).

Bei Manchester ist die Datenlänge immer konstant.
1*f entsteht bei wechselnden Bits, 2*f bei aufeinander folgenden 
gleichen Bits.

Bei Frequenzumtastung ist ein Bit halb so lang wie das andere, weil pro 
Bit eine Periode mit 1*f oder 2*f gesendet wird.


Daß jedes Signal (NF, digital) aus unterschiedlichen Frequenzen besteht, 
hat aber auch garnichts mit Modulation zu tun, das ist schlichtweg die 
Information.


Peter

Autor: Armin G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

erstmal wow, eine Menge Beiträge.

Vielleicht sollte ich einmal erwähnen, dass ich XBee-Module von 
Maxstream verwende.


Nun mal zu dem Beitrag von  Christian Richter:

Meine bisherige Sendefunktion sah so aus:
void SendUSART0(char* str)       // Einen String über die serielle Schnittstelle 
{                                // (USART0) senden
  while (*str != 0)
  {
    // Warten, bis USART0 TX-buffer sendebereit
    while ((!(IFG1 & UTXIFG0))  || ((P3IN & 0x02) == 1));   
    TXBUF0 = *str++;
  }
}/* void SendUSART0(char* str) */

Diese Funktion habe ich dann in einer Enlosschlefe mit 
"SendUSART0("0xFF");" aufgerufen. Da Lag wohl dann auch ersteinmal der 
Fehler, da die Zeichenkette dann ja Zeichen für Zeichen gesendet wurde, 
wenn ich das richtig sehe. Somit konnte der empfangende Controller auch 
kein 0xFF erkennen, weil ja für jedes einzelne Zeichen ein Interrupt 
ausgelöst wird.
Mit
TXBUF0= 0xFF;
wird nun wirklich 0xFF gesendet und der Empfänger detektiert das auch 
als solches und zählt dann eben wie oft es in einer gewissen Zeit 
empfangen wird.
Somit empfange ich doch quasi mit jedem 0xFF 8 Bit oder sehe ich das 
falsch!?



Nun aber eine weitere Frage. Wenn ich das mit dem Manchester-Code usw. 
in den ganzen Beiträgen lese, stellt sich mir eben die Frage, ob das was 
ich hier versuche, also 0xFF senden und für eine gewisse Zeit zählen wie 
oft es ankommt, um herauszufinden, wie schnell die Übertragung ist, 
überhaupt diesen Zweck erfüllt.
Im Moment habe ich die Funkmodule und die Controller auf eine Baudrate 
von 56700 eingestellt und möchte einfach die Übertragungsrate ermitteln. 
Im Moment stehen die Module auch direkt nebeneinander. Später soll die 
Entfernung natürlich vergrößert werden, um dann auch wieder zu sehen, 
was dann noch am Empfängermodul ankommt.

Bin ich da mit meinem Versuch auf dem richtigen Weg oder muss man das 
ganze doch anders bewerkstelligen.

Vielen Dank für die vielen Antworten erst einmal.

Wäre klasse, wenn ihr mir da weiterhin auf die Sprünge helfen könntet.

Grüße Armin

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger (peda)

>Man, Du stellst Dich heute aber auch an.

Kaum. Du meinst mal wieder die Weisheit erfunden zu haben.

>Denk dir mal die Modulation weg, die ist hier völlig fehl am Platze und
>außer Dir hat nie jemand davon geredet.

Schon wieder Irrtum. DU hast davon angefangen.

"Ein anderer neben Manchester gebräuchlicher Funkcode ist
Frequenzumtastung (1,2/2,4kHz)."

>Wenn Du am Klavier sitzt und 2 verschiedene Töne spielst, ist das noch
>lange keine Modulation.

Geh mal davon aus, dass du einem studierten NAchrichtentechniker nicht 
unbedingt erklären musst, was Modulation ist.

>Erst wenn diese NF auf den Sender geht, wird die HF damit moduliert.

Irrtum!

>So und nun zurück zur Kodierung:

>Sowohl Manchester als auch Frequenzumtastung bestehen aus genau 2
>Frequenzen (gibs mal auf nen Spektrumanalysator).

AHHHHH! Ich protestiere aufs Entschiedenste! Manchesterkodierung hat mit 
Frequenzen REIN GAR NICHTS zu tun!

>Bei Manchester ist die Datenlänge immer konstant.
>1*f entsteht bei wechselnden Bits, 2*f bei aufeinander folgenden
>gleichen Bits.

Käse. Du vermischt FSK mit Manchester, mal wieder.

>Bei Frequenzumtastung ist ein Bit halb so lang wie das andere, weil pro
>Bit eine Periode mit 1*f oder 2*f gesendet wird.

Im diesem speziellen Fall, dass F2 = 2*F1. Das ist aber Sonderfall.

>Daß jedes Signal (NF, digital) aus unterschiedlichen Frequenzen besteht,
>hat aber auch garnichts mit Modulation zu tun, das ist schlichtweg die
>Information.

Peter, du haust schlicht und ergreifend die Begriffe unsauber 
durcheinander.

Mancasert ist eine KODIERUNG, dier VOLLKOMMEn unabhängig von 
irgendwelcher Modulation passiert, egal ob FSK, Am, weissderGeier.

Recherchier mal im Netz zum Thema Modulation und Kodierung und OSI 
Schichtenmodell. Auch Du kannst ab und zu noch was lernen.

MfG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Armin G. (Gast)

>Nun aber eine weitere Frage. Wenn ich das mit dem Manchester-Code usw.
>in den ganzen Beiträgen lese, stellt sich mir eben die Frage, ob das was
>ich hier versuche, also 0xFF senden und für eine gewisse Zeit zählen wie
>oft es ankommt, um herauszufinden, wie schnell die Übertragung ist,
>überhaupt diesen Zweck erfüllt.

Nein. Dein Ansatz taugt wenig. Denn deine Funkmodule haben ja in 
Richtung Controller einen normalen RS232-Anschluss. Und wenn da kein 
Handshake erfolgt, dann kannst du mit vollen 57k6 Daten reinpusten, und 
es werden auch die vollen 57k2 wieder rauskommen. Die Frage ist, wie 
sauber die Funkmodule die Daten dann übertragen. Um das zu messen musst 
du eine Bit Error Rate Messung durchführen. Stichwort BERT. Dazu 
erzeugst du eine Pseudozufallsfolge. Der Empfänger synchronisiert sich 
drauf, erzeugt sie parallel und vergleicht die real empfangenen Bytes 
mit den vorausberechneten. Bei Abweichungen hat man Bitfehler, logisch. 
Dazu gabs vor kurzen einen anderen Thread. Stichwort LFSR bzw durch 
Schreibfehler LSFR.

Beitrag "LSFR was ist das überhaupt?"

MfG
Falk

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Xbee Module arbeiten doch mit ZigBee und darunter mit IEEE802.15.4 
und darunter mit DSSS oder sowas, also musst du dir um Modulation und 
sowas gar keinen kopf machen. Das machen alles die Module, incl. 
CRC-Prüfung, Retransmits usw.

Autor: Armin G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

>Die Xbee Module arbeiten doch mit ZigBee und darunter mit IEEE802.15.4
>und darunter mit DSSS oder sowas, also musst du dir um Modulation und
>sowas gar keinen kopf machen. Das machen alles die Module, incl.
>CRC-Prüfung, Retransmits usw.

Was heißt das nun für mich und mein Problem der mein Vorhaben?

Um das ordentlich umzusetzen, muss ich das doch schon mit LFSR machen, 
um eine "zufällige" Bitfolge zu bekommen, welche dann ausgewertet wird!?


Grüße Armin

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie das genau bei den XBee Modulen ist, weiß ich nicht, aber du musst ja 
auch eine Info bekommen, ob das aktuelle Datenpaket jetzt beim Empfänger 
angekommen ist. Erst wenn du die hast, kannst du ein weiteres schicken. 
Eventuell machen die das über die Handshake-leitungen, dann kannst du 
das mit deiner Methode ausmessen, denn dann hast du die wirkliche 
Übertragungsrate durch alle OSI-Schichten hindurch (is bei ZigBee eh zum 
Kot*** wenig).

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

>>Bei Manchester ist die Datenlänge immer konstant.
>>1*f entsteht bei wechselnden Bits, 2*f bei aufeinander folgenden
>>gleichen Bits.
>
> Käse. Du vermischt FSK mit Manchester, mal wieder.

Sorry, wußte nicht, daß Du noch nie Manchester gesehen hast, also:

Bei Manchester ist die Richtung der Flanke das Bit. Hast Du wechselnde 
Bits, hast Du auch nur eine Flanke und damit 1*f.
Hast Du gleiche Bits, muß eine Hilfsflanke eingefügt werden, voila: 2*f.


>>Bei Frequenzumtastung ist ein Bit halb so lang wie das andere, weil pro
>>Bit eine Periode mit 1*f oder 2*f gesendet wird.
>
> Im diesem speziellen Fall, dass F2 = 2*F1. Das ist aber Sonderfall.

Das stimmt, man kann auch andere Frequenzverhältnisse verwenden.
1:2 hat aber den Vorteil, daß es sich besonders leicht digital Kodieren 
und De-Kodieren läßt.


In der Tat sind aber die Begriffe Kodierung und Modulation synonym, d.h. 
es gibt keine exakte Trennung.
Beide verändern das Signal, um bestimmte Eigenschaften zu erzielen unter 
Beibehaltung der Information.

Landläufig spricht man von Kodierung bei digitalen Signalen und von 
Modulation bei analoger Verarbeitung.
Daher kommt es auch daß bei Festplatten beide Begriffe gleich verwendet 
werden, die Signale sind digital, aber das Schreiben und Lesen erfolgt 
analog.

Auch den Tonwahlkode beim Telefon kann man genausogut als Modulation 
bezeichnen.

Hättest Du also gesagt, digitale Kodierungen (z.B. Manchester) sind auch 
Modulationen, hätte ich das gelten lassen müssen.


Umgekehrt kann man die HF-Modulation im Sender auch als Kodierung 
bezeichnen.
Das NF-Signal ist darin zwar vorhanden, aber kodiert, man kann es nicht 
mehr direkt über einen Lautsprecher wiedergeben.
Es muß erst demoduliert (dekodiert) werden.

Auch das Stereosignal wird im Sender moduliert, im Empfänger aber 
dekodiert (Stereo-Dekoder).


Peter

Autor: Armin G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also wie es scheint, ist es schon sinnvoll eine Bitfolge zu senden, die 
beim Sender und Empfänger bekannt ist.

Beim Senden nutze ich Flow-Control, also ich sende nur Daten vom 
Controller an das XBee-Modul, wenn der Buffer des Moduls auch frei ist, 
damit dieser nicht überläuft.

Beim Empfänger lasse ich das XBee-Modul die Daten einfach ohne Kontrolle 
an den Controller senden, da dieser allemal schnell genug sein sollte.

Das Problem ist nun, dass es sein kann, dass Daten verloren gehen. Wenn 
z.B. der Empfangbuffer des Empfängermoduls voll ist, weil man z.B. doch 
Hardware-Flowcontrol nutzt und der Controller dem Modul sagt, dass er 
erstmal keine Daten haben will oder kann, das Sende-Modul aber weiter 
sendet, gehen die Daten verloren, weil der Empfangs-Buffer ja voll ist.

Wenn ich nun zähle, wieviel ankommt, dann hätte man zwar die 
Übertragungsrate, weil man ja weiß, wieviel in bestimmter Zeit 
angekommen ist, aber man hat gar keine Aussage, ob da nicht was fehlt, 
weil es bringt ja nix eine super Übertragungsrate zu messen, wenn aber 
unterwegs die hälfte verloren geht.

Ich hoffe, dass ich das so alles richtig verstanden habe. Ich werde mich 
dann glaube ich doch einmal mit LFSR usw. auseinandersetzen müssen....

oder habe ich da was total falsch verstanden bei den ganzen Anregungen?

Vielen Dank erstmal!


Grüße Armin

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Peter Dannegger (peda)

>> Käse. Du vermischt FSK mit Manchester, mal wieder.

>Sorry, wußte nicht, daß Du noch nie Manchester gesehen hast, also:

Gehts noch bissel arroganter? Ich wette mal, dass DU mir in Sachen 
Kodierung nur wenig erklären kannst.

>In der Tat sind aber die Begriffe Kodierung und Modulation synonym, d.h.

FALSCH!

>es gibt keine exakte Trennung.

In deinem Kopf, ja das ist wohl leider so. Der Rest der Welt sieht das 
anders.

>Beide verändern das Signal, um bestimmte Eigenschaften zu erzielen unter
>Beibehaltung der Information.

Und Apfelmus ist mus aus Äpfeln. Gaspedal und Kupplung sind ja auch 
synonym, weil beide machen das Auto schneller. Ohhhje!

>Landläufig spricht man von Kodierung bei digitalen Signalen und von
>Modulation bei analoger Verarbeitung.

Vollkommen danaben.
Da muss ich leider sagen. Sechs, setzen.

>Daher kommt es auch daß bei Festplatten beide Begriffe gleich verwendet
>werden, die Signale sind digital, aber das Schreiben und Lesen erfolgt
>analog.

Vollkommener Unsinn. Bist du heute auf Droge?

MfG
Falk, die Hoffnung nicht aufgebend

P.S. Auch wenn Wikipedia nicht der Weiheit letzter Schluss ist.

http://de.wikipedia.org/wiki/Kodierung
http://de.wikipedia.org/wiki/Modulation_%28Technik%29

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Armin G. wrote:
> Vielleicht sollte ich einmal erwähnen, dass ich XBee-Module von
> Maxstream verwende.

Meinst Du diese hier:

http://www.maxstream.net/hottag/download.php?ht=/p...

Die haben ein richtiges Kommandointerface.

So einfach direkt Daten senden geht also nicht.

Man muß sich entsprechende Pakete zusamenbasteln und hinschicken.

Und beim Empfang gibt es bestimmt auch Informationen über die Qualität 
der Übertragung, die man auswerten sollte.


Peter

Autor: Armin G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Module nutze ich.

Man kann am Empfängermodul die Empfangsstärke auslesen, aber die hat ja 
so gesehen erst einmal nicht viel damit zu tun wievierl ankommt oder 
wieviel richtig ankommt. Klar, wenn die in den Keller geht, kommt mehr 
Datenmüll raus, aber um die Geschwindigkeit zu testen brauche ich diesen 
Wert nicht auszuwerten.

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.