bidirektionale RS232 Funkbrücke mit RFM12

Hallo,

kurz eine Info, da sich alle Firmen gemeldet haben. Sehr erfreulich!

Hope kauft einfach nur die die's bei Integration ein und baut sie in 
Module ein. Sie dürfen jedoch keine die's einzeln verkaufen ohne 
Erlaubnis. Der freundliche Herr von Integration rief mich grad noch an 
und fragte ausdrücklich, ob irgendwo die's aufgetaucht seien, da scheint 
auch viel Misstrauen zu sein.

Der Befehl D0xx ist undokumentiert, das ist richtig, nähere Infos 
darüber bekomme ich nächste Woche.

Ende gut alles gut ;-)

Gruss,
Christian

Benedikt K. wrote:
> Martin W. wrote:
>> Appropro RSSI ... kann es sein, das das RFM12 garkein RSSI ausgang
>> besizt, und ich folglich garkeine Signalstärke messen kann, abgesehen
>> vom DRSSI Bit im Status-register ?!?
>
> Jain. Er existiert, aber nur auf dem Modul. Auf einer Seite sind 2 SMD
> Kondensatoren. Davon ist es der vorderste Kontakt direkt an der Ecke.
Perfekt .. danke.. werd ich mal ein wenig rummessen müssen


@Christian J. ... bin schon auf die Antwort gespannt.


MfG
TPM

Interessant. Hätte ich jetzt eigentlich nicht erwartet. Das heißt, die 
DIEs im RFM12 sind eigentlich von Integration hergestellte IA4421, oder 
habe ich das falsch verstanden, und HopeRF hat nur die Lizenzen zum 
Nachbauen gekauft ?

@wigbert
Sehe ich das richtig, dass der Abstand zwischen gespeistem Element und 
Reflektor 15cm beträgt ?
Auf dem Foto und bei allen anderen Yagis die ich gefunden habe, sieht es 
nämlich so aus, als wenn der Abstand zwischen Direktor und Reflektor 
etwa 15cm beträgt, und das gespeiste Element dazwischen liegt.

Hallo Benedikt,

hier die Anrwort:

Christian,

HopeRF buy our die products and mount them on boards which they sell as 
modules. HopeRF are not allowed to sell packaged parts or die directly 
without authorization from IAI. There are a few examples where this 
arrangement is in place.

Regards,
Nick

Ich war grad eben mal in unserer Absorberkammer und habe mir eine Yagi 
Antenne (3m) mal genau angeschaut. Du darfst natürlich kein Holz als 
Boom verwenden, die Stäbe werden in Metall eingebettet, so dass Ohmsch 0 
Ohm überall bestehen. Ein Dipol hat immer 240 Ohm und muss durch einen 
Balun angepasst werden, einfach 50 Ohm Kabel aus dem Baumarkt 
entsprechend verarbeiten.

Hallo Benedikt,

ich hab die 4 El. Yagi nach meiner "Baumappe" für 70cm 5W digit.
Betriebsart(Packet) funktionstüchtig im Einsatz.
Die Abmaße stammen aus "Rothammel" Antennenbuch.
Also die 150mm sind Abstand Dipol-Reflektor.
Abstände Dipol-Direktoren sind unterschiedlich.

Anbei mal eine Anpassung mit Trimmer.


Wigbert

Hallo,

falls jemand hat wäre eine leicht verständliche Anleitung für diesen 
Balun von Nutzen, wie man den wickelt und baut - möglichst mit Bildern 
;-)

Christian Julius wrote:
> Ich war grad eben mal in unserer Absorberkammer und habe mir eine Yagi
> Antenne (3m) mal genau angeschaut. Du darfst natürlich kein Holz als
> Boom verwenden, die Stäbe werden in Metall eingebettet, so dass Ohmsch 0
> Ohm überall bestehen.

Das hatte ich mich auch schon gefragt, ob das notwendig ist, denn die 
ganzen Dachantennen bestehen ja alle komplett aus Metall. Andererseits 
sind die Elemente alle Lambda/2, demnach ist die Spannung im Mittelpunkt 
immer 0, also dürfte es wohl egal sein, oder ?

> Ein Dipol hat immer 240 Ohm und muss durch einen
> Balun angepasst werden, einfach 50 Ohm Kabel aus dem Baumarkt
> entsprechend verarbeiten.

Ich dachte dieses gebogene Element dient als Anpassung ? Ähnlich wie bei 
einer J Antenne.

Selbst wenn die Antenne nicht optimal angepasst ist, die Antenne ist 
definitiv um ein vielfaches besser als die 17cm Drahtantenne:
Sender mit 17cm Drahtantenne, minimale Sendeleistung. In 20m Entfernung 
(quer durchs Haus) erreiche ich mit der Yagi nach der Anleitung von 
wigbert noch etwa 850mV. Das ist mehr als ein Empfänger mit 17cm 
Drahtantenne 2m neben dem Sender !

@wigbert
Danke. Es scheint irgendwo bei 6 Elementen eine Änderung in der Bauweise 
zu geben.

Hallo Benedikt,

mal mit meinen bescheidenen Wissen:

>Ich dachte dieses gebogene Element dient als Anpassung

Es gibt Faltdipoldipole(gebogener gstreckter Dipol Breite = Lamda/2 * 
Verkürzungsfaktor R0=240 Ohm) und Halbwellendipole(Stabform).
Beim Habwellendipol+gestreckten Dipol hast Du in der Mitte 
Spannungsnulldurchgang und Strombauch, deshalb mittige Befestigung an 
Metallträger möglich und beide Halbwellendipolhälften verbunden.
Faltdipol dann Übertrager zur Anpassung.
Die Gammaanpassung verschiebt den Anpasspunkt dahin, wo 50 Ohm
anliegen.

Aber das weisst Du ja alles.

Wer eine kleinere Antenne sucht sollte mal nach:
    HB9CV
googeln

Wigbert

Wigbert P. wrote:
> Es gibt Faltdipoldipole(gebogener gstreckter Dipol Breite = Lamda/2 *
> Verkürzungsfaktor R0=240 Ohm) und Halbwellendipole(Stabform).

OK, ganz langsam. Antennentechnik ist alles andere als mein Fachgebiet.
Halbwellendipol ist ein einfacher Stab (in diesem Fall etwa 34cm lang)
Faltdipol ist das ganze als gequetschter Kreis, also so ne Art Schlaufe, 
ebenfalls 34cm lang ?

> Beim Habwellendipol+gestreckten Dipol hast Du in der Mitte
> Spannungsnulldurchgang und Strombauch, deshalb mittige Befestigung an
> Metallträger möglich und beide Halbwellendipolhälften verbunden.

Möglich bedeutet also nicht unbedingt notwendig ?

> Faltdipol dann Übertrager zur Anpassung.
> Die Gammaanpassung verschiebt den Anpasspunkt dahin, wo 50 Ohm
> anliegen.

Das ist soweit klar. Ohne SWR Meter ist die Anpassung für mich aber nur 
schwer möglich.

Jetzt die große Frage. Was wird hier verwendet:
http://www.tfs.net/~petek/rockets/RDF/70ant.html

Das sieht auch wie der Faltdipoldipol aus, aber eine Hälfte ist auf 
Lambda/4 gekürzt und wird gespeist.

> Aber das weisst Du ja alles.

Schön wäre es, dann bräuchte ich hier nicht soviele dumme Fragen 
stellen.

> Wer eine kleinere Antenne sucht sollte mal nach:
>     HB9CV
> googeln

Habe ich gestern schon gemacht, aber im Vergleich zur Yagi sieht die 
sehr kompliziert aus und muss auch wieder abgestimmt werden.
Ich glaube ich muss mir doch mal ein SWR Meter bauen.

Hi Benedikt,
ich melde mich heut Abend zu den Fragen.
Muss jetzt weg.

Wigbert

OK, schonmal Danke !

Ich habe mal ein paar Messungen zur Bandbreite gemacht:
Ein RFM12 als Dauersender, ein RFM12 als Spektrumanalyser (Frequenz 
gesweeped, RSSI Spannung gemessen). So sieht ein Dauersignal auf 
434,27MHz aus wenn ein RFM12 auf 67kHz Bandbreite eingestellt dieses 
misst.
Aufgrund der Bandpassfunktion des Basisbandfilters, ist das RSSI Signal 
schwächer, wenn die Sendefrequenz und Empfangsfrequenz genau 
übereinstimmen.

Hallo Benedikt,

>Faltdipol

aus Parallelschaltung zweier Halbwellenstücke mit geringen
gegenseitigen Abstand D (D<0,05 Lamda) ist der Schleifendipol(Faltdipol)
entstanden. Mitte des Halbwellendipols V = 0, I = groß.
Fußpunktwiderstand grösser als ein eifacher gestreckter Dipol
Bandbreite grösser als ein eifacher gestreckter Dipol

> Möglich bedeutet also nicht unbedingt notwendig

es ist üblich Yagi-Antennen in Ganzmetallausführung aufzubauen.
Sämtliche Antennenelemente sind in ihrer geometrichen Mitte (U=0)
ohne Isolation direkt und leitend auf den Antennenträger zu montieren.
Diese Bauart bringt elektrisch keine Nachteile hat mechanisch und 
hinsichtlich Blitzschutz Vorteile.
Ich hab schon Yagis auf Holzleisten aufgebaut gesehen.

auszüge aus "Antennenbuch"

>Was wird hier verwendet:

hab ich noch nie gesehen, muss ich mir erst übersetzen.

>im Vergleich zur Yagi sieht die
>sehr kompliziert aus und muss auch wieder abgestimmt werden.

nun wo eine Pa da sollte auch ein SWR-Meter sein.
Ansonsten ist die HB9CV aus Baumarktteilen zu fertigen.
konnte meine Anleitung auf die Schnelle nur nicht finden.

Wigbert

Hallo,

eine Idee unsere HF Reaks: Einfach im Baumarkt eine aktive DVBT Antenne 
kaufen, die +15db macht und schon ist der superempfindliche Empfänger
fertig. Kosten 20€ das Stück an 75 Ohm Buchsen.

Hab im TXT jezt 2 neue Kommandos hinzu gefügt, die ich noch vergessen 
hatte. Einmal das PLL-Config-Command sowie das Syncron-Pattern-Command.

Damit kann man zum einen die Oszilatorparameter und zum anderen den 
Syncronisations-Wert für den Datenfilter festlegen.


MfG
TPM

Re.HB9CV

Ich wusste ich hab die Bauanleitung noch.
aus FA 05.01


Wigbert

Hier auch noch was über einfache Helix Antennen und Whip's. 70cm Yagi's 
kosten 39€ bei ebay, da lohnt der selbstbau nicht.

Hallo Martin,

>@Wigbert .. ? .. verstehe deine Antwort in bezug auf meine Frage nicht

wollte sagen Du hast recht.

@Benedikt

>ist das RSSI Signal
>schwächer, wenn die Sendefrequenz und Empfangsfrequenz genau
>übereinstimmen.

damit könnte ich die genaue Frequenzabstimmung prüfen.
aber woher weiss ich, ob ich völlig daneben liege, oder genau
drauf. Abgesehen vom Datenempfang.

Wigbert

Christian J. wrote:
> Hier auch noch was über einfache Helix Antennen und Whip's. 70cm Yagi's
> kosten 39€ bei ebay, da lohnt der selbstbau nicht.

Naja, ich habe 45 Minuten für eine mit 6 Elemente gebraucht, inkl. 
Werkzeug und Bauteilsuche. Also das lohnt sich meiner Meinung nach 
schon.

Wigbert P. wrote:
>>ist das RSSI Signal
>>schwächer, wenn die Sendefrequenz und Empfangsfrequenz genau
>>übereinstimmen.
>
> damit könnte ich die genaue Frequenzabstimmung prüfen.
> aber woher weiss ich, ob ich völlig daneben liege, oder genau
> drauf. Abgesehen vom Datenempfang.

Das ganze war ohne Modulation. Mit Modulation ist das Basisbandsignal ja 
ein Recheck und keine Gleichspannung. Daher gibt es dieses Abfall nicht. 
Um also das RSSI Signal sinvoll nutzen zu können, muss der Sender ein 
FSK Signal senden (z.B. abwechselnd 0 und 1) und der Empfänger wird auf 
maximales RSSI Signal abgestimmt.
Das Bild hatte ich nur gemacht, um den Frequenzganz der Filter sehen zu 
können.

Benedikt,
kann ich die RSSI Spannung messen. Wie hoch ist die.
Mich würde mal die Feldstärke bei Bandbreitenänderung
interessieren.

Wigbert

Ja, die kann man messen. Laut Datenblatt entsprechen -100dBm etwa 
300-600mV und -65dBm etwa 1000-1300mV. Bei mir geht die Spannung von 
etwa 450mV bis 1150mV.

hmm .. ich kann irgend wie den Punkt auf der RFM12 Platine nicht finden, 
wo ich das Analoge RSSI abgreifen kann. .. ich bekomm entweder 0V oder 
5V raus .. an allen möglichen anschlüssen auf der platine ... an einem 
kondensator hab ich noch die Quarzfrequenz messen können, aber kein 
RSSI.


MfG
TPM

Hier:
http://www.mikrocontroller.net/attachment/22519/rfm01.JPG

Benedikt K. wrote:
> Hier:
> http://www.mikrocontroller.net/attachment/22519/rfm01.JPG

ahaaa .. danke .. hmm .. komisch .. da bekomm ich n ziemlich merkürdiges 
Signal raus .. nix lineares, oder irgend n rauschsignal .. da liegt eher 
eine mischung aus rechteck und dreieck an. und das extrem regelmässig.


MfG
TPM

genau Benedikt,

ich messe ohne Messender(Dauerträger) 0,9V
mit Empfang ohne Antenne 1,5V(na ja 1,5m zu Sender)
mit Stabantenne 1,6V.
Alles gegen GND
richtig?

kann man da rumlöten ?

Wigbert

also beim Text senden, springt natürlich der Spannungswert im
Zickzack.
Wie koppel ich das Signal aus ohne den RFM12 zu versauen,
dann den Effektivwert auf einer Balkenskala od. ähnlich bringen.

Wigbert

naja.. .. also .. mein meinem RFM12 sende ich garnichts ... ich nehme 
ihn nur her, und empfange umgebungsrauschen, ohne irgend was explizit 
empfangen zu wollen .. trotzdem zeigt er das ziemlich linear an ...


MfG
TPM

Ich meine wenn der RFM12 den Text empfängt,
also kein monotonen Trägerempfang.
bekommt ja nur kurzzeitig ein Signal zum Auswerten.

Wigbert

naja.. ich ging gerade davon aus, das der RSSI anschluss auch ein RSSI 
liefert, udn nicht nur dann, wenn er etwas empfängt .. schliesslich ist 
es ja eine art Feldstärkemessung. .. dazu noch analog ...  das sollte 
aus meiner sicht ein massives rauschen drauf sein, und kein stetig 
lineares (taktähnliches) rechteck (oder sowas ähnliches) sein .. .. ?!?


MfG
TPM

Hallo Martin,
mein Oszi zeigt auch teilweise undefiniertes Zeug an.
aber nach Benedikt:
>Ja, die kann man messen.
hab ich ein Multimeter rangehangen, war das nicht richtig ?

Wigbert

Ich habe an den RSSI Pin einfach einen Tiefpass aus 10k und 10nF 
gehängt. Bei einem statistisch zufälligen Datensignal ergibt das 
natürlich ein Rauschen an dem Pin, genauso wenn kein Signal anliegt.
Das mit dem Dreieck/Rechteck kann ich auch erklären: Das müssten die 
Daten sein, die empfangen werden.
Das Bild zeigt deutlich, dass noch Reste der FSK Frequenz und der Daten 
auf dem Signal vorhanden sind (was ja auch klar ist).
Das RSSI Signal auswerten, wenn nur kurze Datenpakete empfangen werden, 
ist also nicht ohne weiteres möglich. Eine Möglichkeit wäre aber einfach 
mit einer Diode die die Spitzenspannung in ein RC Glied läd. So macht 
man das ja auch bei einem VU Meter für Audio.

Ach ja, bevor jemand fragt: Der Peak bei 433,8MHz kommt aus der USB 
Leitung an die das Modul angeschlossen ist. Keine Ahnung wiso, es ist 
aber so.
Man sieht aber deutlich die beiden Frequenze 434,36MHz+/-90kHz.

mir ist gerade aufgefallen, das das Modul bei aktivem Daten-Request 
(Hex:b800) irgend n schmarn mit dem RSSI signal macht ... wenn ich die 
abfrage des fifos stoppe, dann habe ich ein lineares signal, das bei 
aufgedrehtem V/Div ziemlich rauscht. wenn ich lese-routine wieder 
aktiviere, dann fängt es wieder mit dem "rechteckigem dreieck" (kann ich 
nicht anders beschreiben) an. sieht auch irgend wie so aus, als wenn 
irgend ein kondensator geladen, udn wieder entladen wird .. irgend was 
kleineres .. vieleicht 10n oder sowas ...


MfG
TPM

Martin W. wrote:
>irgend was kleineres .. vieleicht 10n oder sowas ...

Der Kondensator an dem du das Kabel angelötet hast, hat 4,7nF, das 
könnte also passen.
Ich frage mich aber trotzdem, wiso er das macht. Nur mal damit ich das 
richtig verstanden habe: Das Signal ist solange stabil, bis du das FIFO 
ausliest ? Ob das FIFO aktiv ist oder nicht, hat keinen Einfluss ?

Christian J. wrote:
> Das Riesenproblem bei diesen Modulen ist, dass der zuständige Controller
> binnen 0,2ms (!) auf einen Datenempfang reagieren muss, egal was er
> gerade macht.

Naja, 0,2ms sind für einen µC eine ewig lange Zeit, immerhin etwa 3000 
Befehle.

> Meiner ist sehr beschäftigt, auch mit Dingen die bis zu
> 0,1s dauern, zB Infrarot oder Display bzw MMC Zugriffen. Und dabei sind
> die INTs abgeschaltet.

Wiso schaltest du die INTs ab, die sind genau für solche Fälle gedacht ?

> Ich frage in der Zustandsmaschine der Hauptschleife  des Empfängers
> einfach immer wieder das DQD Bit ab.

Das DQD ist aber auch nicht besonders aussagekräftiger. Meinen Messungen 
nach ist nur das gefilterte VDI Signal einigermaßen zuverlässig:
Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"

Mach das ganze doch einfacher:
Bau etwas ähnliches wie ich ein, so dass die Daten gesendet werden, der 
Empfänger bestätigt den Empfang. Wenn keine Bestätigung kommt, wird 
einige 10ms später nochmal gesendet. Damit sind dann auch 100ms 
Empfangsblockade kein Problem. Allerding setzt sich auf diese Art die 
100ms Blockade auf alle folgenden µC fort (d.h. der sendende µC ist dann 
auch für 100ms ausgelastet.)

Hi,

die INTs sind sehr wohl ein Problem, da die bidirektionalen SPI 
Datenströme mit Timeout der Slaves arbeiten, damit die nicht hängen, 
wenn der Master spinnt. Und es sind 7 Slaves ;-) Habe mal versucht im 
INT auch mit der SPI zu arbeiten, das gibt totales Chaos nach einiger 
zeit.

Das DQD Signal ist bei mir sehr stabil, wenn man den Filter etwas 
heruntersetzt.

OK, das ist ein Problem. Da hilft dann nur Soft SPI für das RFM12.

Hast du bei DQD die Werte runtergesetzt, oder bei RSSI ?

Hi,

also ich habe LNA auf voll gelassen aber RSSI um 2 Punkte runter. Dann 
blinkt DQD im Takt des Trägers.

Aber mal was anderes, lustiges ;-)

Antenne ist ja feritig, wie im Bild zu sehen. Habe mal aus Spass eine 
schnelle Routine laufen lassen, die immer 1 Byte auf allen Frequenzen 
eng um 433,92 Mhz schnell nacheinander sendet. bandbreite auf Maximum 
eingestellt. Antenne ans Fenster gestellt und mal so den Nachbarn 
zugeschaut :-)

Ähmm..... die kriegen ihre Autos mit den Funkschlüsseln nicht mehr auf 
oder nur nach zigmal drücken ;-) prust *grins*

Nettes Spielzeug!

Christian J. wrote:
> also ich habe LNA auf voll gelassen aber RSSI um 2 Punkte runter. Dann
> blinkt DQD im Takt des Trägers.

Allerdings verschenkst du damit Reichweite. Bei mir steht RSSI um 1 
Punkt runter, und mit der Yagi Antenne sind 200m innerhalb bebautem 
Gelände kein Problem. Später werde ich mal die andere Richtung in 
Richtung Wildniss testen.

> Ähmm..... die kriegen ihre Autos mit den Funkschlüsseln nicht mehr auf
> oder nur nach zigmal drücken ;-) prust *grins*

Würde ich auch gerne mal machen. Mein Nachbar hat eine Garage mit 
Funkfernbedienung. Ich wollte schon lange mal schauen ob ich den Code 
kopieren kann, aber leider hat dessen Kleinkind die Fernbedienung eines 
abends vom Balkon geworfen, so dass die Garage mittlerweile nur noch per 
Hand  geöffnet wird.

Hallo Leute,

ein breitbandigen Träger setzen und Fernsteuerungen stören.
Das ist nun wirklich Mist was Ihr macht.
Wie weit seid ihr dann noch von der Funküberwachung entfernt?


Wigbert

Mit 2 von den Yagis bin ich mittlerweile bei 400m. Weiter konnte ich 
nicht testen, denn dann bin ich hinter einer Bergkuppe und der Empfang 
ist weg.

Nur mal Anmerkung, ein Forum ist eigentlich nicht so der richtige Platz 
für ein Zwiegespräch.

Wärs nicht besser, Ihr unterhaltet Euch per E-Mail weiter und postet nur 
dann was, wenn es auch allgemein brauchbare Ergebnisse gibt ?

Das wäre zumindest für Beispielthreads wesentlich günstiger.


Ich denke mal, daß unter diesen vielen privaten Plaudereien kaum noch 
jemand, der auch an dem Thema interessiert ist, die wirklich 
informativen Perlen herauspicken kann.

Ich würde diesen Thread daher als verbrannt (durch uninformativen Müll 
totgepostet) ansehen.


Peter

Mag sein....

... aber das ist Hobby und kein wiss. Projekt und solange nur ein Thread 
zugespamt wird ist das ok. Schlimmer wirds, wenn zu jedem Pups ein neuer 
Thread aufgemacht wird.

Und die Nachbarn mal zu ärgern, naja.... wenn ich meinen Humor nicht 
hätte, dann wäre ich bei diesem trockenen E-Technikerberuf mit lauter 
ernsten Ingenieuren um mich herum schon längst in der Klapse gelandet.

Also, lass uns unseren Spass hier, es wird ja niemand gezwungen Themen 
zu lesen, die nicht seinem Geschmack entsprechen. Und an der Grenze zu 
Legalität ist das sowieso spätestens seit der Bestellung der HF 
Nachbrenner, die schon alle verkauft sind ;-)

>>Kann jemand von euch bitte einen Artikel in der Wiki eröffnen und das
>>wesentliche dort verewigen?

Das ist nur leider mit Arbeit verbunden, Arbeit die niemand bezahlt und 
die einem persönlich nichts bringt, alles Wissenswerte steckt im Code 
oder ich habe es als pdf ausgedruckt bzw. in meinen "Tips & Tricks" 
Ordner ausgedruckt. Wissen auf Webservern, digitales Wissen überhaupt 
ist schnell vergänglich, da lohnt es einfach nicht. Nächstes Jahr sind 
die Module überholt, dann kommt was Neues.... und dafür die viele 
Arbeit?

Vielleicht fängst Du ja mal an, wenn Du ein Wiki bedienen kannst... ;-)

Einen Wiki Eintrag werde ich nicht erstellen, da ich dazu weder Zeit 
noch Lust habe.
Da sich auch sowiso keiner für die Software interessiert (was ich daran 
merke, dass die Software noch einige größere Bugs hat, sich aber noch 
niemand beschwert hat, dass die Software nicht läuft), ist es ja auch 
egal, wenn in dem Thread ein wenig über andere (durchaus für alle 
interessanten) Themen über das RFM12 diskutiert wird.

ich verfolge den tread jetzt schon längere zeit und habe nix gegen 
zwigespräche :)

Klaus Seufzger wrote:
> ich verfolge den tread jetzt schon längere zeit und habe nix gegen
> zwigespräche :)

OT: Dito :-) Ziemlich interessant.

Hallo,

eben kam die Antwort von integration zu undokumentierten Features des 
RFM02, wie zB D040. Leider kein weiterer Kommentar dazu, weil für die 
Funktion dieser Features keine Haftung übernommen wird. Wenn sie erst 
einmal bekannt sind berufen sich Kunden darauf.

Tja, schade....

Gruss,
Christian

Schade. Vielleicht kann Integration weiterhelfen ?
Da die ICs ja von Integration stammen: RF02 sollte auch OOK können, und 
sogar mit einem EEPROM alleine, ohne µC laufen. Der wäre somit ein 
schöner Ersatz für die einfachen AM Sender.

Hallo Benedikt

>Da sich auch sowiso keiner für die Software interessiert

das ist nicht ganz die Wahrheit.

Also bei Deinen Code "Funkbrücke mit Baudrateneinstellung"
benutzt Du bei niedriger Baudrate schmalere Bandbreite.Mehr nicht 
notwendig?
Verstärkung -6dB richtig? warum ?
DRSSI -103 db bedeutet das nicht kleinster Wert ? Warum ?
Zwischenzeitlich hattest Du andere optimale Werte reingestellt.
Sollte ich das ändern ?

Wigbert

Wigbert P. wrote:
> Also bei Deinen Code "Funkbrücke mit Baudrateneinstellung"
> benutzt Du bei niedriger Baudrate schmalere Bandbreite.Mehr nicht
> notwendig?

Das hatte ich anfangs gemacht, da ich dachte die optimalen Werte aus dem 
Datenblatt wären optimal. Allerdings ist mit denen die Reichweite 
teilweise um den Faktor 2 kleiner als mit mehr Bandbreite (ist ja 
irgendwie klar: Mehr Bandbreite heißt eine Störung auf einer Frequenz 
hat weniger Einfluss.)

> Verstärkung -6dB richtig? warum ?

Wo steht das ? Ich finde das nirgends.

> DRSSI -103 db bedeutet das nicht kleinster Wert ? Warum ?

Das ist der kleinste Wert. Dadurch reicht der schwächste Pegel aus, 
damit Daten empfangen werden. Allerdings darf dann wirklich kein anderer 
Sender in der Nähe sein, damit das funktioniert. Daher kann man ja die 
Umgebungsbedingungen einstellen.

> Zwischenzeitlich hattest Du andere optimale Werte reingestellt.
> Sollte ich das ändern ?

Wenn du willst, die bringen etwas mehr Reichweite. Demnächst gibt es 
aber noch eine ganz neue Version, mit besserer CRC und ein paar 
behobenen Fehlern.

Benedikt,
damit ich das richtig verstehe:

>-environment*6dB

Ich dachte LNA ist doch die Empfangsemfindlichkeit

DRSSI dachte ich ist die Analogausgabe der Feldstärke.

Also mit DRSSI stelle ich die Empfindlichkeit ein.Mit grösserer Gefahr
des "Zumüllens"
und was macht dann LNA (Gain heisst doch Gewinn)

Wigbert

Achso, jetzt weiß ich was du meinst.
Es gibt RSSIseth und LNA.
Das erste ist der Schwellwert, den das Signal mindestens haben muss um 
Daten zu empfangen. LNA ist der Verstärker davor. Ich lasse den 
Schwerwellert immer auf dem emfpindlichsten (mittlerweile eine Stufe 
darüber), und verändere die Verstärkung, denn diese verstärkt ja auch 
die Störungen mit, wenn welche vorhanden sind. Vermutlich kann man aber 
auch genausogut den RSSI Schwellwert verändern.

Benedikt,

wohl die wichtigsten Fragen:
Der RSSI-Pin(Analogwert der Feldstärke) steht in welchen
Zusammenhang zur Eingangsfeldstärke (proportional.....Formel?)
Zum Eichen eines S-Meters notwendig.

>Demnächst gibt es aber noch eine ganz neue Version, mit besserer CRC und....

mein Boardentwurf kann der bleiben, oder wird an der Hardware
entscheidendes verändert.

Wigbert

Die Hardware wird bleiben, zumindest bei der RS232 Funkbrücke. Laut 
Datenblatt entsprechen 300-600mV etwa -100dBm und 1000-1300mV -65dBm.

@ Martin W.
Die Recht und Dreiecke die du am RSSI Pin siehst, kann es sein dass das 
die Daten sind ?
Ich erhalte bei mir nämlich auch Rechtecke, das sind aber die einzelnen 
Datenpakete vom Sender.

Hallo,
habe nach Benedikts Einstellungen ein Reichweitentest gemacht.
Durch 2 Gebäude ca 100m (Fahrzeuge stehen zw. den RFM12)
fehlerlose Übertragung.
Als Sendeantenne:
http://www.mikrocontroller.net/attachment/24329/PICT0017.JPG
Als Empfangsantenne Drahtantenne.
wirklich erstaunlich.

Übrigens wer ein Multimeter mit Bargraphanzeige hat kann am
RSSI-Pin die Feldstärke verfolgen. Hatte max.4 Balken. Kein Balken > 
kein Empfang. Einstellung Wechselspannung, da sich der Pegel pos.+ neg. 
gegenüber dem Grundrauschen verhält.

Wigbert

Wigbert,

auch wenn es schon gesagt wurde, habe ich heute sät nachmittag noch mit 
einem Herr Dutton von Integration telefoiert (auch wenn ich dem als 
Begründung für meinen Wissensdrang das Blaue vom Himmel heruntergelogen 
habe, denn Hobbyisten supporten die nunmal nicht)

LNA ist ein einstellbarer Analogverstärker, der all das was er sieht 
verstärkt. Der RSSI Threshold ist die Schaltwelle ab der ein gültiger 
Träger detektiert wird. Es ist egal, welchen Wert man anpasst, das 
Ergebnis ist das Gleiche aber der Chip braucht mehr Strom bei 
empfindlicher Einstellung, denn der Datenmüll erzeugt viele Schaltungen. 
Legt man den Müll auf den Datenpin statt den Fifo zu nutzen kann man das 
schön sehen. Die Gefahr bei sehr hoher Empfindlichkeit ist, dass 2DD4 
häufiger kommt, mehr aber auch nicht. Ich fahre sehr gut mit reiner 
Reduzierung der beiden Werte um jeweils einen Punkt, dann habe ich auch 
ein zuverlässiges DQD Bit, um den Träger zu erkennen. Der 
Reichweitenverlust ist leider nicht unerheblich, runde 50m sind es 
schon, da 3db ja einer Verdoppelung entsprechen aber im Sinne einer 
Übertragung, die nahezu 0% Fehler hat nehme ich das in Kauf.

Gruss,
Christian

Wichtiger Hinweis für die RFM02 Module

Integration: "The RATE/2 comment is there since in thiscase the IA4221 
chip will sample the FSK pin both at rising and falling edges of the 50% 
duty cycle signal on nRES this way keeping the same datarate as set by 
the datarate command."

D.h. wenn das D040 Kommando für langsame uC benutzt wird, muss das Bit 
auf der steigenden Flanke an den Chip gesendet werden UND das nächste 
Bit auf der fallenden Flanke, sonst halbiert sich die Baudrate, was ich 
auch bemerkt habe.

Gruss,
Christian

Hallo Christian,
den reichweitentest hatte ich nur gemacht, um zu sehen ob sich
die "Balkenanzeige" verringert. Musste echt dafür laufen.
>Reduzierung der beiden Werte um jeweils einen Punkt
Wenn ich Dich richtig verstehe würdest Du für

LNA -6dB
RSSI -97dBm

empfehlen.


Wigbert

Interessant. Weist du wie man das D040 Kommando wieder abschaltet ? Mit 
D000 ?

Die LNA und RSSI Einstellungen sind abhängig vom Verwendungszweck. Wenn 
das ganze z.B. nur eine drahthlose Tastatur mit max 5m Reichweite werden 
soll, dann würde ich beide Werte etwas hoch setzen, damit man nicht 
jeden Müll empfängt.
Ich habe mir eine Frequenz ausgesucht, auf der wirklich nichts los ist. 
Dann ist selbst bei einem Punkt über dem empfindlichsten das DQD Bit 
stabil. Allerdings ist dieser Zustand selten in stark bebauter Umgebung.
Ich lasse daher die Einstellungen auf dem empfindlichsten Level (bzw. 
RSSI eines runter) und verwerfe die Pakete bei denen das Syncwort 
fälschlicherweise empfangen wurde (das passiert etwa einmal alle 2-10h) 
spätestens bei der Prüfsumme.

Benedikt hab dir gerade mal ne PN gesendet ;)

Benedikt K. wrote:
> @ Martin W.
> Die Recht und Dreiecke die du am RSSI Pin siehst, kann es sein dass das
> die Daten sind ?
> Ich erhalte bei mir nämlich auch Rechtecke, das sind aber die einzelnen
> Datenpakete vom Sender.

Das glaube ich nicht .. dafür ist das Signal viel zu gleichmässig. Das 
sieht aus, wie von nem Generator generiert. es schwankt nicht. Zudem 
habich garkeinen Sender laufen, der daten schickt. auch mitm Scanner 
kann ich keine Quelle ausmachen, die auf dieser Frequenz was ausstrahlt.

@Wigbert P. Ichhabe hier ... 
https://www.mikrocontroller.net/attachment/24947/RFM12.txt ... ein paar 
beschreibungen zum LNA und RSSI .. aber nur für den RFM12 .. sollte 
allerdings für RFM1 und 2 auch gelten.


MfG
TPM

Hallo Wigbert,

sobald meine bestellten Chipse eintreffen werde ich die Routinen so 
umschreiben, dass Sender und Empfänger einen Komm.Test machen werden, 
der Sender reduziert seine Stärke stufenweise, der Empfänger seine 
Empfindlichkeit und beide messen dann die Fehlerraten und entscheiden 
sich für eine ideale Konstellation. Das wird zwar einiges an Hirnschmalz 
erfordern das zu realisieren aber es ist auf jeden Fall eine 
Herausforderung ein dynamisch arbeitendes System zu haben, das sich der 
Umgebung anpasst. Freue mich schon drauf das zu coden ;-)

Gruss,
Christian

Hallo Martin,
hab das Ding schon gesucht, dank Dir.
Hallo Christian,
Dein Vorhaben ist sicher gut gemeint, aber wenn Du die Funkbrücke,
wie ich über ein längeren Zeitraum nutzt und Störer auftreten,
würde das System sich immer wieder Synchronisieren...........
Bin aber schon gespannt.

Wigbert

Ich hatte mir auch schon den Kopf zerbrochen, wie man das ganze 
ordentlich lösen kann. Es gibt einfach zu viele Fälle die Probleme 
bereiten können, vor allem wenn es mehr als 2 Teilnehmer sind (A in 
Reichweite von B, C in Reichweite von B, aber A und C außer Reichweite 
usw.). Oder solche Fälle wie, dass ab und zu ein Funkthermomenter mal 
für wenige 100ms dazwischenfunkt. Danach ist ja wieder alles OK. Ich 
dachte an ein regelmäßig Statuspaket als Keep Alive Signal. Wenn dieses 
für ein paar Sekunden ausbleibt wird automatisch ein Suchmodus 
gestartet.
Bei Integration gibt es eine Funktastatur als Beispiel für diese ICs. 
Die nutzen 3 Frequenzen um die Daten 3x zu übertragen + ein Suchsystem. 
Da kann man vielleicht einiges abschauen.

noch ein Clone, das Datenblatt gibt diesesmal mehr an Infos her.
Zu kaufen für 3.95 bei CSD -> http://www.csd-electronics.de/de/index.htm

Gruß Hagen

Stimmt, das IC entspricht dem RF12(=IA442x). Letztere sind ja keine 
Clones, sondern identisch.

Und TXC10x ist der RF02, RXC10x der RF01...

Hi Benedikt,

ich habe zu Hause eine Application Note, in welcher der Aufbau von 
Funknetzen mit vieles Nodes beschrieben wird, die Telegramme 
durchreichen, bis sie den richtigen Mode treffen, auch wenn dieser 
ausser der Reichweite des Masters ist. Kommt ein neuer Node hinzu webt 
sich dieser in das Netz mit ein und bekommt eine IP zugewiesen. Gucken 
ob ich das noch finde oder schon gelöscht habe, war jedenfalls recht 
komplex. Aufbau war mit Solarzellen.

Gruss,
Christian

hört sich extrem interessant an, sowas ging mir auch schon durch den 
kopf, aber dürfte ziemlich aufwändig zu realisieren sein das stabil 
hinzubekommen?

@Benedikt: hast du mal den Sync-Pattern Befehl getestet ? Falls der bei 
den RFM12 Modulen funktioniert dann ist der TRC102 richtiger. Allerdings 
findet man nur im TRC101 Datenblatt das Umrechnungsdiagram vom RSSI 
Signal von Volt zu dB. Auf Seite 10 oder 11 wenn ich mich recht 
erinnere.

Gruß Hagen

Hi,

die App.note ist leider weg, ging wohl beim Aufräumen mal verloren. Wie 
ich mich erinnere bestand die allerdings nur aus Software mit dem ARM 
Controller. Der Aufwand gleichberechtigte Nodes miteinander reden zu 
lassen, so dass sie Nachrichten weiterleiten ist allerdings enorm, vor 
allem was Buskollisionen angeht, denn jeder Empfänger muss ja horchen 
wann die Bahn für ihn frei ist. Neu ist die Idee auch nicht, es gab mal 
so eine Produktidee mit einem kostenlosen Telefon, je mehr Leute das 
Gerät haben umso grösser spannt sich das Netz auf, wobei jede Station 
wieder als Relais wirkt. Lassen wir das lieber, keine Lust auf 2 Jahre 
programmieren :-)

Gruss,
Christian

achja für alle die noch rfm12 module brauchen und noch etwas zeit 
haben....

Beitrag "Re: Sammelbestellung RFM12"

Hallo,

welche Senderbandbreite fahrt ihr denn? Ich habe da auf 90khz stehen, 
also 9850 eingeschrieben, den Empfänger dann entsprechend größer 
(irgendwas um 130 khz). Macht es Sinn diese dynamisch mit der Baudrate 
zu verändern oder liebe ein Werte für alle? Möchte meine Routinen 
möglich universell haben.

Gruss,
Christian

Ich lasse die 90kHz immer stehen. Die Baudrate wird bei mir nie über 
65000 Baud liegen, da dann ziemlich schnell die Reichweite kleiner wird. 
Den Empfänger habe ich auf 200kHz stehen.

Weiß jemand ob die Bandbreite +/-200kHz beträgt, oder insgesamt 200kHz, 
wenn man 200kHz einstellt ? Die Modulation macht +/-90kHz wenn man 90kHz 
einstellt.

Hi,

können wir vielleicht mal einen neuen Thread für alle allgemeinen Themen 
aufmachen, damit es nicht so lange wird? Mit Codesammlung hat das ja 
alles nicht mehr viel zu tun.

CJ

Hallo,

anbei noch ein Scan des RFM12 als Senders, die eingestellte Frequenz 
passt exakt.

@ Wigbert

Kannst du evtl. die *.Sch *.brd von  RS232-Funkbr_cke.rar
hier posten ?!

Danke

@W. Przybilla (przybilla)

Mail angekommen?

Wigbert

Hallo Benedikt,

ich habe mir zwei von deinen Platinen mit Mega8 und RFM12 + 
Mutterplatinen aufgebaut. Inzwischen funktioniert die Übertragung auch 
schon :-) Leider habe ich noch ein großes Problem. Die Module wollen den 
Mega8 einfach keine 10MHz gönnen. Beide blieben sturr auf 1MHz. Deshalb 
habe ich erstmal zum internen 8MHz Takt gegriffen. Nur leider ist das ja 
vor allem bei hohen Baudraten nicht das gelbe vom Ei. Bei 19k2 klappts 
noch. Hast du eine Ahnung woran das liegen könnte?
Bis zu welchen Baudraten funktioniert die Übertragung eigentlich noch 
gut? Ich habe hier einen Fall wo ich 57k6 übertragen müsste. Falls das 
klappt, welche RFM12 Baudrate wäre zu empfehlen?

Vielen Dank für die Software und das PCB!

Gruß
Björn

Björn Biesenbach wrote:

> Mutterplatinen aufgebaut. Inzwischen funktioniert die Übertragung auch
> schon :-) Leider habe ich noch ein großes Problem. Die Module wollen den
> Mega8 einfach keine 10MHz gönnen. Beide blieben sturr auf 1MHz.

Eigentlich dürfte das nicht sein: Entweder der Takt wird korrekt 
eingestellt, oder es dürfte garnichts funktionieren.

> Bis zu welchen Baudraten funktioniert die Übertragung eigentlich noch
> gut? Ich habe hier einen Fall wo ich 57k6 übertragen müsste. Falls das
> klappt, welche RFM12 Baudrate wäre zu empfehlen?

Wenn du einen externen Quarz verwendest, sollte nahezu jede Baudrate 
möglich sein.

Das RFM12 kann bis etwa 125kBaud, allerdings ist die Reichweite dann 
ziemlich gering. Ich habe es allerdings noch nicht ausprobiert. Bis etwa 
50kBaud funktioniert es aber ziemlich gut.

Den Inverter kannste dir auch Sparen, wenn du nicht den Level-Int 
brauchst, sonder auf Flanke triggern kannst. Z.B. per PCINT oder auch 
per echtem ext.Int. Dann kannste direkt das FFIT Signal reinfüttern und 
brauchst im Prinzip die Schleife nimmer, da das FFIT solange feuert, wie 
Daten im Puffer sind. Man ruft dann pro Int einfach nur ein Byte ab.

Gruß
Fabian

Es gibt eigentlich keinen Sender und Empfänger. Beide sind gleichwertig. 
Wenn also bei einem die LED von Anfang an leuchtet, ohne dass dieser 
etwas sendet/empfängt, dann würde ich auf einen Fehler im Aufbau tippen.

ehemals Christian M.

So, ich konnte es noch genauer eingrenzen.
Er führt die Funktion

1

unsigned char rf12_rxdata(unsigned char *data)

aus und bleibt dann in der

1

for (i=0; i<number; i++)

Schleife hängen. Alles was danach kommt wird nicht mehr ausgeführt. 
Darum geht die RX-LED auch nicht mehr aus, da dieser Befehl danach 
kommt. Aber zwei Sachen verstehe ich nicht.
Erstens sollte er garnicht in diese Funktion reinkommen, da er noch 
nichts empfangen hat und somit der Buffer leer sein sollte.
Zweitens blinkt die TX-LED die ganze Zeit, was ja zeigt, dass das 
Programm noch läuft. Da man ja keine parallel laufende Tasks hat, dürfte 
das nicht der Fall sein wenn er in im for-Loop hängen bleiben würde.

Bin also gerade ziemlich ratlos und müde...
Würde mich echt über hilfe freuen. Meistens sehen 4 oder mehr Augen mehr 
;-)

Gruß,
Christian

Hi,
ich habe da nochmals ne Frage. Ich habe eine der ersten Versionen auf 
nem ATMega32 und 868MHz Modul zum laufen gebracht. Jetzt versuche ich 
aber schon seit Tagen die "rfm12_rs232_rxtx_check_int.zip" zum laufen zu 
bringen. Aber immer wenn ich den INT1 verwenden will, läuft nix mehr. Es 
scheint, als ob das Programm nicht läuft.
Danach habe ich einfach mal probiert, in die Version die bei mir schon 
läuft den INT1 einzubauen. Aber da ist das selbe Problem.

Ich habe folgende Einstellungen vorgenommen:

1

MCUCR |= (1<<ISC11);

2

GICR |= (1<<INT0);

3

sei();

4

5

.

6

.

7

.

8

9

ISR(INT1_vect)

10

{

11

  cli();

12

  LED_PORT |= (1<<LED_READY);

13

  sei();

14

}

Was heißt "Läuft nix mehr" denn genau ? Geht die LED an, sobald der 
Interrupt Pin aktiviert wird ?

Nein, die LED bleibt aus und es wird auch kein Text mehr über den 
Seriellen Port ausgegeben, was ohne Interrupt wohl geschied.

Christian Mertens wrote:
> Ich habe folgende Einstellungen vorgenommen:
> [c]
> MCUCR |= (1<<ISC11);
> GICR |= (1<<INT0);
> sei();

Du schaltest INT0 ein, verwendest aber INT1...

Okay, da habe ich wieder mal den Wald vor lauter Bäumen nicht gesehen. 
Dann versuche ich jetzt mal deine int-Version zum laufen zu bringen.
Ich danke dir.

Benedikt K. wrote:
> Back to topic. Thema Antenne.
> http://www.tfs.net/~petek/rockets/RDF/70ant.html
>
> Diese habe ich gerade eben nachgebaut. Das ging ziemlich flott und die
> Antenne ist, wie soll ich es am besten beschreiben, einfach nur spitze:
> Das Signal mit dieser Antenne ist ohne Sendersignal um etwa 5dB
> schwächer als mit der 17cm Drahtantenne, die unerwünschten
> Hintergrundstörungen werden also gut unterdrückt (wenn nicht gerade der
> Störer in der gleichen Richtung liegt). In 20m Entfernung quer durchs
> Haus, ist der Empfänger mit dieser Antenne immer noch übersteuert
> (zumindest das RSSI Signal): Das RSSI Signal hängt bei 1130mV fest,
> genau dem gleichen Wert wie direkt neben dem Sender. Die Antenne ist
> also um etwa 20dB besser als die 17cm Drahtantenne !
> Wie groß die Reichweite ist, habe ich noch nicht ausprobiert, ich komme
> mir nämlich etwas komisch vor, wenn ich mit einer 70cm langen Yagi
> Antenne und einer Platine in der Hand die Straße entlang laufe... Ich
> möchte nicht wissen, was die Nachbarn denken, wenn sie mich so sehen.
>
> Mit 2 solcher Antennen sollte die Reichweite ziemlich hoch sein (ich
> schätze mal 500m oder mehr).

@Benedikt,

der von dir gepostete Link funktioniert leider nicht (mehr)
http://www.tfs.net/~petek/rockets/RDF/70ant.html

kannst Du das PDF noch mal bitte einstellen

danke je

http://web.archive.org/web/20070406060949/http://www.tfs.net/~petek/rockets/RDF/70ant.html

das ging ja flott...

noch eine Frage zum Anschluss der Antenne am RFM12 - Koaxkabel direkt an 
PIN8 oder muss noch eine Anpassschaltung dazwischen? Wie hast Du dies 
bei Dir realisiert - vielleicht hat ja Deine Frau den Foto schon wieder 
herausgerückt...;-)

Gruß je

Ich habe direkt ein kurzes BNC Kabel angelötet. Ich habe keine Ahnung, 
ob die Anpassung gut ist, ich denke aber das RFM12 müsste irgendwas um 
die 50 Ohm Impedanz haben. Zumindest liefert es an 50 Ohm etwa +4dBm, 
was auch der Maximalleistung laut Hersteller entspricht.

Hallo Benedikt,

Funkbrücke mit DIP, noch mal zu den LED's:

"Retransmitt"
LED leuchtet wenn keine Datenübertragung von statten geht?
"Error"
LED leuchtet wenn das Modul sich aufgehangen hat?

kann das nicht mehr wiederfinden.


Wigbert

Wigbert Picht wrote:

> "Retransmitt"
> LED leuchtet wenn keine Datenübertragung von statten geht?

Die leuchtet wenn eine Übertragung fehlerhaft war und nochmal gemacht 
wird.

> "Error"
> LED leuchtet wenn das Modul sich aufgehangen hat?

Die leuchtet wenn die nochmalige Übertragung selbst nach mehreren 
Versuchen immer noch nicht gekplappt hat. Also der Empfänger komplett 
außer Reichweite ist, oder nicht läuft.

Dank Dir Benedikt,

war wohl von mir schon in Vergessenheit geraten.

Wigbert

Man müsste die Software überarbeiten. Es soll funktionieren, irgendwo 
hat jemand mal geschrieben, dass er es gemacht hat. Ansonsten nimm halt 
einen beliebigen anderen NPN Transistor mit Vorwiderstand. Der 
funktioniert dann sicher mit 3,3V. Der BS170 sollte auch funktionieren, 
da ja kaum Strom fließt.

Ich habe ein 1000er Rolle von denen rumliegen...

Bei den neueren AVRs kannste den Inverter weg lassen und einfach den 
Pin-Change-Interrupt benutzen...

Gruß
Fabian

Hallo, ich verwende den Code von Benedikt ohne Inverter. Habe dazu den 
den Code wie folgt abgewandelt:

1

void rf12_rxmode(void)

2

{

3

  rf12_trans(0x82C8);                // RX on

4

  rf12_trans(0xCA81);                // set FIFO mode

5

  _delay_ms(.6);

6

  rf12_trans(0xCA83);                // enable FIFO: sync word search

7

  rf12_trans(0);

8

  MCUCR |= (1<<ISC01)|(1<<ISC00);                  // Status lesen um Bits zu löschen

9

  GIFR=(1<<INTF0);

10

  GICR|=(1<<INT0);                // Rising Level Interrupt für FFIT

1

ISR(SIG_INTERRUPT0)

2

{  static unsigned char bytecnt, status, number, id, rf_data[MAX_BUF], rx_lastid=255,crcl;

3

  static unsigned short crc;

4

  while ((FFIT_PIN & (1<<FFIT)))

5

  {

6

    ...

7

  }

Durch die Änderung ist der Interrupt nun aber länger aktiv, so dass 
mehrere Chars bereitstehen können. Die zusätzliche while-schleife 
erledigt dies (darin läuft der alte Code). Den Rising-Level Interrupt 
muss man für den Empfangsmodus aber seperat aktivieren, s.o.. FFIT_PIN 
und FFIT muss jeweils per #define definiert werden.

1

#define FFIT_PORT  PORTD

2

#define FFIT_DDR  DDRD

3

#define FFIT_PIN  PIND

4

#define FFIT    2

An dieser Stelle muss ich Benedikt ein großes Lob für seinen gut 
aufgebauten Code aussprechen. Habe diesen mittlerweile in verschiedenen 
Hobbyprojekten auf einem PSoc und anderen Architekturen am Laufen. Das 
RF12-Modul bietet damit eine prima Schnittstelle zwischen den 
verschiedenen Welten.

Gruß

Lorenz

Christian J. wrote:

(I can read German, but not speak/write it well..)

> ich habe spasseshalber mal bei beiden Firmen nachgefragt, ob die Kopien
> aus China denn legal sind. Auf die Antworten bin ich mal gespannt. Die
> Sache ist nämlich die, dass wenn hier jemand Chips bestellt hat und die
> Frachtpapiere weisen diese als Clone aus, dann war es das mit den Chips,
> die wandern dann in den Shredder und die Kohle ist weg.
Hope RF has licensed their dies and IP to a small number of
chip manufacturers, and the ones mentioned in this thread
are indeed 'legal'.

Tschuss,

Fred

Fred Van kempen wrote:
> Hope RF has licensed their dies and IP to a small number of
> chip manufacturers, and the ones mentioned in this thread
> are indeed 'legal'.

Also diesem Post nach:
Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"
ist es genau umgekehrt. Integration ist der Originalhersteller der Dies 
und verkauft die an HopeRF, die dann die Module daraus bauen.

Wie genau sieht die Minimalbeschaltung für die Software aus?
In der Version ..int ist FFIT mit PD3 und in Version 4 mit PB0 
beschaltet. Kann ich die Version 4 auch ohne die Beschaltung verwenden? 
Außerdem wüsste ich gerene, wass ich mit CLK machen muss wenn ich den 
AVR mit einem 8MHZ Quarz beschaltet habe.
Nebenbei, stört es wenn ich anstelle von R1 eine LED mit 1K 
Vorwiderstand verwende?
Von was für unentdeckten Fehlern spricht Benedikt im Post vom 22.07.2007 
08:02?
Und zu guter Letzt, funktioniert die software wenn CTS(PD2) unbeschaltet 
und RTS(PD3) mit einer LED (von Vcc) beschaltet ist?

Der Hintergrund ist der, dass ich mir vor längerer Zeit mal recht 
erfolglos  eine Funkübertragung mit zwei 433MHZ Modulen von Conrad 
gebaut habe und die Platine jetzt mit möglichst wenig Anpassungen auf 
die RFM12 Module umrüsten möchte.

Malte __ wrote:
> Wie genau sieht die Minimalbeschaltung für die Software aus?
> In der Version ..int ist FFIT mit PD3 und in Version 4 mit PB0
> beschaltet. Kann ich die Version 4 auch ohne die Beschaltung verwenden?

Ja. Das mit dem Interrupt ist nur bei der int version so.

> Außerdem wüsste ich gerene, wass ich mit CLK machen muss wenn ich den
> AVR mit einem 8MHZ Quarz beschaltet habe.

Offen lassen

> Nebenbei, stört es wenn ich anstelle von R1 eine LED mit 1K
> Vorwiderstand verwende?

Nein, aber leuchten wird die LED nicht, da dies ein Eingang ist.

> Von was für unentdeckten Fehlern spricht Benedikt im Post vom 22.07.2007
> 08:02?

In der void save_settings(void) Funktion fehlt noch diese Zeile:
eeprom_write_byte((void *)1,0xAA);
Ohne diese werden bei der SOFTCONFIG Konfiguration die Daten nicht als 
gespeichert erkannt und jedesmal neu die Standardwerte geladen.

> Und zu guter Letzt, funktioniert die software wenn CTS(PD2) unbeschaltet
> und RTS(PD3) mit einer LED (von Vcc) beschaltet ist?

RTS wird von der Software noch nicht unterstützt. Du kannst die Pins 
also beide offen lassen.
Du darfst dann nur nicht zu schnell die Daten senden, denn wenn die 
Verbindung schlecht ist, liegt die Datenrate nur bei wenigen kBit/s oder 
noch weniger. Und wenn der Empfangspuffer dann überläuft, gehen Daten 
verloren.

Fred wrote:

> As we are planning on doing European sales and support for them (yes,
> guys, which includes samples !)

Please keep us updated on this, and let us know who 'we' is. ;)

gibt es denn nochmal eine zusammenfassung des aktuellen codes und der 
schaltungen?

Hier die korrigierte Version.

Vielen Dank, die Funkbrücke funktioniert jetzt. :-)

Hallo,
ich will die Funkbrücke mit einem mege168 und einem RFM12B-868 aufbauen.
Bekomme beim übersetzen aber die Fehlermeldung TIMSK undefined. Da ich
von C keine Ahnung habe, bräuchte ich mal einen Tip.

Gruss Peter

ok, Datenblätter verglichen, der Mega8 hat TIMSK und der Mega168
TIMSK0 bis TIMSK2. Wenn ich es in TIMSK0, 1 oder 2 ändere, gibt es keine
Fehlermeldung. Muss ich einen bestimmten TIMSK nehmen? Da der RFM12B ja
nur max 3,8V kann, wollte ich den 168er nehmen, weil der für diesen
Bereich ausgelegt ist. Der normale 8er ja nicht.
Danke.

Gruss Peter

Du musst dir die Bedeutungen der einzelnen Bits im Register ansehen und 
danach entscheiden. Es gibt von Atmel sicher auch ein Datenblatt wie man 
von einem ATMEGA8 auf einen ATMEGA168/88 o.ä. migriert, also was 
geändert werden muss.

Hallo,

kann mir niemand evtl. nen Tip geben, was ich ändern muss und vorrauf zu 
achten ist, wenn man ein 868 Modul anklemmt?
Ich habe die befürchtung, das etwas kaputt gehen kann, wenn die Software 
falsche oder unvollständige Einstellungen vornimmt...

Gruß
Clyde

Ich kann nicht viel dazu sagen, da ich diese Software bisher nur mit den 
433MHz Modulen ausprobiert habe. Der Betrieb im 868MHz Bereich ist 
nämlich nicht so einfach, wenn man es richtig machen möchte (LBT, 
Einhaltung der Sendezeit usw.). Klar, es funktioniert trotzdem aber ich 
möchte nicht dafür verantwortlich sein wenn es Ärger deswegen gibt.

Anpassen muss man die Umrechnung Frequenz -> Einstellwert, und der 
Frequenzbereich des RF12 muss auf 868MHz gesetzt werden.

Hi,

das ist ja wirklich ein Super-Thread. Wer noch aktuelle (=Überarbeitete) 
Datenblätter für die Chips sucht, sollte mal hier schauen:

https://www.silabs.com/products/wireless/EZRadio/Pages/default.aspx

Den ehem. Hersteller "Integration" gibt es wohl nicht mehr bzw. wurde 
übernommen.

Si4021 = IA4221 = RF(M)02 (Transmitter)
Si4320 = IA4320 = RF(M)01 (Receiver)
Si4420/21 = IA4420 = RF(M)12 (Transceiver)

Es gibt dort wohl sogar Software für die Berechnung der Register. Die 
CDs inkl. Datenblätter und Software gibt es hier:

ftp://ftp.integration.hu/

Viel Spass...
Markus

Hallo Pit!

Habe vorige Woche den Code von Benedikt - die Version aus dem ersten 
Post -  auf m168 mit 20mhz in betrieb genommen, dabei ist nur zu 
beachten das die spi-frequenz die 2.5mbit nicht überschreitet, das hatte 
ich erst nicht gemacht und bekam nur ca. 10% der daten durch.

Da ich die 868er Module habe, musste ich den code natürlich ein wenig 
anpassen... schau dir mal im Datenblatt vom RFM12 an mit welchen 
kommandos die trägerfrequenz vorgegeben wird, ich musste nur diese 
anweisung an mehreren stellen im code anpassen, ist im prinzip der 
austausch von einem word welches an das rfm12 geschickt wird.

Zum setzen der frequenz ist die formel auch anzupassen, ich habe mir auf 
die schnelle mal einen passenden wert aufgrund der formeln im datenblatt 
ausgerechnet und 'hardcoded', die formel im code durch 860-f/0,005 zu 
ersetzen ist aber auch rasch geschehen.

Sonst funktioniert die sache super, vom 1. Stock aus den dachboden (3 
stockwerke) oder ins letzte eck vom keller, es kommt zwar zu 
retransmissions, aber selbst mit einem retry-counter von 2 ging bisher 
trotzdem alles fehlerfrei durch, bin echt zufrieden mit diesem Code -

An dieser Stelle auch mein DANK an Benedikt!

Aber aufgrund der Hinweise - wo finde ich infos zum thema 868mhz, soweit 
ich es bisher verstand sind dort keine dauerträger erwünscht, sonst kann 
ich mich austoben, oder ist sonst noch was zu beachten? nachdem ich aus 
wien komme ist natürlich auch die frage ob hier alles 1:! aus .de 
anwendbar ist?

Die sendeleistung würde ich wenn die module demnächst in den mk 
eingebaut werden hochdrehen soweit von den modulen unterstützt.

Danke auch für die Info - bin auch für passende Links dankbar, in diesem 
endlosthread habe ich diese hoffentlich nicht übersehen!

lG, Martin.

Martin S. wrote:

> Aber aufgrund der Hinweise - wo finde ich infos zum thema 868mhz, soweit
> ich es bisher verstand sind dort keine dauerträger erwünscht, sonst kann
> ich mich austoben, oder ist sonst noch was zu beachten?

Das Band 868-870 ist in Bereiche unterteilt, für die jeweils die 
maximale Sendeleistung und Belegungsdauer festgelegt sind:

http://de.wikipedia.org/wiki/Short_Range_Devices

Noch genauer steht es in den entsprechenden 
Allgemeinzuteilungsverfügungen der Bundesnetzagentur:

http://www.bundesnetzagentur.de/media/archive/6709.pdf
http://www.bundesnetzagentur.de/media/archive/4470.pdf

> nachdem ich aus wien komme ist natürlich auch die frage ob hier
> alles 1:! aus .de anwendbar ist?

Für den Bereich 869,3-869,4 schreibt die BNetzA, daß er nur noch in 
Deutschland genutzt werden darf, daher denke ich, daß der Rest 
europaweit einheitlich ist. Aber schau besser mal beim ösrerreichischen 
Pendant zu unserer BNetzA vorbei, da gibt es sicher auch Informationen 
über die bei Euch gültigen Allgemeinzuteilungen.

> Die sendeleistung würde ich wenn die module demnächst in den mk
> eingebaut werden hochdrehen soweit von den modulen unterstützt.

Dabei solltest Du aber das erlaubte Maximum beachten, das für die 
Frequenz gilt, die Du nutzt.

Hallo Reinhard,

Danke für die Tipps, habe über Google für Österreich noch immer nicht 
viel gefunden, unsere Regulierungsbehörde hat leider keine so tolle 
webseite... viele verweise auf richtlinien,...

letztendlich habe ich ein eu-dokument gefunden
http://www.bmvit.gv.at/telekommunikation/recht/downloads/en2006de771.pdf
in welchem per 1.6.2007 diverse richtlinien in länderrecht umzusetzen 
ist.
ev. auch für andere länder interresant, daher poste ich das mal hier!

dazu noch eine änderung dieser entscheidung aus 2008, umsetzbar bis 
1.10.2008, denke also das wir hier das aktuellste dokument haben:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:151:0049:0054:DE:PDF

Sollte somit überall in der eu gültig sein, oder?

lG, Martin.

ps.: spiele noch immer mit Benedikts Code, nachdem 57600 in eine 
richtung halbwegs fehlerfrei funktioniert, der durchsatz durch hamming 
aber schwindet & uni-direktionale kommunikation wenn eine seite ständig 
sendet kaum geht, bastel ich eine version in der man per #define hamming 
code deaktivieren kann. in meinem fall gibt es auf anwendungsebene 
prüfsummen und retransmissions sind egal da die daten zeitkritisch, d.h. 
später nicht mehr aktuell sind. Wenn Interresse besteht kann ich den 
code - wenn ich damit mal fertig werde - gern hier posten!

Hallo Zusammen,

ich habe jetzt das 433Mhz antelle des 868 Modul laufen.
Klappte von Anfang an und lief auch immer wieder mal.
Habe keine Dauerbetrieb sondern momentan einfach zu testen.

Allerdings hatte ich gestern abend Probleme, keine Verbindung.
Soeben habe ich es dann über Soft-Config nochmal konfiguriert.
Hat dann auch hinterher funktioniert, allerdings war die Konfig bei 
Modul 1 ok, aber bei Modul 2 waren erst nur Hyroglyphen und hinterhen 
immer noch komische Zeichen...

Hyroglyphen lassen ja noch auf falsche Baudrate schliessen, aber kann es 
sein, das die gespeicherten Daten mit der Zeit verloren gehen bzw. 
verstümmelt werden?

Hat jemand ähnliches durch?


Gruß
Clyde

BOD eingeschaltet?

Ich weiß es gerade nicht wirklich...
Aber es war unmittelbar nach dem Einschalten schon, nachdem die Module 
ca. 1-max 2 Tage ausgeschaltet waren.
Auch Resets haben nix gebracht oder Spannungslos schalten...

Das ist da etwas merkwürdig gewesen...

seit 40 Min läuft es wieder ohne Probleme, nachdem ich neu 
Soft-Konfiguriert habe...

Clyde H. wrote:
> Ich weiß es gerade nicht wirklich...
> Aber es war unmittelbar nach dem Einschalten schon, nachdem die Module
> ca. 1-max 2 Tage ausgeschaltet waren.
> Auch Resets haben nix gebracht oder Spannungslos schalten...
Dass der EEPROM seine Daten vergisst, habe ich bei diversen Projekten 
auch hin und wieder. Deswegen baue ich inzwischen immer eine Checksumme 
(zb einfach die Config noch mal Bitweise invertiert ablegen, wenn der 
Speicherplatz kein Problem ist) ein, anhand der die Config überprüft 
wird und im Fehlerfall auf die Ausgangswerte zurückgestellt wird.

>  Wie gehe ich dann mit diesem Anschluß am CLK-Pin des RFM12 um?
Genau das hatte ich auch gefragt, die Antwort gibt es etwas weiter oben:
Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"

Hier eine minimal aktualisierte Version: Die Takt Umschaltung
1MHz->10MHz führte vereinzelt zu Problemen beim AVR. Als Abhilfe wird
die Umschaltung jetzt Stufenweise 1MHz->2MHz->5MHz->10MHz durchgeführt.

Dann wäre dieser Version besser:
http://www.mikrocontroller.net/attachment/48080/rfm12_just_rxtx.zip

Das ist im Prinzip obige Version ohne das ganzen UART Zeug.

Welche Version meinst du jetzt?

Ralf R. schrieb:
> Also, irgendwie will keins der beiden Boards.
> Ablauf: Die LED_POWER geht an, wenn ich dann über die UART (vom PC) was
> schicke, geht die LED_RETRANS an und ne Sekunde später die LED_ERR.

Das klingt schonmal gut. Das heißt das wohl der Sender und die Software 
an sich funktionieren.

> Im PC auf der Receive-Seite kommen dann ein paar Mal "0x01" an.

Der Empfänger scheint also nichts zu empfangen. Sender und Empfänger 
haben die gleichen Einstellungen was Frequenz, Baudrate usw. angeht?

An der Stelle werden die Pins für die LEDs auf Ausgang gesetzt (und auch 
für den RFM12, aber dessen Pins werden in der rf12.c automatisch 
abhängig von den dortigen Einstellungen nochmal gesetzt. Sind die LEDs 
also wo anders angeschlossen, muss das hier geändert werden.

Wenn die Module nebeneinander liegen, dann sollte es sogar ohne Antenne 
funktionieren.

ich versuche nun seit 2 Tagen meine (schon mal funktionierende) 
Funkbrücke wieder zum laufen zu bringen.

Ich verwende den Code von Benedigt
rfm12_rs232_rxtx_check3.zip

Da ich 868MHz-Module habe, habe ich die dafür benötigten Einstellungen 
durchgeführt (die hie im Thema erwähnt wurden). Ausserdem habe ich die 
Baudrate auf 9600 geändert. Mehr im Code habe ich nicht geändert.

Mein Problem ist nun, dass die Module zwar die Daten hin und her 
schicken, es aber nur Müll ankommt. Retransmitt und Error-LED's leuchten 
nicht auf, also kein Fehler bei der Übertragung. Die Module liegen 
direkt nebeneinander. Im Terminal ist die Baudrate auch auf 9600 
eingestellt.

Im Anhang habe ich meinen Schaltplan, sowie das AVR-Studio-Projekt, den 
ich verwende (incl. Makefile), eingefügt.

Woran kann es liegen? :-(
vielleicht an den nicht richtig gesetzten "Security and Configuration 
Bits" des Controllers?

Ich vermute dass die Baudrate nicht passt.
Sind die Fusebits auf externen Oszillator gesetzt? Stell mal auch im AVR 
Studio die Frequenz auf 10MHz.

Die Fusebits sind folgendermaßen gesetzt (Screenshot aus PonyProg)
http://img135.imageshack.us/img135/8608/bits.jpg

Bei AVR habe ich in den Projekt-Einstellungen die Frequenz auf 10MHz 
gesetzt
http://img145.imageshack.us/img145/7972/avr.jpg

hat nichts gebracht

Die Fusebits stehen auf Quarz <8MHz wenn ich das richtig interpretiere, 
also nicht ganz das richtige. Es sollte aber trotzdem funktionieren.

Hast du einen DIP Schalter angeschlossen? In der Software ist dieser 
nämlich aktiviert. Falls du das nicht hast, kommentier mal #define 
USE_DIPSWITCH aus.

tatsächlich!
ich habe angenommen, dass so lange wie hinter #define
USE_DIPSWITCH keine 1 steht, wird es nicht ausgeführt :-/

Nun geht es! Ich danke Dir, Benedikt!

Wenn ich die DIP-Schalter einsetzen möchte, dann ist es doch richtig, 
dass am PortC die PIN's 0-2 für die Baudrate, 3-4 für HF-Kanal sind und 
5 unbenutzt?
In der rfm12_rs232_rxtx_check3.zip ist es wohl nicht richtig beschrieben

Ja, so ist es.
Nimm am besten die neueste Version von hier:
http://www.mikrocontroller.net/attachment/50533/rfm12_rs232_rxtx_check5.zip
Da sind die ganzen Fehler der alten Versionen behoben.

Ich habe mal die Unterstützung für die 868MHz Version eingebaut, aber 
nicht getestet, da ich keine 868MHz Module betriebsbereit aufgebaut 
habe.
Für die Einhaltung der Sendebeschränkungen im 868MHz Bereich sowie die 
Verwendung auf nicht erlaubten Frequenzen übernehme ich keine 
Verantwortung! Die eingestellten Kanälen sind meinem Verständnis der 
Listen der BNetzA nach für eine derartige Verwendung zugelassen, aber 
jeder der auf diesen Frequenzen sendet sollte das selbst nochmal 
kontrollieren.

habe das Programm für 868MHz v5 ausprobiert.

Folgende Änderungen habe ich für den Betrieb mit DIP-Schaltern 
durchgeführt:
- in leds.h die define's für DIP-Schalter festgelegt und für Soft-Config 
auskommentiert
- in rf12.c "#define USE_868" aktiviert
- in main.c "#define USE_DIPSWITCH", sowie "#define USE_868"  aktiviert 
und "#define USE_SOFTCONFIG" deaktiviert

funktioniert alles prima, nur bin ich mit den Einstellungen des 
DIP-Schalters etwas irritiert.
Bei mir ist nun Schalter1 (PinC0) ohne Bedeutung, Schalter2-3 
(PinC1+PinC2) HF Kanal und Schalter4-6(Pin3-Pin5) die Baudrate.

Verdrahtet nach dem oben eingefügten Schaltplan.

Andreas V. schrieb:

> Bei mir ist nun Schalter1 (PinC0) ohne Bedeutung, Schalter2-3
> (PinC1+PinC2) HF Kanal und Schalter4-6(Pin3-Pin5) die Baudrate.

Kann nicht sein, denn in der Software werden ganz klar PinC0-2 für die 
Baudrate verwendet.

blödsinn was ich da oben geschrieben habe...
es funktioniert alles super!

Hallo zusammen,

ich verwende ebenfalls das RFM12 Modul mit einem leicht geänderten Code 
von Benedikt (Basis ist die IRQ-Version, jedoch mit den Änderungen von 
rfm12_rs232_rxtx_check5 integriert). Erweitert habe ich die 
Funktionalität durch eine eigenen Adressimplementierung. Somit sind nun 
auch Multipoint-Verbindungen möglich. Broadcast ebenfalls. Sollte 
Interesse bestehen, so kann ich hier ein Diff zu Benedikts Basiscode 
posten.

Leider treten beim Versenden von großen Mengen der gleichen Chars Fehler 
auf. Teilweise werden Zeichen verschluckt. Mir ist das erst bei meinem 
aktuellen Projekt aufgefallen, da ich eine "Trennzeile" aus '-' nicht 
immer empfange.
Daraufhin habe ich eine Testfunktion eingebaut, die mir 256x jeweils 
eine Zeile "0123456789\r\n" ausgibt und anschließend das gleiche mit 
"----------\n\r" macht. Die Ziffern kommen prima an, bei den Strichen 
kommt er aber nach ca 100 Zeilen aus dem Tritt.
Erst dachte ich es liegt an der neuen Implementierung, jedoch tritt der 
Fehler auch mit allen älteren (gepollten) Versionen auf.

Hat jemand bei seinem RFM12 ähliche Beobachtungen gemacht? Ich werden 
gleich mal versuchen einen Workaround (zusätzliche Stuffbytes bei 
gleichen Chars) versuchen.

Lorenz .. schrieb:
> Leider treten beim Versenden von großen Mengen der gleichen Chars Fehler
> auf. Teilweise werden Zeichen verschluckt.

Sendest du eventuell zu schnell, so dass der Sendepuffer überläuft?

> Daraufhin habe ich eine Testfunktion eingebaut, die mir 256x jeweils
> eine Zeile "0123456789\r\n" ausgibt und anschließend das gleiche mit
> "----------\n\r" macht. Die Ziffern kommen prima an, bei den Strichen
> kommt er aber nach ca 100 Zeilen aus dem Tritt.

Dass die Striche Probleme machen ist merkwürdig: Diese haben eigentlich 
nichts spezielles an sich, haben viele 1en und 0en, also ausreichend 
Flanken, so dass es eigentlich keine Probleme geben dürfte. Den RF12 und 
auch die Software interessieren die Daten nicht, daher dürfte der Inhalt 
eigentlich keine Probleme machen.

Hallo Benedikt,

Testweise habe ich mal eine Pause von der Länge der "TX-Sammelzeit" 
zwischen die Ausgabe von jeweils 50 gleichen Chars gesetzt. Und siehe 
da, es funktioniert.
Dies verwundert mich aber etwas. Wenn ich den Code richtig 
interpretiere, dann wird im Timerinterrupt alle z.B. 50ms ein Paket 
abgeschickt, egal ob es nur aus einem Char besteht.
In der Funktion rf12_putc wird jedoch nach dem Einfügen eines neuen 
Chars in die Sendequeue die aktuelle Bufferposition geprüft und bei 
einem (drohenden) Überlauf in der Abzweigung

1

if (tx_cnt>=MAX_BUF)

 das Paket aus bisher gesammelten Daten incl. des aktuellen Datums 
SOFORT gesendet. Somit sollte für das nächste Zeichen Platz sein. Da 
durch das Absenden des Pakets auch ein ACK angefordert wird und vor dem 
Eintreffen desselben kein weiterer Char (durch

1

while(flags&WAITFORACK);

) ankommen kann, bin ich zu dem (eventuellen) Trugschluss gekommen, dass 
ein Pufferüberlauf nicht möglich ist. Die Funktion rf12_busy() prüft auf 
diese Weise ja auch die Belegung des Moduls.

Bitte kläre mich doch auf, falls ich da falsch liege.

Momentan beschäftige ich mich noch mit der Umsetzung von CSMA/CD, was 
ich bei meiner Multipoint-Lösung für dringend notwendig halte. Hat mir 
jemand einen Tipp wie ich eine halbwegs zufällige Zahl auf mehreren uCs 
erzeugen kann? Seriennummer usw scheidet bei den Atmels ja aus. Und da 
ich auch resets über Broadcast plane, scheidet eine einfache rand() aus.

Danke

Lorenz

Lorenz .. schrieb:

> Dies verwundert mich aber etwas. Wenn ich den Code richtig
> interpretiere, dann wird im Timerinterrupt alle z.B. 50ms ein Paket
> abgeschickt, egal ob es nur aus einem Char besteht.

Nicht im Interrupt sondern in der main Schleife werden die Daten 
verschickt. Davon abgesehen passts.

> In der Funktion rf12_putc wird jedoch nach dem Einfügen eines neuen
> Chars in die Sendequeue die aktuelle Bufferposition geprüft und bei
> einem (drohenden) Überlauf in der Abzweigung

1

if (tx_cnt>=MAX_BUF)

> das Paket aus bisher gesammelten Daten incl. des aktuellen Datums SOFORT
> gesendet.

Genau. Durch diese 2 Kriterien wird einerseits die Paketgröße maximiert 
um die Datenrate zu erhöhen, andererseits auch die Latenzzeit klein 
gehalten wenn nur wenige Daten übertragen werden.

> Somit sollte für das nächste Zeichen Platz sein. Da durch das
> Absenden des Pakets auch ein ACK angefordert wird und vor dem Eintreffen
> desselben kein weiterer Char (durch

1

while(flags&WAITFORACK);

)
> ankommen kann, bin ich zu dem (eventuellen) Trugschluss gekommen, dass
> ein Pufferüberlauf nicht möglich ist.

Ein Pufferüberlauf von diesem Puffer ist nicht möglich. Solange aber 
gesendet, bzw. auf eine Bestätigung gewartet wird, verbleiben alle 
weiteren empfangenen UART Daten in einem 512 Byte großen FIFO. Das kann 
aber überlaufen.

@Benedikt:

Danke für deine schnelle Aufklärung. Wie gesagt, ich verwende die 
IRQ-Version, die sendet durch Triggerung im IRQ oder manuell, aber das 
ist ja irrelevant. Komisch hingegen ist der Umstand, dass meine 
Funknodes keinen UART verwenden, sondern nur intern (gleicher uC) auf 
Funksteuerbefehle reagieren (z.B. Tempsensor x auslesen). Daher kann ein 
Bufferüberlauf durch einen UART nicht entstehen. Und die 
rf12_putc-Funktion ja wartet, falls der relevante Sendebuffer voll (bzw 
ein ACK ausstehend) ist. Diese putc-Funktion verwende ich zur Ausgabe 
von Variablen und Strings aus dem Flash.

Weiter würde mich interessieren, ob du mir Erfahrungswerte zu der 
Definition von ANSWER_TIMEOUT geben kannst. Wie lange dauert z.B. die 
Übertragung eines einzelnen Chars (ohne den für ein Paket erzeugten 
Overhead) grob? Ich kann das leider nicht richtig zur RF-BAUDRATE (und 
dann natürlich auch der Paketgröße) in Relation setzen.

Lorenz .. schrieb:
> Und die
> rf12_putc-Funktion ja wartet, falls der relevante Sendebuffer voll (bzw
> ein ACK ausstehend) ist. Diese putc-Funktion verwende ich zur Ausgabe
> von Variablen und Strings aus dem Flash.

Was machen die LEDs? Ist die retransmit oder error LED aktiv?
Es gibt einen ID Zähler der mit jedem Paket übertragen wird. Wenn ein 
Paket empfangen wurde, wird dessen ID als neuer Wert übernommen. Alle 
nachfolgenden Pakete mit gleicher ID werden verworfen.
Ich denke eher nicht dass hier noch ein Fehler in der Software ist, aber 
ich suche nochmal ob ich etwas finde, dass diesen Fehler erklären 
könnte.

> Weiter würde mich interessieren, ob du mir Erfahrungswerte zu der
> Definition von ANSWER_TIMEOUT geben kannst.

Ich hatte das mal ausprobiert, ist allerdings eine Weile her. Ich glaube 
5ms hat zu Problemen geführt bei 20000 Baud.

> Wie lange dauert z.B. die
> Übertragung eines einzelnen Chars (ohne den für ein Paket erzeugten
> Overhead) grob?

(8*/20000)s, also 0,4ms.

Da durch die Präambel, das Syncword, CRC usw. mindestens 9 Bytes 
gesendet werden, dauert alleine die Übertragung der Empfangsbestätigung 
3,6ms. Dazu kommt noch der Jitter des Timers der als Zeitbasis der 
Software dient von 1 Periode, also 2ms, was dazu führt dass die 
eingestellte Zeit um bis zu 2ms kürzer sein kann. So ab 6-7ms aufwärts 
sollten daher ausreichen. Die 10ms sind ein eher großzügiger Wert.

Benedikt K. schrieb:
> Was machen die LEDs? Ist die retransmit oder error LED aktiv?
> Es gibt einen ID Zähler der mit jedem Paket übertragen wird. Wenn ein
> Paket empfangen wurde, wird dessen ID als neuer Wert übernommen. Alle
> nachfolgenden Pakete mit gleicher ID werden verworfen.
> Ich denke eher nicht dass hier noch ein Fehler in der Software ist, aber
> ich suche nochmal ob ich etwas finde, dass diesen Fehler erklären
> könnte.
Retransmit oder Error-Led sind beide aus. Naja, mit einer Pause in der 
Größenordnung des TX-Sammellimits tut es aber korrekt.
Erklären kann ich mir den Fehler auch nicht, da deine PutC ja 
blockierend ist und das durch Warten vermeiden sollte.
An der ID liegt es auch nicht, die habe ich mir testweise ausgeben 
lassen bzw den entsprechenden Codeteil auskommentiert. Wozu nutzt du 
diese genau? Das war mir beim Studium deines Codes auch nicht klar. Für 
erneut übertragene Pakete?

Danke für deine Arbeit, die ist echt spitze!

Lorenz .. schrieb:

> An der ID liegt es auch nicht, die habe ich mir testweise ausgeben
> lassen bzw den entsprechenden Codeteil auskommentiert. Wozu nutzt du
> diese genau? Das war mir beim Studium deines Codes auch nicht klar. Für
> erneut übertragene Pakete?

Ja.
Das Problem war folgendes:
Der Sender sendet ein Paket, der Empfänger empfängt dieses. Er sendet 
ein ok zurück, was dem Sender sagt dass die Daten angekommen sind.
Jetzt können 2 Fehler auftreten: Der Empfänger bekommt das Paket nicht, 
oder der Sender bekommt das ok nicht.
In beiden Fällen wird der Sender das Paket nochmal senden da die 
Empfangsbestätigung ausbleibt. Der Empfänger muss daher erkennen können 
ob es sich um ein neues Paket handelt, dazu dient die ID. Diese wird 
nämlich nur bei neuen Paketen erhöht.

mikes schrieb:

> müßte nicht 0x94XX statt 0x95XX übertragen werden?
> In Deinem alten Code überträgst du auch diesen (0x94) Oppcode. Leider
> habe ich in den Datenblättern keinen Oppcode 0x95 gefunden.

Das ist das "5. Receiver Control Command" aus dem Datenblatt.
Der Unterschied von 4->5 ist, dass VDI von fast auf medium gesetzt 
wurde. Dies macht die Sache etwas unempfindlicher gegenüber Störungen.

cyberlink schrieb:
> Wie sieht es eigentlich mit der Portierung auf andere Controller aus?

Die Software sollte sich ohne viel Aufwand auf jeden anderen Atmega AVR 
portieren lassen. Eventuell sind ein paar Registernamen und die Position 
des SPI Interface anzupassen.

> Weil der Mega8 ist mir ein bisschen zu gross (auch SMD, bzw. nicht
> lötbar). Es gibt ja auch z.B. den Tiny84, der ist kleiner, hat weniger
> I/O-Pins und etwa gleich viel Flash.

Dafür weniger RAM und keinen UART.

> Kann man da einfach den C-Code darauf brennen, oder erfodert das
> Pin-änderungen, etc...

Das erfordert erstmal einen Software UART. Ist also prinzipiell machbar, 
aber erfordert doch einige Anpassungen am Code.