ok also hatte ich doch alles richtig eingestrahlt. und bei mir kommt
irgendwie nur müll an.
zumindest kann es nicht an dem Seriel->USB Adapter liegen da er beim
test einbandfrei funktioniert hat.
als Antenne benutze ich eine 1mm² draht aufgewickelt zur spule.
habt ihr vielleicht eine ahnung woran es liegen könnte. zudem es ist
nicht immer der gleiche müll varriert etwas.
Sender
20 EB DD 87 E7 EE BF 08 80 F3
20 EB DD 87 E7 EE BF 08 80 F3
20 EB DD 87 E7 EE BF 08 80 F3
20 73 75 08 0A C8
20 73 75 08 0A C8
Empfänger
14 58 1A 79 71 41 F8
14 58 1A 5E 71 43 F8
14 58 1A 5E 71 43 F8
14 61 1A 59 1C 41 F8
14 94 75 1A 59 12 00 CD
also ein gewisses muster ist zu sehen aber net dat was kommen sollte und
empfangen tut er auch net. das sind die strings die beim start
ausgegeben werden sollen.
Die Daten haben Bitweise betrachtet nicht wirklich viel Ähnlichkeit.
Hast du schonmal ausprobiert, ob bekannte Daten die in der Software
gesendet werden (also z.B. uart_putc(0x23)) richtig ankommen?
ehm ok glaub wir missverstehen uns wieder aber mal wieder meine schuld
sorry die dinger kommen nur nach einem reset. muss mir angewöhnen das
ich ausführlicher werde.
sprich jede zeile kam nach einmal reset drücken.
und dann geht es ja ehr um die zeile:
1
uart_puts_P("Sender laeuft !\n");
oder sehe ich das falsch kann es sein das diese uart.c und uart.h net so
funzt wie sie soll für das funk-evu-board obwohl ich schon gescheckt
habe ob es wie beim normalen evu-board angeschlossen ist (was es auch
ist). oder muss ich da noch irgendwo was definieren um es auf das board
anzupassen? <- könnte ich mir ehr vorstellen aber wenn ja wo?
die prozessoren laufen beide von board aus auf 16MHz also vom quarz und
fuse bits passen. das prog selber hab ich auf die 8MHz stehen lassen.
muss man das auf die board frequenz anpassen oder was? <- mal dumm
gefragt
jo hab es mal nach dem schreiben gleich praktiziert und oh wunder der
sender gibt nun den richtigen string raus nur der empfänger net. hab
nochmal die fuse bits kontrolliert die sind bei beiden identisch und
durch ein einfaches blicken weiß ich das der quarz zumindest schon mal
dran ist aber raus kommen tut nur folgendes:
E0 E0 00 E0 E0 E0 E0 E0 00 E0 00 00 E0 E0 00 E0 E0 E0 00 E0 00 E0 E0 E0
00 E0 E0 E0 00 E0 00 00 E0 00 00 00 E0 E0 E0 00 E0 E0 E0 00 E0 E0 E0 E0
E0 00 00 E0 00 E0 E0 00 00 E0 00 00 00 E0 00
das kommt bei einmal reset.
aber so wie es ausschaut kommt der sender auch nicht viel weiter da der
string "sende..." nicht ausgegeben wird.
wie kann ich nun rausfinden wo er sich genau aufhängt? kann zumindest
noch sagen das er bis "rf12_txdata(test,32);" noch hinkommt.
ok anscheinend brauchten beide eine bedenkzeit und ein programm wechseln
was getsern sender war ist heut empfänger und umgekehrt und siehe da es
klapt nur das ich vor dem "Dies...." noch immer ein zeichen empfangen
wird keine ahnung von wo da es auch variiert.
Benedikt, danke für die tolle Arbeit!
Hat schon mal jemand daran gedacht, hierfür einen Wiki einzurichten?
Ich hab zwar nicht den ganzen Thread gelesen, aber mir scheint dass den
Usern immer wieder die gleichen Fehler passieren (z.B. fehlender
Bypass-C am RFMxx). Außerdem verliert man bei den verschiedenen über den
ganzen Thread verteilten Versionen und Unterversionen schnell den
Überblick.
lG Patrick
Ich benötige beim RFM12 den PIN nIRQ für den Wake-Up Timer
(Batteriebetrieb).
Leider wird nIRQ auf LOW gesetzt und blockiert, nachdem ein Byte
erfolgreich gesendet wurde (d.h. Statusbit RGIT => 1 und nIRQ => 0).
Wird jetzt der Wake-Up Timer gestartet, bleibt nIRQ die ganze Zeit auf
LOW. Das Wake-Up Event wird korrekt im Statusregisterbit WKUP angezeigt,
nur der nIRQ ist leider blockiert.
Ich habe keine Befehlsequenz gefunden, die den nIRQ sauber wieder
freigibt.
Ich habe getestet:
- Lesen der Statusregister (0x0000)
- das Bit et im Power-Managemant gelöscht und gesetzt, wie im Handbuch
unter "12. wake-up timer" beschrieben
- Alle Varianten den Chip schlafen zu legen (0x8201) und wieder
aufzuschalten.
Als einzigen dirty Workaround habe ich gefunden, ein zusätzliches dummy
Byte zu senden und den Sender sofort stromlos zu schalten (0x8201) bevor
das Statusbit RGIT/FFIT Erfolg meldet und nIRQ wieder auf LOW geht.
Hardware: Pollin RFM12s Rev:3.0
Hallo zusammen,
zunächst vielen Dank an Benedikt für das tolle Stück Software.
Ich habe jetzt etwas Probleme, das ganze auf meine Fragestellung zu
portieren:
Ich möchte Daten zunächst über 2 RFM12 zwischen 2 Controllern
austauschen (halbduplex reicht). Die Daten gehen dann aber nicht sofort
an den jeweiligen UART, sondern erst mal in einen Buffer. Erst im Zuge
des weiteren Programmablaufs entscheidet sich, ob die Daten über den
UART gesendet werden oder direkt intern verarbeitet werden.
Hat jemand schon mal so etwas gemacht und ich habe es hier nicht
gefunden? Oder ist das so "exotisch", dass ich es selbst implementieren
muss ;) ?
Viele Grüße
Hermann
Hermann Gebhard schrieb:
> Die Daten gehen dann aber nicht sofort> an den jeweiligen UART, sondern erst mal in einen Buffer.
Das machen eigentlich alle Programme: Die empfangenen Daten werden
zunächst in einen internen Speicher eingelesen. Dann kann man die Daten
Byteweise abholen. Allerdings muss die Software dafür sorgen, dass der
Puffer leer ist bevor das nächste Paket ankommt, sonst gibts Probleme.
Die UART Ausgabe baue ich immer nur als Beispiele ein, da man so die
Software leicht ausprobieren und testen kann.
Hallo Allerseits,
das Problem vom Oliver Schneider ist gelöst.
Vorweg eine wichtige Hardware-Sache: Die Verbindung zwischen dem µC und
dem Funkmodul muss ziemlich kurz sein. Bei einem Pollin-Board und dem
Funkmodul auf einem externen Board, das mit einem Flachbandkabel
verbunden ist, funktioniert es mit einem ca. 20cm Kabel nicht mehr, mit
ca. 6cm dagegen wunderbar. Scheinbar ist das Clock-Signal zu schwach
oder die Sampling-Zeitpunkte für die Datenübernahme extrem dicht
zusammen, oder sonst irgendwas.
Ansonsten gibt es noch ein paar Verbesserungsmöglichkeiten und Bugs in
Benedikts Code (dem unidirektionalen für RF12).
- GAAANZ Wichtig: Das letzte gesendete Byte wird nicht ordentlich
übertragen, man muss also noch ein Dummybyte hinterherschicken. Das hat
wohl mit dem Empfang und verschiedenen Buffern zu tun, der
Taktrückgewinnung und irgend welchen anderen seltsamen Dingen.
Jedenfalls, wenn man noch ein weiteres Byte sendet, das beim Empfang
aber ignoriert, klappts.
- In der Empfangsroutine kann leicht über die Feldgrenze geschrieben
werden: Es wird immer ein unsigned short (sind offenbar 16 Bit, sonst
passt das mit den restlichen Routinen nicht) an eine Feldposition mit 8
Bit Platz geschrieben. Das funktioniert auch, bis man zum letzten
Element kommt. Da kann man dann nur hoffen, dass hinter dem Feld nichts
wichtiges steht. Besser, man schreibt einen expliziten Typecast in die
Zuweisung.
- Die Synchronisierungsphase vor der Präambel könnte man noch etwas
verlängern. Ich hatte das Gefühl, dass dann die Übertragung sicherer
startet.
Hallo Ihr,
ich versuche das beispielprogramm von Benedikt auf einem AT90USB128 zum
laufen zu bringen. aber leider bleibt es immer in der rf12_ready() in
der schleife hängen. Die funktion habe ich, nachdem ich gelesen habe das
schon mehrere hier ein problem damit haben, entsprechend geändert zu:
1
void rf12_ready(void)
2
{
3
cbi(RF_PORT, SDI);
4
cbi(RF_PORT, CS);
5
_NOP(); //einen Takt warten. Funktion aus ina90.h
6
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready; hier bleibts hängen
7
set_7seg(4);
8
}
die Dateien im anhang ist nur die erste version mit geänderten PINS für
MISO, MOSI, SCK und SS. Die Spannungsversorgung erreiche ich indem ich
das entsprechend an PORTD an einen PIN hänge (sind nicht alle
rausgeführt bei PORTB) der dauerhaft die Spannung gewährleistet.
Konfiguration:
1
#define RF_PORT PORTB
2
#define RF_DDR DDRB
3
#define RF_PIN PINB
4
5
#define SDI 2
6
#define SCK 1
7
#define CS 0
8
#define SDO 3
ich hoffe einer von euch kann mir bei meinem problem helfen und ich
befürchte das es ein dumme fehler ist den ich nur dauernd übersehe :(
Gruß und Danke
AVRnoob
- Wo bleibt er hängen: Beim Senden oder beim Empfangen?
- Funktioniert die Kommunikation prinzipiell, also wird der Takt vom
RFM12 auf 10MHz umgeschaltet?
Du könntest einen 2. AVR als Teiler durch 1 Million programmieren und
diesen damit Takten. Ob die LED mit 1Hz oder 10Hz blinkt sollte man
erkennen können.
Ich tippe nämlich auf ein generelles Kommunikationsproblem, denn
zumindest beim Senden sollte die Software nicht hängen bleiben.
also ich habs nun einfach an ein oszi von einem freund abgemessen (CLK
port am rfm12) und der schaltet aufjedenfall auf 10Mhz.
kann ich eigentlich den takt vom rfm12 irgendwie variabel ändern? beim
pollin beispiel steht drinnen das der mit 8Mhz taktet statt mit den 10
(einfach ein fehler?).
Nach langes Basteln funktioniert das Testprogramm mit dem Propeller
wunderbar !
Wer für Propeller Hilfe braucht kann sich bei mir gerne melden ...
Ciao
Hallo allerseits,
Horst Meier stellte in seinem Beitrag vom 23.06.2007 eine RFM12 (433
MHz) Assembler-Lösung für einen ATtiny 2313 vor.
Ich versuche gerade die Schaltung und den Code auf eine 868 MHz Lösung
mit einem ATMega88A mit RFM12B abzuändern.
Die Lösungen von Benedikt "rfm12_r2323_rxtx_check5" und "RF12_just_rxtx"
habe ich bereits mit 2 x STK500 und ATMega8L ( 868 Mhz )aufgebaut.
Die Datenübetragung funktioniert einwandfrei. Da ich zwar etwas
Erfahrung mit C habe aber kein C-Experte bin und einige Projekte bereits
in Assembler realisiert habe, scheint mir Horst's Lösung passender zu
sein.
Ich möchte ähnlich wie joern ( 11.03.2009 )von einer Basistation bis zu
3 Außenstationen ansteuern mit entsprechender Rückantwort.
Die Stationen sollen spätzestens nach 3 Minuten antworten, ansonsten
werden die Relais der Stationen per separater Watchdogschaltung
abgeschaltet.
etwa mit nur 3 Bytes : von Basis -> Station1
1.Byte Zieladresse
2.Byte Absenderadresse
2.Byte Command ( z.B. Aus- oder Einschalten und Watchdog retriggern)
danach 3 Bytes Station1 ->Basis
1.Byte Zieladresse ( hier die Adresse der Basis )
2.Byte Absenderadresse ( damit ich die Stationen unterscheiden kann )
2.Byte Statusinfo ( z.B aus- oder eingeschaltet etc.)
Die Funkübertragung ist nur ein Teil meines Projekts
Es werden noch diverse Sensoren ( Temperatur/Druck) ausgewertet (per
TWI) und Relais geschaltet.Eine kabelgebundene Lösung in Assembler
existiert bereits.
Ich hoffe es kann jemand helfen.
Gruß
Willy
Und was war jetzt die Frage?
Die Lösung hast du schon genannte: Du überträgst die Daten (z.B. hiermit
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module") so wie du sie
genannt hast, der Empfänger prüft ob die empfangene Nachricht für ihn
ist, falls ja wird sie abgearbeitet, falls nein verworfen.
Hallo Benedikt,
Vielen Dank für Deine schnelle Antwort.
Deine Software "just_rxtx" sendet die Bytes optimal nacheinander und
gibt pro Byte eine Rückmeldung an den Absender 0=ok 1=Fehler. Da es sich
in meinem Projekt um eine Basis und drei Außenstationen handelt ist
diese Kommunikation nicht ausreichend. Wenn von der Basis eine bestimmte
Außenstation angesprochen wird (über das Adressbyte),dann soll auch nur
diese entsprechend antworten und nicht alle.
Lässt sich das so realisieren wie ich das beschrieben habe ?
Wo genau in der Software sind die Änderungen notwendig ?
Gruß
Willy
Die rf12 Routinen kannst du eigentlich unverändert übernehmen.
Das eine Byte pro Übertragung ist nur ein Beispiel. Wenn du z.B.
tx_data(data,16); schreibst, werden 16 Bytes aus dem data Array auf
einmal übertragen. Maximal sind 128 Bytes möglich.
Ebenso beim Empfangen: Dort kommen auch die Daten als 128Byte Packete
an.
Hallo Benedikt,
for (;;)
{ check_rx_packet();
if (rx_data_in_buffer())
{ unsigned char count, i;
count=rx_data(data);
for (i=0; i<count; i++) // Empfang
{
uart_putc(data[i]);
}
}
if (uart_data()) // sende Beispiel
{
data[0]=uart_getchar(); // ???
uart_putc(tx_data(data,1)); // ???
}
}
wenn ich das richtig verstehe, dann wird durch die Funktion
check_rx_packet,
ob Daten vorhanden sind, wenn rx_data_in_buffer "true liefert dann wird
die Anzahl der empfangenen Bytes gezählt
count=rx_data(data) und anschließend alle Daten an die UART ausgegeben.
Den anschließenden Sendeteil vertehe ich nicht richtig.
uart_data() kommt aus uart.c und gibt 1 zurück wenn 1<<RXC ( receive
complete). Aber wie funktioniert das mit den beiden folgenden Zeilen ?
Gruß
Willy
Willy K. schrieb:
> wenn ich das richtig verstehe, dann wird durch die Funktion> check_rx_packet,> ob Daten vorhanden sind,
Ja. Allerdings läuft über diese Funktion der komplette Empfang der Daten
usw. ab. Daher muss diese ausreichend oft aufgerufen werden, damit der
Empfangspuffer des RF12 nich überläuft.
> wenn rx_data_in_buffer "true liefert dann wird> die Anzahl der empfangenen Bytes gezählt> count=rx_data(data) und anschließend alle Daten an die UART ausgegeben.
Jaein. Das ganze ist Paket basiert. Sollte eine nachricht empfangen
werden, wird diese von der check_rx_packet Funktion empfangen und in den
internen Puffer gespeichert. Das gesamte Paket wird über rx_data()
abgeholt und in das neue Array kopiert. Das muss ausreichend schnell
geschehen, denn wenn das nächste Paket empfangen wird, ehe das alte
abgeholt wurde, geht das alte Paket verloren.
> Den anschließenden Sendeteil vertehe ich nicht richtig.> uart_data() kommt aus uart.c und gibt 1 zurück wenn 1<<RXC ( receive> complete). Aber wie funktioniert das mit den beiden folgenden Zeilen ?
uart_data() zeigt an, dass sich Daten im Empfangspuffer befinden. Falls
ja, wird ein Byte mittels uart_getchar() aus dem Puffer gelesen, in
data[0] kopiert und dieses über tx_data() versendet. Zusätzlich wird der
Sendestatus über den UART zurückgesendet.
Das ganze ist nur zur Demonstration vorhanden, damit die Software direkt
ohne Anpassungen lauffähig ist, und man so die Module testen kann.
Hallo Benedikt,
ich verstehe ,dass die Software nur zum Testen der Module gedacht ist.
Die entprechenden Anpassungen muss ich wohl selbst durchführen.
Vielen Dank vorerst
Gruß
Willy
So, ich habe mein RFM12 nun auch zumindest als Sender mit eigenem Code
in Betrieb genommen. Ich hatte einige Probleme, beim Senden den die
Ready-Signale mittels IRQ bzw. SDO zu bekommen. Hier scheinen so
ähnliche Fehler auch recht häufig aufzutreten, daher mal meine
Erkenntnisse dazu:
Im Gegensatz zu den (falschen) Angaben im Datenblatt ist es nicht
möglich, Steuerbefehle im Sende-Datenstrom unterzubringen. Die
Beschreibung im Datenblatt (TX Register Buffered Data Transmission),
erst zwei Bytes in den TX-Buffer zu schreiben und dann per Power
Management-Befehl den Transmitter einzuschalten, funktioniert genau wie
das Ausschalten des Transmitters im selben Beispiel nicht!
Das heißt, Kommandos müssen immer am Anfang nach dem Ziehen der Chip
Select-Leitung abgesetzt werden, nach dem Schreiben irgendwelcher Bytes
in den TX-Buffer erkennt das RFM12 diese Befehle nicht mehr, solange die
Chip Select-Leitung noch gehalten wird.
Die ganzen Code-Beispiele halten sich interessanterweise nicht an die im
Datenblatt empfohlene Vorgehensweise und funktionieren daher.
Mit der folgenden Reihenfolge läuft mein Sender nun anscheinend
erfolgreich:
CS auf Low setzen
Config Command (EL=1)
Power Management Command (ER=0, ET=1)
Warten auf SDO==1 oder nIRQ==0
Schreiben in TX-Buffer
Warten auf SDO==1 oder nIRQ==0
.
.
.
Schreiben in TX-Buffer
Warten auf SDO==1 oder nIRQ==0
CS auf High setzen
CS auf Low setzen
Power Management Command (ER=1, ET=0)
CS auf High setzen
Die Kommunikation per SPI hätten die Designer des Chips wirklich etwas
durchdachter machen können. Die Rückmeldung zu gesetzten Register-Werten
ist gleich Null. Dabei wäre es schon nicht schlecht, ohne Hilfsmittel
oder zusätzlichen Schaltungsaufwand herausfinden zu können, ob der
Sender nun an oder aus ist. Glücklicherweise gibt es noch den
CLK-Ausgang, an dem man mit dem Multimeter(!) "debuggen" kann (indem man
CLK ein und ausschaltet).
Gastino,
ich habe mehr oder wenig genau dieselbe Erfahrung mit dem rfm12 gemacht.
Es geht noch zuverlässiger wenn du immer die ganze Reihenfolge schickst:
CS_Low
SPI_Befehl
CS_High
Die Sendegeschwindigkeit hängt praktisch von der SPI Geschwindigkeit
ab...
Ich habe ca. 86.000 kbs erreicht.
kann man mit den dingern so eine art funksteckdose bauen, aber mit
rueckantwort. ich bekomme naemlich immer die kriese wenn ich per funk
steckdose was an und ausmachen will aber nich erkennen kann obs geklappt
hat da das ja aus dem baumarkt immer nur one way ist ..
die naechste frage waere kann man mit dem rfm12 auch die baumarkt
steckdosen steuern?
wuerde dso nen ding auch gerne an den net-io haengen .. sollte gehen
oder?
wie zufrieden seit ihr mitlerweile mit dem ding?
viele gruesse mentox
Hiiiiiilfe!
Nach tagelangem rumprobieren mit den Modulen bin ich jetzt wirklich kurz
vorm Aufgeben...
Wie es aussieht wird was gesendet und der Empfänger sieht auch, daß da
ein Sender ist, aber der FIFO bleibt leer!!!
Ich hab fast den ganzen Thread hier gelesen und dieses Problem bisher
nicht nochmal gefunden. Hat jemand eine Idee?
Defekte Module kann ich weitestgehend ausschließen, da ich es schon mit
2 433MHz und 2 868MHz Modulen versucht habe.
Die Kommunikation mit den Modulen läuft anscheinend auch einwandfrei,
denn das CLK-Signal läßt sich ohne Probleme auf 10MHz oder "Aus"
schalten.
Benedikts Programm habe ich natürlich auch schon ausprobiert, aber da
tut sich leider gar nichts.
Und da Benedikts Progamm zwar gut strukturiert ist, es dadurch aber auch
etwas unübersichtlicher wird, habe ich mal etwas kompakteren Code
zusammengeschrieben, der empfängerseitig den Modul-Status pollt und auf
RS232 ausgibt. Und falls im Status ein voller FIFO angezeigt wird, wird
auch der FIFO ausgelesen und auf RS232 ausgegeben. Habe ich aber bisher
noch nicht erleben dürfen...
Die RF-Konfiguartion habe ich dabei von Benedikt übernommen.
Meine große Bitte wäre, daß jemand, bei dem die Module laufen, den Code
mal bei sich draufspielt und schaut ob er im Status was mit 0x8000 oder
größer bekommt.
Wenn irgendwas mit dem Bit 0x0100 kommt, wird zumindest ein RF-Signal
empfangen, wie es bei mir (meistens) der Fall ist. Das Status Read
Command ist ja im Datenblatt auch ausführlich beschrieben.
Für Leute die Sender und Empfänger genau abgleichen wollen, ist der Code
ebenfalls interessant, weil im Status ja der Frequenzoffset mitangegeben
wird...
Ansonsten ist der Code für einen ATmega8 mit Auslieferungskonfiguartion.
Also internem Oszillator und 1Mhz Takt. Und ich benutze das Hardware
SPI, weil es sehr einfach zu handhaben ist. Nur der nSEL-Pin muß
wahrscheinlich angepasst werden, da ich ihn auf PortD habe. Läßt sich in
den #defines leicht machen. Pull-up an FSK ist natürlich auch dran...
Oh, und der Sender benutzt nIRQ. Für den Fall, daß jemand auch den
Sendecode testen will.
Falls also jemand vor lauter Schnee etwas Zeit dafür übrig hat, wäre ich
sehr dankbar. Andernfalls wandert das alles bald in den Müll...
Viele Grüße
aXeL
Hallo!
Erstmals will ich mich bei allen die Code für die Funkmodule geschrieben
haben, bedanken... ich weiß echt nichtmehr woher ich alles hab, aber ich
glaub hauptsächlich eh von benedikt... Also Danke!
Auch wenn meine Source Codes noch nicht vollständig sind, und ich mir
noch nichts passendes für den empfang überlegt hab, will ich mal meine
vorläufigen Codes hier reinstellen. Bin demnächst drauf und drann das
ganze nochmal mit interrupts + fehlerkorrektur etc. zu schreiben, aber
zum testen ist das so mal ganz toll.
(Wollte zuerst alles mit #defines auswählbar machen, aber ich glaub das
wird sehr unübersichtlich. Aber so wies jetzt ist gehts glaub ich noch.
einfach in config.h alles richtig eintragen. Falls man den Reset
verwendet würd ich einen zusätzlichen Wiederstand empfehlen, weil ich
nicht weiß, was bitte ein DIO sein soll... hab mal was gelesen dass man
das für den Controller als Reset verwenden kann, die meisten lassen ihn
unbeschaltet, hat bei mir aber irgendwie nicht geklappt siehe unten...)
Weil ichs noch nirgendst gelesen hab und es aber aus unerklärlichen
gründen bei mir fehler gemacht hat: nRes lege ich über einen Wiederstand
(kiloohm unkritisch) auf die Versorgungsspannung. Erst seitdem ich das
mach funktioniert bei mir senden und empfang. lustigerweise hat das
umschalten der Ausgangsfrequenz (CLK) auch schon vorher funktioniert.
Bin mir aber nicht ganz sicher ob da nicht noch irgendein problem war...
Inzwischen find ich die hope datenblätter schon viel besser... es gibt
aber auch irgendwie verschiedene, bei manchen steht nur sehr wenig, bei
anderen viel... wenn man mal drinnen ist dann kann man glaub ich echt
viel mit den Modulen machen.
Sobald ich wieder Zeit hab gibts auch einen RF_FREQUENCY_868 switch.
Ich weiß dass es schon vieles gibt zu dem Thema, wollte nur mal einen
Laagebericht abgeben, da ich einige Probleme mit dem Pollin Funkboard
usw. hatte.. und es doch recht viel arbeit war bis alles funktioniert
hat.
Ich hoffe es hilft wem und ist nicht nur Wiederholung der letzten
Beiträge :P
hallo leute
ich möchte jetzt auch mal per funkt daten übertragen. Habe mir überlegt,
dass ich leicht anfangen sollte. Möchte also mal nur über funk eine LED
an und aus-schalten. Ich habe nicht ganz verstanden, wie ich die
hardware aufbauen soll. Einfach atmega8 an RFM12 oder mus noch etwas
dazwichen?
Hier sind ziemlich viele versionen würde sich die im anhang dafür
eignen?
danke für eure hilfe
Marcelo
Nicht alle auf einmal antworten bitte... ;o)
Was ist denn los? Seit 11 Tagen kein einziger Beitrag, trotz 20
Downloads...
Einer von Euch muß doch das Programm inzwischen mal getestet haben...
Auch wenn gar nichts funktioniert hat, würde ich mich über eine kurze
Rückmeldung freuen, damit ich vielleicht doch noch einen Anhaltspunkt
finden kann, warum es bei mir nicht richtig funzt...
Viele Grüße,
aXeL
hallo
habe nur mal ne kurze frage gibt es irgendeinen unterschied zwichen
rfm12 oder rf12? Das programm rf12 läuft das auch auf einem rfm12 funk
Modul?
Mfg
Tobias
Hallo aXel, hallo an alle RFM12-Benutzer,
ich muss mich jetzt auch in die Gruppe der Erfolglosen einreihen.
Nach dem bei mir ein Funkstrecke RFM02 -> RFM01 seit 4 Wochen
erfolgreich Daten überträgt, versuche ich es jetzt mit den
RFM12-Modulen.
Aber was das RFM12 sendet kommt nirgends an. Weder an einem RFM12 noch
an einem RFM01.
Empfangsseitig ist alles ok, das RFM12 empfängt die gesendeten Daten des
RFM02 korrekt.
Ich versuche jetzt schon seit 1 Woche den Fehler in der Senderoutine zu
finden, habe die Beispielcodes angepasst, verändert, zigmal das
Datenblatt gelesen, aber alles ohne Erfolg.
Das Trägersignal ist da, das habe ich mit einem Fernseher kontrolliert.
Ich habe schon unzähliges versucht, daher bin jetzt der Meinung, dass
die RFM12 (hab's mit 2 von 4 probiert) defekt sein müssen.
Vielleicht eine fehlerhafte Serie?
Ich habe meine Mitte Dezember bei Pollin gekauft.
Gibt es noch Andere, die auch das Sendeprobleme haben?
Danke schon jetzt für Eure Mithilfe.
Freundliche Grüße
Andreas
Hallo,
das Senden funktioniert jetzt doch.
Leider habe ich keine Erklärung, woran es lag. Am Code habe ich nichts
geändert. Möglicherweise hat's schon gestern funktioniert und ich hab's
einfach durch das viele ausprobieren übersehen.
Tut mir Leid, dass mein Beitrag von heute morgen unnötig war.
Gruß
Andreas
@ Andreas Montnacher
Hallo,
habe gelesen, dass deine Funkstrecke RFM02 --> RFM01 funktioniert.
Bei mir läuft es leider noch nicht.
Könntest Du mir mal bitte sagen, wie Du die Module an den Controller
angeschlossen hast, und evtl. deine Programme hochladen?
BRauche mal was zum vergleichen.
Danke
Gruß Tom
Einen schönen guten Tag auch, bin neu hier und hab mich mal n bischen
mit dem pic und dem RFM auseinandergesetzt, bei der Programmierung hab
ich mich sehr an eure Vorschläge gehalten, aber irgenwie ist da noch der
wurm drine, ich selber benutz das RFM12 von Pollin. Ich wollte damit ein
kleines spiel programmieren, um die Funkübertragung erstmal
auszuprobieren. Wäre cool wenn mir jemand nen tipp geben kann wo ich
scheisse gebaut hab.
Außerdem nimmt er den PORTA als eingang nicht an, und ich weiß nicht
wieso, aber ihr bestimmt:-)
Mfg Karl
Hallo Tom,
meine Programme sind in Assembler geschrieben und durchgehend
kommentiert.
Falls Du einen Assembler brauchst, am Anfang der Programme findest du
den Link dazu.
Die Verbindungen zw. AVR und RFM sind gleich denen vom Pollinboard.
Die Led's und Schalterpins nicht. Das 2. Funkmodul hatte ich immer auf
einem Steckbrett aufgebaut.
Die Settings der RFM-Register sind nicht unbedingt ein Muss, aber es
funktioniert mit diesen Einstellungen. Habe die Settings noch nicht
optimiert.
Zur Funktion: der RFM02 sendet alle 5 Sek, 5x das gleiche Byte, wobei
immer nur der Zustand eines Schalters gesendet wird.
Der RFM01 gibt den Zustand der Schalter an den Leds, als Flash, für ca
100ms aus.
Du kannst mich jederzeit fragen, wenn's klemmt.
Gruß
Andreas
Hallo zusammen,
ich habe im Datenblatt von dem RFM12 gelesen, dass man diesen auch ohne
TX Buffer/Register benutzen kann. Für eine spezielle Anwendung würde ich
gerne mit dem RFM12 Modul gerne einzelne Bits vertschicken können. Kann
mann, wenn man das Bit 7 "el" im Configuration Control Command Register
auf low lässt, einzelne Bits wie beim RF02 Modul versenden? d.h. wird
die Bit Rate vom RFM12 Modul dann als Taktgeber an irgendeinem Pin
herausgegeben und kann ich dann am FSK Input meine zu versendenen Bits
anlegen? Ich hoffe, dass mir da jemand weiterhelfen kann- danke für eure
Hilfe!
Gruß
Tim
Vielleicht ist es im Thread schon erwaehnt, ist etwas zu lange zum
gruendlichen Durchlesen:
Im Code von Benedikt K. (rfm02.zip vom 16.04.2007 15:28) fuer das
RFM02-Modul ist in der Funktion zum Setzen der Sendeleistung ein Bug.
1
voidrf02_setpower(unsignedcharpower)
2
{
3
rf02_trans(0xB000|((power&7)<<8));
4
}
Die Sendeleistung bleibt immer auf 0dB (also auf Maximum, weshalb es
wohl auch nicht direkt auffaellt), da die Bits fuer die Wahl der
Leistung nicht hoch genug geschoben werden. Sie muessten eigentlich
direkt ins hohe Byte, also direkt nach dem B stehen, laut Datenblatt zum
RF02.
Korrekt muesste der Code so lauten, wenn ich mich nicht irre:
Tim schrieb:
> Kann> mann, wenn man das Bit 7 "el" im Configuration Control Command Register> auf low lässt, einzelne Bits wie beim RF02 Modul versenden? d.h. wird> die Bit Rate vom RFM12 Modul dann als Taktgeber an irgendeinem Pin> herausgegeben und kann ich dann am FSK Input meine zu versendenen Bits> anlegen?
Ja, funktioniert. Es gibt allerdings keinen IRQ vom RFM12 als Takt für
die Bitrate. Das musst du im AVR mit einem Timer machen.
Abend, ich habe mir überlegt wie ich mit den rfms bisschen Energie
sparen könnte. Habe paar Infos zur Filter gefunden und mir überlegt ob
es eine gute idee wäre ein aktiven rc bandpass filter zu bauen mit den
man erst den nc weckt und dann den rfm Modul anschmeißt. Momentan wecke
ich meine ncs in bestimmten Abständen und lausche ob was los ist.
Wollte euch fragen ob Ihr in die Richtung schon was gemacht habt oder
bessere Ideen gibt wie man die Batterien schont.
Grüße fantomas
PS
bei lynx-dev gabs Preissenkung für Module. Die btm Module sind auch
billiger geworden.
Wenn der Empfänger immer erreichbar sein soll dann muss der Modul
ständig im Empfangsmodus sein und das kostet Strom(20mA). Und ich möchte
eben so wenig wie möglich Strom verbrauchen. Deswegen dachte ich warten
bis etwas auf der Frequenz spuckt und erst dann den Modul an schmeißen.
Hallo,
habe mir Platinen geätzt für das RFM01 und RFM02 und grade erst diesen
Text gesehen in den Sourcen:
> // nFFS: 1-10k Pullup an Vcc !!!
Da ich kein Bock habe die Platinen nun noch mal zu ätzen, warum muss das
und kann ich das nicht mit dem internen Pull-Up machen?
Fabian S. schrieb:
> Da ich kein Bock habe die Platinen nun noch mal zu ätzen, warum muss das> und kann ich das nicht mit dem internen Pull-Up machen?
Sicher, wenn du den Pin sowieso mit dem µC verbunden hast geht das auch.
Nur ist für den nFFS-Pullup nicht unbedingt ein µC-Pin notwendig, wenn
du nur dien FIFO nutzen möchtest.
Jo hab ich auch vorhin raus bekommen, danke ;)
Habe jetzt noch ein Problem, dass ich Datenmüll empfange. Das letzte der
32 Zeichen (letzte Leerzeichen in dem String) ist immer ein Zufallswert.
Also habe den Test verwendet aus dem Code hier, wobei ich jetzt doch
zwei RF12 Module drin habe.
Also du zu sendenen Daten kommen korrekt an, danach gibt es jedoch
Datenmüll beim ausgeben übern uart.
Vielleicht liegt es daran, dass mir nicht ganz klar ist wie das
Empfangen funktioniert. Ich sage der Funktion ja, dass sie 32 Bytes
empfangen soll. Wartet er dann wirklich bis 32 Bytes da sind? Macht er
eine Null-Terminierung?
Fabian S. schrieb:
> Habe jetzt noch ein Problem, dass ich Datenmüll empfange. Das letzte der> 32 Zeichen (letzte Leerzeichen in dem String) ist immer ein Zufallswert.
Nach dem letzten (32.) Byte mit Nutzdaten musst du noch 2 Byte
zusätzlich senden. Die letzten 2 Byte müssen nämlich noch aus dem
TX-Register zum Sender geschoben werden. Sonst bleiben die drin stecken
und der empfangende RFM bekommt nur noch Rauschen.
Fabian S. schrieb:
> Wartet er dann wirklich bis 32 Bytes da sind? Macht er> eine Null-Terminierung?
Wenn einmal das Sync erkannt wurde, liefert der FIFO so lange Daten bis
zum Abschalten des Empfangs oder FIFO Reset. Wenn das Programm 32 Byte
erwartet, wird es diese auch bekommen falls du nur die Hälfte sendest.
Der Rest ist einfach digitalisiertes Rauschen.
Verstehe ich das richtig? Ich soll statt 32 einfach 34 Bytes senden,
wobei die letzten beiden nur irgendwas ist, was irgendwo in der Tonne
landet?
Kommt mir seltsam vor :-/
Richtig, die 2 zusätzlichen Bytes sind nur "Dummys". Der RFM hat ein 2
Byte großes TX-Register. Das ist ein FIFO in Senderichtung. Wenn du nach
dem 32. Byte sofort den Sender ausschaltest, werden die nicht mehr
komplett gesendet. Daher schiebst du noch 2 Byte zusätzlich in den FIFO.
Damit werden die 32 Byte dann wirklich gesendet, vom vorletzten (33.)
Byte übrigens auch ein Teil. Ich habe das mit einem Logikanalysator
nachvollziehen können.
Naja ausschalten wollte ich ihn dann noch nicht.
Er soll ein paar Pakete im Abstand einiger Sekunden senden. Wenn ich
dann immer die 2 Bytes rein schiebe, damit er das aktuelle Paket sendet
kommen doch die beiden Dummy Bytes an, sobald ich das 2. Paket sende
oder?
Dieser Ablauf ist aber nicht gut. Damit ist der Sender auch dann aktiv,
wenn du gar nichts zu übertragen hast. So etwas soll nicht vorkommen.
Richtig wäre folgender Ablauf:
Sender: Tx an - sende Präambel (2D, D4) - sende 32 Byte Daten - sende 2
Dummybytes - Tx aus ...warten ... TX an ...
Empfänger: RX an - FIFO Init/Reset - 32 Byte empfangen - FIFO Reset - 32
Byte empfangen - FIFO Reset .....
Beim Einschalten des TX wird der TX-FIFO initialisiert. Die 2 Byte am
Ende stören so überhaupt nicht. Damit gibt es einen klaren Ablauf. Nach
dem Senden braucht der Empfänger natürlich etwas Zeit, um die Daten zu
verarbeiten bzw. zur RS232 zu schicken. Das muss mit dem Sender
abgestimmt sein. Sonst kann es zu Überschneidungen kommen und Daten
gehen verloren.
Ich muss zugeben, dass ich von den Modulen sogut wie keine Ahnung habe
und verwende die Lib vom Benedikt. (Vielen Dank übrigens!)
Habe da nun keine Funktion gefunden wie tx_on oder tx_off :P
Und auch um den Fifo zu resetten finde ich nichts. Wie stellt man das
an?
Hallo,
also ich hab hier ein paar allgemeine Fragen zu diesem Empfangsmodul.
Ich arbeite hier nämlich an einer Diplomarbeit und unsere Hauptschaltung
muss bis nächsten Freitag fix sein, es geht soweit alles, es fehlt aber
eben noch, dass RFM02 zum empfangen. Verwendet wird ein ATMEGA8, dieser
wird von einem externen Takt gespeist (1,8..MHz), ca. 5V
Versorgungsspannung, dann wird ein LCD im 4-Bit Modus betrieben, 2 ADC
Eingänge sind belegt, ein weiterer Pin von PORT C. Somit bleiben
eigentlich nur mehr PortC und PortB über für genügend Pins. Was ich mit
dem RFM02 machen will ist simpel, ich will ein Signal senden, welches
den µC aus einem Schlaf-Modi aufweckt, am liebsten wäre mir der
Power-Down Modus. Nun hab ich mich bereits ein WENIG in die Materie von
RFM eingelesen. Soweit ich weiß geht ein Pin High sobald der Buffer des
Modules voll ist. Nun hab ich mir gedacht, dass ich, das als externen
Interrupt verwenden kann zum wieder aufwecken. Nun, der Pin des externen
Interrupts ist ja bereits durch, das LCD belegt. Was nun? Den Pin vom
LCD anders Belegen? Gibts andere Möglichkeiten den µC aufzuwecken?
Weiters wollte ich auch nach der Beschaltung von dem Modul fragen. Ist
wirklich nur die Versorgungsspannung, Ground und ein 10k Widerstand
zwischen Data und Vdd nötig (Anhang)?
Und soweit ich, das verstanden habe müssen die Pins SDI, nSEL, SCK und
SD0 nun nur mehr mit dem µC verbunden werden. Der Rest bleibt in der
Luft?
Ich bitte um eine kurze Rückmeldung ob meine Gedankengänge richtig sind.
MFG Julian
Was das Anschließen des Moduls angeht kann ich nun nicht weiter helfen,
aber wenn du dein Pin des LCDs nicht umlegen willst kannst du ja den
16Bit Timer nehmen, um den Atmega regelmäßig aufzuwecken und schaust
dann kurz nach, ob was neues da ist. Bei 1,8Mhz und 16 Bit kommst auf
ca. 37Hz runter, der Stromverbrauch sollte also nur unwesentlich
steigen.
Hallo, habe die Kombination RFM01 und RFM02. Verwende den Code von
Benedikt (danke für die gute Arbeit) und habe es nun endlich nach 2
Tagen zum laufen bekommen. Es lag einzig und allein an der
Optimierungseinstellung. Hatte -O0 eingestellt und nun auf -O2
umgestellt und es klappt. Könnte mir bitte einer erklären, wieso es
daran lag oder wo man etwas zu diesen Einstellungen nach lesen kann.
Schau dir mal in Zukunft die Warnings deines Compilers genauer an. Der
AVR-GCC z.B. gibt ein sehr diskriptives Warning aus, wenn eine _delay
Funktion mit -O0 verwendet wird.
Gruß
Fabian
mal ne kleine Frage am Rande;-)
Die meisten werden wohl müde lächeln;-)
versuche RFM01-RFM02 zum laufen zu bringen mit Software von Benedikt.
Kann ich am Atmega auch den Internen Takt nehmen und auf 8Mhz stellen
und nur noch in der Software die anpassung von F_CPU vornehmen?
Wird das funktionieren?
Vielen Dank
Hallo Leute!
Ich habe mir nun auch die RFM12 Module von Pollin bestellt. Leider habe
ich, wie viele andere hier auch ein kleines Problem:
Ich bin Besitzer des Pollin AVR Funk Evaluationsboard, und habe dort ein
RFM12 Modul draufgelötet. Das Modul sendet am CLK die Frequenz 10Mhz
aus, und scheint auch zu senden und zu empfangen. Soweit wunderbar!
Das 2. Modul habe ich über einen Adapter auf mein Steckbrett gebracht.
Dort gibt es aber nur Probleme: Die Initialisierung scheint nicht
anzukommen. Es werden 1Mhz am CLK ausgesendet, und dadurch kann man auch
nicht senden oder empfangen, logisch. Ich habe bereits den AtMega32 und
den AtMega8 ausprobiert. Ich habe auch schon versucht, erst den
Empfänger einzuschalten, oder die Init-Routine mehrmals zu senden. Alles
vergeblich! Übrigens programmiere ich in Bascom :D
Die SPI Pins habe ich auch schon etliche Male überprüft, sogar mit denen
vom Pollinboard verglichen.
Ich bin nun wirklich am Ende meines Wissens! Ist das Modul kaputt? Kann
ich eine Erstattung fordern?!
DTMRacer
Also ich hatte es, dass sich das Modul nicht initialisiert hat einmal
dadurch, dass die Sleeps zu klein waren und dann auch, dass die Clock
nicht groß genug war. Also mit nem Clock von 1Mht habe ich es noch nicht
hinbekommen.
welche genauen Sleeps meinst du? Während der Initialisierungsphase? Also
zwischen den ganzen Routinen?
Und übrigens läuft mein M8 mit 8MHz.
Ich bin echt ratlos..
So ich hab dann auch nochmal ne Fragen, wenn hier noch jemand aktiv ist
;)
Ich versuche grade den Wake-Up Modus zum laufen zu bringen, es
funktioniert jedoch kein Stück.
Einfache Frage: Was zur Hölle muss ich machen???
Momentan sieht meine Initialisierung so aus:
rf12_init();
sleep_10ms(100);
rf12_setfreq(RF12FREQ(433.92));
rf12_setbandwidth(4, 1, 4);
rf12_setbaud(19200);
rf12_setpower(0, 6);
sleep_10ms(100);
rf12_trans(0xE000 | 512 | (1<<8)); // wake up timer value => 1024ms
rf12_trans(0x8200 | (1<<5) | (1<<1) | (1<<0) | (1<<7)); // WA aktivieren
Warum passiert da nichts am Interrupt Pin?
hmm.. :/ Ich weiß nicht genau welche Sleeps du meinst. Den Einzigen den
ich hier sehe, ist 150 ms vor dem Beginn der Initialisierung.
Kann es nicht vielleicht wirklich sein, dass das Modul kaputt ist?!
okay. Du hast ja oben schon erwähnt, dass du kein Bascom kannst, aber
danke für die Namen der Routinen!
Leider funktioniert auch das nicht. Übrigens wäre es auch unlogisch, da
ich aus Testzwecken exakt die gleiche Software auf beiden Controllern
habe. Und auf dem einem Controller funktioniert es ja. Erstmal geht es
bei mir darum, die 10Mhz am CLK zu erreichen.
Ich werde mich mal mit Pollin in Kontakt setzen...
Hi DTMRacer, ich hatte mit 3 RFM Chips das gleiche Problem, die init
wurde nur halb abgeschlossen und ich bin auch nicht auf 10 Mhz gekommen.
Hab die Timings während der Ansteuerung auch mal verzögert... Kein
Plan... Hab auch keine Lösung
Karl K. schrieb:> Hi DTMRacer, ich hatte mit 3 RFM Chips das gleiche Problem, die init> wurde nur halb abgeschlossen und ich bin auch nicht auf 10 Mhz gekommen.> Hab die Timings während der Ansteuerung auch mal verzögert... Kein> Plan... Hab auch keine Lösung
jaa.. ich hab jetzt eine:
Ich habe die SPI Pins von dem Pollin Experimentier Funk Board direkt an
dem funktionierendem Modul, mit Kabel ausgestattet. Den Vcc Jumper
gezogen, also bekommt das eig. funktionierende Modul keinen Strom mehr,
und die SPI Pins an das Modul auf dem Steckbrett geklemmt. Das Modul
springt nicht auf 10 Mhz. Also ist es wohl kaputt, ich wende mich jezt
einfach mal an Pollin, mal sehen was die dazu sagen..
Würde ich dir auch einfach mal empfehlen!
Hallo,
Wir haben uns vor einigen Tagen das Funkmodul RFM12 gekauft und haben
diese nun hier. In Bascom kennen wir uns zwar einigermaßen gut aus (so
grundlegende Funktionen) und wollten nun eine Datenübertragung mit Hilfe
dieser Funkmodule einrichten. Jetzt ist halt unser Problem, dass wir
ersteinmal von Funkmodulen keine Ahnung haben ;-)!
Nach Lesen von gefühlten 200 Posts in diesem Thread und nachdem wir uns
ca 5 Stunden mit dem Thema beschäftigt haben, kriegen wirs immernoch
nicht hin :-D
Ich wollte jetzt malhier euch fragen, ob jemand von euch uns den
Programmcode (Sende, sowie Empfangsmodul) in Bascom zur verfügung
stellen könnte.
Besonders hamma wäre natürlich, wenn jemand lust hat uns das zu erklären
bzw wir, nachdem wir das Programm haben, einige doofe Fragen dazu
stellen dürfen, wenn wir was nicht verstehen.
Hallo zusammen
Man das ist ja nen echt Krass langer Fred geworden in den letzten Jahren
XD
Ich habe einen Traum den ich gerne umsetzen würde.
Und zwar möchte ich in meiner Wohnung eine Art EIB Bus Haben der auf
Funk Basiert (Mietwohnung) um zB. per Fernbedienung Lampen oder anderes
Zeugs zu schalten.
Jetzt habe ich einige fragen:
- Hat jemand von euch so etwas schon mal gebaut und gibt es dazu
vielleicht schon eine fertige Dokumetation ?
-Funktionieren die RFM12 Module auch einwandfrei wenn man mehrere Sender
und Empfänger hat oder kommt es da zu Störungen untereinander ?
-Hab ich das richtig gelesen das man mit den Programmen die ihr
entwickelt habt 4byte übertragen kann ?
Was ich mir überlegt habe:
-da ich glaube ich nie mehr als 255 Geräte in meiner Wohnung haben würde
täte es eine 8bit Identifizierung der Geräte anhand zugeteilter IDs
-In den meisten fällen werde ich nur 1/0 als Daten wert brauchen
(Schalten)
-zum messen zB Temperatur dann 0-255 oder für Dimmer
-Fehleranalyse/Korektur der Daten mittels Parity oä. muss mich da
nochmal ind INF1 Skript einlesen :D
-Auswertung von Daten an einem Empfänger von mehreren Sendern
Was ich besitze:
-CNC-Fräse -> Platinen Fräsen mittels Target 3001!
-Tektronix TDS 1002b Digi ossi mit 1GS/s 2CH 60MHz
-Mögliche Kanalerweiterung von 10kanälen(1,0) Elektor Schaltung für Ossi
-C und mProzessor Kentnissen aus Studium (wenig Praxis mit AVR)
-AVR Programmer (mySmartUSB+Software)
-Steckboard, Lötkolben, und was man so braucht zum basteln :D
Ist das Reliesierbar Ja/Nein ? mit begründung bitte ^^
Viele Grüße Alex
Hallo,
ich habe ein kleines Problem mit meinem Empfänger:
Der Empfang der Daten funktioniert nur wenn ich am SCK-Pin ein ca 30 cm
langes Drahtstück anlöte... Ansonsten kommt nur Müll am Empfänger an.
Weiter oben gibt es schon so einen Eintrag mit einem Tastkopf am
sck-pin.... wurde eine Lösung gefunden?
Danke
Grüße Fabian
Alexander P. schrieb:> - Hat jemand von euch so etwas schon mal gebaut und gibt es dazu> vielleicht schon eine fertige Dokumetation ?
Gebaut ja, Doku nein.
>> -Funktionieren die RFM12 Module auch einwandfrei wenn man mehrere Sender> und Empfänger hat oder kommt es da zu Störungen untereinander ?
Bei Funk kommt es immer zu Störungen und jedes Modul ist Sender und
Empfänger.
>> -Hab ich das richtig gelesen das man mit den Programmen die ihr> entwickelt habt 4byte übertragen kann ?
Oder mehr, was der RAM so hergibt.
Hallo Benedikt,
habe Deinen (uralten) Code (vom 22.05.2007) entpackt, in Avr-Studio
importiert, die Konfiguration an die Pollin Funk-Board angepasst und
alles hat auf Anhieb funktioniert!!!!
Vielen Dank,
Grüße,
Micha
Hallo Micha,
ich arbeite auch mit dem Pollin Board und versuche es vergebens ans
laufen zu bekommen. Mir fehlt ein bisschen die Übersicht und bin so zu
sagen einsteiger in der AVR Programmierung mit c.
Vielleicht könntest du oder auch andere helfen. Möchte mein rf12 im
868MHz Band betreiben und einfach einen String übertragen. Ich würde
mich sehr über eure Hilfe freuen.
Vielen Dank
Hallo,
ich beschaeftige mich auch erst seit kurzem mit dem Modul und kenn mich
daher auch nicht so gut aus, bei mir funktioniert das Senden beim
empfangen habe ich auch noch meine Probleme, er haengt sich jedesmal in
der rf12_ready funktion auf. Satusregister ausgelesen und bekomme da
immer was anderes raus... vielleicht kann auch mir wer helfen.
-ATmega32
-Pollin Board
Aber vielleicht kann dir ein anderer aus diesem super Forum noch Helfen
ich druecke dir die Daumen.
Moin moin,
ich habe soeben meine beiden RFM12 868-MHz-Band FSK Module zum Laufen
gebracht. Allerdings nicht mit einem AVR, sondern der Sender laeuft mit
einem pic16f88 und der Receiver mit einem pic16f628a.
Der Sender schickt einen String samt checksum in die Welt und der
Receiver empfaengt den String und wertet die checksum aus. Das laeft
jetzt schon seit 1 Stunde ohne checksum-Error ueber 4 Stockwerke!
Wichtig ist die Initialisierung der Funkmodule! Ein gern gemachter
Fehler ist auch Port-Konfiguration des Controllers, heisst welcher Port
ist input, welcher output (SDI auf SDO usw.).
Wenn es gewuenscht ist, kann ich den Schaltplan samt Software posten!
der Kaila
Interessant wäre vor allem (eben auch für AVR-ler) die Initialisierung
bzw. Configurationsparameter für's RFM.
Also welches Register initialisiert du wie...
Gruß
Fabian
Moin,
oki, hier der Sourcecode samt Schaltplan, der fuer Sender und Empfaenger
gleichermassen gilt.
Die Software ist mit PikLab, sdcc, gputils und gpsim entwickelt worden.
Bitte gebt Bescheid, wenn ihr Ungereimtheiten findet. Ich bin gerne fuer
Diskussionen zugegen!
der Kaila
Vielen Dank fuer deine Bemuehungen. Weisst du zufaellig auch warum man
einen String empfaengt dieser im Terminal richtig angezeigt wird aber im
outputfile unterscheiden sich die Zeiten.
hier mal ein Beispiel:
13:54:34.322:
H
13:54:34.430:
i
13:54:34.430:
er wird auf 868.3MHz gesendet
empfangen
wuerde mich ueber jegliche Antworten freuen.
mfg
Hey,
das ging aber schnell :-). Also das ist ein Auszug aus dem Outputfile
von HTerminal mit dem ich meinen ganzen Sende Empfangsvorgang
ueberwache. Sprich ob eine uebertragung zu stande kommt oder nicht. Und
hierbei wundere ich mich ein bissschen ueber die "unterschiedlichen"
Zeiten.
Wuerde das gerne in ein Log file schreiben weiss aber nicht wie das
geht.
mfg
Vielleicht koenntest du mir deine Mail addresse geben dann koennten wir
vielleicht darueber etwas schneller uns austauschen vielen Dank.
oder wenn du moechtest schreib mich einfach mal an huibui@gmx.de
Hallo zusammen,
ich habe hier zwei RFM12 auf zwei Pollin Boards laufen.
Am Empfänger hängt ein Display, auf dem ich den empfangenen Text
ausgebe.
Kann mir jemand sagen, warum das letzte Zeichen immer Müll ist?
Kann das einfach nicht nachvollziehen.
Benutze den Code von Benedikt auf einem Mega32 mit 16MHz und das Display
hat nen T6963C.
MfG
Robert
Robert Knipp schrieb:> Hallo zusammen,>> ich habe hier zwei RFM12 auf zwei Pollin Boards laufen.> Am Empfänger hängt ein Display, auf dem ich den empfangenen Text> ausgebe.> Kann mir jemand sagen, warum das letzte Zeichen immer Müll ist?> Kann das einfach nicht nachvollziehen.> Benutze den Code von Benedikt auf einem Mega32 mit 16MHz und das Display> hat nen T6963C.>> MfG> Robert
Der Fehler ist in Zeile 42
Werner B. schrieb:> Der Fehler ist in Zeile 42
Na das ist ja mal eine konstruktive Antwort.
Zu viel Per Anhalter durch die Galaxis gelesen, oder?
Ich weiß ja dass meine Frage nicht gerade präzise ist. Ich habe aber
keinen balssen Schimmer woran es liegen könnte und dachte dass
vielleicht jemand hier einen konstruktiven Tip hat, wo ich bei der
Fehlersuche ansetzen kann.
Moin moin und Prost,
bin gerade in Zwischenstation vom Mera-Luna-Festival. Hab noch 'ne
dicke Birne aber, hier die kompletten Files meines Senders und
Empfaengers!
der Kaila
Ps: Arbeite unter Linux und kann nur zip. Sollte aber von WinZip de-
komprimiert werden koennen!
Pps: Der Sender rotzt jetzt testweise alle 10ms einen String nebst
checksum raus. Ueber 4 Stockwerke taucht dann doch ab und zu ein
chksum-Error auf, aber ganz selten! Ist schon ziemlich sicher die
ganze Uebertragung :-D
Hey,
wollte mal nachfragen ob es eine einfach Möglichkeit gibt eine CRC
einzufuegen? Da ich neu auf deisem Gebiet bin komme ich mit Kaila's code
nicht zurecht.
Theoretisch ist mir eine crc bekannt nur beim implementieren hapert es
noch.
mfg
Hi Niko,
der String "Kaila" wird in rfm12_snd_msg in der for-Schleife ins
tx-Fifo geschrieben, also in msg[0..4] steht der String. In msg[5]
ist dann die berechnete check-Summe. Das ist keine zyklische Redundanz-
pruefung, sollte aber fuers erste reichen.
msg[0]='K',
msg[1]='a',
...
msg[4]='a'
msg[5]=chksum
Der Empfaenger bekommt aus den rx-Fifo den String wie folgt:
msg[0]='K',
msg[1]='a',
...
msg[4]='a'
msg[5]=chksum
Die chksum in msg[5] vom Sender muss mit der berechneten im
Empfaenger verglichen werden.
Das sollte erst einmal den evtl. Datenverlust registrieren!
der Kaila
Hallo allerseits,
erst einmal vielen Dank Kailer fuer deine rasche Antwort. Nun habe ich
es geschafft eine CRC zu implementieren, aber bin auch schon wieder auf
ein neues Problem Aufmerksam geworden :-(.
Versuche ein syn. Byte zu senden damit der Emppfaenger bescheid weiss
das er empfangen kann. Es funktioniert nur habe ich ein
Verstaendnisproblem und zwar schicke ich s. Quelltext:
1
Sender:
2
uint16_tsyn,syn_Byte=0xAA;
3
...
4
rf12_ready();
5
syn=rf12_trans(0xB800|syn_Byte);
6
...
// und versuche das nun im Sender auszulesen was letztendlich in syn
drinsteht!
1
USART_Transmit(syn);
2
USART_Transmit(syn&0x00FF);
3
USART_Transmit(syn>>8);
4
USART_Transmit_String("\n",1);
// aber es sind nur Nullen, im Empfaenger jedoch sehe ich das AA
gesendet worden ist wie kann das sein?
hey,
nein das mache ich nicht, es wird der naechste Schritt sein eine Art
chat aufzubauen dazu benoetige ich spaeter vielleicht noch ein paar
Tipps.
mfg
Hallo Leute,
ich besitze auch die RFM12 Funkmodule. Alles funktioniert wunderbar, nur
mein Controller hat keine Zeit mehr die ganze Zeit auf das SDO Signal zu
warten. Mit anderen Worten: Ich möchte ein nIRQ Interrupt nutzen, wenn
das RFM12 Modul Daten empfangen hat. Meine Unterroutinen sehen
folgendermaßen in Bascom aus:
1
'--------------------------------------
2
'---Funkmodul---
3
'--------------------------------------
4
5
Sub Rf12_init:
6
Waitms 150
7
Temp = Rf12_trans(&Hc0e0)
8
Temp = Rf12_trans(&H80d7)
9
Temp = Rf12_trans(&Hc2ab)
10
Temp = Rf12_trans(&Hca81)
11
Temp = Rf12_trans(&He000)
12
Temp = Rf12_trans(&Hc800)
13
Temp = Rf12_trans(&Hc4f7)
14
Waitms 150
15
End Sub
16
17
18
Sub Rf12_setfreq(byval Freq As Single)
19
20
Freq = Freq - 430.00
21
Temp = Freq / 0.0025
22
If Temp < 96 Then
23
Temp = 96
24
Elseif Temp > 3903 Then
25
Temp = 3903
26
End If
27
Temp = Temp + &HA000
28
Temp = Rf12_trans(temp)
29
End Sub
30
31
32
Sub Rf12_setbandwith(byval Bandwith As Byte , Byval Gain As Byte , Byval Drssi As Byte)
33
Drssi = Drssi And 7
34
Gain = Gain And 3
35
Temp = Bandwith And 7
36
Shift Temp , Left , 2
37
Temp = Temp + Gain
38
Shift Temp , Left , 3
39
Temp = Temp + Drssi
40
Temp = Temp + &H9400
41
Temp = Rf12_trans(temp)
42
End Sub
43
44
45
Sub Rf12_setbaud(byval Rfbaud As Long )
46
Local Ltemp As Long
47
48
If Rfbaud < 663 Then Exit Sub
49
50
If Rfbaud < 5400 Then
51
Temp = 43104 / Rfbaud
52
Temp = Temp + &HC680
53
Else
54
Ltemp = 344828 / Rfbaud
55
Temp = Ltemp
56
Temp = Temp + &HC600
57
End If
58
Decr Temp
59
Temp = Rf12_trans(temp)
60
End Sub
61
62
63
Sub Rf12_setpower(byval Outpower As Byte , Byval Fskmod As Byte)
64
Outpower = Outpower And 7
65
Temp = Fskmod And 15
66
Shift Temp , Left , 4
67
Temp = Temp + Outpower
68
Temp = Temp + &H9800
69
Temp = Rf12_trans(temp)
70
End Sub
71
72
73
Sub Rf12_txdata(byval Maxchar As Byte)
74
Temp = Rf12_trans(&H8238)
75
Rf12_ready
76
Temp = Rf12_trans(&Hb8aa)
77
Rf12_ready
78
Temp = Rf12_trans(&Hb8aa)
79
Rf12_ready
80
Temp = Rf12_trans(&Hb8aa)
81
Rf12_ready
82
Temp = Rf12_trans(&Hb82d)
83
Rf12_ready
84
Temp = Rf12_trans(&Hb8d4)
85
Rf12_ready
86
For Count = 1 To Maxchar
87
Rf12_ready
88
Temp = &HB800 + Rfdata(count)
89
Temp = Rf12_trans(temp)
90
Next Count
91
Rf12_ready
92
Temp = Rf12_trans(&H8208)
93
End Sub
94
95
96
Sub Rf12_rxdata(byval Maxchar As Byte)
97
Temp = Rf12_trans(&H82c8)
98
Temp = Rf12_trans(&Hca81)
99
Temp = Rf12_trans(&Hca83)
100
For Count = 1 To Maxchar
101
Rf12_ready
102
Temp = Rf12_trans(&Hb000)
103
Rfdata(count) = Temp
104
Next Count
105
Temp = Rf12_trans(&H8208)
106
End Sub
107
108
109
110
Function Rf12_trans(byval Wert As Word) As Word
111
Local Lowbyte As Byte
112
Local Highbyte As Byte
113
114
Lowbyte = Wert And 255
115
Shift Wert , Right , 8
116
Reset Spi_cs
117
118
Highbyte = Spimove(wert)
119
Lowbyte = Spimove(lowbyte)
120
Set Spi_cs
121
122
Temp = Highbyte * 256
123
Temp = Temp + Lowbyte
124
Rf12_trans = Temp
125
126
End Function
127
128
Sub Rf12_ready
129
Reset Spi_cs 'Chip Select = 0
130
For I = 1 To 30000
131
If Spi_sdo = 1 Then Exit For
132
Next
133
End Sub
Ich habe nun den nIRQ Pin an INT1 am AtMega32 angeschlossen und den
Interrupt auf fallende Flanke konfiguriert. Leider wird beim Empfangen
kein Signal am nIRQ Pin geliefert. Muss ich diese Funktion im RFM12
konfigurieren? Und wenn, was muss ich an das Modul senden, damit ein
Interrupt ausgelöst wird, wenn Bytes im FIFO sind?
Viele Grüße,
Wolfang
Hi Wolfgang,
uha, ist das so ein Mix zwischen Basic und Fortran, was Du da
programmierst?
Oki, zum Thema. Deiner Initialisierung nach sollte der nIRQ-Pin vom
RFM12 im default-Zustand auf +5V sein. Das wuerde ich erstmal testen.
Bei mir war das anfaenglich nicht so (einige mV). Wenn dem so ist - also
nicht +5V -, dann wuerde ich ein 22uF Elko direkt am VDD und GND vom
RFM12 loeten und checken, was dann passiert. Die Dinger sind
betriebsspannungsmaessig ziemlich empfindlich. Bei mir liefen die erst
dann zuverlaessig....
der Kaila
Guckst du hier:
http://bascom-forum.de/index.php/topic,3421.0.html
Da gibt es Beispiele für alle möglichen Ansteuerversionen.
Der nIRQ bleibt übrigens so lange auf low, bis das Statusregister
gelesen wurde und entsprechend reagiert wurde. Beim FIFO IRQ muss der
FIFO geschrieben oder gelesen werden, die anderen IRQ's werden beim
Lesen gelöscht.
Moin,
hmmm, aber bei mir macht es keinen Unterschied, ob ich das Status-Reg in
der Initialisierungs-Routine vorsichtshalber lese oder Peng!
Erst mit dem Elko liess sich der nIRQ ueberreden, ueberhaupt auf High zu
gehen?!
der Kaila
Ich habe die RFM auf dem Pollin Funk AVR Board, da ist auch kein Elko in
der Nähe. Es funktioniert trotzdem. Hast du diesen "high sensitivity
reset" deaktiviert? Wenn man den Status ausliest, kann man ja sehen
welcher IRQ der Auslöser war.
Hallo,
ich mag diesen nIRQ-Pin nicht mehr.. Ich habe eure Vorschläge mal
ausprobiert, leider funktionierte es irgendwie nicht.
Naja.. und so habe ich halt weiter gesucht und gesucht und gefunden:
Ohne weitere(!) Konfiguration (siehe meinen Code oben) konnte ich den
FFIT Pin benutzen. Dieser schaltet auf High sobald der voreingestellte
Wert an Bits (Bytes?) im FIFO Speicher gelandet ist. Bei mir ist dies
glaub ich 8 Bits. Einfach den INT0 auf steigende Flanke konfigurieren
und mit dem Byte auslesen beginnen.
Trotzdem danke für eure Hilfe!!
Wolfgang
Ich hatte am Anfang die selben Probleme. Nur mit einem Logikanalysator
kommt man da wirklich weiter. Sonst tappst du da immer im Dunkeln.
Mit FFIT funktioniert es natürlich auch so. Aber Funktionen wie Wake-up,
welche einen IRQ benötigen kannst du nicht nutzen.
Hallo liebe RFM12 Nutzer,
erstmal danke an Benedikt fuer die Bereitstellung des Sourcecodes. Ich
habe 2 AVR Funkboards von Pollin und nutze den internen 8Mhz Takt des
ATmega32.
Leider bekomme ich das ganze nicht so recht zum laufen, meine AVRs
haengen im rf12_ready() beim warten auf den FIFO. Lustigerweise hatte
ich nach laengerem hin-und-her schon einmal eine funktionierende
Verbindung zwischen den 2 Boards hinbekommen. Nach kurzer Stromtrennung
hat das ganze aber nicht mehr funktioniert (1 mal tat der Sender spaeter
nochmal auf einem Board...). Seither haengen beide wie gesagt im
rf12_ready...
Kann mir bitte jemand weiterhelfen wie ich da auf Fehlersuche gehen
kann? Bin ein Anfaenger was Mikrocontroller betrifft, werde mich aber
bemuehen :)
Viele Gruesse,
Manuel
erstmal wollte ich mich auch an Benedikt bedanken für seinen starken
sourcecode.
nun nachdem ich die ersten teste mit dem rfm12 erfolgreich sind habe ich
festgestellt dass manche daten die ich empfange nicht rechtzeitig aus
dem fifo ausgelesen werden..gibts es die möglichkeit die Grösse des FIFO
buffer zu beinflussen oder ist die schon beim programm von benedikt auf
die maximale Grösse eingestellt?
vielen dank
Hi,
wollte mich auch für den code rfm01 und rfm02 bedanken.
Dann hätte ich noch ne Frage, beim rfm02 is ja keine fsk-modulation auf
dabei, über nimmt dein code die funktion dann?
MfG
Up4
Hallo Benedikt,
ich bin durch deinen Code aus folgendem Beitrag schon sehr viel weiter
gekommen:
Beitrag vom "Datum: 15.03.2009 19:17"
Da ich normalerweise nicht mit makefiles arbeite habe ich noch eine
kurze Frage zur Verwendung anderer µCs.
Ist es richtig, dass ich wenn ich anstelle eines ATmega8 einen
ATtiny2313 verwenden möchte nur im Makefile die Zeile MCU ändere?
Oder muss ich im Quelltext noch weitere Änderungen vornehmen?
Vielen Dank!
Das hat mir nicht sonderlich weiter geholfen. Ich nutze momentan den
Code rfm12_just_rxtx.
Auf zwei ATmega8 läuft alles wunderbar. Ich möchte das genze jetzt gerne
mit zwei ATtiny2313 zum laufen bekommen. Ich hab einige Probleme beim
Anpassen des Codes, da die ATtiny 2313 ja kein richtiges SPI haben.
Außerdem hab ich große Probleme mit dem compilieren, da ich sonst nicht
mit makefiles arbeite und normalerweiße nur eine .C Datei habe.
Alle Versuche, die ich in den letzten Tagen unternommen habe um das
ganze nach einigen Änderungen im Code zu kompilieren, sind gescheitert.
Ich nutze Code::Blocks. Wenn ich das Ganze zu compilieren versuche,
bekomme ich einige Fehlermeldungen, die alle wie folgt beginnen:
undefined reference to '...'
Ich konnte leider keine Lösung dafür finden.
Ich wäre über Hilfe sehr dankbar.
Grüße ext.
Hallo
Ich nutze das Funk-Avr-Evaluationboard und die Module RF01 bzw. RF02 von
Pollin. Das Senden funktioniert einwandfrei jedoch das Empfangen leider
nicht. Beide Module takten auf 10Mhz und ich weiß einfach nicht mehr
weiter. Im Anhang befindet sich der Code fürs empfangen. Kann mir
vielleicht einer weiterhelfen?
mfg Jonny
Hallo,
soweit ich das gesehen habe fehlt das "Receiver FIFO Read Command"
(0xB000) damit die Daten aus dem FIFO geladen werden. Aktuell sendest du
nur ein 8 Bit Kommando anstelle eines 16 Bit Kommandos ... (zumindest
wäre es beim RFM12 so).
1
for(j=0;j<16;j++)// read and discard status register
2
{sbi(RF_PORT,SCK);
3
asm("nop");
4
cbi(RF_PORT,SCK);
5
}
6
7
// hier 0xB0 senden => "Receiver FIFO Read Command"
Hallöle,
ich habe 2 Pollin-Boards v1.2 mit Atmega8 sowie jeweils RFM12-433.
Nach einigen Stunden Foren-Lektüre wage ich nun doch mal 'ne kleine
Frage:
Welcher der vielen Beispielcodes läuft auf meinen (unmodifizierten)
Boards? Dabei möchte ich den Atmega8 am 12MHz Quarz betreiben/belassen
und optimalerweise SPI benutzen (muß aber nicht unbedingt sein).
Kleiner Tipp wäre nett.
Viele Grüße
Igel1
Danke an Benedikt ich habe die Module mit zwei Anpassungen zum laufen
bekommen. Ich habe ein tamega32 in Verbindung mit avr bord von
robotikhartware gennutzt.
1. es muste nur die pins vom port änder
#define SDI 5 //5
#define SCK 7 //6
#define CS 4 //7
#define SDO 6 //0
2. die angepaste ready funktion nutzen weil dich der sender immer
aufgehangen hat.
void rf12_ready(void)
{
cbi(RF_PORT, SDI);
cbi(RF_PORT, CS);
asm("nop");
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
}
danke an alle.
Danke für den Beitrag auch wenn er schon ein paar Tage alt ist.
Hat mir doch Anregungen gegeben
Also ich beschäftige mich geraume Zeit mit RFM Module
und bin wie viele Wutausbrüche bekommen, weil das tweaken
nicht so stimme in den Hope Beschreibung ist.
Schaut euch die Microchip Doku zum MRF49XA ist identisch mit den Silab
Chip IA oder SI 4420 nur eben Microchip genau.
http://ww1.microchip.com/downloads/en/DeviceDoc/70590C.pdf
Was mich zur Verzweiflung gebracht hatte das der FIFO des Receivers
Das erste Paket richtig empfangen hatte und dann meist nur Müll.
Alles geändert was so geht auf TX RX Seit aber über eine richtige Daten
rate von über 10% Quersummencheck kam ich nicht darüber.
Also noch mal
http://www.mikrocontroller.net/articles/RFM12
studiert was man tun kann bei FIFO Overflow.
Meine MCU's liefen beide mit 10MHZ
Geschwindigkeit ändern, also internen.
Die Geschwindigkeit auf 16MHZ geändert und nun habe ich bei 4800 baud
525 gute zu 2 Drops.
Warum ich das geschrieben habe, weil ich selbst nicht glauben konnte das
bei einer so niedrigen Bitrate von Bedeutung sein könnte. CU :)
Hallo,
Ich beschäftige mich jetzt seit 2 Wochen mit den 868MHz Modulen und bin
langsam am verzweifeln.
Ich benutze die RFM12b Module mit 2 Atmega8, habe alle Änderungen für
die 868MHz übernommen und benutze den RFM12_RX_TX.zip Code von Benedikt
vom 16.05.07 mit der optimierten Senderoutine.
Ich musste lediglich die neue uart Library runterladen und alles ging
problemlos kompilieren.
Die While-Schleife läuft er problemlos durch, das "senden...." kann ich
sekündlich im Terminal auslesen.
Nur gibt er mir weder ein 10MHz Signal an SCK aus, noch kann ich sonst
irgendwelche Signale an MISO oder MOSI feststellen.
Also wird das RFM12 Modul wohl nicht richtig initialisiert, obwohl ich
beim Debuggen keine Fehler feststellen kann.
Neben anderen möglichen Fehlerquellen wollte ich mal Fragen, ob es an
meinem Atmel Studio 6 liegen kann, da der Code ja mittlerweile 8 Jahre
alt ist und ja auch die uart-Library schon veraltet war.
Vielleicht hat sich ja etwas an sonstigen Libraries geändert, sodass es
irgendwo zu Problemen kommt.
Alle anderen Fehlerquellen wie falsche Verdrahtung etc kann ich
ausschließen, da ich alles schon sehr oft kontrolliert habe.
Ich würde mich freuen, wenn mir jemand helfen könnte.
Gruß
Thread beobachten
Seitenaufteilung abschalten