www.mikrocontroller.net

Forum: HF, Funk und Felder RFM12 als Empfänger für TFA THX301 Funk Wetter Sensor


Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da dies mein erster Beitrag ist möchte ich erstmal ein großes Lob an 
dieses tolle Forum aussprechen.
Ich lese nun seit ca. 4 Jahren hier mit und das Forum hat mir den 
Einstieg in die Mikrocontroller Welt sehr erleichtert. Wenn ich nicht 
weiter wusste habe ich hier so gut wie immer den richtigen Tip gefunden. 
(...glaubt mir das war oft der Fall :-))

Weiter so...

Nun zu meinem Problem:

Mein aktuelles Projekt soll die Daten von Funk Hygrometern empfangen und 
aufzeichen. Dies soll zunächst mit einem cortex-m3 STM32F103 verbaut in 
einem PRIMER2 geschehen.

Status Quo des Projekts ist:

Als Sensoren werden die Funk Hygrometer THX301 von TFA Dostmann 
verwendent (Conrad Best Nr.: 646235 - 6, kosten nur 5 Euro) 
Sendefrequenz ist laut Datenblatt 433 MHZ

Der verwendete Empfänger ist eine RFM12 von Pollin. Zur Konfiguration 
und zum Empfang/Senden verwende ich den RFM12 code von Benedikt den ich 
an meinen MCU angepasst habe.

Eine Normale Funkbrücke( RFM12 <--> RFM12) Funktioniert einwandfrei !!!

Das Protokoll des Sensors habe ich bereits decodiert. D.h. ich habe das 
RFM12 auf externe Filterung geschaltet und dann an PIN DCLK/CFIL/FFIT 
das Empfangene Signal mittels Soundkarte abgegriffen. Das Signal habe 
ich am PC mit einem kleinen VB tool aufbereitet und dann decodiert.

Details zum Protokoll im angehängten *.txt file " THX301_protokoll"

Jetzt zum wirklichen Problem...

Ich bekomme es nicht hin das mein RFM12 das THX301 Signal empfängt und 
ind den RX FIFO schiebt.

Ich habe mittlerweile alle Kombinationen von SETBANDWIDTH_RFM12(x,x,x); 
durch. Auch habe ich versucht die Frequenz des THx301 einzugrenzen, Sie 
liegt meines Erachtens bei 433,92 MHz.

Ich weiß das normalerweise auf das sync pattern 0x2DD4 gewartet wird 
daher schalte ich auf "always fill" (0xCA87) und versuche manuel 
auszuwerten ob 0xAA oder 0x55 im fifo empfangen wurde. Leider ohne 
Erfolg (mit einem RFM12 als Test Sender funktioniert die manuelle 
Auswertung)

Das was  am DCLK/CFIL/FFIT PIN raus kommt sieht man im Bild 
"Signal_anCFIL.jpg " oben ein Teil des RX Signals vom THX301 und unten 
das Signal eine RFM12 Senders.

Vielleicht mache ich auch einfach einen grundsätzlichen Fehler und das 
was ich Vorhabe kann nicht funktionieren.

Was meint ihr?
Habt ihr Tips wie ich weiter vorgehen kann?

Ich hoffe einer von den hier anwesenden Spezialisten kann mir Helfen das 
Projekt zum Abschluss zu bringen.

Ich hätte eigentlich gedacht das es kompliziert wird das Protokoll 
auszuknobeln aber nicht das ich am RFM12 scheiter...

Besten Dank im Vorraus und ich entschuldige mich für die harte Nuss im 
ersten Beitrag :-)

Grüße
Stefan

Autor: Holger S. (holli_1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz einfach, die RFM senden/empfangen normalerweise mit FSK-Modulation, 
der Sensor wie viele andere Fernsteuerungen mit OOK-Modulation. Da 
kannst du lange an der Bandbreite drehen und auf den FIFO warten. Da 
kommt nix.
Aber es geht mit folgenden Einstellungen doch, OOK zu empfangen:

1. Datafilter auf hC420 (OOK) stellen
2. FIFO aus - hCE00
3. Receiver setting: RSSI threshold -79 oder -85dBm einstellen

Am DATA/FSK Pin wird das empfangene Bitmuster ausgegeben, mit Input 
Capture kann die Pulslänge gemessen werden. Der FIFO kann nicht benutzt 
werden, das geht nur mit FSK. Wichtig ist, den RSSI threshold richtig 
einzustellen. Damit wird die 0/1 Schwelle festgelegt. Und da ist auch 
der Nachteil des Ganzen. Entfernte Sender werden schlecht empfangen, zu 
Nahe funktioniert das auch nicht mehr richtig.
Ich benutze bei mir den RFM01 als FS20 Empfänger, geht eigentlich recht 
gut. Mit besagten Einschränkungen natürlich.

Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Holger,

besten Dank für die promte Antwort.

Das meinte ich mit "grundsätzlicher Fehler"....
Ich werde gelich mal versuchen deinen Vorschlag umzusetzten.

Nur zum Verständniss:
Ich habe kurzmal gelesen was denn die Unterschiede zwischen FSK und OOK 
sind.
Nun ist mir aber immer noch nicht klar warum der RFM12 das OOK 
modulierte Singal am Data Pin ausgibt, obwohl er nur FSK Modulierte 
Signale in den FIFO schieben kann.
Könnte das vielleicht nochmal jemand in einfacher Art und Weise für 
einen nicht HF Spezialisten erklären?


Ich habe gesehen das meine Protokoll Datei etwas verschoben war, daher 
angehängt nochmal ein Update.


Grüße
Stefan

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Nun ist mir aber immer noch nicht klar warum der RFM12 das OOK
> modulierte Singal am Data Pin ausgibt, obwohl er nur FSK Modulierte
> Signale in den FIFO schieben kann.

Nochmal kurz zur Feststellung:
FSK: Trägersignal mit Mittenfrequenz f0, zur Übertraung der Symbole A 
und B wird das Trägersignal auf (f0 +df) bzw. (f0 +df) 
(frequenz)moduliert.

OOK: Trägersignal mit Mittenfrequenz f0, zur Übertragung der Symbole A 
und B wird das Trägersignal auf 100% bzw. 0% Amplitude moduliert.

Das sind also zwei komplett unterschiedliche Modulationsarten. Selbst 
decodieren kann der RF* 'nur' FSK (dafür bekommt er ja im Regelbetrieb 
auch eine hinreichend lange Präambel mitgeschickt von 3 oder 4 Mal 0xAA, 
sodass er seinen PLL tunen kann).

Beim OOK bekommt er 'nur' 'Signal an' und 'Signal aus' - und genau das 
gibt er letztenendes am Pin aus. Er selbst decodiert/speichert das aber 
nicht weiter. Warum? Keine Ahnung, ist halt so(tm). Das decodieren im µC 
sollte aber auch nicht allzu aufwendig sein.

Ich hoffe ich habe sämtliche Klarheiten beseitigt ;-)

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An einer Lösung hätte ich auch großes Interesse - so könnte ich meine 
Uhr sehr preiswert mit Außentemperatur/Feuchte ausstatten - also bitt 
als Projekt reinstellen!!!!!

(mit den RFM habe ich leider noch keinerlei Erfahrung....)

Viele Grüße,

egberto

Autor: Holger S. (holli_1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei OOK nimmt er RFM einfach den RSSI Pegel als Eingangssignal und den 
RSSI threshold als Schwellwert zwischen 0 und 1. Bei Überschreiten des 
Schwellwertes erscheint am Ausgang eine 1, sonst bleibt das auf 0. 
Außerdem sind bei diesen Übertragungen die Bits mit unterschiedlichen 
Puls/Pausenzeiten kodiert, z.B. 400µs für 0 und 600µs für 1 (FS20). Mit 
so etwas kann der FIFO nicht gefüllt werden, da der Empfänger keinen 
Takt erzeugen kann. Daher muss der AVR dann noch die Pulsdauer auswerten 
um die korrekte Bitfolge wieder herzustellen.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
schön das doch ein paar Leute Interesse haben.
Kurzer Zwischenbericht nachdem ich den ganze Feiertag mit "Funken" 
verbracht habe.

@Holger:
du schreibst das du die Version RFM01 hast, ich habe RFM12. Das von dir 
genannte Register CE gibt es bei mir nicht und das Register CA hat beim 
RFM12 eine andere Bedeutung. Ich habe trotzdem anhand des Datenblatt's 
und in Anlehnung an deine Vorgabe versucht das RFM12 auf "OOK" zu 
konfigurieren. (Wobei ein "OOK mode" nirgends im Datenblatt erwähnt 
wird).

@all:
Ergebinss des ganzen war:
DCLK Pin = Clock mit der von mir eingestellten Baudrate
Data Pin = binär Signal,hat nach Datenschrott ausgesehn, Signal war 
permanent vorhanden und konnte auch durch verstellen von DRSSI nicht zum 
schweigen gebracht werden.

Leider ist das debuggen nur mit Soundkarte als Oszi ziemlich armselig.

Gibt es eine Idee wie ich den DATA pin dazu zu bewegen nur bei sinvollen 
Daten was von sich zu geben? (Die richtige Stellschraube sollte schon 
DRSSI + LNA gain sein, oder?
Ist es richtig das RSSI -103dB stärker Filtert als RSSI -67dB, gilt das 
auch für LNA gain?
Vielleicht kann jemand nochmal explizit eine passende Konfiguration für 
das RFM12 posten damit ich Sie mit meiner vergleichen kann.


Wenn das mit dem Data Pin nicht klappt noch ein alternativ Vorschlag:
Wie bereits im ersten Post erwähnt habe ich zum decodieren des 
Protokolls das RFM auf externen Filter gestellt und am DCLK/CFIL/FFIT 
Pin das Signal mit meiner Soundkarte aufgenomen. Das Filtern von 
Rauschen habe ich alles per SW gemacht.

Ich habe nun versucht per Input Capture das DCLK/CFIL/FFIT Signal 
auszuwerten. Damit das Rauschen reduziert wir habe ich zwischen 
DCLK/CFIL/FFIT Pin und VBatt noch eine passende Filter Capazität (16nF 
bei 2000 Baud) d
Leider ist das Rauschen noch sehr stark und mein Capture trigger 
permanent auf Müll.

Habt ihr ne Idee wie ich das Rauschen weiter reduzieren und am 
DCLK/CFIL/FFIT ein schönes Signal abggreifen kann?
Wie kann ich aus dem Signal ein eindeutiges Binäres Signal machen 
(Schmidtrigger???)
Alles in allem ist die aufgezeigte Alternative ein gangbarer Weg, oder 
gibt es hier auch ein grundlegendes Problem?

Nochmal bezugnehmend auf Holgers letztes Statement:
Die Pulse die am DCLK/CFIL/FFIT Pin herauskommen habe, wie man im Bild 
oben sieht, eine konstante Bitzeit sind allerdings Manchester codiert. 
Wenn ich mir das Block Diagramm auf Seite 1 des Datenblatts vom RF12 
ansehe geht das was ich am DCLK/CFIL/FFIT Pin Messe direkt in den "Data 
Fit/ Clock Recovery block" und dann direkt in den Fifo. Wenn das Signal 
soweit kommt das es am DCLK/CFIL/FFIT Pin so wie aufgezeichnet 
herauskommt verstehe ich trotzdem nicht warum es nicht im FIFO landet. 
(natürlich bei FIFO = "always fill")

Soweit so schlecht ich freue mich auf eure Ideen.

Grüße
Stefan

Autor: Holger S. (holli_1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch mal mit einem RFM12 ein bisschen getestet. Die obigen 
Werte waren für den RFM01, da habe ich mich vertan. Der RFM12 hat 
tatsächlich keinen direkten OOK support. Aber es geht doch zu machen. 
Folgende Einstellungen habe ich angewendet:

;RFM12B - Configuration Command
;el : Enable TX register = 0
;ef : Enable RX FIFO buffer = 0
;Select 433 MHz band
;Select 12 pF crystal load capacitor
8017

;RFM12B - Power Management Command
;er : Enable receiver chain = 1
;ebb : Enable baseband circuit = 1
;et : Enable PLL,PA, TX = 0
;es : Enable synthesizer = 1
;ex : Enable crystal oscillator = 1
;eb : Enable low battery detector = 0
;ew : Enable wake-up timer = 0
;dc : Disable clock output = 0
82D8

;RFM12B - Frequency Command
;Set center frequency to 433.92 MHz
A620

;RFM12B - Receiver Control Command
;p16 : 0=INTin, 1=VDIout = 1
;VDI response time = Fast
;Receiver bandwidth = 200 kHz
;LNA gain = 0 dB
;RSSI threshold = -97 dBm
9481

;RFM12B - Datafilter Command
;al : Clock recovery auto lock control = 0
;ml : Clock recovery lock control = 0
;s : (0=digital, 1=analog filter) = 1
;DQD threshold = 0
C238

;RFM12B - FIFO / Reset Mode Command
;sp : Select single Byte Sync pattern = 0
;al : Disable Sync pattern recognition = 0
;ff : FIFO fill = 0
;dr : Disable highly sensitive Reset = 0
;FIFO IT level = 0
CA00

;RFM12B - AFC Command
;AFC automatic mode = Run once
;st : Strobe edge = 0
;fi : Fine mode = 0
;oe : Offset register enable = 1
;en : Calculate offset = 1
;Range limit = +3fres to -4fres
;Max. Deviation = +7.5 kHz to -10 kHz
C473

;RFM12B - PLL Command
;lpx : Enable low power crystal oscillator = 0
;ddy : Enable phase detector delay = 0
;ddit : Disable PLL loop dithering = 1
;Select clock output slew rate control for 2.5 MHz or less
;Select PLL bandwidth for max. 256 kbps
CC67

Am FSK-Pin kommen dann im Leerlauf ständig zufällige Bitmuster raus. 
Beim Aktivieren eines Senders entstehen dann längere Pausen. Die 
Pausenzeiten werden vom AVR gemessen und entsprechend ausgewertet. Das 
hatte ich schon mal vorher probiert, das geht. Der AVR ist dann 
natürlich ständig beschäftigt. Besser wird es mit dem RFM12 nicht gehen. 
FIFO kannst du auch vergessen, das geht wirklich nur bei FSK.

Autor: Holger S. (holli_1)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bingo, ausgetrickst. Ich habe noch mal den RFM01 und 12 verglichen und 
dann einfach mal die Einstellungen des RFM01 auf den 12 übertragen. Und 
siehe da, er kann es doch. Das nennt sich dann "undokumentierte 
Funktion".
Der neue Wert für data filter ist C220h, damit wird OOK aktiviert.
RSSI ist bei -91dBm gesetzt. Die Auswertung ist jetzt einfacher, da ein 
sauberes Signal am FSK heraus kommt.

Autor: Stefan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Holger: Vielen Dank für die Mühe. Du bist auch eher ein Nachtmensch 
oder bist du immoment im Ausland?

Ich habe deine Settings noch nicht ausprobiert da ich heute Früh einen 
"Durchbruch" hatte. Ich habe mal etwas mit der Frequenz gespielt, und 
siehe da bei 433 MHz war das Signal deutlich stärker. Hängt das 
vielleicht damit zusammen das im Hygrometer ein HR433C Resonator verbaut 
ist? Ich konnte leider kein Datenblatt für die "C" version finden. Oder 
kann es sein das die Tatsächliche Freqenz von der Beschriftung abweicht.

Mit folgenden Settings und einem 3.0 nF als Filter Kapazität am CFIL Pin 
bekomme ich ein lupenreines Signal am DATA Pin das ich mit Input Capture 
auswerten kann (Momentan werden die Bit Zeiten erstmal in ein Array 
geschrieben):

Das Setup wir nur einmal gemacht und dann nicht mehr angefasst:
SPI_SEND(0xC0E0);      // AVR CLK: 10MHz
SPI_SEND(0x8097);      // Disable FIFO
SPI_SEND(0xC2BB);      // Data Filter: internal AB/ external BB
SPI_SEND(0xE000);      // disable wakeuptimer
SPI_SEND(0xC800);      // disable low duty cycle
SPI_SEND(0xC4F7);      // AFC settings: autotuning: -10kHz...+7,5kHz
SPI_SEND(0x82C8);      // RX on
  
SETFRQ_RFM12(RF12FREQ(433.00));     // Sende/Empfangsfrequenz auf 433,00MHz einstellen
SETBANDWIDTH_RFM12(1, 0, 0);        // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm 
SETBAUD_RFM12(2000);              // 19200 baud
SETPOWER_RFM12(0, 6);             // 1mW Ausgangangsleistung, 120kHz Frequenzshift

Ich kann mir auf das alles zwar noch keinen Reim machen, vorallem warum 
der 3,0 nF das Signal so gut filtert. Laut RFM12 Datenblatt müssten es 
16nF sein, aber gut... es funktioniert.

Ich werde trotzdem nochmal deine Einstellungen ausprobieren.

Noch einen Punkt, warum seit ihr euch so sicher das es OOK ist.
Gibt es eine Möglichkeit mit Hausmitteln das Modulations Verfahren 
eindeutig zu bestimmen? Könnt ihr aus der Platine was entnehmen?

Wenn ich die Routinen zur  C ausgewertet hab dann stell ich das mal als 
Projekt hier rein ... wenn ich darf.

Grüße

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach Ja RFM Setup Tool das du verwendest hätte ich mal eher gebrauchen 
können:-)

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn ich die Routinen zur  C ausgewertet hab dann stell ich das mal als
>Projekt hier rein ... wenn ich darf.

Ja bitte !!

Grüße,

egberto

Autor: Kutte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Wenn ich die Routinen zur  C ausgewertet hab dann stell ich das mal als
> Projekt hier rein ... wenn ich darf.

und ich würde mich auch freuen -- auch über Codefragmente)
Kutte

Autor: Ruedi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan

Läuft dein Projekt noch oder hast du es aufgegeben ?

Autor: HansP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat von Euch schon jemand versucht die Funksignale der Wetterstation 
TE831x (von C) zu empfangen.

lg. Hans

Autor: ansel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab' vor ein paar Wochen auch mal mit dem undokumentierten
OOK-Modus des RFM12 experimentiert, und empfange nun neben dem
Sensor unserer TCM-Wetterstation noch drei weitere unbekannte aus
der Nachbarschaft.

Der angehängte Code gibt auf meinem Pollin-Funk-Eval-Board mit
atmega32 auf der rs232-Schnittstelle die empfangenen Daten aus.

Die Signale der Sensoren sind im Code beschrieben. Leider sieht
keines davon dem THX301-Signal ähnlich, aber vielleicht findet dennoch
jemand den Code nützlich...

Autor: Bernhard Hochstätter (felli47)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
AVR-Dekoder für Wetterstationen und Funkthermometer OHNE USART
==============================================================
Ein kleiner, ergänzender Beitrag zu vielen, wertvollen Vorarbeiten der
Community-Mitglieder. Vielleicht nutzt es dem ein oder anderen 
"Suchenden".

Aufgabe:
--------
Wie lassen sich Funksignale einer Wetterstation OHNE Nutzung des USART
auswerten?

Ansatz:
-------
Nutzung eines Binär-Eingangs am Parallelport!
Empfänger -> ATmega-Port -> Rauschdetektor -> Signaldekoder -> Ausgabe

Lösung:
-------
Das Programm tastet PA0 eines ATmega644 periodisch ab und wertet ggf. 
Signale aus die außerhalb des Rauschens liegen.

Wird ein Signal-Strobe detektiert, füllt sich ein Array mit 
"Puls-Daten".
Viele Pulse entsprechen "langen Bits" wenige "kurzen Bits", low-Pulse
entsprechen logisch 1 und high-Pulse logisch 0.

Aus diesen Daten lassen sich nun Pulsweiten und Logikpegel ableiten. Je 
nach Sensortyp ergeben sich hiefür unterschiedliche Algorithmen.
Das Programm erkennt Standard-Wetterstationen und analysiert den
Temperatur-Strobe, den Strobe für Luftfeuchte und den Strobe eines 
Regenmessers. Außerdem ist auch ein Manchester-Dekoder für 
Medion-Funkthermometer implementiert.....

Die komplette Beschreibung, weitere Infos und die Sourcen findet ihr im 
Anhang.

Grüße
Bernhard

Autor: RFM12-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger Sch. schrieb:
> ;Select 12 pF crystal load capacitor

hallo,
mal ne dumme frage, woher hast du eigentlich diesen wert?
ich such mich grad dumm, aber finde nichts passendes, wo steht, wo der 
wert herkommt.

danke schon mal.

Autor: Holger S. (holli_1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Register "Configuration", Bits 0-3. Es ist einfach ein Wert aus der 
Bereichsmitte, welche von 8,5pF bis 16pF geht. Die Abweichung der 
Quarzfrequenz habe ich aber nie genau gemessen.

Autor: RFM12-User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank!
also ist das eher unproblematisch.... gut.
dachte schon, was wollen die von mir wissen, die haben das modul doch 
gebaut.
ok, ist wohl dann die C zwischen den leitungen oder so. oder was ic 
internes?

na egal.

danke jedenfalls.

Autor: Joop (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Holger
Danke Holger fur diesem ,undokumentierten OOK-Modus des RFM12!

Ich hab' auch mal mit dem undokumentierten OOK-Modus des RFM12 
experimentiert und habe den RFM12B etwas modifiziert.

Den RFM12B ist mit einem 5nf  C_arrsi kondensatorausgerüstet
Wenn Sie diesem Kondensator ändern,mit einem 150-300pf Kondensator.
Dan wurden auch nahe und entfernte Sender sehr gut empfängen.

Reichweite im Feld RFM12B .Protocol ist FS20 OOK.

868 1/4 wave = 82.2mm    sensitivity ok 0.7 - 70 meter
868 1/2 wave = 164.3mm   sensitivity ok 0.7 - 100 meter
868 full wave = 345.5mm  sensitivity ok 0.7 - 120 meter


Folgende Einstellungen habe ich angewendet


(0x8027); // 868 Mhz;disabel tx register; disabel RX fifo buffer; xtal 
cap 12pf
(0x82c0); // enable receiver ; enable basebandblock        = 430.2400 - 
439.7575
(0xa68a); // 868.2500 MHz exact frequency     a060 - af3f = 860.4800 - 
879.5150
(0xc691); // datarate 2395 kbps 0xc647 = 4.8kbps
(0x9489); // VDI; FAST;200khz;GAIN -6db ;DRSSI 97dbm
(0xC220); // datafiltercommand ; ** not documented command **
(0xCA00); // FiFo and resetmode command ; FIFO fill disabeld
(0xC473); // AFC run only once ; enable AFC ;enable frequency offset 
register ; +3 -4
(0xCC67); // pll settings command
(0xB800); // TX register write command NOT USED
(0xC800); // low dutycycle disabeld
(0xC040); // 1.66MHz,2.2V NOT USED see 82c0

Grüße
Joop

Autor: Joop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
software und hardware-modification RFM12B ,fur empfange und senden OOK
auf dieser Website.

http://jeelabs.net/projects/cafe/wiki/Receiving_OO...

Autor: Holger S. (holli_1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Joop

Ich habe das mal mit dem RFM01 getestet. Das Tastverhältnis ist wie von 
dir beschrieben viel besser als vorher. Allerdings ist die Reichweite 
hier bei mir im Haus nicht viel größer geworden. Ich probiere aber 
weiter.

Autor: Uli W. (ueli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an die Mitstreiter zum RFM- Funkmodul.
ich würde auch gerne mit-funken aber ich bekomme die rechte Übersicht 
zum Pollin Funkmodul nicht. Aus den "C"-Programmen kann ich nicht viel 
ableiten denn ich programmiere in Bascom. Das tolle 
Konfigurationsprogramm von Holli würde mir auch gefallen.
Nun aber der eigentliche Grund weshalb ich extra angemeldet habe.
Ich empfange schon seit einiger Zeit ein Temp.- Feuchte Modul mit 433Mhz 
mit dem Conrad Funk-Sende-/Empfänger-Set das gibt es in 433Mhz und in 
868Mhz.
kostet 15€ und empfängt in AM was in eurem Ausdruck wahrscheinlich OOK 
bedeutet.
Mit dem 868 Mhz Modul empfange ich Funk-Heizungssteuerung,FS20-ähnlich. 
Es läuft aber noch nicht 100%ig. Den Code habe ich aus den I-net und 
wenn ich mich nicht täusche ist er von Holli (mit einigen Änderungen)
Den Link habe ich mal eingestellt ich weis noch nicht ob es geht.
http://www.conrad.de/ce/de/product/130428/SENDE-EM...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.