Codierung für Funkübertragung mit R7G - T7G

Hallo,

ich habe mit letztens eine Schaltung mit einem ATMEL Mega32 µC und einem SHT11 Temperatursensor zur Aufzeichnung von Temperatur und Luftfeuchtigkeit gelötet. Diese funktioniert auch einwandfrei, ich verwende zur Aufzeichnung einen externen I2C EEPROM.

Nun wollte ich die Schaltung erweitern, indem ich mir die gemessenen Daten alle paar Minuten (z.B. alle 15 min) per Funk an den PC schicken lasse.
Da ich noch einen Funktransmitter T7G (von www.rfsolutions.co.uk) und dazugehörigen Receiver R7G habe, dachte ich mir, ich könnte diese doch verwenden.

Zu meiner eigentlichen Frage:
Ich habe zwar mit Google schon einige Zeit gesucht, aber auch nichts passendes gefunden.
Ich suche ein Codebeispiel für die Codierung, die ich für die Funkübertragung benötige.
Welche Codierung wäre die beste bzw. störungssicherste?

Bin für alle Hinweise dankbar!

Hallo DarkFire,

nach dem Datenblatt gehe ich davon aus, dass du für die Datenübertragung mit dem Modul eine Manchester-Codierung brauchst.

Darüber gibt es hier schon einige Beiträge und wohl eine Bascom-Lösung.

Ich bastele auch gerade daran herum und versuche eine C-Lösung, die mir aber bis jetzt nicht gelungen ist. :(
Vielleicht hat hier ja jemand noch eine gute Idee oder das ganze in C schon umgesetzt.

Gruß Dirk

Hallo,
ja ich denke auch, dass ich eine Manchester Codierung benötige. Die Manchestercodierung eines Bytes an sich ist auch kein Problem, da habe ich schon etwas gefunden, das Problem was ich habe ist, wie soll ich dieses Byte dann an den Transmitter schicken?
Über UART gehts ja leider schlecht, da mir ja dieser durch die Start und Stoppbits die Codierung wieder unbrauchbar macht.
Und vor allem, wie kann ich die gesendeten Bytes dann empfangen?
Ich dachte vorher nur mit dem PC, aber das wird wohl nicht möglich sein, da muss wohl auch ein kleiner µC her, der mir das ganze dekodiert und dann via UART an den PC schickt.

Hier die Routine für die Manchester Kodierung bzw. Dekodierung:

Code:

---

typedef unsigned char uchar;    /* to avoid typing "unsigned" all the time */
typedef unsigned short ushort;
enum {false, true};            /* for bit flags */

extern bit manErrFlg;  /* set this flag if an invalid byte is received */
/* NOTE: For example only. You decide how to signal a receive error */

/* Manchester encode byte c as two bytes: Odd bits in MS byte, Even in LS */
ushort manEncode(uchar c)
{
    uchar ms, ls;
     
    ms = (c & 0xAA) | ((~c & 0xAA)>>1);    /* encode odd bits w/ their cpls */
    ls = (c & 0x55) | ((~c & 0x55)<<1);    /* now even bits */
    return ((ushort)ms << 8) | ls;          /* build two bytes into a short */
}

/* decode odd bits from MS byte, even bits from LS byte. If mc is not */
/* valid (bits don't match complements) then set manErrFlg and return 0 */

uchar manDecode(ushort mc)
{
    uchar ms, ls;
     
    ms = (uchar)(mc >> 8);      /* get ms byte from short */
    if ( (ms & 0xAA) ^ ((~ms & 0x55) << 1) )
    {
        manErrFlg = true;  /* odd bits != complement of their complements */
        return 0;          /* so flag the error and punt */
    }
    else
        ms &= 0xAA;        /* otherwise, valid data, so just clear cpls */

    ls = (uchar)mc;        /* now test even bits... */
    if ( (ls & 0x55) ^ ((~ls & 0xAA)>>1) ) 
    {
        manErrFlg = true;
        return 0;
    }
    else
        ls &= 0x55;        /* valid, so clear complements */

    manErrFlg = false;
    return ms | ls;        /* OR original odd and even bits back together */
}

---

Hallo DarkFire,

mein Problem ist wie bei dir das Empfangen der Manchester-codierten Daten. Ich bekomme die Flankendetektion und Synchronisierung nicht hin.
Mir fehlt dazu auch ein Oszilloskop, um meine Fehler einzugrenzen. Wenn ich das Ergebnis habe, ist die Umwandlung kein Problem.

Mit deinen Modulen wirst du tatsächlich auch auf PC-Seite einen kleinen uC für die Decodierung/Empfang und Umwandlung in eine byteweise RS232-Umsetzung nehmen müssen. Es gab hier jemanden, der eine direkte RS232-Anbindung sowohl beim Senden als auch beim Empfang mit einem ähnlichen Modul gemacht hat. Das soll auch begrenzt funktionieren.
Zuverlässig ist das aber nicht durch die Gleichspannungsanteile.

Gruß Dirk

Hallo Dirk,

ich habe mir ja auch schon gedacht, man könnte es so ähnlich wie einen Software UART realisieren, also das man einen Timer für den Takt verwendet und dann die Bits mit einem bestimmten Takt an den Transmitter sendet.
Zur Synchronisation dachte ich mir wäre eventuell soetwas wie eine Startsequenz, die eventuell sogar nicht Manchester kodiert ist, hilfreich.

Das Signal vom Empfänger müsste man dann halt am Interrupt Eingang anschließen und auf fallende und steigende Flanken triggern.
Sobald der Empfänger dann das Startwort komplett empfangen hat, weiß er, dass jetzt die Daten folgen und kann diese empfangen.

Soweit habe ich mir das von der Theorie her überlegt. Nur leider fehlt es dabei noch ein Stück bis zur praktischen Umsetzung.

Könnte man das vom Prinzip her so realisieren, oder muss man noch weitere Faktoren beachten?

Zitat:

---

Das Signal vom Empfänger müsste man dann halt am Interrupt Eingang anschließen und auf fallende und steigende Flanken triggern.
Sobald der Empfänger dann das Startwort komplett empfangen hat, weiß er, dass jetzt die Daten folgen und kann diese empfangen.

---

Ja, genau. Als Startsequenz wird dann eine illegale Codierung (z.B. $F0) ein- oder mehrfach gesendet, die eindeutig zu identifizieren ist. Danach kommen die Daten, wobei mein Problem ist, die 0-1 oder 1-0 Übergänge in Bitmitte zu identifizieren. Das ist sehr timing-lastig und mir fehlt ein Oszi, um zu sehen, was ich gerade verbocke. Ich habe das schon ne Weile auf Eis liegen, weil ich nicht weiter komme. :(

Gruß Dirk

Ja stimmt, da muss ich dir recht geben, das ist wahrscheinlich sehr timinglastig und ich habe leider zur Zeit auch kein Oszi zur Hand.

Könntest du mir vielleicht freundlicherweise trotzdem mal deinen Ansatz schicken, damit ich mir anschauen kann, wie du an das Problem herangegangen bist?

Gruß,
Chris

Zitat:

---

Könntest du mir vielleicht freundlicherweise trotzdem mal deinen Ansatz schicken ...

---

Nee, das ist noch viel zu stümperlich und funktioniert auch gar nicht.

Meine Idee für die Empfangsseite war:
1. Aus den empfangenen Startbytes ($F0) die Manchester-Bitlänge errechnen. Wenn ich z.B. dort die 0- oder 1-Gesamtlänge messe, dann müßte die das 4-fache der Bitlänge sein (?).
2. Nach dem letzten Startbyte würden ja die Daten beginnen und ich müßte einen Timer starten.
3. Die gewünschte Flanke würde ich dann bei der halben Bitlänge erwarten, müßte aber natürlich, um sie nicht zu verpassen DAVOR, also wohl etwa ab der Dauer einer viertel Bitlänge auf die Flanke warten.
4. Nach dem Startbyte müßte man also das erste Mal nach 1/4 Bitlänge auf die erste Flanke warten, für alle weiteren Bits nach einer weiteren ganzen Bitlänge.
5. Das ganze System müßte sich immer wieder neu synchronisieren an den Startbytes, ich habe aber auch gelesen und kann mir das gut vorstellen, dass anhand aller empfangener Flanken auch eine fortlaufende Synchronisierung bei längeren Übertragungen möglich ist. Man müßte dann bei laufendem Empfang die Aufrufzeit für die ISR (= Bitlänge), die die Flanken detektiert, variabel gestalten und in gewissen Grenzen vom Abstand der empfangenen Flanken (= 1/2 Bitlänge) abhängig machen.

Vielleicht kriegst du das ja hin bzw. gibt uns jemand hier ein paar Hinweise, wie man's machen kann.

Gruß Dirk

Hallo Dirk,

ja das klingt für mich vom Ansatz her recht logisch, allerdings muss ich dir recht geben, das größte Problem ist wahrscheinlich die Synchronisierung.

Ich habe da übrigens zufällig was mit Google gefunden, ein Studienarbeit, wo es ebenfalls um die Funkübertragung geht, ist mit einem ATMEL µC realisiert zwar in Assembler aber vom Ansatz her recht interessant.
http://www.uni-koblenz.de/~physik/in...ten/toeppi.pdf

Danke, werde ich mir 'mal in Ruhe durchlesen.

Gruß Dirk

Hi, und hast du dir den Text schon durchgelesen?

Ich habe nochmal etwas in google gesucht, und in einem anderen Forum eine Lösung gefunden, die mittels UART funktioniert.
http://www.mikrocontroller.net/topic/38924
Ich habe die Routinen etwas verändert, und die einfache Checksumme durch eine CRC16 Prüfsumme ersetzt und getestet.
Durch die Übertragung im UART Protokoll ist die ganze Sache zwar nicht wirklich gleichspannungsfrei funktioniert mit meinen FM-Modulen aber trotzdem recht gut. Vor allem aber benötigt man auf der Empfängerseite nur einen PC mit RS232 Schnittstelle (ich habe die Dekodierung einen ATMEGA8 machen lassen, da ich diesen jetzt sowieso schon beim Empfänger eingebaut habe).


Meinen Quellcode ist im Anhang.

Im Quellcode müsste man doch die StatusLED_On; und ErrorLED_On; usw. entfernen, diese habe ich nur zu Testzwecken eingebaut und die defines sind im File nicht vorhanden.

Hallo DarkFire,

diese Studienarbeit ist das, was ich gesucht habe. Aber mit meiner Version kämpfe ich noch.
Ich wollte eigentlich auch einen interruptfähigen Pin für den Receiver nehmen, habe aber keinen mehr frei. :(
Nun bin ich wohl zum Polling verdammt. Ich hätte lieber eine Flankenerkennung und arbeite jetzt an der Pegelerkennung. Ich bleibe dran, aber: Keine große Hoffnung.

Danke für deine Variante. Klappt es damit?

Gruß Dirk

Hallo, freut mich zu hören, dass dir diese Studienarbeit weiterhilft.
Ja für mich klappt die Version, wie sie in dem hochgeladenen File ist, allerdings ist das natürlich bei weitem nicht perfekt und doch auch noch recht fehleranfällig (auch wenn ich die Fehler erkennen kann, kann ich sie dennoch nicht korrigieren, da ich keine bidirektionale Verbindung habe).

Würde mich auf jeden Fall freuen, wenn du es mich wissen lässt, sobald du einen lauffähigen Code auf Basis dieser Studienarbeit oder in diese Richtung hast.

Ich habe mir die Arbeit auch schon durchgelesen, und das meiste auch verstanden nur glaube ich reichen meine Kenntnisse im Bezug auf µC Programmierung doch nicht ganz aus, das ich das umsetzen könnte.

Kannst du denn in deiner Schaltung keinen Interrupt Pin freimachen? Denn ich glaube per Polling ist es doch noch um einiges komplizierter bzw. zeitkritischer zu realisieren, oder sehe ich das falsch?

Gruß Chris

... ich lese gerade in der Studienarbeit, dass es bei denen mit den Modulen von Conrad nicht geklappt hat, weil die Pegel zu unsauber waren.

Na prima, genau mit denen (868 MHz: 190939) arbeite ich. :-s
Da kann ich wohl lange herumkaspern ...

Gruß Dirk

Hallo, ja das habe ich in der Studienarbeit auch gelesen, mir ist auch aufgefallen, dass die Übertragungsdistanzen nicht gerade lange waren, für die Anzahl der Fehler, die aufgetreten sind.

Ich verwende ja schon seit einiger Zeit die RFM12 Module von Pollin, mit diesen und der benötigten Lib von www.mikrocontroller.net (Forum) funktionieren diese auch sehr gut, vor allem muss man sich nicht um die Codierung kümmern. Der Nachteil ist neben der geringen Reichweite (naja wie mans nimmt so um die 100m sind immerhin auch), dass man eine SPI Schnittstelle benötigt, also die für SPI Pins müssen frei sein.

Die Module von rsolutions verwende ich nur deswegen, weil ich eine höhere Reichweite benötige.

Ich habe heute übrigens mal einen Reichweitentest gemacht, mit der von mir geposteten Variante über UART.
Ich bin auf freiem Gelände auf über 1,2 km gekommen und wenn ein paar Bäume dazwischen sind, dann ists immer noch knapp 1 km.
Im Datenblatt der Module steht, dass die maximale Reichweite des T7G und R7G 1 km beträgt, also kann ich glaube ich ganz zu frieden sein.

Zitat:

---

Ich bin auf freiem Gelände auf über 1,2 km gekommen und wenn ein paar Bäume dazwischen sind, dann ists immer noch knapp 1 km.

---

Das klingt sehr gut! Glückwunsch.
=D> (Warum funktioniert der Applaus-Smily eigentlich nicht?)

Gruß Dirk

Danke!

Die Conrad Module die du verwendest sind ja AM Module oder nicht? Ich verwende nämlich FM Module, sind zwar teurer aber nicht so störanfällig wie AM Module.

Würde es mit deinen Modulen auch mit einer Flankenerkennung nicht funktionieren, oder funktioniert es nur wenn du es per Pegelerkennung machst nicht?