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?
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.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.
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
Nee, das ist noch viel zu stümperlich und funktioniert auch gar nicht.Könntest du mir vielleicht freundlicherweise trotzdem mal deinen Ansatz schicken ...
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
Berechtigungen
Zitieren
Lesezeichen