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
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.
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
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.
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
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
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 ?
Hallo,
mal so ein Tipp, da ich die Auswertung des RSSI nicht so ganz verstehe,
denn das Signal ist einfach nur Murks, ebenso das RSSI Bit im Status,
das wackelt auch wie verrückt.
Das Riesenproblem bei diesen Modulen ist, dass der zuständige Controller
binnen 0,2ms (!) auf einen Datenempfang reagieren muss, egal was er
gerade macht. 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.
Ich frage in der Zustandsmaschine der Hauptschleife des Empfängers
einfach immer wieder das DQD Bit ab. Der Sender wird mit aktiviertem
Synthesizer als reiner Müllsender betrieben, der den Fifo nicht auslöst
aber das DQD Bit bedient. Das kann der Empfänger erkennen und sich auf
den Empfang einstellen, der kurze Zeit später kommt.
Alles nicht ganz einfach, bei Duplex wird es noch schwieriger :-(
Christian
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.
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
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 ;-)
Ich komme zwar nicht mehr mit, da ich die wichtigen Infos in dem Thread
nicht mehr finde. Aber mit den Garagentoröffnern könntet ihr Pech haben.
Hörmann sendet z.B. auf 35MHz... Bei den Autos sieht es anders aus.
Kann jemand von euch bitte einen Artikel in der Wiki eröffnen und das
wesentliche dort verewigen? Ich suche mir mittlerweile den Wolf...
Danke im voraus!
Gruß Elektrikser
>>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.
@Benedikt
Ich habe mir auch einige der Module besorgt.
Ich interessiere mich für die Software! Für RS232 habe ich auf jeden
Fall Verwendung und möchte auch Funkthermometer Luftfeuchtemesser und
verschiedene elektrische Steckdosen damit ansteuern (weiss halt noch
nicht ob das prinzipiell möglich ist).
Möchte aber auch selbst etwas entwickeln und mit Bluetooth und/oder WLAN
etwas zusammenbrauen. Irgendetwas zusammenzulöten damit es, wenn es
funktioniert in der Ecke liegt, das ist nicht mein Ziel und war noch nie
so.
Ich persönlich brauche immer relativ viel Zeit, bis ich genau weiss wie
ich etwas realisiere. Die Realisation selbst ist dann in ganz wenig Zeit
gemacht. Aus diesem Grund habe ich mir nichtmal die Mühe gemacht etwas
runterzuladen, nicht weil deine Software möglicherweise Bugs enthält
sondern weil ich noch nicht weiss was ich damit anfangen kann.
Die meisten Blödmänner attestieren mir jetzt dass ich minderbemittelt
bin. Ich bin nur anspruchsvoll das ist alles. EIn paar Bugs stören mich
nicht eher schon, dass ich da von deiner Arbeit rumschnorre....
Hi
die Platinen sind endlich gekommen. Werde versuchen sie heute abend mal
aufzubauen und zu testen.
Benedikt hatte ja freundlicherweise was geschrieben was sich via
Software configurieren lässt.
Ich sag bescheid wie es läuft.
Grüsse
Tobi
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 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.
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
ich habe mir auch mal ein Angebot für den IA4420/IA4421 machen lassen.
Die Teile kosten ab 97 Stück (Stange ) 2,60 EUR incl. MwSt.
Ist also immer noch teurer, als so ein Modul. Den Quarz sollte man auch
mit 0,40 EUR noch einrechnen.
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
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 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.
Hallo zusammen,
Nach nächtelanger Fehlersuche habe ich nun endlich das RFM12-Modul im
IRQ-Betrieb zum Laufen bekommen. Als Hardware verwende ich ein
Breedboard mit RFM12 und das Pollin-Board. Danke an HagenRe für den Tip.
Mein größtes Problem war die Auswertung des IRQ-Signals. Da ich auf dem
Pollin-Board keine größeren Modifikationen vornehmen konnte war der
Einsatz eines Inverters ausgeschlossen. Darum hatte ich mit dem
MCUCR-Registern gearbeitet und Die Trigger auf steigende Flanken
eingestellt. Heute hat es endlich zum Erfolg geführt. Weil evtl noch
andere an dieser Stelle hängen hier die Änderungen am Code:
rf12_init:
1
FFIT_DDR&=~(1<<FFIT);// Muss eingestellt werden zur späteren Abfrage, FFIT vorher per #define eingebunden
2
RF_PORT=(1<<CS);
3
RF_DDR&=~(1<<SDO);
4
RF_DDR|=(1<<SDI)|(1<<SCK)|(1<<CS);
5
//DDRD&=~8; // Die Settings wurden doch schon gemacht - bringt nur Fehler deshalb raus...
6
//PORTD|=8;
In der ISR habe ich dann noch folgende Schleife eingebaut
1
while((FFIT_PIN&(1<<FFIT)))
2
{
3
...
4
}
Nun funktioniert die Übertragung per IRQ bei mir auch perfekt. Da die
ISR nur noch 1x pro Paket aufgerufen wird ist die Schleife notwendig.
Ansonsten kann man sich mit diesen Settings den Inverter sparen.
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
Hallo,
ich bin gerade dabei meine ersten Erfahrungen mit den RF12 868MHz
Modulen zu machen und benutze die zweite Softwareversion vom 19.06.2007.
Habe das ganze auch versucht auf die 868MHz Module abzustimmen. Dafür
habe ich folgende Änderungen gemacht:
1
main.c
2
rf12_setfreq(RF12FREQ(868.50));// Sende/Empfangsfrequenz auf 868,50MHz einstellen
3
4
rf12.h
5
#define RF12FREQ(freq) ((freq-860.0)/0.005) // macro for calculating frequency value out of frequency in MHz
6
7
rf12.c
8
voidrf12_init(void)
9
rf12_trans(0x80E7);// Enable FIFO zweiten Character(von rechts) von D auf E gestellt 433 auf 868 MHz
sonst habe ich alles so gelassen wie es war.
Er scheint zu senden, jedenfalls leuchtet die TX LED kurz auf.
Nur beim Empfänger leuchtet die RX LED von Anfang an. Auch wenn der
Sender nicht läuft.
Freue mich über jede Hilfe.
Bye,
Christian
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.
Jup, sind beide gleichwertig. Habe mich wohl falsch ausgedrückt. Die
RX-LED leuchtet bei beiden Modulen von Anfang an. Laut Code soll die
doch eigentlich nur leuchten, wenn er Daten im RF12 RX Puffer hat.
Gruß, Christian
ehemals Christian M.
So, ich konnte es noch genauer eingrenzen.
Er führt die Funktion
1
unsignedcharrf12_rxdata(unsignedchar*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:
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.
Zudem solltest du dir das cli(); und sei(); in der ISR sparen ;-)
A) Das macht schon der Compiler für dich rein.
B) Das 'kann' zu Problemen führen, da die Interrupts schon freigegeben
werden solange die ISR noch aktiv ist. Das vom Compiler generierte
sei(); ist so gelegt/optimiert, dass Interrupts wirklich erst wieder
möglich sind wenn der Programmzähler wieder im unterbrochenen
Programmteil steht.
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
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.
Hallo,
könnte man den BS170 (invertieren der Interruptanforderung vom RFM12
aus) auch weglassen und statt dessen den Interrupt von pegelgetriggert
auf flankengetriggert umschalten, oder müsste man dafür die ganze
Software überarbeiten?
Wäre der Transistor auch für den Betrieb an 3.3V geeignet? Im Datasheet
finde ich lediglich Diagramme für eine Gate-Source-Spannung von 4V.
Gruß
Dirk Schlage
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.
Sorry,
habe mich in meinem ersten Post unklar ausgedrückt.
Genau das hätte meine Frage sein sollen. Ich will eigentlich einen
Mega48 benutzen. Da aber doch ein unterschied zwischen pegelgetriggert
und
flankengetriggert ist, hier nochmal die Frage.
Benutzt jemand von euch den Code von Benedikt, und welche Änderungen
waren
nötig, um ihn mit flankengetriggert zum Laufen zu Bringen.
Gruß
Dirk
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
Danke Lorenz.
Ich habe den Code jetzt umgestellt, wie du beschrieben hast.
Ich verwende einen Mega88. Ein paar Registeranpassungen waren nötig.
Ausserdem habe ich den Code wieder von INT0 zurück auf INT1 umgestellt.
Leider hängt sich der Controller jetzt in der Init-Routine nach
TIMSK1=(1<<OCIE1A); auf.
1
voidrf12_init(void)
2
{
3
unsignedchari;
4
// RF_PORT=(1<<CS);
5
CS_PORT=(1<<CS);
6
RF_DDR&=~(1<<SDO);
7
// RF_DDR|=(1<<SDI)|(1<<SCK)|(1<<CS);
8
RF_DDR|=(1<<SDI)|(1<<SCK);
9
CS_DDR|=(1<<CS);
10
DDRD&=~8;// INT1 als Eingang schalten
11
PORTD|=8;
12
SPCR=(1<<SPE)|(1<<MSTR);
13
14
TCCR1A=0;
15
TCCR1B=(1<<WGM12)|1;
16
OCR1A=((F_CPU+2500)/500)-1;
17
TIMSK1=(1<<OCIE1A);
Mit dem Mega48 erlebt man immer wieder Überraschungen, wenn man Code vom
Mega8 einsetzen will. Vieleicht hätte ich lieber einen Mega16 oder
Mega32 nehmen sollen.
Gruß
Dirk
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.
Ich have geschrieben:
> > 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'.
und Reinhard Max schrieb:
> Also diesem Post nach:> Beitrag "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.
Das ist korrekt.
OK, now back to English, as my German writing is very bad :)
It is correct- Integrated makes the dies, and sells a chp version
of those dies. HopeRF has a license to integrate those dies into
modules, the ones we all know.
As we are planning on doing European sales and support for them (yes,
guys, which includes samples !) we did request a copy of their
agreement with Integrated.. they are 'legal' indeed, and not a
cloning house (of which there are MANY in that area..)
Gruss,
Fred
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. ;)
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.
Hi all,
See attached - I added this little board to our PCB run of
yesterday. Small carrier board designed to easily "use"
the RFM12 modules:
- single 5x2-pin connector (2.54mm) for VCC, GND, SPI and I2C
- single 10x1-pin connector (2.54) for plugging onto a breadboard
(the VDD generated by this PCB is also on the breadboard conn)
- DIP switch for the FSK and RESET lines (with pullup)
- space for RFM12B DIP and SMD versions, as well as RFM12BP
If anyone is interested, let me know !
Cheers,
Fred
Hallo zusammen,
was muss in der letzten Version .check4.korr.
alles geändert werden um die RFM12S-868 zu betreiben?
Das was Christian schrieb
Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"
passt irgendwie nicht mehr, da wesentlich mehr angaben der Frequenz
enthalten sind...
Gruß
Clyde
@ Fred (gast)
Your PCB are little bit wrong by designing concepts.
The GND-Field on many places are not connected to the gound. On a
HF-Designed board u need to scatter or rastersize the complete GND field
(if u can't connect it to gnd) or u must connect each field to the gnd.
if u can't do the last then u cant place the filled poligon on this
section.
If u use Eagle-CAD then u can use the "Name" command in the
PCB-Designer, click on the poligon and give it the name of your GND (on
most .sch its "GND"). Then the rastnest will fill only fields are
connected to the GND.
If u place not connected fields on the PCB then HF can let the PCB
intrude and go over the spi/data-lines to the MCU CPU ... The result
are hang or crash the software in the controler or (by powerfull HF)
destroy any components where EM-senstiv.
Greez
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
Hallo, ich hätte auch gern mal vom Programmautor einen Hinweis, worauf
beim Wechsel von Controller (Mega168 gewünscht) und Frequenz (868MHz) zu
achten ist... Vilen Dank!
MfG Pit
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.pdfhttp://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
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.
Hi,
im ZIP-Paket ist ein Schaltplan abgebildet (rfm_simple). In diesem ist
XTAL1 vom Mega16 mit CLK vom RFM12 verbunden.
Meine Frage:
in meiner Schaltung benutze ich einen externen Quarz. Wie gehe ich dann
mit diesem Anschluß am CLK-Pin des RFM12 um? Wie muss ich in meinem fall
das RFM12 beschalten?
Danke
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.
Hi,
Klasse dass dein Paket noch immer weiter verfeinert wird, Benedikt.
Meine Frage:
Ich habe an meinem Atmega32 (7,3728MHz extern) eine Servo und einen
Drehimpulsgeber angeschlossen. Mit dem Drehimpulsgeber lässt sich die
Servo bewegen. Diese Verbindung möchte ich nun über das RFM12
"verlängern".
So ungefähr:
Impulsgeber -> Atmega32 -> RFM12 ........ RFM12 -> Atmega32 -> Servo
In wie weit kann ich die rf12.c / .h nutzen bzw. was müsste ich in der
rf12.c / .h anpassen um diese getrennt nutzen zu können?
Danke schonmal,
Ralf
Hey Klasse!
Aber sind in dieser Version nicht noch einige Bugs drinn? Das File ist
ja im ersten Post angehängt und wurde schon 5 Mal ergänzt. Kannst du mir
das vielleicht noch sagen?
Danke
Guten Morgen,
hab gerade nochmal nachgesehen und habe "rfm12_rs232_rxtx_check5" mit
"rfm12_just_rxtx" verwechselt.
Ich verteile meine Schaltung heute mal auf 2 Boards und hänge die
rfm12-Module dazwischen. Als Antenne müsste es für den Anfang ein 16 -
17cm langes Kabel tun.
Gruß,
Ralf
HILFE
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. Im
PC auf der Receive-Seite kommen dann ein paar Mal "0x01" an.
Angepasst habe ich die SPI-Ports und die LED-Ports in der rf12.c auf den
Atmega32. Die F_CPU habe ich überall auf 8MHz angepasst. Den
RFM12-CLK-PIN habe ich NICHT mit meinem Atmega32 verbunden, da ich
diesen normalerweise mit einem externen Quarz betreibe. Aber für den
Test habe ich auf internen Clock (8MHz) umgeschaltet. Die UART geht.
Habe ich getestet indem ich nach der uart_init() nen String sende. Als
Antenne habe ich ein 17cm langes Stück Kabel angelötet. Die SPI ist
richtig angeschlossen.
Hat einer ne Idee, was ich übersehe?
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?
Ja, haben sie. 2 identische Bords mit der selben Software geflasht.
Meine LEDs sind zwar low-aktiv, aber das macht ja nix. Einfach umgedreht
anschauen.
Habe gerade mal in die Routine zum Senden über die UART ne Debugausgabe
reingehängt: Wenn ich "test" vom PC Richtung Board schicke, wird die
Senderoutine 4 mal durchlaufen. Für jeden Buchstaben einmal.
Meine LEDs (low aktiv):
#define LED_TX PORTC_4 // TX LED
#define LED_RX PORTC_3 // RX LED
#define LED_RETRANS PORTC_2 // Retransmit LED
#define LED_ERR PORTC_1 // Error LED
#define LED_POWER PORTC_0 // Power LED
nach Reset:
LED_POWER, LED_RX aus. Rest an.
direkt nach senden von einem String vom PC zum Boart über UART:
LED_RETRANS, LED_ERR geht aus. LED_RX glimmt
nach dem Senden aller Buchstaben von "test":
LED_POWER, LED_RX, LED_RETRANS, LED_ERR aus.
bei erneutem Senden eines Strings:
LED_RX glimmt und geht nach dem Senden wieder aus.
Liegt es vielleicht an der Antenne oder so?
Ach ja, eins noch. Ich werde aus der Konfig der Ports in der main.c wenn
ich parallel den Schaltplan anschaue nicht schlau.
int main(void)
{ PORTB=1;
PORTD=31;
DDRC=63;
DDRD=238;
...
Für was sind diese Einstellungen gut?
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?
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
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.
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.
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. Deshalb
erschließt sich mir diese Veränderung auch nicht. Kannst du mir einen
Tipp geben?
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.
Hi Lorenz!
Kann man mir deinem Code bei z.B. 3 Schaltungen festlegen, dass man von
z.B. Schaltung 1 etwas an Schaltung 2 schickt?
Wenn ja, könnt ich mir den Code mal ansehn?
lg, Steevie
Wie sieht es eigentlich mit der Portierung auf andere Controller aus?
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.
Kann man da einfach den C-Code darauf brennen, oder erfodert das
Pin-änderungen, etc...
mfg, cyberlink
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.
Hallo Benedikt,
erstmal Danke für die Mühe die du dir da gemacht hast! Ich habe dein
Programm auf 2 Boards aufgespielt, die ich nach deinen
Schaltplanvorschlägen gebaut habe. Am einen ATMega8 kommt das Wort
"TEST" mit 2400 Baud rein(an RX), alle Baudraten sind auf 2400 gestellt.
Es leuchten bei beiden Schaltungen die 3 LEDS, die Error LED ist aus.
Leider kommt aus der Empfänger Schaltung nichts raus :/ Hast du einen
Tip wo ich nachmessen/schauen könnte wo der Hund begraben liegt?
Grüße
Martin
Ja die leuchten alle 3... bei beiden Boards und auch wenn ich kein
Eingangssignal anlege. Die LEDs gehen von den PORTS die du bei der
check5-Version angibst nach GND. In die Menüs beider controller komme
ich, da habe ich auch Baudraten und Kanal eingestellt.
Oh ich sehe gerade, in der LED.h steht dass die Belegung an PORTD nur
gilt, wenn man DIP Schalter verwendet. Ich habe zwar welche dran,
verwende aber SoftConfig... D.h. ich müsste erstmal die LED Belegung
umprogrammieren, um korrekte Statusmeldungen zu bekommen. Werde das mal
machen und mich dann wieder melden.
Prüf mal die leds.h, ob die der Anschlussbelegung entspricht. Je nach
Konfiguration (DIP Schalter oder Config Menü) ist die Belegung nämlich
unterschiedlich.
Ok also das hat keinen Unterschied gebracht, leuchten immer noch alle 3.
Hab mal den Schaltplan angehängt, DIP Schalter sind zwar auf dem Board,
aber alle nicht angeschaltet.
Hast du die Software auf den DIP Modus gestellt, oder verwendest du den
Softconfig oder festen Modus?
Wenn du den Softconfig oder den festen Modus verwendet hast, dann sind
die LEDs normalerweise an PortC angeschlossen. In dem Fall musst du die
die Belegung der LEDs in der leds.h und auch die DDRx und PORTx Register
in der main.c entsprechend verändern, dass die entsprechenden Pins auf
Ausgang sind, und die LEDs beim Einschalten alle aus sind.
So, hab ein bischen mit dem code gespielt und den Eindruck, er bleibt in
configmode() irgendwo hängen. Wenn ich danach eine Kontroll-LED anamchen
will, geschieht nichts. Ich muss das Menü ja nicht jedesmal im Terminal
bedienen oder? Hab das einmal eingestellt und denke das reicht auch.
Ok genug für heute Nacht, so ist der momentane verzweifelte Stand:
Der Code ist absolut original bis auf das hier:
1
intmain(void)
2
{
3
#ifdef USE_SOFTCONFIG
4
PORTD=255;
5
LED_TX=0;
6
LED_RX=0;
7
LED_RETRANS=0;
8
LED_ERR=0;
9
DDRD=230;
10
DDRC=255;
11
#else
12
PORTD=15;
13
PORTC=255;
14
DDRD=242;
15
#endif
16
17
sei();
18
rf12_init();// ein paar Register setzen (z.B. CLK auf 10MHz)
1
/*
2
// für DIP Schalter
3
#define LED_RX PORTD_7
4
#define LED_TX PORTD_6
5
#define LED_RETRANS PORTD_5
6
#define LED_ERR PORTD_4
7
*/
8
9
// für Soft Config
10
#define LED_RX PORTD_7
11
#define LED_TX PORTD_6
12
#define LED_RETRANS PORTD_5
13
#define LED_ERR PORTD_4
Es leuchtet nun keine LED, auch nicht wenn ich ein serielles signal
anschließe :/ Im Softconfig Menü wurde 2400Baud und Kanal 2 eingestellt.
Wenn du noch einen Tip hättest wäre ich dir wirklcih dankbar,
entschuldige bitte die Post-Flut hier.
Grüße
Martin
Und bevor ich nun ins Bett gehe, verlasse ich das Softconfig Menü mit s,
sind LED RX und RETRANS an und TX blinkt, wenn das serielle Signal
anliegt. Stimmt das soweit? Das hieße ja, ich muss jedesmal erst ins
Softconfig Menü und dann rasugehen bevor ich die Schleife configmode()
verlassen kann??
Da er anscheinend jedesmal in den Softconfig Modus geht, heißt dass das
du den Softconfig Anschluss auf Low geklemmt hast. Lasse den mal offen,
dann sollte er diesen überspringen.
Jetzt funktioniert die Übertragung in eine Richtung - In die andere
nicht. Wenn ich die 2 µc in den Schaltungen vertausche, geht es
ebenfalls nicht - sehr seltsam wie ich meine. Hsat du noch eine Idee?
Zur Not würde ich beide Platinen nochmal neu layouten und ätzen, aber
ich sehe so vom Leiterbahnenbild zwischen meinen beiden aktuellen auch
keinen Unterschied :/ Wenn ich deine Software ohne Änderungen übernehmen
will, muss ich die LEDS an PORTC hängen richtig?
Grüße
Martin
Ok habe das mit den LEDs geändert, werde nun bei Reichelt bestellen und
mich dann wieder melden, bis dahin vielen Dank Benedikt, das ist echt
super wie du hier weiterhilfst!
Grüße
Martin
#define LED_RX PORTD_7 ?!?
welchen compiler hast du?
bei infineon gab es einen schönen sbit befehl, bei WINAVR muss man das
mit Einzelbits und nem kompl. define machen.
Timo P schrieb:
> bei WINAVR muss man das> mit Einzelbits und nem kompl. define machen.
Richtig, das Makro dazu befindet sich in der portbits.h. Mich hat es
nämlich genervt bei WinAVR immer PORTD|=(1<<7); oder etwas ähnliches zu
schreiben. PORTD_7=1; ist erstens deutlich besser lesbar und wird auch
von den meisten anderen Compilern besser verstanden als PORTD|=(1<<7).
Viele setzen das nämlich so um, wie es da steht: Einlesen vom Port,
verodern, zurückschreiben. Die andere Lösung wird dagegen sowohl von
WinAVR als auch von allen anderen Compilern die ich verwende direkt in
einen Bit Setzen Befehl übersetzt.
Kleines Definitionsproblem
RS232 --> Recomendet Standard (empfohlener Standard)
beschreibt in erster Linie die Physik. hier wird kein wireless serial
interface beschrieben.
RS232 ist immer Kabelgebunden. Was Du realisiert hast (Hut ab) ist eine
Funkstrecke, die serielle Daten überträgt.
Oder habe ich das falsch verstanden, handelt es sich um einen RS232 -
Funk -Konverter ?
Gruß
https://www.xing.com/profile/Thomas_Lamparter4