freebus.org

Ich hab schonmal mit nem AVR FS20 gesendet und auch Empfangen. Aber eben wie es sich gehört in AM nicht FSK

Die FS20 Geräte verstehen FSK nämlich nicht

Ich hab die ganze Wohnung voll davon und bin relativ unzufrieden damit. Daher interessier ich mich nun auch für EIB

die Anbindung eines FS20 Gerätes ist zwar ganz net aber wiederspricht das nicht generell dem Eib gedanken?

Eine ACK vom Aktor wird es mit FS20 niemals geben. Daher kann von verlässlichkeit nicht mehr gesprochen werden.

Genau diese unzuverlässigkeit läst mich von FS20 weg gehen.

Gruß martin

Hallo Martin,

Radio Eriwan würde senden: Im Prinzip "ja", aber dennoch "nein"!

Die Problematik mit den ACK usw. hatte ich bereits unter dem Aspekt Datenkollision angerissen. In Gedanken spiele ich bereits mit einer on/off-Modulation. Wie auch immer diese implementiert wird, sodaß ein Hören während der LOW-Bits möglich ist. Ein Ansatz wäre die Manchester-Kodierung, mit 0110 für log. Null und 1001 für log. 1 - oder umgekehrt. Dann könnte man hören, ob andere Geräte sich ebenfall melden.

Mit FSK, also ununterbrochenem Träger, müßte man in einem "Zeitschlitzverfahren" den Geräten ihre jeweilige Sendezeit zuordnen. Würde man die Telegramme einfach nur mit unterschiedlichen Zeitabständen wiederholen, wäre man ein Stück weiter, jedoch nicht am Optimum.

Ich habe mich in den letzten Tagen mit den Lösungen von Siemens und Weinzierl/enOcean auseinander gesetzt. Mir ist noch nicht ganz klar, was sich die Ingenieure bei der Definition gedacht haben oder warum sie bestimmte Festlegungen von TP-UART-KNX aufgegeben haben.

Gruß

Bernd

Will keiner glauben, dass es mit RFM12 funktioniert?
Hier ein C-Code zum Jeelab:
http://code.google.com/p/jeelabs/source/browse/trunk/libraries/RF12/examples/fs20demo/fs20demo.pde

Probiert es doch mal aus, die preiswerten Baumarktsteckdosen sind damit auch noch möglich und da man es selbst in der Hand hat kann man auch x-Mal den Befehl zum Schalten ausgeben.
Gruß Helmut

Ich persönlich würde auch den RFM12 (868MHz) bevorzugen, da billig, einfach zu programmeieren, bidirektional und wiederbeschaffbar.

Gruß
kubi

Hallo in die Runde!

Zwar hege ich im Augenblick noch Zweifel, ob wir das RFM12 verwenden sollten, jedoch finde ich, daß es Zeit wäre sich über das Protokoll Gedanken zu machen.

---
Kurzer Einschub noch: bei einer kontinuierlichen Programmierung eines Radio-Moduls über SPI oder IIC, entstehen bei der seriellen Datenübertragung Störungen am Haupträger. Dies äußert sich so, daß Seitenbänder mit einer Frequenz der Datenübertragungsrate entstehen und in der Größenordnung um etwa 40dB (manchmal auch schon 20dB) unterhalb des Trägers vorzufinden sind. Der Nachweis erfolgt später über einen Spektrumanalysator (kann ich für Euch messen). Einfluß hat das auf die Reichweite, wenn die Signalpegel später nicht so optimal sind, bzw. Phasenjitter bei den Flanken im Basisband des RX. Da die Taktrate auch mehrere 10 bis 100kHz beträgt, verläßt man den Kanal in seiner begrenzten Bandbreite - damit nicht konform zu EMV-Gesetz, etc. ... wie auch immer, denn mit einem Probeaufbau kann man natürlich prüfen, wie kritisch das ist.
---

Da ich aufgrund eines Projektes die nächsten zwei Wochen nicht mitlesen kann, möchte ich Euch hiermit erst einmal einen Anstoß geben zu diskutieren, wie denn das Protokoll, bzw. die Datenkodierung nach Euren Ideen aussehen soll. Eine gute Ausgangsbasis wäre ja die Realisierung nach "Weinzierl", enOcean oder Siemens.

Den ersten Aufbau können wir später auch modifizieren und ein anderes Modul ebenfalls prüfen, auch bei 434MHz oder 2.45GHz.

Gruß

FreeBernie

Hallo Freebus Freunde,
ich bin vor ca. 2 Wochen auf das freebus Projekt gestoßen. Ich habe seit etlichen Jahren auch schon die Idee, den EIB mal mit AVRs o.ä. nachzubauen. Also bin ich begeistert, dass ich damit nicht allein bin und mich einer Gemeinschaft anschliessen kann.

Abgesehen davon, dass ich im Haus eine TP Lösung anstrebe (ich habe mir beim Bau meines Hauses gleich das entsprechende Kabel mitverlegen lassen), ist mein "aktuelle Problem" der Bewegungsmelder mit Lampe am Grundstückseingang. Da liegt nur Strom. Ich habe vor 2 Jahren eine "Standalone" Schaltung gebaut, die mir zusätzlich die Lampe bei der Haustür einschaltet, wenn jemand vorn das Grunstück betritt, und umgekehrt kann ich die Lampe vorn auch vom Haus aus bedienen. Das natürlich per Funk. Bidirektional. Mit RFM12+AVR auf beiden Seiten. Allerdings hatte Pollin zu der Zeit nur die 433MHz Version.
Ich verwende z. Zt. ein "selbsterfundenes" Protokoll, mit Quittung.
So, und diese "Standalone" Lösung will ich in ein Gesamtsystem einbinden. Ich habe ein paar Experimente mit kleinen Webservern und der ethersex software gemacht, da wird IP (Internet Protokoll) über RFM12 gesendet, aber das erscheint mir für diesen Zweck weniger geeignet. freebus scheint mir genau das Richtige.
Nach Sichtung der entsprechenden Doku (z.B. Weinzierl) möchte ich ein zu KNX-RF kompatibles System aufbauen (oder zumindest anstreben), mit RFM12 (evtl auf 868MHz unsteigen). Die RFM12 sollten sich, wenn ich das Datenblatt richtig verstehe, KNX-RF spec konform einstellen lassen.
Ich bin also motiviert, hier aktiv mitzuarbeiten.
Allerdings muss ich mir erstmal die freebus Grundausstattung aufbauen. Und da ich sowieso Teile bestelle, auch gleich 2 RFM12 868MHz mitbestellen.
Welche Variante würdet Ihr bevorzugen? Es gibt eine "DIL" Version mit Pfostenstecker, und eine SMD Version.
Beide gibt's z.b. bei it-wns.de. Pollin hat glaub' ich nur SMD.

Die FS20 Lösung käme für mich nicht in Frage. Bietet mir zu wenig Möglichkeiten.

So, jetzt bin ich gespannt auf Eure Reaktion.

Hallo tuxbow,

Wenn das +- 1µs per hand machen musst, dann sollten wir überlegen den SILABS
controller einzusetzen. Dieser bringt 50Mips, bei 64k flash, 5 timer ect...
Dies würde da von vorneherein
Probleme aus dem Weg schaffen

_________________
LG
Andreas

Hallo nochmal,
nachdem ich mit Andreas und StefanT schon im chat bzw private Nachricht kontakt hatte, schreib' ich hier nochmal, was ich inzwischen herausgefunden habe:
Der RFM12 hat 'ne SPI Schnittstelle hat, und die ATMEGAs auch, so dass es hardwaremäßig besser zusammen passt als mit LPC900. Mit letzerem muss man SPI via "bit-banging" bedienen. Ginge auch, hab' ich sogar schonmal gemacht, damals war's mit 'nem PIC und RFM12. Ist nur nicht so elegant.

Eine recht übersichtliche Zusammenstellung von KNX-RF habe ich hier gefunden:
http://www.carontenet.it/approfondiment ... marest.pdf

Frequenz, FSK-Hub, Sendeleistung, Empfänger-Bandbreite und Empfindlichkeit kann mit RFM12 passend eingestellt werden. Nur die Chiprate (32.768 kChips/sec +/- 1.5%) nicht. Das lässt sich aber dadurch umgehen, dass man den FSK I/O direkt vom controller aus ansteuert / auswertet. Das ist wiederum zeitkritisch, Jitter darf max. +/-1µs sein.
Kann jemand (z.B. Andreas) mal untersuchen, ob der LPC ein Manchester-Codiertes Signal erzeugen kann, mit
der obigen Chiprate und Jitter? LPC hat einen timer-mode "toggle I/O on timer overflow" und "auto reload". Kann man, gesteuert über timer interrupt, das TL0 Register nach jeder toggle-Flanke neu laden, und damit die high/low Zeiten des Signals immer wieder anders setzen?
Und könnte man mit demselben LPC dann auch noch die TP Schnittstelle bedienen? (für ein TP <-> RF interface)

Ich seh' gerade, oldcoolman hat einen ganz anderen controller vorgeschlagen. Den kenn ich noch gar nicht. Trotzdem danke! LPC und ATMEGA sind ja bei freebus schon eingeführt. Ich meine, wir sollten erstmal versuchen, es mit einem davon zu machen.

Ich mach derweil mal versuche mit ATMEGA, da hab' ich hier 2 Platinen mit ATMEGA und RFM12 liegen.
Ich hab' bisher noch nie den FSK I/O benutzt, das will ich jetzt probieren. Ergebnisse lassen sich später ja evtl. auf LPC übertragen.

Ja, über die Antenne kann sich auch mal jemand gedanken machen. Haben wir hier einen Experten?
Antenne direkt auf der Leiterplatte wäre ja ideal. Optimale Ergebnisse würde man wohl mit einer groundplane (siehe Rothammels Antennenbuch) erzielen, aber wie sieht das aus Obwohl, für die Wetterstation im Garten doch gar nicht so übel...

NOCH WAS: RFM12 868MHz hat Sendeleistung 1mW (0 dBm)
Das steht auch bei KNX-RF drin.
Zugelassen sind auf der Frequenz (868.0 - 868.6 MHz) 25mW (ca 14dBm).
Es gibt jetzt auch einen RFM22, der könnte das. Der hat auch einen empfindlicheren receiver. Wenn man googlet, findet man auch Anbieter. Auch kaum teurer wie RFM12.
Also, wenn jemand Reichweienprobleme hat....

Soweit für heute!
Grüße von tuxbow.

hallo tuxbow,
schöne feine theorie alles.
ich denke einen µsec genauen code mit 3,6Mips erzeugen und dazu noch den sehr zeitkritischen TP stack fahren geht wohl nicht.
da wird es wohl nötig sein 2 LPCs ein zu setzten einer kümmert sich um TP dern andere um RF. unterhalten tun sie sich über seriell oder besser i2c.
die LPC's können einen Pin toggeln (PWM) dessen frequenz ist aber fest zum quarz.

Eventuell überlegen ob der RF chip dann nicht eine füe die anwendung günstige quarz
frequenz kriegen kann.

den high speed core findest du hier:
http://www.silabs.com/products/mcu/auto ... fault.aspx

_________________
LG
Andreas

Hallo oldcoolman,
ob alles mit einem LPC geht, war ja die Frage. Evtl braucht man 2, richtig.
Ich ziehe LPC in Betracht, weil Andreas auf den fixiert ist, und ich darauf Rücksicht nehmen will.

von wegen Theorie.
Ich habe gerade meinen ATMEGA dazu gebracht, ein zeitgenaues Signal zu erzeugen.
10MHz clock (den kann man vom RFM12 abgreifen), timer0 prescaler / 8, compare auf 38, gibt 32.895 kChips/sec, das sind knapp 0.4% zuviel, aber die KNX-RF spec erlaubt +/- 1.5%

Ich führe bei compare match einen interrupt aus, der mir das compare-register neu lädt (38 oder 76), so kann ich einen wunderbaren manchester erzeugen, theoretisch ohne jitter (flanken werden von der hardware erzeugt).
Auf dem scope sieht das Signal tiptop aus.
Zwischen den interrupts liegen ca 300 oder 600 instructioncycles, das sollte reichen um parallel auch TP zu bedienen.
Für die TP Schnittstelle gibt es ja noch einen zweiten timer, der auch per compare einen weiteren pin bedienen kann.
Ob das jetzt mit LPC auch so gut geht, muss geprüft werden. Das Reichelt Päckchen ist gerade gekommen, mit LPCs und Material für das Programmiergerät. Aber ich lasse auch gern einen LPC Erfahrenen dran (Andreas?)

Soweit erstmal
Grüße von tuxbow.

hi,
wollte ja nur sagen dass alles leichter gedacht als getan ist

Der LPC hat 3 timer inne.

2 brauchen wir für TP, den 3. für die Aplikation
Ich würde TP die höchste IRQ prio geben(nach wie vor)
Das ack muss genauso genau positioniert sein wie diese fsk.

_________________
LG
Andreas

[quote="tuxbow"]http://www.carontenet.it/approfondiment ... marest.pdf
quote]

Der Link will nicht bei mir?

_________________
mfg


Klaus D.

Hi tuxbow,

wenn du hier Probleme mit dem LPC siehst, heisse ich dich gerne im AVR Lager willkommen .
Da du hier aber von mehr als 8MHz sprichst, würde das sowieso nicht mehr mit unserem AVR-Kontroller zusammenpassen, da dieser bei 8MHz läuft.

Du kannst aber ja mit dem AVR anfangen, wir schauen, was alles geht und portieren es dann später auch auf einen LPC, was dir lieber ist.

_________________
Gruß
Matthias

Sorry, der link war verstümmelt. Ich hab ihn korrigiert.

Matthias,
danke für die Unterstützung.
Ein "RF only" Busteilnehmer hat ja ohnehin nichts mit dem AVR TP(Draht) controller zu tun. Die 10MHz bieten sich einfach an, weil die aus dem RFM12 sowieso rauskommen, da braucht der AVR keinen extra Quarz. Daher die 10MHz.

Ich hab' jetzt das mit AVR erzeugte manchester Signal in den FSK input des RFM12 eingespeist.
Und versuch's aus einem anderen RFM12 wieder rauszubekommen. Ist noch verstümmelt, aber ich forsche weiter.

Gruß von tuxbow.