bidirektionale RS232 Funkbrücke mit RFM12

Hallo,

habe für dieses tolle Projekt zwei kompakte Eagle-Layouts entworfen.
"SFI-Test" ist eins mit DIP-Mega8 Fassung + RFM12 2mm Steckverbindern.
Die LEDs sind hier solche mit eingebautem Vorwiderstand.
Das in etwa Funkmodul-kleine "SFI-SMD" schließlich mit SMD-Mega8 auf der 
Top- sowie dem (gespiegelten) RFM12 auf der Bottomseite.

Gruss Jan

Bitteschön.
Möchte einige davon fertigen lassen,
bei Interesse evt. Sammelbestellung
möglich.

Prinzipiell ja. Allerdings muss die Software erweitert werden, damit 
diese die TXEN und RXEN Signale ausgibt.
Weiterhin müssen natürlich noch die Vorschriften beachtet werden, da man 
mit diesen Modulen nicht in allen Bereichen einfach so senden darf.

cyberlink schrieb:

> Zu TXEN und RXEN: Soweit ich das verstanden habe, müssen diese Pins je
> nach Datenrichtung (Senden/Empfangen) auf high gezogen werden.

Ja.

> Wie das
> Schaltungstechnisch geht weiss ich noch nicht genau (vielleicht Pullup
> gegen GND und AVR-Pin auf Input stellen?).

Einfach direkt die 3,3V Signale vom AVR auf TXEN/RXEN.

> Aber die Möglichkeit der
> Anzeige der Senderichtung ist doch glaube ich schon in der Software
> eingebaut, müsste man also nur noch über zwei Ports ausgeben, oder?

Ja. In der Software gibt es Kommentare wie RX ON, TX ON, RX OFF usw.
An diesen Stellen müssen die Pins entsprechend geschaltet werden.

Daniel schrieb:
> Ich verstehe nicht ganz warum der Schaltplan DIP Version und Softconfig
> so verschieden sind was RTS/CTS betrifft.

Es gibt keinen Unterschied, RTS ist vorgesehen aber nicht implementiert.

> Kann man das deaktivieren um
> nur mit RX und TX zu arbeiten?

CTS wird immer ausgegeben, man kann das Signal ignorieren, muss dann 
aber damit rechnen, dass Daten verloren gehen wenn man zu schnell 
sendet.

> Was ist mit der FFIT Leitung?

Die ist vorgesehen wird aber auch nicht verwendet.

Man kann jeden Pin verwenden, man muss diesen nur auf Ausgang setzen und 
in der uart.h den Pin einstellen.

Hallo,
reicht es eigentlich aus in Bascom die Funktion

1

SPIOUT Kommando(1) , 1

bzw.

1

SPIIN Kommando(1) , 1

zu verwenden, um mit dem RFM12 zu kommunizieren?
Bastelbär hatte ja in einem anderen Thread einen Code gepostet, der mit 
einer Software SPI funktioniert.

Eine kleiner ablauf der kommunikation wäre nicht schlecht, wenn den 
jemand beschreiben würde.

Gruß
Tobi

Hallo!

Ich habe den Code dieses Threads verwendet, um das 
Pollin-Funk-AVR-Evaluationsboard (v1.2) in Betrieb zu nehmen. Hat nach 
wenigen Anpassungen sehr gut funktioniert.

Hier meine Änderungen für diejenigen, die auch dieses Board nehmen:

verwendete Hardware:

* Pollin Funk-Avr-Evulationboard V1.20
* RFM12 mit 17cm-Draht-Antenne
* Atmega32 mit 16 MHz-Quarz

Änderungen in den Dateien rfm12_rs232_rxtx_check5.zip:

main.c
======
CPU-Frequenz
- #define F_CPU 10000000UL
+ #define F_CPU 16000000UL

CONFIG-Schalter  (Taster gegen 5V statt Jumper gegen GND - bei Reset 
oder Start drücken und halten)
- #define CONFIG      PIND_4
+ #define CONFIG      PINB_1

Abfrage CONFIG-Schalter in main()
- if (!CONFIG)
+ if (CONFIG)

rf12.c
======
CPU-Frequenz
- #define F_CPU 10000000UL
+ #define F_CPU 16000000UL

SPI-Pins am Atmega
- #define SDI    3
- #define SCK    5
- #define CS    2
- #define SDO    4

+ #define SDI    5
+ #define SCK    7
+ #define CS    4
+ #define SDO    6

SPI-Geschwindigkeit clk/16 statt clk/4  in rf12_init(void)
- SPCR=(1<<SPE)|(1<<MSTR);
+ SPCR=(1<<SPE)|(1<<MSTR)|(1<<SPR0);  // clk/16

leds.h
======
- #define LED_TX    PORTC_2
- #define LED_RX    PORTC_3
- #define LED_RETRANS    PORTC_1
- #define LED_ERR    PORTC_0

+ #define LED_TX    PORTD_5
+ #define LED_RX    PORTD_5
+ #define LED_RETRANS    PORTD_6
+ #define LED_ERR    PORTD_6

Anfang bekam ich nur Müll ausgegeben bis mir auffiel, dass die SPI-Speed 
auf clk/4 steht. Das ist mit 10Mhz für AVR oberste Geschwindigkeit für 
RFM12. clk/16 ist für 16 MHz OK (dürfte auch für 10 Mhz nicht zu langsam 
sein).

Das Board hat nur zwei LEDs (ich habe sie 1x gelb und 1x rot bestückt). 
Daher musste ich TX+RX und ERR+RETRANS zusammenlegen.

Einige #defines sind mehrfach in main.c und rf12.c definiert. Das 
verwirrt und provoziert Fehler. Ich denke, diese sollte man in die 
(ohnehin vorhandene) config.h auslagern. Die Hardware-nahen #defines 
wären da auch gut aufgehoben!

Grüße
Stefan

Hallo,

super Lib, funktioniert bei mir den den RFM12 Modulen einwandfrei :)

Nun stelle ich mir die Frage, ob man auch ohne großen Aufwand die 
RFM12BP-868 (500mW) Module verwenden kann?

Gruß
Dirk

Hallo,

funktioniert das auch mit:

http://www.pollin.de/shop/dt/Mzg4OTgxOTk-/Bausaetze_Module/Module/Funkmodul_RFM12BP_868_Sende_Empfangsmodul.html

Davon habe ich noch 2 Daheim :-D

Würde diese gerne verwenden, da ich auch eine etwas höhere Reichweite 
benötige!

LG

Guten Tag

Ich bin ein Neuling und habe nicht so viel Erfahrung mit µC und 
Funkmodulen. An dieser Stelle möchte ich mich bei Benedikt bedanken für 
seinen robusten Code. Ein zweiter Dank geht an Stefan für seinen Beitrag 
vom 16.05.2010 in dem er den Code auf die 
Pollin-Funk-AVR-Evaluationsboard angepasst hat. Mit diesen Anpassungen 
ist mir gelungen relativ rasch zwei solche Boards, die mit RFM12 Modulen 
bestückt sind zum Einsatz zu bringen und die bidirektionale RS232 
Funkbrücke aufzubauen. Ich finde es einfach fabelhaft, dass ich mit der 
bidirektionale RS232 Funkbrücke für meine eigenen, zukünftigen Projekte 
ein verlässliches Testsystem habe.

Gruß an Alle

Borislav

Hallo,

erst mal ein großes Dankeschön an Benedikt für den Code!
Ich möchte in den Code eine Funktion Einbauen, die es mir ermöglicht, 
nach Eingabe einer bestimmten Zeichenkombination in den Config-Modus zu 
kommen. Als Zeichenkette wäre für mich irgendetwas denkbar, was man 
sonst nicht sendet, z.B. eine Kombination aus Sonderzeichen oder 
ähnliches.
Mir ist nun leider nicht ganz klar, wo (und wie) ich diese Funktion 
einbauen muss. Ich müsste ja die letzten 3 Zeichen abfragen und dann mit 
der gewünschten Zeichenkette vergleichen.

Schonmal Danke im Voraus und Gruß
André

Hallo

Ich wollte gerde die Funkbrücke zum testen aufbauen und dabei ist mir 
aufgefallen das die Pinbeschriftungen von dem Avr garnicht passen
Geschrieben steht Atmega 8 allerdings Reset an pin 29 und auch sonst 
passen die Nummern garnicht

Sven Möller schrieb:
> Ich wollte gerde die Funkbrücke zum testen aufbauen und dabei ist mir
> aufgefallen das die Pinbeschriftungen von dem Avr garnicht passen
> Geschrieben steht Atmega 8 allerdings Reset an pin 29 und auch sonst
> passen die Nummern garnicht

Das ist nicht das DIP Gehäuse, sondern das 44 polige TQFP...

Bez. Baudrate: Benedikts Formel ist zwar lt. Datenblatt korekt, aber 
durch das Integer-Runden / Wegschneiden kommen teilweise sehr 
unglücklicher Werte raus, bei 19200 wird z.B. real auf ~20284 Baud 
eingestellt.
Mit 345600 statt 344828 kommt man meiner Meinung nach besser hin...

Ich habe gestern meinen ersten Versuch gestartet und bin wie zu erwarten 
gescheitert ...

Beide module schalten auf 10mhz, Fuse auf Extern gestellt.
Aber beide avr's senden mir über rs232 nur Datenmüll und das in einer 
tour. Auch wenn einer der beiden aus ist und auch sonst vermutlich nix 
auf 433 senden dürfte.

Rs232 am pc eingestellt auf 19200 auch im config modus nur datenmüll
version war die rfm12_rs232_rxtx_check5

hat jemand einen hinweis?

Hallo,

ich verwende den Code aus "rfm12_rs232_rxtx_check5.zip" mit komplett 
anderer main() und habe das Problem, das ausschließlich beim Empfang die 
folgende Aufrufkette bei ca. jedem zweiten Telegramm blockiert:

rf12_rxdata() -> rf12_rxbyte() -> 1.Aufruf von rf12_ready()

konkret in dieser Zeile:
while (!(RF_PIN&(1<<SDO)));         // wait until FIFO ready

Ich will das als Basis für einfache Funk-Spielereien nehmen. Es ist also 
kein UART etc. beteiligt. Es wird ein Telegramm gesendet wenn eine Taste 
gedrückt wird.

Der Code in main() ist deswegen auch hinreichend simpel und es sind 
keine Interrupts aktiv.

1

#define CHANNEL      2     // Sende/Empfangskanal (0-3) (nur gültig wenn kein DIP Schalter verwendet wird)

2

#define RF_BAUDRATE  20000 // Baudrate des RFM12 (nur gültig wenn kein DIP Schalter verwendet wird)

3

#define MAX_BUF      128   // Paket Größe in Bytes (maximal 250, siehe auch rf12.c)

4

    :

5

    :

6

    rf12_init();  // ein paar Register setzen (z.B. CLK auf 10MHz)

7

    rf12_config(RF_BAUDRATE, CHANNEL, 0, QUIET);  // Baudrate, Kanal (0-3), Leistung (0=max, 7=min), Umgebungsbedingungen (QUIET, NORMAL, NOISY)

8

    rf12_rxmode();

9

10

11

    /* endless main loop */

12

    while (1) {

13

        /* check for received data */

14

        if (rf12_data()) {                               // Daten im RF12 RX Puffer ?

15

            rx_cnt=rf12_rxdata(rxbuf, &status, &rx_id);  // komplettes Paket empfangen

16

            if (rx_cnt<=MAX_BUF) {                       // Daten gültig (d.h. kein CRC Fehler) ?

17

                snprintf(line, sizeof(line), "%03d Received: %d", (int) loop, (int)status);

18

                WriteString(0, 4, line);

19

            } else {

20

                snprintf(line, sizeof(line), "%03d RX error!", (int)loop);

21

                WriteString(0, 4, line);

22

            }

23

        }

24

        /* middle key triggers sending */

25

        if (!KEY_MIDDLE) {

26

            rf12_stoprx();  // auf TX umschalten

27

            WriteString(0, 7, "Sending ...      ");

28

            rf12_txdata(txbuf, 30, value, 0);

29

            delay_ms(700); // "debouncing ;-)"

30

            rf12_rxmode();  // wieder auf RX umschalten

31

            value++;

32

        }

33

        :

34

        :

35

    }

Hardware ist das bekannte OLED Blutzuckermeßgerät:
http://www.mikrocontroller.net/articles/Compact_Plus_Blutzuckermessger%C3%A4t-Hardware
Es ist also ein 3,3V-System. Das Modul ist RFM12S in der 868 
MHz-Version. "USE_868" ist gesetzt und grundsätzlich funktioniert das 
System auch, da ca. jede zweite Botschaft (durch Tastendruck gesendet) 
fehlerfrei durchkommt - die Pins sind also korrekt angeschlossen etc. 
NFFS und NSEL sind je mit einen 12k-Pullup versehen.

Das Problem äußert sich so, dass rf12_ready() blockiert. Wenn eine 
weitere Botschaft vom Sender geschickt wird, dann läuft es weiter - 
natürlich für dieses Telegram mit fehlerhafter CRC aber die main()-Loop 
wird wieder ausgeführt.

Ich habe zwei gleiche Systeme aufgebaut und die können sich gegenseitig 
durch das Senden von Botschaften blockieren und auch wieder 
"entblockieren".

Hat jemand eine Idee, woran das liegen könnte?

Gruß,
Bernd

Noch ein Hinweis:
Das Modul ist über ca. 4cm lange Käbelchen verbunden und die Spannung am 
Modul mit 10µF Tantal / 100 nF keramisch abgeblockt. Sollte also 
eigentlich alles passen. Ich habe die SPI-Frequenz mal halbiert, hat 
aber nichts gebracht, da gleiches Verhalten.

Hat niemand eine eine Idee?

Gruß,
Bernd

Guten Morgen zusammen,

ich habe ein Problem und hoffe auf eure Hilfe.
Ich habe die Version Check5 auf einem Mega8 und 868Mhz fehlerfrei 
compiliert(led.h und use868 entsprechend bearbeitet usw.) aber bekomme 
nur eine Unidirektionale Verbindung obwohl auf beiden der gleiche Code 
läuft.
Ich kann nur von 1 auf 2 Senden aber nicht von 2 auf 1. Die RX-LED 
blinkt auch nur bei 1 und bei beiden geht die Error-LED an. Die Retrans 
und TX LEDs bleiben bei beiden aus.
Wo kann ich noch nach dem Fehler suchen?
Sender sind sowohl TeraTerm auf dem PC und ein Mega168 mit 
Temperaturwerten. Bei direkter Kabelverbindung klappt alles und emnach 
scheint von der Seite alles ok zu sein.

Habe gestern auch schon das Funkmodul was"scheinbar" nicht sendet 
ausgetauscht, da ich mehrere habe aber ohne Erfolg.

Hat jemand evtl. einen Tip?

Gruß
Clyde

Ich vergaß, ich nutze die DIP-Schalterversion.

Hallo zusammen,

nach dem Aufbau eines dritten Moduls klappt die Verbindung in beide 
Richtungen. Weiss zwar noch nicht, was ich versemmelt habe aber werde es 
später mal suchen.

Nun habe ich aber ein anderes Problem...

Ich habe keine ausreichene Reichweite, ich komme nicht mal 10-15m durch 
die Wohnung. Antennen sind Drahtstücke von ca. 8cm(868Mhz-Modul) und 
eine selbst gewickelte Spule aus einem der wenigen noch Funktionierenden 
Links.
Habe auch mal von QUIET über NORMAL auf NOISY aber es brachte nichts.
Als Leistungsabgabe habe ich den Originalcode übernommen, weil ich es so 
verstehe, das mit maximaler Leistung gefunkt wird.

Wer weiß Rat?

Huhu,
guckt hier noch jemand?!?!
Mittlerweile habe ich eine Aurel-Antenne für 868Mhz, aber vom PC-Zimmer 
bis ins Wohnzimmer(ca. 15m ums Eck aber offene Türen, Wände Massiv) 
klappt es immer noch nicht...
Habe jetzt auch mal nen anderen Kanal gewählt, aber ohne Erfolg...
Mit der Baudrate stehe ich noch auf Kriegsfuß, auf 19200 klappt alles in 
Sichtweite.
bei anderer Baudrate verstehen sie sich nicht mehr, trotz gleicher DIP 
Stellung, TeraTerm zeigt nur wirre zeichen obwohl ich die Baudrate 
angepasst habe(2400,4800,9600 ausprobiert).
19200 klappt wie gesagt...

Wo könnte der Fehler/das Problem liegen?

Gruß
Clyde

Moinsen,
da ich eine interne UART Funkbrücke brauchte die nicht an den Hardware 
UART geht habe ich mal diese Funkbrücke als Library gekapselt.

Der Aufruf erfolgt genauso wie die UART Lib von Peter Fleury.

Im Anhang eine Echo Funkbrücke, ein Modul sendet was es vom UART bekommt 
und das andere Funkt dies zurück.

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Frage an die Moderation? Ich verstehe das nicht, habe weitere Fragen zum 
Projekt und keine Antwort!


Hallo Benedikt, klasse Teil habe es nachgebaut und es tut was es soll.
Hast du noch eine Idee wie man das so erweitern kann das DTR und RTS und 
CTS mitübertragen werden für eine drahtlose FTDI(RS232) Verbindung zum 
Arduino mini oder clones zum drahtlos programmieren?

Da ich vor Jahren Benedikts Code für eine Funkbrücke zwischen zwei 
ATmega8 verwendet habe und auf einem aktuellen Board ebenfalls ein RFM12 
bestückt hatte, war es naheliegend das Projekt von damals als 
funktionsfähiges Gegenstück zu verwenden.
Zu diesen Zweck habe ich Benedikts Code etwas erweitert und dafür 
gesorgt dass er mit einem aktuellen gcc übersetzbar (zumindest für eine 
mega8) ist . (Interrupt Namen...)
Features:
-Timeout und Anzahl der Retries lassen sich per Software ändern und 
werden im EEprom gespeichert.
-Timeout fürs erneute Senden ist nun variabel (Pseudozufall) um ein 
wiederholtes gleichzeitiges Senden von beiden Teilnehmern zu vermeiden.
-Zu Testzwecken kann auf ein Senden der Bestätigung verzichtet werden 
und CRC Fehler können angezeigt werden.
Und das Protokoll war glaube ich auch nirgends dokumentiert:

TX POS  RX POS
0...4   ------: Sync data: 0xAA + 0xAA + 0xAA + 0x2D + 0xD4
5       0     : Status byte: bit 0 set: received ok
6       1     : Number of data bytes to send (id not counted!)
7...N   2...M : Data bytes: Only if number of bytes is > 0.
                If at least one data byte, first byte(7) is an id.
                Receiver accepts package when ID is different to the
                previous one.
                Transmitter increases ID if the reception has been
                acknowledged or the the acknowledge is not received
                within some timeout.
N+1     M+1   : CRC of bytes 5...N/0...M
N+2     ------: 0 - not received
Speciality in protocol: If one byte is 0x0 or 0xFF, the next byte will 
be completely ignored (stuff byte).
The default values will result in a re-sent after 10ms if no ACT has 
been received.

Sample reception:
00: Status
AA: Stuff byte because previous byte is 0
01: Number of data bytes to send = 1
05: The 5th packet to send
77: The Data - ascii w
2F: CRC (excluding stuff byte and excluding CRC itself)
E2: Garbage

Vielleicht interessiert es ja jemanden - die RFM12 scheinen ja weiter 
aktuell zu sein.

Da ich per PM danach gefragt wurde,
hier ein fertiges Binary aus dem Quellcode des vorherigen Posts
Hex für:
AtMega8 mit 8MHz Quarz.
Der Uart läuft standardmäßig mit 9600 Baud.
Um in das Konfigurationsmenü zu kommen, muss beim Power Up PinD.2 auf 
Low gezogen sein.