Beispielprogramm für RFM12 433MHz Funk-Module

[Benedikt K. (benedikt)]

Dieses Programm steuert ein RFM12 Funkmodul an, und sendet/empängt einen 
Datenblock einstellbarer Länge. Es ist keine Fehlerkorrektur oder 
ähnliches vorhanden.
Die gesamte Hardwareansteuerung wird von der Software in der RF12.c 
erledigt, ebenso das Ein/Ausschalten von Sender und Empfänger.
Man muss also nur das Modul initialisieren, die ganzen Parameter 
einstellen und kann direkt senden oder empfangen.
Der Takt am CLK Pin ist auf 10MHz eingestellt, damit man damit z.B. den 
AVR damit versorgen kann.
Um den Schaltungsaufwand klein zu halten, benutze ich nicht den 
Interrupt Pin sondern Polle das Interrupt Bit im Status Register. 
Dadurch kommt man mit nur 4 Pins aus (SPI + Chipselect). Da alles ohne 
speziellen Hardwarefunktionen läuft, sollte die Software auf jedem AVR 
(mit SRAM) lauffähig sein.
Der FSK/DATA/nFFS Pin muss über einen Pullup (z.B. 1-10k) an VDD gelegt 
werden, damit alles richtig funktioniert. Alle anderen, in der Software 
nicht aufgelisteten IO Pins des Moduls, werden auf Ausgang geschaltet 
und brauchen daher nicht angeschlossen zu werden.

Die meisten der Einstellungen habe ich irgendwo in die Mitte gesetzt. 
Für eine optimale Datenrate und Reichweite muss man mit Sicherheit noch 
ein paar Details anpassen.

[Bascom Jünger (Gast)]

Heul,
schade nicht in Bascom.
Könnte es ein C-Versteher den Code in Bascom übersetzen, oder wenigstens 
ein Flußdiagramm schreiben.
Hätte vielleicht auch ein ASM-Freak was davon.
Bitte bitte

[433MHz-Frager (Gast)]

Hallo,
meine Module sind leider noch nicht da :-/
Ich habe mir gerade mal Dein Programm angesehen und frage mich gerade 
warum Du bei "void rf12_init(void)" :

for (unsigned char i=0; i<10; i++)
    _delay_ms(10);

statt z.B.:

    _delay_ms(100);

genommen hast ?
Denke mal Du hast einfach solange probiert, bis die passende Delay-Zeit 
erreicht war ?
Ich habe einige hahnebüchene Fehler in den Code-Beispielen bei Pollin 
und Hope entdeckt :-?
Woher hast Du Deine Infos ?
Aus den Hope-Datenblättern, die sind ja auch ziemlich neben der Reihe 
:-?
Ich wollte mit einem RFM01 und RFM02 eine kleine Funkfernsteuerung 
bauen.
Jetzt Frage ich mich, ob Dein Code auch auf einem Tiny13 läuft oder zu 
groß wird ?
In Assembler bin ich nämlich nicht so fit :-P
Danke für Deinen Code ;-)

[Benedikt K. (benedikt)]

Der Grund wiso delay(100ms) nicht funktioniert:
Delay ist eine Schleife mit 16bit Zähler. Diese kann je nach CPU Takt 
nicht länger als einige 10ms werden. Bei 20MHz sind daher nur 13,1ms 
möglich.

Falls die Software nicht richtig laufen sollte: Eventuell muss die Delay 
Zeit vergrößert werden, denn 100ms braucht das Modul nach dem 
Einschalten bis es Befehle ausführen kann.

Die Datenblätter von den Modulen und die Beispielcodes sind nahezu 
kompletter Mist.
Programmiert habe ich das ganze nach den Datenblättern der einzelnen 
ICs, die weitaus besser und vor allem fehlerfreier sind:
http://www.hoperf.com/pdf/RF01.pdf
http://www.hoperf.com/pdf/RF02.pdf
http://www.hoperf.com/pdf/RF12.pdf

Das RFM12 Programm hat nicht ganz 800Bytes (RFM12 Routinen + main mit 
Initialisierung auf einem tiny2313). Der Code ist nicht auf Codegröße 
optimiert, sondern so dass es erstmal funktioniert. Da kann man mit 
Sicherheit noch einiges verbessern.
Die RFM01 und RFM02 Routinen sind etwas kleiner, da bei diesen ja nur 
Senden oder Empfangen benötigt wird.

[433MHz-Frager (Gast)]

Danke für die Erklärung und die Datenblätter ;-)
Soweit ich das jetzt verstanden habe, müßte ich den RF02-Sender mit zwei 
Steuerleitungen SCK und MISO betreiben können, da es nur einen Sender 
gibt kann ich doch nSel direkt auf GND legen, sowie FSK mit Pullup gegen 
Vcc.
Oder übersehe ich da was ?
Meine Idee ist im Tiny13 den aktuellen Zustand des zu steuernden Geräts 
zu speichern und kontinuierlich abzusenden.
Ich denke diese Lösung ist am sichersten ;-)
Oder gibt's da bessere Varianten ?

[Benedikt K. (benedikt)]

Bei dem RF02 Sender ist das etwas komplizierter: Im Gegensatz zum RF12 
besitzt dieser kein Sende FIFO. Man muss die Bits also im Takt der 
Baudrate entweder an den FSK oder an den SDI Pin legen (ist per Befehl 
umschaltbar). Den FSK Pin braucht man also nicht unbedingt, aber der 
SDO/IRQ Pin ist notwendig, denn an diesem gibt der RF02 den Takt der 
Baudrate an. Bei jeder fallenden Flanke von diesem wird das Bit an FSK 
oder SDI eingelesen und gesendet.
Momementan polle ich die Leitung noch, später möchte ich das aber per 
Interrupt oder per USI/SPI im Slave mode machen, denn der IRQ Pin ist 
nur für 1,6us high. Wenn da ein Interrupt dazwischen kommt, gehen Bits 
verloren.
nSEL kann man nicht auf GND legen, denn damit wird u.a. die Übertragung 
beendet.

Ich habe gerade eine Testplatine mit einem RF02 aufgebaut, im Laufe des 
Tages werde ich also die Software dafür fertig testen können und diese 
dann hier rein stellen.

[Benedikt K. (benedikt)]

Hier nun dasselbe für den RF02 Sender. Funktioniert ähnlich, ist aber 
etwas einfacher (da nur Senden), und kleiner (rund 650Bytes inkl main).
Ein Nachteil hat das ganze aber: Während die Senderoutine läuft, darf 
kein Interrupt auftreten, also Interrupts während dem Senden abschalten.
Eine bessere Lösung wäre, die Senderoutine selbst teilweise in einen 
Interrupt zu packen (USI, SPI, INT), aber das würde dann nicht mit allen 
AVRs funktionieren, daher erst mal die einfache Lösung.

[Benedikt K. (benedikt)]

Und hier die Software für den Empfänger RF01.

[Dr (Gast)]

Na, da tut sich auch bei Pollin was. Die C-Programme com 
Sender/Empfänger sind jetzt vom 16.4.07 8:45.

[Benedikt K. (benedikt)]

Oder auch nicht:
Den einzigen Unterschied den ich sehe ist, dass das Wort "Pinbelegung" 
hinzukam.

[jonny (Gast)]

verkauf ihnen doch deine Verion xD

[Sven G. (s705081)]

Hallo Benedikt,

sag mal wo kommt bei dir die utils/delay.h her? Ist das aus einer avr 
clib?

Gruss Sven

[Benedikt K. (benedikt)]

Die ist beim Libc vom AVR GCC dabei.

[Thomas K. (thomas_k)]

Sorry für die dumme Frage aber was genau hat jetzt rfm01 und rfm02 mit 
dem rfm12 Modul von Pollin zu tun?

[433MHz-Frager (Gast)]

@ Thomas Kropf:
Alle drei Module gibt es bei Pollin ;-)
RFM01 & RFM02 für 4,95 Teuronen
RFM12 für 7,95 Teuronen
Auf dem RFM01 und RFM12 sind Chips mit FIFO verbaut und (Danke Benedikt) 
der Sender RFM02 hat leider keinen :-/
Aber alle Chips haben identische Kontrollparameter ;-)
Hoffe das meine Bestellung bald mal ankommt, zum Basteln und Testen ;-)
Bin schon ganz kribbelig mal zu probieren ob meine Ideen auf 100m Sicht 
funzen :-P

[Thomas K. (thomas_k)]

Aaah, danke!

Ich bin noch stark am Überlegen.
Vor allem wieviele Stück (wenn dann nur rfm12) ich mir zulegen soll. Ich 
kann leider schwer einschätzen wie "gut" die Dinger wirklich sind.

Pollin wird wohl auch nicht ewig diese Module verkaufen. Deswegen würde 
ich mir gleich einen kleinen Vorrat zulegen wollen.

Wenn ich irgendwann mal eine von diesem MCA-25 Kameras wo billig 
ergattern würde dann wär die Kombination von Funkübertragung und Kamera 
ein Traum (ich weiß es würde lange dauern aber das wäre egal) :)

[Sven G. (s705081)]

@ Benedikt

das mit der Library hat sich grade aufgeklärt, meine war etwas veraltet.

Gruss Sven

[bastelbär (Gast)]

Hi, da ich die Teile auch bestellt habe, habe ich mir schon mal den Code 
von Benedikt auf BASCOM angepasst. Ich weiss allerdings nicht ob er so 
funktioniert, jedenfalls kompiliert er ohne Fehler.
Damit der/die BASCOM-Jünger auch was mit den Funkmodulen machen können 
poste ich ihn mal. Aber ohne Gewähr, nur als Anregung zu verstehen
Viel Spass damit

  Fossie

[R. M. (rmax)]

Hi,

vielen Dank an Benedikt für die Bibliotheken!


Hier noch ein kleiner Optimierungsvorschlag für die Funktion 
rf12_trans():

Während das auszugebende Wort am "High-Ende" rausgeschoben wird, kann 
vom "Low-Ende" her der Rückgabewert in die gleiche Variable geschoben 
werden. Dadurch wird die Variable werti eingespart, es sind nur halb so 
viele Schiebeoperationen nötig und der Code wird ein bißchen kleiner.

cu
Reinhard

[Humix (Gast)]

@Bastelbär
Sauber programmiert Respekt
werde es nächste Woche testen

@alle
Muss der AVR zwingend mit 10MHZ takten ?

[Benedikt K. (benedikt)]

Nein, der AVR kann beliebig getaktet werden. 10MHz bietet sich nur an, 
das dieser Takt von dem Modul zur Verfügung gestellt wird. So spart man 
sich den Quarz. Ein weiterer Vorteil ist auch: Man kann den AVR 
dynamisch takten, indem man den Takt bis auf 1MHz reduziert.

[Bascom Jünger Nr12 (Gast)]

@Bastelbär
Respekt auch von mir, wie kommt der AVR denn zum 10 Mhz-Takt?
Hat er hier einen eigenen Quarz?
Bzw. wie wird das verdrahtet?
Vielen herzlichen Dank für den Code !!!

[Uwe .. (uwegw)]

Das Modul gibt die 10MHz an CLK aus. Am AVr speist man sie dann an XTAL1 
ein, lässt XTAL2 unbelegt und setzt die Fusebits auf externen Takt.

[Michael (Gast)]

Hallo Benedikt,

hier nochmal in einem anderen Thread die passende Frage.
Bin gerade dabei mal einen Schaltplan zu machen.

Ich lese von dem Pull-Up an dem FSK/DATA/nFFS Pin.
Der Atmel-Port lässt sich doch so programmieren,
das ein interner Pull-Up eingeschaltet wird.
Das weisst Du aber sicherlich.
Warum hast Du dennoch einen externen Pull-Up empfohlen?

Gruss
Michael

[Benedikt K. (benedikt)]

Wiso einen Pin verschwenden, wenn ein Pullup reicht ?

[Michael (Gast)]

Hallo Benedikt,

uups, habe ich da was falsch verstanden?
Benutzt Du ausschliesslich SDI/SDO/SCLK?
Und der FSK/DATA/nFFS Pin ist garnicht mit Deinem Controller verbunden?

Gruss
Michael

[Benedikt K. (benedikt)]

Ja, so in etwa. nSEL braucht man aber noch, also das komplette SPI 
Interface: Daten, Takt, Chipselect.

Alle anderen Leitungen wie Interrupt oder nFFS sind optional, wenn man 
alles auf maximale Geschwindigkeit auslegt, oder es eben mit einem 
Interrupt betreiben möchte.

[Michael (Gast)]

Hallo Benedikt,

ah, mein Fehler.
Ja, das mit der Geschwindigkeit war so mein Hintergedanke.
Danke für die Infos.

Gruss
Michael

[Humix (Gast)]

@Bastelbär  @Alle

Die Bascom Datei von Bastelbär enthält meiner Meinung nach einen Fehler?

Sub Rf12_setfreq(byval Freq As Single)

  Freq = Freq - 430.00
  Temp = Freq / 0.0025
  If Temp < 96 Then
    Temp = 96
  Elseif Temp > 3903 Then
    Temp = 3903
  End If

 Temp = Temp + &HA000    !!!! Diese Zeile fehlt  oder irre ich mich ???

  Temp = Rf12_trans(temp)
End Sub

Kann es leider noch nicht Testen

[bastelbär (Gast)]

@Humix

Hast natürlich recht. Die Zeile fehlt. Wird Zeit das meine Module 
endlich kommen damit ich das testen kann.

Korrigierte Verison anbei.

mfg.
    Joachim

[Tobi A. (Gast)]

Hi

Ich hab mir irgendwan bei einer früher AVR GCC version mal einen hass 
auf das programm anprogrammiert und meide es seitdem.
Hat irgendwer eine Idee wieviel Aufwand es sein wird das auf Codevision 
zu portieren?

Tobi

[Benedikt K. (benedikt)]

Eigentlich kaum Aufwand, da es kaum hardwarenahe Funktionen gibt, die 
irgendwas spezielles vom Compiler erwarten.
Es müssen eigentlich nur die #defines passen, dann sollte das Programm 
laufen.

[Juppi (Gast)]

Hat jemand schon Erfahrungen mit dem Antennenanschluß gemacht. Wie 
sollte diese Antenne optimal beschaffen sein?

gute Zeit wünscht Juppi

[Uwe .. (uwegw)]

Welche Entfernung willst du schaffen? Mit 15cm Draht ist schon einges 
machbar...

[Tobi A. (Gast)]

@ Juppi
"Wie sollte diese Antenne optimal beschaffen sein?"

Das hängt von der Anwendung ab.
Sag uns was Du vorhast und wir können Dir eine Antenne empfehlen.

[Andy (Gast)]

Hallo,

Ich habe das Bascom Programm einmal mit einem Mega8 probiert, aber es 
will nicht so recht. Ich habe nach der RX-Routine in der for-Schleife 
ein "Print rfdata(count)" eingebaut, um zu sehen, ob der Text auch 
übertragen wird, aber es kommt immer der Text "96" (ASCII 39 und 36) 
heraus.

Kann es sein, das im Code noch Fehler sind? Ist da was bekannt?


Vielen Dank!!


Andy

[Sascha F. (sascha_focus)]

Hi,

habe nachdem meine RFM12 endlich gekommen sind, den Code ausprobiert.
Keinerlei Datenverlust. Aber eine Frage mal so nebenbei. Warum Software 
SPI und nicht Hardware SPI?

Gruß Sascha

[Benedikt K. (benedikt)]

Ganz einfach: Weil nicht jeder AVR SPI hat.
Damit die Software wirklich auf jedem AVR läuft, und nicht jeder erst 
die Software an seinen Wunsch AVR anpassen muss.

[Koko Lores (Gast)]

Hier mal der Link zur Diskussion vom Modul

Beitrag "RFM12 - Funkmodul"

[Stefan (Gast)]

Habe versucht den Code von Benedikt zum laufen zu bringen, leider ohne 
Erfolg. Nutze zwei ATMEGA16 und zwei Module RFM12 gemeinsam auf großem 
Steckboard. Habe den Pull Up an FSK mit 10kOhm gesteckt, rückmeldung 
bekomme ich über RS 232. Antenne ist 17cm lang. Dabei fiel auf, daß das 
Senden scheinbar funktioniert (an SDO kommt mit steigender Flanke 
rückmeldung). Allerdings scheint der Empfang nicht zu funktionieren. Das 
Empfangsprogramm bleibt in der Funktion:
void rf12_rxdata.....
....
  for (i=0; i<number; i++)
  {  rf12_ready();
    *data++=rf12_trans(0xB000);
  }
  rf12_trans(0x8208);
...
bei dem rf12_ready hängen, da der RFM12 an SDO das Signal nicht wieder 
auf HIGH zieht...
Hatte das jmd von Euch schon mal???

[Avr N. (avrnix)]

@bastelbär: Hast du schon dein BASCOM Programm mit den RFM12 Modul 
ausprobiert?

[Benedikt K. (benedikt)]

@ Stefan
Entweder wurde das Modul nicht richtig initialisiert, oder der Sender 
sendet nichts.
Versuch mal die Pause vor der Initialisierung größer zu machen.

[Stefan (Gast)]

@ Benedikt

Danke,also, die Pause in der Initialisierung habe ich schon auf 150ms 
erhöht...muß mir mal nen Funkscanner leihen, um zu sehen, ob er 
sendet...oder wie macht Ihr das?

[Benedikt K. (benedikt)]

Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet. Ergibt 
einen wunderbaren Spectrumanalyer im Bereich 45-880MHz mit etwa 100kHz 
Auflösung.

[Marco S. (masterof)]

Benedikt K. wrote:
> Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet. Ergibt
> einen wunderbaren Spectrumanalyer im Bereich 45-880MHz mit etwa 100kHz
> Auflösung.

ist zwar etwas OT aber:

Wie nutz du den TV-Tuner als Spectrumanalyer?

[Benedikt K. (benedikt)]

Ich habe am Ausgang des Tuners (ca 34-40MHz) einen SA615 hängen, der als 
Bandpass + logarithmischer Gleichrichter dient (nebenbei kann man an dem 
auch noch das FM demodulierte Signal abgreifen, aber das nutze ich 
nicht). Das RSSI Signal messe ich mit einem AVR, der dem Tuner die 
Frequenz per I2C vorgibt. So durchlaufe ich den ganzen Frequenzbereich. 
Leider hat der Tuner nur ein 62,5kHz Abstimmraster, aber das reicht für 
die meisten Sachen. Die Bandbreite meiner ZF Filter ist sowiso größer.

[Avr N. (avrnix)]

Hast du dazu eine Bauanletung oder sowas?

[Sven G. (s705081)]

@ Stafan
ich habe hier genau das gleich Problem mit zwei ATmega16s. Das senden 
scheint zu klappen nur beim empfangen hängt der zweite Atmel. Der Code 
ist nicht angepasst, Original aus dem Zip. Beide können Senden. Sehr 
Komisch.

Hat jemand einen Mega16 als Empfänger am laufen?

Gruss Sven

[Tino (Gast)]

Beim mir das gleiche Problem, ich hab Mega32 dran hängen. Senden geht 
auf jeden Fall, hab ich mit einem Spektrumanalysator überprüft.

[Sven G. (s705081)]

@ Stefan sorry habe mich vertippt.

[Benedikt K. (benedikt)]

Ich habe es bei mir gerade nochmal ausprobiert: Die Module an je einen 
tiny2313 @ 10MHz, und es funktioniert.
Probiert mal folgendes: Erst den Empfänger einschalten, dann denn 
Sender.

[Stefan (Gast)]

@ Benedikt

Also der Sender sendet eindeutig, das habe ich jetzt mit nem Funkscanner 
überprüft! Man hört dann beim Senden ein kurzzeitiges Rauschen!...
Aber der Empfänger scheint nicht zu funtionieren, auch wenn ich den 
Empfänger  zuvor mit Spannung versorgt habe und anschließend den Sender 
einschalte!
Aber woran soll es dann noch liegen?

[Benedikt K. (benedikt)]

Leider kann ich da auch nicht viel machen, da man ja nicht in die Module 
reinschauen kann.
Falls du ein Oszilloskop oder einen Frequenzzähler hast: Schau mal ob am 
CLK Ausgang (vom Empfänger) 10MHz rauskommen. Falls ja, dann ist das 
Modul zumindest halbwegs richtig initialisiert. Dann sollte es 
eigentlich funktionieren.
Der Sender sollte etwa im 1s Takt Daten senden. Das müsste man deutlich 
an kurzen Rauschimpulsen hören können.

[Benedikt K. (benedikt)]

Ich glaube ich habe das Problem: Es liegt am Sender !
Aus irgendeinem Grund funktioniert die Initialisierung nicht immer, 
sondern erst nach ein paar Versuchen. Zu Beginn höre ich auch nur ein 
Dauerrauschen, schalte ich den Sender aber mehrmals ein und aus, dann 
kommen plötzlich die 1s Rauschimpulse. Danach funktioniert es aus 
irgendeinem Grund jedesmal beim Einschalten.

[Stefan (Gast)]

@Benedikt

Also: Die Rauschimpulse kommen bei mir immer, das macht mein Scanner 
hörbar!
Die 10MHz kommen sowohl am Sender als auch beim Empfänger an.(Oszi) Habe 
die Empfängerschaltung jetzt mit einem MEGA8 versucht, aber auch das 
funktioniert nicht! Der Empfänger bekommt scheinbar kein Signal! Die 
Signale an SDI und SCK kommen am Modul an, allerdings nichts an 
SDO!...kann es sein, daß die Initialisierung beim Empfänger nicht 
stimmt??

[Benedikt K. (benedikt)]

Die Module gegeben nach dem Einschalten 1MHz aus. Ich schalte den Takt 
auf 10MHz um. Wenn also die 10MHz rauskommen, versteht also das Modul 
die Befehle. Ich habe es jetzt noch ein paarmal ausprobiert: Sobald der 
Sender läuft, empfange ich jedesmal die Daten problemlos.

[stefan (Gast)]

DANKE, Benedikt, aber ich bin noch nicht weiter...:(
Ich hoffe wir sprechen von dem gleichen Programm!?...ich habe das 
rfm12.zip, des ersten Eintrags genommen...und das send auskommentiert 
und receive rein! oder hab ich da noch was vergessen??? vlt. kannste das 
aktuelle noch mal posten???

[Benedikt K. (benedikt)]

Ja, genau dasselbe nutze ich auch. Wenn der Sender läuft, sollte der 
Empfänger eigentlich auch funktionieren. Hast du auch die Pause in der 
Schleife beim Empfänger auskommentiert ? Funktionieren müsste es aber 
trotzdem.

[Stefan (Gast)]

ja, habe ich alles gemacht...mir fiel jetzt folgendes auf, wenn ich den 
Tastkopf an de SDO anschließe, dann scheint es zu funktionieren, aber 
warum???? Hat da jmd ne Ahnung?

[Benedikt K. (benedikt)]

Timingproblem ? Oder ist der Pin nicht richtig angeschlossen ? Wie 
schnell läuft der AVR ?
Muss der Tastkopf schon beim Einschalten vorhanden sein, oder reicht es 
erst später während dem Empfangen ?
Probier mal ob es mit einem Pullup oder Pulldown funktioniert.

[juppi (Gast)]

Also um nochmal auf die Antenne zurückzukommen:

Zum Einsatz kommen nur RFM12 Module:
macht es in der Beschaffenheit der Antenne einen Unterschied, ob ich 10, 
20 oder 50m überbrücken möchte? - wahrscheinlich nicht - die Länge und 
Beschaffenheit hängt doch von der Frequenz ab, oder?

Zum Einsatz kommen sowohl RFM01 alsauch RFM02 Module:
Verwendet man unterschiedliche Antennen bei Sender und Empfänger ?

Um eventuelle Auschweifungen vorzubeugen: nein - keine Richtantenne - 
ich will nur ein Stück Draht dranhängen.

[Benedikt K. (benedikt)]

Im einfachsten Fall: etwa 16cm Draht reicht. Die Antennenanpassung macht 
den Rest. Falls die Entfernung klein ist, kann man die Sendeleistung per 
Software reduzieren.

[Stefan (Gast)]

@Benedikt

Also, der SCK Takt liegt bei 3,7kHz und die Daten an den RFM12 Sender 
scheinen anzukommen. Allerdings kommt am SDO nicht heraus! Hast Du da 
noch einen Tipp für mich????

[Benedikt K. (benedikt)]

Es gibt da eigentlich nur 2 Möglichkeiten (vorausgesetzt die Hardware 
ist OK):
a) Die Intialisierung des Empfängers ist nicht korrekt angekommen. 
Versuch einfach mal die Init Routine mehrmals hintereinander aufzurufen.
b) Der Sender sendet nicht die korrekten Daten.

[Stefan (Gast)]

Also die initialisierung des Empfängers scheint zu laufen! Danach gibt 
es, da
der SDO auf Low-Bleibt keine weiteren SCK-Impulse mehr....

[Sebastian (Gast)]

In Dateianhang ist meine code fuer:

ATmega8 + RFM02 (TX modul) + hardware SPI

PB2 (SS)   -> nSEL=CS
PB3 (MOSI) -> SDI
PB5 (SCK)  -> SCK
PB0        <- nIRQ
PB1        -> FSK

[Sebastian (Gast)]

...

[Joachim R. (bastelbaer)]

Hi Leute,
nachdem nun endlich meine Module gekommen sind habe ich mir mal meinen 
Code wieder vorgenommen und wollte ihn probieren. Dabei habe ich, 
abgesehen von einem Programmierfehler von mir, einige Ungereimtheiten im 
Compiler festgestellt. Duch diese Ungereimtheiten war es nicht möglich 
dass das Programm richtig lief obwohl beim Compilieren kein Fehler 
auftrat.

Als kleine Info: Ohne die Angaben von $hwstack, $swstack und framesize 
werden beim Aufruf der Funktionen bzw. Subs die Parameter anscheinend 
nicht richtig übergeben bzw. verarbeitet. Und beim Berechnen der 
Baudrate wird beim casten der Wert von Temp null anstatt 16 da die 
344828 für Word zu gross sind. Also man lernt nie aus was Compiler so 
alles machen.
Ich habe den Code entsprechend geändert und mal duch den Simulator 
laufen lassen und jetzt klappt es zumindest mit den Aufrufen.
Leider kann ich erst morgen das ganze an der Hardware testen. Aber ich 
schick das File mal mit, die Tage gibts dann einen Erfahrungsbericht von 
mir.
Also bis denne dann....

[Humix (Gast)]

@bastelbär
In die Config SPI muß NOSS = 1 eingefügt werden und dann den SS Pin
 im Programm schalten. ansonsten geht SS (Chip Select) schon nach
8 Bit wieder auf High.

[Avr N. (avrnix)]

@HUMix - geht es bei in bascom und würdest das zur verfügung stellen?

[bastelbaer (Gast)]

ES LEBT, ES LEBT!!
Die Routinen für den BASCOM laufen. Ein kleiner Fehler, abgesehen von 
dem den HUMIX gemeldet hat, war noch drin (Highbyte zuerst senden) aber 
jetzt laufen sie. Ich habe sie gerade an der Hardware mit einem 
Evalboard getestet. Allerdings hab ich den MEGA32 mit 8Mhz vom Evalboard 
getaktet, also nicht mit den 10MHz vom Modul. Also aufpassen im 
Quelltext falls einer die 10Mhz nutzt. Angeschlossen hab ich das Modul 
folgendermassen:
VDD    ->  VCC
GND    ->  GND
SDI    ->  MOSI (PB5, Pin 6)
SDO    ->  MISO (PB6, Pin 7)
SCK    ->  SCK  (PB7, Pin 8)
nSel   ->  SS   (PB4, Pin 5)
FSK    ->  R 10k Pullup

Jetzt gehts weiter im Programm mit den Feinheiten und IRQ-Steuerung. 
Auch werde ich mal mit dem SPI-Clock spielen um schneller zu werden.

Datei anbei, und nicht die Fuses vergessen.

Joachim

[Avr N. (avrnix)]

@bastelbär kann ich dein Bascom Programm auf http://www.comwebnet.de 
veröffentlichen? Dort sammele ich von Usern Projekte und die werden 
veröffentlicht. Gucke mal rein und schreib mir bitte.

[Stefan (Gast)]

@Benedikt

Kannst Du mir bitte mal die AVR Studio Version nennen, mit der du das 
Programm compiliert hast..bei mir ist Version 4.13 , Bulid 528....
Bei der Version habe ich bereits rausgefunden, daß man das "#define 
F_CPU 1000000UL" weder in der Header noch in der c-Datei definieren 
darf, sondern nur im Makefile von AVR...sonst bekommt man falsche Zeiten 
bei DELAY.h routinen...
Wie gesagt, es funktioniert immer noch nicht und ich sehe im Moment 
keinen Fehler..!?

[Benedikt K. (benedikt)]

Ich nutze den GCC ohne AVR Studio und erstelle alles über das Makefile.

[Ronald (Gast)]

Hallo liebe gemeinde!

ich habe vor, mir auch eine Datenstrecke basierend auf den Modulen RF12 
aufzubauen, meine Frage richtitet sich an die Antenne. und zwar nicht 
für wieweit sie lang sein muss, sondern eher ob ihr erfahrungen mit der 
max. Länge habt? Der einsatz ort einer Gegenstellt ist dirket neben 
einem leeren metal roh, gute 30 cm hoch, wenn nicht länger.

meine Frage wäre, ob was dagegen spricht dieses zu verwenden.
(habe im DB nichts gefunden oder übersehen)
lg

[Andy (Gast)]

Hallo,

@bastelbär:
Ich habe dein Programm nun ausprobiert - nur funktioniert es nicht! Ich 
verwende ein RFM12-Modul mit einem ATMega8 (mit 4MHz extern) als Sender 
und ein RFM12-Modul mit einem ATMega48(mit 8MHz extern) als Empfänger.
Den Empfängerteil hab ich via RS232 an meinen PC angeschlossen. Schalte 
ich die beiden Teile ein, so gibt mein Terminal folgendes aus:

Init<\r><\n>Set Frequenz<\r><\n>Set Bandwith<\r><\n>Set 
Baudrate<\r><\n>Set Power<\r><\n>Empfange<\r><\n>

Das passt ja alles so weit - nur gibt er sonst nichts mehr aus! Ich habe 
dann versucht rauszufinden, wo das Programm hängen bleibt. Und das ist 
im Rf12_rxdata - Teil. Und zwar bleibt das Programm in der for-Schleife 
hängen. Ich habe dort ein "Print temp" hinein gegeben und mein Terminal 
hat dauernd 0<\r><\n> ausgegeben.

Woran kann das liegen? Normalerweise sollte die for-Schleife doch nur 
32mal durchlaufen, oder?
Wie sieht das eigentlich mit den Fusebits aus? Vertragen die der Mega8 
und der Mega48?

Danke für eure Hilfe!!


mfg
Andy

[bastelbaer (Gast)]

Bei mir kommt, wenn ich eine Ausgabe in der Schleife von rf12_rxdata 
mache, gerade einmal diese Ausgabe und dann hängt das Teil halt. Kann es 
sein dass das Modul nicht richtig angeschlossen ist? Wenn das Modul 
korrekt angeschlossen ist und bei dir die Schleife durchläuft muss die 
rf12_ready nicht klappen. Dass der Mega48 eine andere Anschlussbelegung 
des SPI hat, ist dir bekannt. Und dass du oben im Programm hinter der 
SPI-Definition den SS und den MOSI-Pin extra definieren musst hast du 
auch gemacht?
Wenn ja, dann bin ich im Moment am Ende mit meinem Latein. Schau mal 
diese Sachen nach und evtl. den SPI-Speed. Aber eher ist es das mit den 
extra-Defs des SS und MOSI-Pin.
Was ist denn mit dem Sender? Gibt der im Sekundentakt "Sende" aus?.

mfg.
    Joachim

[Andy (Gast)]

Hallo,

Danke für die rasche Antwort. Ich habs jetzt geschafft, dass der 
Empfänger im Sekundentakt Daten ausgibt (Hab die hw- und die swstacks am 
Anfang vergessen). Nur die Daten sind immer 0. Dh. der Text kommt nicht 
an!

Dann hab ich natürlich den Sender unter die Lupe genommen und siehe da: 
Der Text "Senden" kommt NICHT! Auch der andere Text ("Init", "Set 
Frequenz" ...) kommt nicht, sondern nur irgendwelche verstümmelte Daten.

Muss noch genauer gucken, was da los ist!

Aber trotzdem danke nochmal!

lg
Andy

[bastelbaer (Gast)]

"Verstümmelte" Daten sind ein Hinweis auf falsch gesetzte Quarz-Fuses. 
Das bedeutet normalerweise dass der Chip mit der falschen Quarzfrequenz 
läuft und dadurch die Baudrate falsch setzt.
Und mach, falls du im Empfängerproggi das "Wait 1" drin hast, das raus. 
Nur Nullen deutet immer noch auf einen falschen Anschluss hin, sodass 
rf12_ready den falschen PIN einliest. Insbesondere wenn der Sender dabei 
aus ist.

mfg.
    Joachim

[bastelbaer (Gast)]

@avrnix
Nimm ihn nur den Code. Ist GPL.

mfg.
    Joachim

[Andy (Gast)]

Hallo,

Habe jetzt alles gelöst! Der Sender sendet, und der Empfänger empfängt! 
Aber der Empfänger empfängt nur:

Empfange<\r><\n><\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-< 
\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0 
>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\r><\n>

Sonst würde alles klappen! Was kann da noch sein??


THX Andy

[Andy (Gast)]

Guten Morgen!

Kann ich irgendwie überprüfen, ob AM Modul etwas empfangen bzw. gesendet 
wird?

THX Andy

[Benedikt K. (benedikt)]

Andy wrote:
> Kann ich irgendwie überprüfen, ob AM Modul etwas empfangen bzw. gesendet

Senden: Mit einem Spectrum Analyser
Empfangen: Mit dem Oszi am Filter Kondensator des RSSI Pin messen:
http://www.mikrocontroller.net/attachment/22519/rfm01.JPG

[Andy (Gast)]

Hallo,

Danke für die Antwort, ABER: Einen Spectrum Analyser hab ich nicht und 
am RSSI Kondensator tut sich nichts - weder am Empfänger, noch am 
Sender!

Ich hab jetzt alles nochmal kontrolliert - richtig angeschlossen ist 
alles.

Kann es sein, dass ein Modul defekt ist? Woran würde ich das merken! 
Wenn ich den CLK Pin messe, bekomme ich ein Signal - ist das eine 
Garantie, dass das Modul funktioniert?

Ich bin am Verzweifeln!!

THX Andy

[Benedikt K. (benedikt)]

Wenn du meinen Code verwendest, dann kannst du die Frequenz am CLK Pin 
messen: Da sollten 10MHz rauskommen (standardmäßig sind das 1MHz). Durch 
die Software wird auf 10MHz umgeschaltet. Wenn das der Fall ist, kann 
man eigentlich davon ausgehen dass das Modul OK ist, und auch richtig 
angeschlossen ist.

[Andy (Gast)]

OK, da stimmt was nicht!

Beim Sender hab ich 10Mhz - beim Empfänger jedoch nur 1MHz. Da wird der 
Hund begraben sein. Werd nochmal die Anschlüsse kontrollieren. Wo könnte 
noch ein Fehler liegen bzw. gibt es noch eine einfache Möglichkeit die 
Funktionalität des Moduls zu testen??

THX Andy

[Benedikt K. (benedikt)]

Lade mal die Sender Software rein. Dann kannst du einen Softwarfehler 
ausschließen, da der Sender ja anscheinend funktioniert.

[Andy (Gast)]

Also, zuerst hat es mit der Sendersoftware funktioniert (nur die 10MHz). 
Dann ist er auf 1Mhz runtergesprungen und jetzt kommt am CLK gar nix 
raus!

Aber am SDO kommt was raus!

Ich glaub, das Modul ist im A...., oder gibt es noch Hoffnung?


THX Andy

[Benedikt K. (benedikt)]

Es könnte sein, dass die Software einfach nur den Takt abschaltet, also 
falsche Daten am Modul ankommen.
Was hast du mit dem Modul gemacht, wenn du denkst das es kaputt ist ?

[Andy (Gast)]

Naja, dann wäre der Takt bei beiden Modulen aus, oder!

Es könnte sein, dass ich einmal zuviel Spannung angelegt habe, habe 
irrtümlich 7V anstatt 5V angelegt - daher befürchte ich, dass es was 
abgekriegt hat!

[Andy (Gast)]

So, beide Module lassen sich nun auf 10MHz einstellen (Hab ein neues 
eingebaut), aber es kommen immer noch lauter Nullen??

Was is da los??

Nur so nebenbei: Haben die Einstellungen von SWStack, HWSTack und 
FrameSize etwas damit zu tun? Wie lauten denn die richtigen 
Einstellungen für einen Mega8 bzw. Mega48??

Danke
Andy

[Andy (Gast)]

Nochwas: Wie muss ich eigentlich den Antennen-Pin beschalten??

Ich weiß, ich bin nervig, aber ich kenn mich da nicht so aus!!

THX Andy

[Benedikt K. (benedikt)]

Ein 16cm langes Stück Draht dran.

[JR (Gast)]

Hallo Gemeinde!

Mir geht es so wie Andy.
Ich habe Sender und Empfänger mit ATMega8 aufgebaut. 10 MHz kommen
am Taktpin raus. Ich empfange nur Nullen. Hat jemand noch eine Idee?
Mir fällt im Moment nicht mehr viel ein.

Danke schon mal!
JR

[Stefan Krupop (Gast)]

Bei mir ging es erst, nachdem ich in RF12_RXData
RF12_Ready();
durch
while (!(RF12_Status() & 0x8000));
ersetzt hatte. Aber eigentlich möchte ich nicht jedes mal das 
Statusregister abrufen, um zu sehen ob ein neues Byte da ist. Gibt's 
vll. ne ähnliche Möglichkeit wie beim Senden? Im Datenblatt habe ich 
dazu nichts gefunden.

Stefan

[Benedikt K. (benedikt)]

Im Prinzip machst du mit dem Status lesen dasselbe wie ich auch, nur das 
ich  nur das 1.Bit und nicht den ganzen Status lese. Probier mal 
folgendes: Ersetze die rxdata Funktion durch diese hier:

void rf12_rxdata(unsigned char *data, unsigned char number)
{  unsigned char i;
  rf12_trans(0x82C8);      // RX on
  rf12_trans(0xCA81);      // set FIFO mode
  rf12_trans(0xCA83);      // enable FIFO
  cbi(RF_PORT, SDI);
  for (i=0; i<number; i++)
  {  rf12_ready();
    *data++=rf12_trans(0xB000);
  }
  rf12_trans(0x8208);      // RX off
}

Vielleicht liegt es ja daran, dass SDI high ist.

[Luke H. (bukados)]

Hallo Benedikt + Helfer,

vielen Dank für Eure Arbeit. Meine Test HW mit 2 x Atmega16 + RF01 + 
RF02 lief mit den Treibern auf Anhieb, d.h. nachdem ich meine 
Verdrahtungsfehler beseitigt hatte ;-)

Beim Empfang hatte ich lediglich das Problem, daß das letzte Byte 
manchmal falsch empfangen wurde. Ich habe dann ein bisschen 
experimentiert, hier die Lösung:
Beim Sender in der rf02_txdata Funktion eine extra Verzögerung einbauen, 
vor dem Abschalten des Chip Select und vor dem Ausschalten des 
Transmitters, erst dann traten bei mir keine Fehler mehr auf.

void rf02_txdata(unsigned char *data, unsigned char number)
{
  ...
  ...
  ...
  _delay_us(10);
  sbi(RF_PORT, CS);
  while(RF_PIN&(1<<IRQ));  // wait until transfer done
  _delay_us(10);
  rf02_trans(0xC464);    // TX off after 10us
}

[Humix (Gast)]

Das Problem mit dem letzten Byte tritt auch bei den RF12 Modulen auf.

Eine Anmerkung zur RF_Ready

Zeitweise bleibt das Programm in der RF12_Ready hängen 
--Endlosschleife--
daher habe ich ihr ein Timeout verpasst.

Sub Rf12_ready
  Reset Ss                   'Chip Select = 0
  For I = 1 To 30000
  If Miso = 1 Then Exit For
  Next
End Sub

[JBecker (Gast)]

Ich benutze den Kode von Benedikt und habe einige Zeit gebraucht, um 
zwei Module zur Zusammenarbeit zu bewegen (man 'sieht' ja leider nicht, 
ob der Sender wirklich sendet).
Ich bekam zuerst am Empfänger auch nur Nullen angezeigt, habe dann mit 
dem Oszi festgestellt, das die rf12_ready() immer sofort wieder 
verlassen wird, auch wenn überhaupt kein Zeichen gesendet 8und damit 
wohl auch nicht empfangen) wurde.
Der Grund ist aber eigentlich klar. Wenn man einen gut optimierenden 
Compiler verwendet, dann wird nach dem Aktivieren des CS sofort im 
nächsten Takt der Zustand des SDO abgefragt. Der Zustand ändert sich 
aber beim AVR erst einen Takt später. Also auf jeden Fall ein NOP 
einfügen.

void rf12_ready(void)
{ 
   RFM12_CS = 0;                        // cbi(PORTB, CS);
   __no_operation();
   while(!RFM12_SDO);                   // wait until FIFO ready
   RFM12_CS = 1;                        // sbi(PORTB, CS);
}

(Ja, ich hab's etwas umgeschrieben und ).

Läuft bei mir jetzt absolut stabil, vielen Dank an Benedikt für die 
Mühe.

Gruß,
Jörg.

[Benedikt K. (benedikt)]

@JBecker und Luke H.
Danke für die Fehler. Ich werde es sofort ändern.

@diejenigen bei denen sich das Programm bei rf12_ready() aufhängt:
Funktioniert die Software bei euch, wenn ihr den Code wie folgt ändert ?
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"

[Humix (Gast)]

@ Benedikt
Das Problem des hängens entsteht in dem Moment wenn RX aufgerufen wird
aber aus welchen Gründen auch immer nichts zum Empfangen da ist.
Wenn ich es richtig verstehe wird das erste bit vom Status nur high wenn 
der fifo gefüllt ist.
Oder habe ich da etwas falsch verstanden?

[Benedikt K. (benedikt)]

Ja, das stimmt.
Entweder sendet der Sender also nicht das Startzeichen, oder der 
Empfänger empfängt nicht.
Da die Software also prinzipiell lauffähig ist (da sie bei mir und bei 
anderen läuft), könnte es ein Timing Problem sein (so ähnlich wie der 
Fehler von JBecker, der ist bei mir ja auch nicht aufgetreten.) Daher 
die kleine Änderung an der Software. Vielleicht könnte man jemand bei 
dem es nicht geht, ausprobieren ob die Änderung was bringt.

Hier nochmal die Änderung in vereinfachter Form. Falls es darann liegt 
müsste es funktionieren:

void rf12_ready(void)
{  cbi(RF_PORT, SDI);
  cbi(RF_PORT, CS);
  asm("nop");
  while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
}

[JBecker (Gast)]

@ Humix
Man sollte auf jeden Fall, wie schon beschrieben, ein Timeout in der 
rf12_ready() einfügen.

Besser noch:
Ich würde gerne den IRQ-Ausgang des Moduls verwenden, habe damit aber 
bisher gar keinen Erfolg?!? Der Ausgang geht nur gaaaaaanz selten 
überhaupt mal auf high (und ich habe nicht herausgefunden, wann).

Es gibt noch einige Ungereimtheiten. Nach dem Senden sollte man auch 
warten, bis alle Daten 'raus sind, bevor man den Sender ausschaltet. 
Eine feste Wartezeit funktioniert zwar, besser wäre es aber wohl, 
hierfür irgendein Statusbit zu benutzen (wie gesagt, IRQ 'geht' bei mir 
nicht).

Wenn ich zuerst den Empfänger einschalte und dann den Sender, dann 
empfange ich immer nur das erste gesendete Zeichen, danach hängt der 
Empfänger.

Hmmm, da ist wohl noch etwas Arbeit nötig. Ich möchte die Module zum 
Fernschalten von Lampen (dimmen) und Geräten einsetzen (Hausautomation). 
Bevor ich die Platinen anfange, möchte ich nur wissen, das alles 
funktioniert.

Jörg.

[Humix (Gast)]

@ Benedikt
Da haben wir uns misverstanden . Die Software funktioniert !!
Es geht mir nur darum das wen ein Byte verloren geht das
Programm irgendwie aus der Rf__Ready Schleife herauskommen muß.

[Benedikt K. (benedikt)]

Du meinst, wenn irgendwo in der Mitte ein Byte verloren geht, oder wenn 
das Sync Word verloren geht ?

[Humix (Gast)]

Richtig. Kann ja auf der Funkstrecke mal passieren.

[Benedikt K. (benedikt)]

Wenn das Sync Word nicht ankommt, hängt der Empfänger eben. Da muss man 
halt vor die Empfangsfunktion anpassen (erst einschalten, dann abfragen 
ob Daten vorhanden sind, und falls ja dann empfangen.
Wenn aber während der Übertragung was verloren geht, dann interessiert 
das nicht: Nach dem Sync Word emfpängt das Modul egal was kommt, bis man 
das FIFO abschaltet.

[Andy (Gast)]

Hallo,

Ich hab jetzt bei rf12_ready das nop und bei rxdata das reset sdi 
eingebaut! Beides hat nichts gebracht!!
Ich empfange immer noch Nullen!

Ist vielleicht schon jemand weiter gekommen??


THX Andy

[Benedikt K. (benedikt)]

Seltsam. Jetzt wäre interessant zu wissen, was du anderst machst als 
z.B.  Humix, JBecker oder ich. Es ist leider sehr schwierig einen Fehler 
zu finden, der nur bei etwa der Häfte der Schaltungen auftritt. Hast du 
an der Software irgendwas verändert (außer zwischen Senden/Empfangen 
umgeschaltet) ?

[Andy (Gast)]

Nein, das einzige, das ich verändert habe, ist, dass ich anstatt 32 
Zeichen nur 8 sende, damit ich das im Terminal vernünftig ablesen kann.

Sonst hab ich nix verändert. Die Antenne ist 16cm lang! Aber an dem 
Kondensator bei RSSI messe ich auch kein Signal!!

Irgendetwas stimmt da nicht!

[Benedikt K. (benedikt)]

Hast du mal die unveränderte Software ausprobiert (also nur 
Senden/Empfangen etsprechend angepasst) ?
Welche Optimierungseinstellungen verwendest du ? Ich habe aus -o2 
gestellt, da dies meiner Meinung nach das optimalste ist.

[Andy (Gast)]

Was meinst du mit Optimierungseinstellungen? Ich arbeite mit Bascom!

Außerdem ist mir aufgefallen, dass beim Sender bei der RS232 folgendes 
rauskommt: D-i-e-s- -i-s-t-<\r><\n>Sende<\r><\n>

Müsste "Sende" nicht zuerst kommen??

Fragen über Fragen....

[Benedikt K. (benedikt)]

Achso, du verwendest das Bascom Programm. Da kann ich dir leider nicht 
weiterhelfen, für Bascom Probleme musst du dich an bastelbär wenden.

[Andy (Gast)]

@bastelbär
Hallo, kannst du mir vielleicht weiterhelfen??


THX Andy

[Andy (Gast)]

Nochetwas: Welche Fuses muss ich setzen?? Vielleicht liegt hier das 
Problem!!

Ich setze meine Fuses mit AVR Studio 4. Vielleicht kann mir wer einen 
Screenshot posten!!


THX Andy

[JBecker (Gast)]

So langsam fange ich wohl an zu verstehen, wie der Empfängerteil im RF12 
funktioniert:

Nach dem Einschalten des Empfängers und der Initialisierung des FIFO 
wartet der Empfänger auf die Präambel und das Sync Word. Danach werden 
kontinuierlich Daten in den FIFO geschoben. Man kann jetzt beliebig 
viele Bytes auslesen, auch wenn gar keine mehr gesendet (und empfangen) 
werden. Die Abfrage, ob Daten vorhanden sind, ergibt immer wieder ein 
positives Resultat. Daher die Nullen, die einige beobachten (und ich 
teilweise auch).

Für eine vernünftige Datenübertragung sollte man also die Daten beim 
Senden in Paketen blocken, also eventuell ein Protokoll wie STX/ETX oder 
SLIP verwenden (möglichst mit Checksumme), bei dem man eindeutig (den 
Anfang und) das Ende des Blocks erkennen kann.
Beim Empfang liest man dann solange Daten ein, bis man das 
Paket-Endezeichen bekommt. Dann kann man den Empfang beenden (oder 
Abbruch nach einer bestimmten maximalen Anzahl von Zeichen).

Um beim Senden nicht eine Wartezeit nach dem letzten Zeichen einfügen zu 
müssen, kann man auch einfach ein bis zwei Füllbytes senden.

Mit Bitte um Kommentare ......

Jörg.

[Benedikt K. (benedikt)]

Ja, genauso ist es. Die Idee mit dem Ende Zeichen ist gut. Wenn man 
allerdings nur Steuersignale mit einer festen Länge überträgt, kann man 
auf das Endzeichen verzichten, und hat damit schonmal eine Fehlerquelle 
weniger.

[Andy (Gast)]

Guten Morgen,

Kann mir vielleicht jemand die Sende- und Empfangsroutinen (in Bascom) 
erklären, damit ich auch ein bisschen weiß, was da eigentlich passiert!

Warum wird zum Beispiel 3x hintereinander &HB8AA gesendet, bevor die 
Daten übertragen werden, usw.

Wäre euch sehr dankbar!!


Danke,
Andy

[Andy (Gast)]

Nochwas:

Wenn ich in der Empfangsroutine anstatt von Temp = Rf12_trans(&Hca83) 
den Befehl Temp = Rf12_trans(&Hca87) ausführe (Verwenden von Syncword 
ein), dann lese ich irgendetwas anderes als dauernd 0 aus! Nur sind 
diese Daten nicht das, was ich mit dem anderen Modul sende. Wenn ich den 
Sender ausschalte, kommt der gleiche Mist an!!

Ich kenn mich nicht mehr aus! Irgendwie komm ich mit diesem sch... Modul 
nicht weiter. Hab bei Pollin schon 3 weitere bestellt - vielleicht sind 
meine defekt!

Wäre aber trotzdem für Infos über die Sende- und Empfangsroutine 
dankbar!

mfg
Andy

[Andy (Gast)]

Ähhmm...   Temp = Rf12_trans(&Hca87) bedeutet natürlich: Verwenden von 
SyncWord aus!!

[Benedikt K. (benedikt)]

Das deutet darauf hin, dass entweder die Frequenz oder 
Baudrateneinstellung von Sender und Empfänger nicht übereinstimmen, oder 
der Sender einfach nicht sendet.

Gibt es eigentlich jemanden, bei dem das C Programm noch nicht läuft ?

[Andy (Gast)]

Aber an den Baudraten und Frequenzeinstellungen hab ich nix verändert! 
Kann es daran liegen, dass der Sender und der Empfänger (nur die Atmels) 
mit zwei verschiedenen Quarzen laufen?? (Empfänger mit 8Mhz und Sender 
mit 4Mhz)

[Benedikt K. (benedikt)]

Daran dürfte es eigentlich nicht liegen, da die Baudrate im Modul 
erzeugt wird.

[Andreas P. (andyp17)]

Ob der Sender sendet, kann ich ohne Spectrum Analyzer nicht feststellen, 
oder??

Andy

[Benedikt K. (benedikt)]

Mit einem passenden Funkgerät würde es noch gehen, oder zur Not mit 
einem TV (das müsste Kanal S38 sein). Keine Ahnung was man auf dem TV 
erkennen kann, wie und fein man heutige TVs abstimmen kann, aber 
zumindest bei älteren TVs ohne automatischem Sendersuchlauf sollte man 
die 1s Sendeimpulse im Ton hören wenn die Frequenz passt.

[Andreas P. (andyp17)]

OK, hab ich beides nicht in der Firma. Mal sehen, ob ich die Dinger mit 
nach Hause nehmen kann.

Ansonsten hat keiner eine Idee, was da sein könnte, oder?? Das gibt es 
ja nicht - bei allen funktioniert es, nur bei mir nicht. Entweder bin 
ich zu blöd (was ich langsam glaube gg) oder meine Module sind 
wirklich defekt! Aber dann könnte ich doch überhaupt nichts auslesen, 
oder. Und auch die Frequenz lässt sich einstellen!

Ich steh jetzt echt an!!!

mfg
Andy

[Claude (Gast)]

Also bei mir läuft Benedikts C Programm ohne Probleme. Den Sender hab 
ich mit einer TV Karte auf Kanal S37 mit einwenig Finetuning gefunden,
man hört den Datenstream im Tonkanal.
Werde am Wochenende mal versuchen den Stream mit Gnuradio zu dekodieren.

Ich hab mal eine Verständnissfrage:
Wie JBecker schon meinte Signalisiert der Empfänger nicht wenn das 
Empfangene Byte/Daten vom FIFO abgeholt wurde. Welche Funktion hat dann 
das FFIT Signal? Lt. Datenblatt geht FFIT ja LOW wenn der FIFO Füllstand 
unter den Programmierten Wert des FIFO IT Levels fällt.
Wenn ich nun den FFIT Ausgang des Moduls an einen Interrupt Pin des
AVRs hänge, sollte ich doch mitbekommen wenn das Modul den FIFO geleert 
haben will und wenn der FIFO leer ist?

[Benedikt K. (benedikt)]

Claude wrote:
> Wie JBecker schon meinte Signalisiert der Empfänger nicht wenn das
> Empfangene Byte/Daten vom FIFO abgeholt wurde. Welche Funktion hat dann
> das FFIT Signal?

Das gibt an, ob im FIFO mehr Bits sind, als das eingestellte Level. Bei 
mir signalisiert FFIT also ob ein komplettes Byte im FIFO ist oder 
nicht.
Ich verwende aber nicht den FFIT Pin, sondern lese das Bit über das 
Statusregister aus, um einen Pin zu sparen.
Bei all denjenigen wo das Programm hängt, müsste also der FFIT Pin auf 
Low liegen. Denn im Gegensatz zum INT Pin ist der FFIt Pin high aktiv.

[Andreas P. (andyp17)]

@Benedikt:
Ich habe noch eine Idee. Wäre es möglich, dass du mir 2 Hex-Files mit 
deinem C-Programm machst. Das wäre super, dann würde ich gleich sehen, 
ob es am Modul oder am Programm liegt, oder?

Der Sender wäre ein Mega48 mit 8Mhz und der Empfänger ein Mega8 mit 
4Mhz. SPI-Pins nicht vergessen!

Das wäre ganz nett von dir - nur wenn du Zeit hast!!

Vielen Dank schon im Voraus!!


mfg
Andy

[Claude (Gast)]

@Benedikt
Ok, danke für die Erleuchtung :-) Ich hab momentan das Problem das der 
AVR in der while schleife im rf12_ready hängen bleibt wenn das rfm12 
keine Daten empfängt. Werde mal versuchen mit dem FFIT Pin und einer IRQ 
Routine das ganze
ans laufen zu bekommen.

@ Andy
Warum lädst Du dir nicht einfach WinAVR runter und probierst es selber? 
Ein Makefile findst Du im Anhang. Für deinen Mega48 musst Du noch im 
Makefile die Zeile "MCU = atmega8" in "MCU = atmega48" ändern und in 
rf12.c noch deine
Quarzfreuenz einstellen.

[Benedikt K. (benedikt)]

Ich erstelle jetzt mal 2 Hexdateien, beide für einen mega8 für Sender 
und Empfänger, teste die mal bei mir an einer Minimalhardware und wenn 
beide sicher funktionieren, dann lade ich die hier hoch (vermutlich 
heute Nachmittag bis Abend.) Das sollte dann bei jedem funktionieren.
Falls nein -> Hardwarefehler, ansonsten liegt es an der Software.

[Benedikt K. (benedikt)]

Hier 2 Programme, die bei mir mit einem Minimalaufbau laufen:
RFM12 an einen mega8 gelötet. Der hängt über einen FT232 am PC.
Sonst sind keine weiteren Bauteile verbaut (weder Quarz, noch 
Kondensatoren oder sonstwas). Den mega8 habe ich mit dem internen 8MHz 
Takt laufen.
Die Module sind am SPI Interface angeschlossen, verwenden dieses aber 
nicht (Software SPI.)
Die Hex Dateien kann man direkt den AVR brennen.

Jetzt bin ich mal gespannt.

[Andreas P. (andyp17)]

JJJUUUUUUUUHHHHHHHHHHHUUUUUUUUUUUUU!!!!!

Es kommt die Meldung Empfänger läuft und dann im Sekundentakt "Dies ist 
ein 433MHz-Test". Und ein bisschen wirres Zeug herum!!

Wow, danke!! Hast mir sehr geholfen! Jetzt muss ich nur mehr rausfinden, 
warum das mit Bascom nicht funzt!! Irgendeine Idee? gg


Danke nochmal!!

Andy

[JBecker (Gast)]

>Claude wrote:
>> Wie JBecker schon meinte Signalisiert der Empfänger nicht wenn das
>> Empfangene Byte/Daten vom FIFO abgeholt wurde. Welche Funktion hat dann
>> das FFIT Signal?

Ähm, das muss ich relativieren. Wenn man den Portpin, an dem man FFIT 
angeschlossen hat, auf Eingang schaltet, dann kommt da schon was an :-)
Es liegt übrigens am FFIT exakt das gleiche Signal an, welches Benedikt 
mit seiner rf12_ready Routine am SDO-Pin abfragt. Man gewinnt also durch 
den zusätzlichen Pin eigentlich nicht viel. Den IRQ-Pin benutze ich 
nicht, weil hier ein Gemisch von allen möglichen Statusbits ver-odert 
anliegt, damit kann ich momentan nicht viel anfangen.

In der rf12_ready habe ich ein timeout eingebaut:

U8 rf12_ready(void)
{  U16 timeout = 1000;
  
   RFM12_CS = 0;                        // cbi(PORTB, CS);
   __no_operation();
   __no_operation();
   while((!RFM12_SDO)&&timeout)
   {
      timeout--;
      __delay_cycles(10);               // wait until FIFO ready
   }
   RFM12_CS = 1;                        // sbi(PORTB, CS);
   if(timeout==0)
      return 0;
   else
       return 1;   
}

und in rx_data liefere ich als Rückgabewert die Anzahl gelesener 
Zeichen:

U8 rf12_rxdata(U8 *data, U8 number)
{ 
   U8 i;
    
    FLAG5 = 1;
    rf12_trans(0x82C8);     // RX on
    rf12_trans(0xCA81);     // Init FIFO
    rf12_trans(0xCA83);     // enable FIFO
    for (i=0; i<number; i++)
    { 
       FLAG4 = 1;
       if(rf12_ready())
          *data++ = (U8)rf12_trans(0xB000);
       else
           break;
       FLAG4 = 0;
    }
    rf12_trans(0xCA81);     // disable FIFO
    rf12_trans(0x8208);     // RX off
    FLAG5 = 0;

    return i;
}

So kann ich im Empfangsprogramm einfach rx_data aufrufen und bekomme 
entweder die Anzahl der gelesenen Zeichen, oder aber 0, wenn während der 
timeout-Zeit keine Daten empfangen wurden. Klappt schon ganz gut (also 
eigentlich perfekt).
Das Blocken der Daten in Paketen kommt als nächstes (morgen ist ja 
Feiertag).

Gruß,
Jörg.

[Uli (Gast)]

Hallo

Hier Die LIB für EAGLE der Module RFM 01,02 und 12

Gruss
Ulrich

[Georg E. (Gast)]

Hallo Benedikt,

ich habe hier Dein Programmierbeispiel gefunden, nachdem ich mit dem 
Code-Beispiel von Pollin fast verzweifelt hatte, war Dein super 
strukturierter Code die wahre Wohltat.

Ich habe mir von Pollin zwei Funk Eval Boards zugelegt, jeweils mit 
RFM12 und ATmega32-16 bestückt.
Die Verdrahtung ist zwar etwas anders als bei Deiner Hardware, aber mit 
wenigen Änderungen (Pin defines und Pullup programmieren) lief Deine 
Software auf Anhieb !!!!

Danke für dieses Stück gute Arbeit !!!


Georg

[Malte (malthy)]

Hallo zusammen!

Mich würde interessieren, ob es jemand mittlerweile geschafft hat, die 
Module unter Bascom richtig anzusprechen. Ich würde das RF12 nämlich 
gerne im Zusammenhang eines kleines Roboterprojektes einsetzen, dass 
ansonsten auf Bascom basiert.

Gruß&Dank!
Malte

[Humix (Gast)]

Das Basicprogramm von Bastelbär in diesem Thread funktioniert!!!

[Malte (malthy)]

Okay, sorry! Ich hatte die Probleme die Andy hatte, als Probleme des 
Bascom-Codes interpretiert. Danke für den Hinweis!

Gruß,
Malte

[Uli (Gast)]

Hallo@all

Der Code von Benedikt K. funktioniert, wie in diesen Thrad schon 
angesprochen bei mir nur mit NOPs in RF_Ready.
Im Freien komme ich auf etwa 150m! Interessant wäre für mich noch ein 
Verstärker um die Reichweite zu erhöhen.

Gruss
Ulrich

[Marius S. (lupin)]

Kommuniziert bei benedikts letzten beispiel das RFM12 modul mit sich 
selbst?

Meine Idee ist so ein Modul per software usb an den PC zu bringen. Ist 
es eigentlich wichtig wie die Daten die ich sende aussehen? Bringt es 
vielleicht die irgendwie zu kodieren (nicht in Bezug auf Sicherheit 
sondern in Bezug auf Reichweite/Stromverbrauch oder sonstige komischen 
Effekte)?

[Benedikt K. (benedikt)]

Marius Schmidt wrote:
> Kommuniziert bei benedikts letzten beispiel das RFM12 modul mit sich
> selbst?

Nein, ein Modul kann nicht gleichzeitig senden und empfangen.

> Meine Idee ist so ein Modul per software usb an den PC zu bringen. Ist
> es eigentlich wichtig wie die Daten die ich sende aussehen? Bringt es
> vielleicht die irgendwie zu kodieren (nicht in Bezug auf Sicherheit
> sondern in Bezug auf Reichweite/Stromverbrauch oder sonstige komischen
> Effekte)?

Manchester Kodierung bringt vermutlich ein kleinwenig, da die Bittakt 
Wiederherstellung dann einfacher wird. Zwingend notwendig ist das aber 
nicht, solange es ausreichend Flanken im Datenstrom gibt.
Ich teste gerade einen 8-4 Hamming Code, der eigentlich immer 
ausreichend Flanken in einem Byte erzeugt. So benötigt man zwar auch 
16bit für 1Byte Nutzdaten, aber dafür kann man immerhin noch ein 
falsches Bit wieder korrigieren.

[Marius S. (lupin)]

Vielleicht kann man das ja hiermit kombinieren:
http://www.jrobot.net/Projects/AVRcam.html

Ist irgendwie logisch, dass das modul nicht beides gleichzeitig kann, 
schließlich hat es ja nur eine Antenne :-)

[Claude S. (claudeschwarz)]

Um den Thread etwas zurück zu geben,
eine kleine Bastelei von mir. Das RFM12 als Bidirektionaler RS232 
Tunnel.

Folgendes ist bis jetzt Implementiert:
- Basierend auf Benedikts Code
- Timeout für RX , wie von JBecker beschrieben.
- STX/RTX Stack von der Procyon AVRlib.
- Verpacken von UART RX Bytes in STX/ETX Packete .
- Entpacken von STX/ETX Packeten und schicken an den UART.
- Erkennen von validen STX/RTX Paketen (STX,ETX,CRC).
- Bidirektional Half Duplex mit 1200 Baud.

Was noch fehlt :
- Neuanforderung von STX/ETX Paketen falls diese nicht valid sind.
- Nutzung aller Features der STX/ETX Library.
- Sauberer Code ...
- Schneller Code ...

Als Testhardware habe ich 2 ATmega8 mit 14,7456MHZ Quarzen benutzt.
Das RFM12 ist ,wie in Benedikts Code, nur mit 4 Leitungen am ATmega.

PS: Bitte klopft nicht zu arg auf mich ein, Programmieren ist nicht so 
mein Ding. Das Werkzeug meiner Wahl ist der Lötkolben,und so 
Programmiere ich auch :-)

[Avr N. (avrnix)]

Was ist ein STX/ETX Packet und was warum sollte ich das noch Tunneln?
Ich verstehe den Sinn der Anwendung nicht kannst du das mal erläutern?

[linker (Gast)]

http://hubbard.engr.scu.edu/avr/avrlib/docs/html/group__stxetx.html

[Claude S. (claudeschwarz)]

Auszug aus der Beschreibung der STX/ETX Lib von Procyon :

STX/ETX is a simple packet protocol for serial data streams
and offers packetization, type tagging, and checksum protection
for user data.
Common uses of STX/ETX might include radio communications
were it can improve data reliability over lossy channels.
STX/ETX may also be used effectively anywhere multiple access
to the communication medium is required.
The packets can be made to contain destination addresses
or routing information as well as data.

Ich benötige das STX/ETX für meine Anwendung. Als Test hab ich die RS232 
durchgetunnelt.
Gruß
Claude

[Bingo (Gast)]

@Benedikt K

Brauchst du die code von hier ??
Beitrag "Re: RMF12 - Funkmodul"

Ich habe diser kode testet (ohne einer rf modul) , und die tabelle 
version ist sehr schnell.

Ich kriege hoffentlich 4 modules von Pollin morgens , und auch von die 
sammelbestellung.

mfg
Bingo
Dänemark

[Marvin e. (maavin)]

Ohmann, Fossie...

da haste mir ma ein Ei gelegt :)

Die Bascom Version läuft wunderbar, man muss nur wissen, dass bei

"Spi_sdo Alias Pinb.6    ' MOSI-PIN"

der "MISO" Pin gemeint ist!

>_<

Das hat mir und möglicherweise noch ein paar anderen die nicht den 
Mega32 verwenden und von daher die Pins umdefinieren müssen "das Genick 
gebrochen"...

Aber einen Vorteil hatte es, ich hab kurz vorm Seppuku noch eine "Soft 
SPI" Routine (angelehnt am C Code) geschrieben:

' werden benötigt für rf12_ready bzw SoftSPI (Definitionen für Mega8)
Spi_sdi Alias Portb.3                          ' MOSI-PIN
Config Spi_sdi = Output

Spi_sck Alias Portb.5                          ' Clock-Pin
Config Spi_sck = Output

Spi_cs Alias Portb.2                           ' SS-Pin
Config Spi_cs = Output

Spi_sdo Alias Pinb.4                           ' MISO-PIN

...
...
...

Function Rf12_trans(byval Wert As Word) As Word
 Dim I As Integer

 Reset Spi_sck
 Reset Spi_cs

 For I = 0 To 15

  If Wert.15 = 1 Then
   Set Spi_sdi
  Else
   Reset Spi_sdi
  End If

  Shift Wert , Left , 1

  If Spi_sdo = 1 Then
   Wert = Wert Or 1
  End If

  ' clock
  Set Spi_sck
  $asm
    nop
    nop
  $end Asm
  Reset Spi_sck

 Next I

 Set Spi_cs

 Rf12_trans = Wert

End Function

Und die ready methode noch abgeändert:

Sub Rf12_ready
  Reset Spi_sdi
  Reset Spi_cs

  $asm
    nop
    nop
  $end Asm

  While Spi_sdo = 0
  Wend
End Sub

Ich hoffe das war das Problem.

[Matze (Gast)]

Ich habe gestern endlich meine Module bekommen und gleich eingebaut. Ich 
benutze sie am Tiny44. Leider funktioniert der Code beim senden nicht. 
Der Code hängt sich in der rf02_txdata() auf. Die Inits davor werden 
aber ausgeführt.
Da ich nur Pins an 2 Versiedenen Ports zur verfügung habe, habe ich den 
Code etwas angepasst. Oder hat der Code irgendwo noch ein Bug, weil das 
die erste Version (Post vom 16.04.2007 15:28) ist. Wie kann ich weiter 
vorgehen bei der Fehlersuche?

[Benedikt K. (benedikt)]

Verwendest du irgendwelche Interrupts ?

[Matze (Gast)]

Ja, hab aber erstmal zum testen sei() nicht gesetzt.

[Matze (Gast)]

P.S. ich habe die Leiterplatte mit einem Tropfen Sekundenkleber an der 
Unterseite mit einem Balsaholz verbunden. Ist Sekundenkleber leitfähig, 
oder greift es die Leiterbahnen an?

[Matze (Gast)]

So neue Info: Es hängt bei der Funktion:
void rf02_shiftout(unsigned char wert)
{  unsigned char j;
  for (j=0; j<8; j++)
  {  while(RF_PIN&(1<<IRQ));
    while(!(RF_PIN&(1<<IRQ)));   <-Diese Schleife läuft ewig!!!!!!!!!!
    if (wert&128)
        sbi(RF_PORT, SDI);
      else
        cbi(RF_PORT, SDI);
      wert<<=1;
    }
}

[Benedikt K. (benedikt)]

Hast du ein Oszilloskop ?

Falls ja, dann sollte and der nIRQ (=SDO) Leitung kurze Impulse im 
Baudratentakt zu sehen sein.
Falls ja, dann überprüfe ob die an dem Pin landen, der abgefragt wird.
Liegen am CLK Pin 10MHz oder 1MHz an ?

[Matze (Gast)]

hab leider kein oszi. Nur ein Frequenzmesser bis 200KHz.

[R. M. (rmax)]

Matze, könnte es vielleicht sein, daß Du den IRQ-Pin am falschen Port zu 
lesen versuchst? Weiter oben hattest Du ja geschrieben, daß die Pins 
über zwei Ports verteilt sind.

Poste doch mal Deine Pinbelegung und die entsprechenden #define-Zeilen 
für RF_PIN, RF_PORT, usw.

[Matze (Gast)]

Die Defines stehen in der C Datei (siehe Post 22.05.2007 08:42 )
B2=Csel
A4=SCL
A5=SDI
A6=IRQ

[R. M. (rmax)]

Ah - sorry, das Attachment hatte ich übersehen.

Mir ist noch aufgefallen, daß Du util/delay.h inkludierst ohne vorher 
F_CPU zu definieren. Das ist OK, wenn Du den Tiny44 mit 1MHz taktest 
oder F_CPU in einem vorher inkudierten Header oder an der 
gcc-Kommandozeile definierst.
Falls der Controller aber schneller getaktet ist und F_CPU nicht 
entsprechend gesetzt wird, sind Deine Delays zu kurz und das kann dazu 
führen, daß das Modul das Sendekommando nicht erkennt und Dir deshalb am 
IRQ-Pin keine Takte liefert.

[Matze (Gast)]

Ich habe den Takt mit 8MHz definiert, derzeit läuft mein Controller aber 
nur mit 1MHz um zu schnelles schalten zu vermeiden.

[R. M. (rmax)]

Hast Du es denn schonmal mit 8MHz versucht, vielleicht ist die CPU ja 
mit 1MHz zu langsam? Auf jeden Fall sollte F_CPU der tatsächlich 
eingestellten Taktfrequenz entsprechen, damit die Delays die korrekte 
Dauer haben.

Noch ein Gedanke: Hast Du schonmal untersucht, ob die Schleife gleich 
beim ersten Aufruf von rf02_shiftout hängen bleibt, oder erst nachdem 
schon ein paar Bytes zum Modul geschickt wurden?

[Benedikt K. (benedikt)]

1MHz ist definitiv zu langsam: Die zu erkenenen Impulse haben 1,6µs. 
Vielleicht solltest du besser die USI oder einen Interrupt nutzen, 
anstelle der Software Routine.

[Andreas P. (andyp17)]

Hallo,

Hab noch eine ganz andere Frage.

Und zwar: Woran kann es liegen, dass Zeichen "verschwinden" (bei der 
Übertragung)? Ich will eigentlich nur 3 Byte übertragen. Das erste kommt 
immer an und die letzten zwei nur selten oder falsch.

Was kann da sein?


THX Andy

[Benedikt K. (benedikt)]

Das liegt am Sendepuffer. Der fasst 2 Byte, die noch nicht übrtragen 
sind wenn der Sender abgeschaltet wird.
Hier mal die neueste Version, wo alle mir bisher bekannten Fehler 
behoben sind.

[Andreas P. (andyp17)]

Und warum funktionierts dann mit der Version, wo 32 Byte übertragen 
werden??

[Benedikt K. (benedikt)]

Da funktioniert es nicht so ganz, aber das merkt man nicht, da die 
letzen paar Zeichen "!\n" sind.

[Andreas P. (andyp17)]

Hallo,

OK, ich will 3 Bytes übertragen, d.h. ich muss eigentlich 5 Bytes 
übertragen, weil die letzten beiden irgendwie verschwinden, oder?
Das habe ich nun gemacht und es funktioniert jetzt auch besser als 
vorher. Nur hab ich nochwas komisches festgestellt! Wenn ich z.B. 02 FF 
03 übertrage, klappt das wunderbar - immer wieder. Nur wenn ich 02 01 03 
sende, dann kommt der Wert 02 immer an und die folgenden nur manchmal. 
D.h. wenn ich in der Mitte der 3 Bytes eine höhere Zahl sende, klappt es 
gut, nur bei kleineren funktionierts nicht richtig.

Woran kann das nun wieder liegen??


THX Andy

[Benedikt K. (benedikt)]

Vielleicht sind dem Empfänger zu wenige Pegelwechsel in den Daten. Da 
müsste eine Manchestercodierung helfen.

[Matze (Gast)]

Der AVR, der das Sendemodul ansteuert läuft jetzt wieder mit 
8MHz(interne Clock).

Ich habe jetzt einen alten AVR auf externe Clock gestellt und habe den 
CLK vom Sendemodul genommen so konnte ich die Frequenz des Senders 
messen. Der Sender läuft nur mit 1 MHz!
Bedeutet das dass die InitRoutine schon nicht funktioniert?

[R. M. (rmax)]

Matze wrote:
> Bedeutet das dass die InitRoutine schon nicht funktioniert?

Ja.

[Luke H. (bukados)]

@Andreas:
Wenn im Empfangsstream zu wenig Pegelwechsel vorliegen, dann kann der 
Empfänger den Takt nicht genau genug rekonstruieren.
Mögliche Abhilfe: Bit- oder Byte Stuffing.
Ich würde erstmal mit Byte Stuffing anfangen, d.h. wenn in einem Byte 
weniger als z.B. Vier "1"en vorkommen, dann einfach ein Füllbyte "0xAA" 
hinterher senden. Im Empfänger muß dann das Füllbyte natürlich wieder 
entfernt werden.
Wenn das nicht genügend funktioniert, muß man wohl auf Bit Stuffing 
umsteigen was aber wesentlich mehr Performance frisst.

[Matze (Gast)]

@Reinhard Max
und woran kann das liegen?

Bei meinem Versuch ist mir einwas aufgefallen. Ich habe den Test AVR 
über 2 ca. 10cm lange Kabel (aus einem alten LPT Druckerkabel) mit dem 
Clocksignal versorgt. Doch der AVR lief nicht an. Erst als ich die Kabel 
auf ca. 3cm erkürzt habe lief der AVR.
Den Sender habe ich mit den gleichen Kabeln am Tiny angeschlossen.Das 
sieht dann so aus: 3cm Kabel, Steckbuchse, 3cm Kabel (Kabellänge der 
einzelnen Adern teilweise unterschiedlich lang)
Kann das sein dass das eigentlich Problem an den Kabeln liegt? Hab 
leider mit HF, EMV und co. nicht so viel Erfahrung. Wenn ja wie sollte 
ich es ändern und auf was muss ich achten?

[R. M. (rmax)]

Matze wrote:

> Kann das sein dass das eigentlich Problem an den Kabeln liegt?

Gut möglich. Ich wollte Dir eh schon vorschlagen die Verbindung zwischen 
AVR und Funkmodul nochmal zu überprüfen.

Wenn die Kabel zu lang sind (und auch noch unterschiedlich lang) kann es 
durchaus sein, daß am Funkmodul die Signale an der Daten- und 
Taktleitung so verschliffen sind, daß sie nicht mehr ordentlich erkannt 
werden. Außerdem fangen die Leitungen sich mit zunehmender Länge (und 
ohne Abschirmung) leichter Störungen ein.

[Jörg B. (manos)]

Was für eine Distanz kann man eigentlich ohne Antenne überbrücken mit 
den Modulen?

[Uwe .. (uwegw)]

Mit 15cm Draht am Sender (hab ich fest angelötet, kann ich also nicht 
einfach abnehmen) komme ich auf 10m Meter störungsfrei bis zum Empfänger 
ohne Antenne (bzw. eine Kontaktreihe auf dem Steckbrett, macht ca. 1,5cm 
effektive Länge)

[Andreas P. (andyp17)]

Hallo,

Wie geht das genau, wenn ich nur etwas empfangen will, wenn der Sender 
gesendet hat. Kann mir jemand dazu Auskunft geben?

THX Andy

[Uli (Gast)]

Hallo,

Hier mal mein USB_Funk Module!

Gruß
Ulrich

[Michael (Gast)]

Hallo Ulrich,
sehr schön gemacht und auch gut dokumentiert (so wie man es von Dir 
gewohnt ist). Kannst Du mir vielleicht kurz erklären, warum Du MISO mit 
R4 (welchen Wert hat der eigentlich?) auf 5V ziehst? Hab ich bisher noch 
nicht gesehen.

ciao Michael

PS: Der Link auf Deiner Seite auf die Zip-Datei funktioniert nicht.

[Uli (Gast)]

Hallo,

Der Widerstand hat den Wert von 10K, ohne diesen gab es bei mir ein 
Problem mit dem Bus. Der Link auf meiner HP sollte nun auch gehen.
Mehr Doku kommt noch!

Gruss
Ulrich

[Claude (Gast)]

Hallo Ulrich und Thread,

im Anhang mal mein RFM12 USB Stick (Schnellschuss!). Das Ganze passt in 
ein Hammond Mfg. 1551H Gehäuse 60x35x20mm . Den AVR im Stick kann man 
per STK500 Protokoll updaten.
Auf dem Steckbrett läuft das ganze schon relativ gut.
Habe gestern mal einen Reichweiten Test gemacht, konnte damit 4 
Stockwerke überbrücken und was mich am meisten beeindruckt hat war die 
Tatsache das die Kommunikation sogar im Fahrstuhl (faradayscher Käfig) 
über 3 Stockwerke hinweg funktioniert hat.

Sobald ich die Tage Abends mal etwas Zeit finde werde ich mir die 
Leiterplatten mal Ätzen.

Gruß
Claude

[Andreas P. (andyp17)]

Hallo,

So, ich hab jetzt meine Daten Manchester-codiert (wegen des 
Pegelwechsels). Dann sende ich nach meinen Nutzdaten noch 2 Byte 
Wirr-Warr hinterher (weil der Empfänger ja 2 Bytes "frisst"), aber es 
funktioniert immer noch nicht ordentlich. Die Daten kommen an, wie sie 
wollen. Zweimal kommen sie vollstädnig an, dann wieder 3 mal nicht usw. 
Was kann da sein?

Ich verwende noch die Variante von ganz oben, d.h. ich frage dauernd den 
Buffer ab, auch wenn nichts gesendet wurde. Liegt darin der Fehler?

Bin für jede Hilfe dankbar!

THX Andy

[Benedikt K. (benedikt)]

Verwendest du das Programm von ganz oben, oder diese rf12.c ?
http://www.mikrocontroller.net/attachment/23418/rf12.c

Die erste Version hatte noch ein paar kleinere Fehler, die bei der neuen 
Version behoben sein sollten (inklusive dem Verschlucken der 2 Bytes.)

[Andreas P. (andyp17)]

Naja, das Problem ist, dass ich Bascom verwende, und ich C nicht so 
beherrsche!

Aber gibt es nicht eine Möglichkeit, dass den Buffer nur auslese, wenn 
ich auch wirklich etwas gesendet habe??

[Benedikt K. (benedikt)]

Dazu musst du die Software anpassen:
- Empfänger einschalten.
- den Status auslesen (FFIT bit)
- Nur wenn dieses gesetzt ist, sind Daten im Puffer.

Also im Prinzip die Empfangsfunktion zerlegen und die einzelnen Teile in 
dein Programm einbauen.

[Andreas P. (andyp17)]

Das heißt, ich muss trotzdem immer ein Bit auslesen, oder? Oder gibt es 
vielleicht einen Pin, der den Pegel beim Empfang von Daten ändert??

[Benedikt K. (benedikt)]

Ja, der FFIT Pin. Aber ob du den einließt, oder den SDO Pin ist 
eigentlich egal (denn das FFIT Bit wird als erstes am SDO Pin 
ausgegeben, wenn SDI und nSEL low sind). Daher habe ich mich für die SDO 
Version entschieden, da man so einen Pin spart.

[Andreas P. (andyp17)]

Hallo, danke nun mal für deine Antworten.

Ich möchte das ganze gerne mit dem FFIT-Pin lösen. Ich habs nun selbst 
versucht, aber irgendwie klappt das nicht! Ich komme jetzt nur in die 
rx-Routine, wenn der FFIT-Pin HIGH wird, aber da sind keine Daten im 
Buffer.

Kannst du mir vielleicht kurz aufzählen, was ich wie aktivieren muss, 
damit ich meine Daten bekomme? Und was kann ich jetzt von deinem 
Programm weglassen, weil ich den FFIT-Pin verwende!

Wäre echt cool, wenn du mir da weiterhelfen könntest!!

Vielen Dank!!

mfg
Andy

[Benedikt K. (benedikt)]

Andreas Posch wrote:
> Kannst du mir vielleicht kurz aufzählen, was ich wie aktivieren muss,
> damit ich meine Daten bekomme? Und was kann ich jetzt von deinem
> Programm weglassen, weil ich den FFIT-Pin verwende!

- Empfänger einschalten
- FIFO Modus Einschalten
- FIFO einschalten (Sync Word Erkennung aktivieren)

- FFIT Pin abfragen, wenn high Daten empfangen
- Wenn Daten empfangen, FIFO ausschalten und Sync Erkennung neu 
einschalten (das sind diegleichen Befehle wie beim Einschalten des FIFO 
Modus).

Die Befehle dazu finden sich in der rf12.c in der Funktion void 
rf12_rxdata(unsigned char *data, unsigned char number).

[Björn Biesenbach (Gast)]

Hallo!
Ich bin jetzt gerade erst über diesen Thread gestolpert und finde die 
Thematik höchst interessant. Gibt des noch Bezugsquellen für das RFM12 
Modul? Bei pollin gibts nur noch RFM01 und 02.

Gruß
Björn

[R. M. (rmax)]

Hier wird es nächste Woche nochmal eine Sammelbestellung direkt beim 
Hersteller in China geben: Beitrag "Sammelbestellung RFM12"

[Andreas P. (andyp17)]

Hallo Benedikt,

Zuerst mal vielen Dank für deine Hilfe!! Ich hab das ganze nun probiert, 
und es schein auch prinzipiell zu funktionieren.
Nur hab ich jetzt das Problem, dass ich nur 2 von 8 Bytes empfange! Der 
Rest ist 0. Was ist da schon wieder los!

Ich weiß, ich bin lässtig, aber ich will das sch... Ding endlich 
verstehen!!


THX... Andy

[Klaus R. (ruebi)]

Gibt´s bereits einen Schaltungsvorschlag/Softwarelösung um mit HP03D, 
FOST02A und RFM12-868-S1 (wenn möglich basierend auf dem Pollin 
AVR-Board) Wetterdaten aufzunehmen und an eine Master-Station (ebenfalls 
das Pollin-Board) zu übertragen. Von dort sollen die aufgenommenen 
Messwerte per Seriell/USB an den PC zur weiteren Auswertung übertragen 
werden. Am besten Pufferung der Daten in der Master-Station (SRAM?!?), 
sofern der PC nicht eingeschaltet ist.

Gruß,

Klaus

[Benedikt K. (benedikt)]

Sonst noch irgendwelche Wünsche ?
Vielleicht fertig aufgebaut frei Haus zugeschickt ?

[Jörg B. (manos)]

Sicher kannst Du in Deiner Master-Station (Pollin-Board) die Messdaten 
im SRAM zwischenspeichern... zumindest soviel wie Dein verwendeter 
Controller RAM (und evtl. noch EEPROM) hat. Da ich davon Ausgehe, dass 
Du mit dem Pollin-Board das Funk-AVR-Evaluations-Board meinst hat dieses 
auch keinen Sockel für ein externes EEPROM (im vergleich zum ATMEL 
Evaluations-Board Version 2.0).

Da hier wahrscheinlich noch keiner ein HP03D oder ein FOST02A hat ist 
diese Anfrage noch was zu früh.

[Klaus R. (ruebi)]

BK>Sonst noch irgendwelche Wünsche ?
Für den Anfang denke ich sollte das ausreichen, oder fehlt Dir noch 
etwas?

BK>Vielleicht fertig aufgebaut frei Haus zugeschickt ?
Nein, das würde ich schon noch gerne selber machen.

Wenn´s so etwas noch nicht gibt (hört sich ja danach an), dann werde ich 
mich mal ans Werk machen und dieses (sofern es von Erfolg gekrönt ist) 
gerne hier für alle anderen zur Verfügung stellen.

Gruß,

Klaus

[Jörg B. (manos)]

Du hast Deine HP03D und FOST02A schon? ;-)

[Matze (Gast)]

Leider hab ich mein Problem immer noch nicht lösen können. Desshalb habe 
ich mich erstmal um denn Empfänger gekümmert und der lief auf anhieb mit 
10MHz. Ganz so blöd kann ich also doch nicht sein. Hat überhaubt schon 
jemand den rfm02 zum laufen bekommen (mit diesem Code), ich lese hier 
immer nur vom rfm12 ?
Werde jetzt mal einen Mega8 an den Sender hängen, vielleicht klappt es 
ja mit dem. Dann könnte ich wenigstens von einem Fehlerfreiem Code 
ausgehen.

[Matze (Gast)]

Ich habs geschafft. Keine Ahnung wo der Fehler war, aber jetzt läuft das 
System. Den Sender muss ich zwar manchmal 2-3mal anstecken bis er 
ordentlich anläuft, aber das bekomme ich auch noch hin. Vielleicht sind 
die Pausen noch zu kurz.

[Wigbert P. (wigbert)]

Hallo Marvin,
habe Dein Soft-SPI-mega8 in Bascom eingearbeitet.
Sollte der rf12 auf senden bleiben,macht er bei mir,
oder im Zeitintervall immer wieder auf Senden schalten.


wigbert

[Wigbert P. (wigbert)]

Nachtrag
also wenn ich bei ready

> While Spi_sdo = 0 auf 1 ändere sendet er im Sekundentakt
ist das richtig?

Wigbert