Low-Cost / High Performance Tranceiver 868 Mhz (1. Modul: 3-4CH PWM LED-Dimmer)

Begonnen von LJ_Skinny, 08 Januar 2014, 09:09:44

Vorheriges Thema - Nächstes Thema

LJ_Skinny

Hallo zusammen,

mein Name ist Holger Fürstenberger und ich bin seit kurzem User des Homematic Systems für meine Heizungssteuerung geworden. Nebenbei habe ich mir noch ein paar Dimmer zugelegt und mittlerweile bin ich von den vielfältigen Einsatzmöglichkeiten begeistert. Was mir bisher noch fehlt, ist die "schöne" Ansteuerung von diesen RGB-Led Stripes! Es gibt zwar ein Dimmermodul (HM-LC-Dim1PWM-CV), allerdings ist dieses zu teuer und groß um damit eine RGB-Ansteuerung auszubauen. Außerdem fehlt mir dann die Möglichkeit einzelne Presets vorher abzuspeichern. (Einzelne Farben oder Lauflichtprogramme)

Da ich aus dem Embedded-Bereich komme, plane ich einen eigenen Tranceiver zu entwickeln und mit dem neuen, günstigen und leistungsfähigen 32Bit ARM Cortex M3 zu betreiben. Somit wäre die Basis-Architektur MCU + CC1101 für ein paar wenige Euros hinzubekommen. Da ich mit dem Prozessor schon mehrfach gearbeitet habe, wäre somit auch eine schnelle Umsetzung möglich. Da der Prozessor sehr viel Peripherie mitbringt, sollte sich damit später alles mögliche realisieren lassen. 

Vorteil wäre es, dass die späteren Module alle möglichen Protokolle im 868Mhz Band benutzen könnten (FS20, Homematic, FHZ, ....)  und somit generische Module entstehen könnten. Durch den sehr leistungsfähigen Prozessor (gegenüber den AVR 8-Bit) wären genügend Reserven für alle möglichen Spielereien vorhanden.

Folgende Schritte wären zu tun:

1. Platinenlayout (zum Test Cortex EvalBoard + CC1101 Breakout Board)
2. SPI Verbindung mit CC1101 herstellen
3. Protokoll-Stack für die einzelnen Protokolle implementieren
4. Applikation anbinden (PWM-Controller)
5.Final Design erstellen und PCBs fertigen lassen

Falls noch jemand Ideen, Vorschläge, Wünsche oder Kritik hat, der kann sich sehr gerne melden. Über jede Art der Unterstützung würde ich mich freuen.

Viele Grüße

Holger

hexenmeister

Hallo und willkommen im Forum, Holger!

Das klingt schon sehr interessant. Vielfältige Verwendungsmöglichkeiten für ein flexibles Grundmodul werden sich sicher schnell finden ;)

Grüße,

Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

daduke

Hallo Holger,

hört sich gut an. Ich spiele gerade mit einer ähnlichen Idee, allerdings eher mittels eines Spark Cores (https://www.spark.io/). Hab 2 zum Testen hier und der Preis ist sehr interessant (USD 39 für das komplette Modul mit WiFi). Ein Vorteil könnte sein, dass man über WiFi auch near-realtime-Dinge wie VU-Meter oder so hinbekommen könnte... Ich weiss aber auch noch nicht so ganz, in welche Richtung das wirklich gehen soll.

viele Grüße,
-Christian
fhem auf pcengines apu, Philips Hue, MAX!, div. HomeMatic, Spark Core, panstamp, div. eigene Hardware

ext23

Aus deinem Topic geht das nicht hervor, du möchtest das aber über HomeMatic machen oder wie?

Ein ähnliches Projekt:
http://forum.fhem.de/index.php/topic,13890.0.html

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

LJ_Skinny

Eure Anregungen finde ich gut. Wie ich sehe gibt es viele Module mit MCU + Funk die dann in irgendeinem Sockel stecken. Wenn es möglich wäre dies einigermaßen zu vereinheitlichen, dann hätte man einen schönen Systembaukasten.


Mit Spark-IO und PanStamp gibt es ja schon entsprechende Module für WLAN oder mit CC1101. Beim PanStamp verwendet die neuere Variante ja einen MSP430. Gibt es dafür schon Firmware? Grund auf den ARM Cortex M3 zu setzen ist,  dass er bei gleichem Preis wesentlich leistungsfähiger ist als ein AVR 8Bit RISC.

Das RGB-Modul von Daniel klingt auch sehr interessant. So etwas hätte ähnliches hatte ich auch geplant. Ich habe für einen deutschen Hersteller Scheinwerfer (hauptsächlich LED) für die Veranstaltungstechnik entwickelt, und kann da einige Ideen zu DMX und Artnet beisteuern. Denkt auch an einen Speicher um später Lauflichtprogramme als Makro aufrufen zu können.

Mein Ziel ist es das Modul erstmal für (mein) Homematic zu designen.

Dann mal fröhliches Basteln... ;-)

ext23

Wie sieht es denn mit der Energiebilanz aus bei dem ARM Cortex M3? Ich arbeite nur mit den AVR's und naja weniger ist manchmal mehr ;-) Kommt natürlich auf den Anwendungsfall an, aber meistens sind ja die AVR's mittlerweile schon maßlos überdimensioniert für viele Fälle. Dann gewöhnt man sich auch schnell einen schlampigen Programmierstil an wenn man mehr Leistung hat als man braucht ;-)

Achso und wie sind denn die packages bei dem M3? Man muss oder sollte zumindest auch immer an die Bastelfreunde denken, die keinen Reflow Ofen zu Hause stehen haben.

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

LJ_Skinny

Hi Daniel,

ich habe das mal soweit verglichen und zu dieser Tabelle gekommen..

       






ModeSTM32F050 48MhzSTM32F050 8MhzSTM32L15XX 32MhzSTM32L15XX 8MhzAVRmega324 8Mhz
Running FLASH20,1mA4mA11mA3mA12mA
Sleep11,7mA2mA2,5mA0,5mA5mA
Standby15uA15uA2uA2uA15uA
Deep-Standby1,3uA1,3uA0,5uA0,5uA0.5uA

Fazit: Im Standby und Deep-Standby  schenken sie sich nicht viel. Im Betrieb kommt zur 32 Bit-Fähigkeit hinzu, dass der AVR etwa eine Leistungsaufnahme hat wie der ARM bei 24Mhz. Wirklich nur über den Daumen gepeilt etwa 10mal schneller und effizienter als der AVR. Macht natürlich nur Sinn für Anwendungen die Leistung benötigen. Durch die Interne PLL kann man allerdings auch in der Firmware den Speed festlegen lassen, während man da beim AVR schon die Fusebits setzen muss.


Gehäusetypen sind    LQFP48 und TSSOP. Also noch durchaus lötbar.
   
Aber ich gebe die recht, wer nur einen LM75 ansteuern will, der braucht nicht unbedingt solch eine MCU. Da kämen mir auch noch die guten alten 8051 in den Sinn...


ext23

HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

LJ_Skinny

Was ich schon fertig für den ARM habe sind:

-RS485 (DMX)
-Ethernet (Artnet, UDP, TCP-IP => lwIp)
-SPI
-SDIO (SD-Karten)
-I2C
-LCD
-Kapazitive Touchfelder
-LED Leistungstreiber
-Motorsteuerungen
-RTOS

Damit lässt sich einiges bei der Hausautomatisierung anstellen... ;-)

trilu

Hi Holger,
Ich bastle gerade an einer Homematic Arduino Library. Ist der Arm kompatibel zu Arduino? Dann würde einer Erweiterung um Homematic nichts im Wege stehen :-)
Viele Grüsse
Horst

ext23

Ich lese hier gerade "ArtNet", da warte ich noch auf ein FHEM Modul für ;-)

- mal so in den Raum geworfen -

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

LJ_Skinny

@Daniel: Hast du schon Artnet Nodes zum Ansteuern? Oder meinst du FHEM als Client für ArtNet? Wenn ich wüsste wie man auf ner Fritzbox den IP Stack verwendet, könnte ich da bestimmt einen Port von meiner Implementierung machen

@Horst: Was meinst du mit Arduino Library? Pinkompatibles Modul zu Arduino, oder dass du mit dem Arduino-Framework Code für mein Board compilieren könntest?

Hat jemand eine Ahnung wie pinkompatibel die derzeitigen Boards sind? Spark-IO und PanStamp? Wie wäre da der Gedanke, Applikation (LED-Dimmer, Motorsteuerung, Tempsensor) und ControlBoard (MCU [ARM Cortex M3, AVRmega324, MSP430] +Schnittstelle [WLAN, Homematic, FS20,Ethernet, KNX,...] auf einen FHEM Standard zu bringen?

Dann könnte man sich die beste Lösung zusammenbauen. Die DIP-Fassungen finde ich da schon gar nicht schlecht. Aber ich bezweifle, dass die Module da bisher irgendwie kompatibel sind. Das würde aber dem ganzen System einen neuen Schub bringen.



ext23

Ich hab genau ein Node, sollte auch reichen für eine Wohnung ;-) Aber den nutze ich nicht, da mir ein FHEM Modul fehlt und die Zeit was selber zu frickeln. Ich hab im Moment den DMX4All USB Adapter, das geht aber über PHP, also auch nicht FHEM. Ist halt nur wenn man Mails bekommen und anrufe etc. das dann die Lichter welche am DMX Bus hängen das ganze visualisieren. Aber wie gesagt ist alles zusammengefrickelt. Und der Farbwechsler läuft dann als eigener Daemon wenn man den aktiviert.

Ein FHEM Modul für den USB Adapter macht wenig Sinn, aber ArtNet ist ja nun recht gängig und da bietet es sich ja an mal ein Modul zu schreiben für ArtNet Nodes. Irgend wann wird sich schon jemand finden der mal ein stück weit mehr Zeit und Muße hat ;-)

/Daniel


Zitat@Daniel: Hast du schon Artnet Nodes zum Ansteuern? Oder meinst du FHEM als Client für ArtNet? Wenn ich wüsste wie man auf ner Fritzbox den IP Stack verwendet, könnte ich da bestimmt einen Port von meiner Implementierung machen
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

stenny73

Hallo.

Wenn Eder soviel Leistung hat wäre es da nicht möglich gleich mehrere Protokolle parallel zu machen?
Also ein Gerät was HM, MAX usw hat.....

Stemmt73
FHEM auf XEN, Ubuntu-Server 14.04   - HM-Lan - Max - ZWave -WS1080 -BlueTooth

FHEM auf Ubuntu-Server 14.04   - HM-LAN

FHEM auf Raspberry Pi   - CSM für Max - HM-USB - WiFi-LED

LJ_Skinny

Es ist die Frage, ob das technisch vom CC1101 her geht. Ich habe auf dem Cortex M3 ein RTOS laufen lassen, da könnte man problemlos einem Tasks für jedes Protokoll laufen lassen, und sich die Ressource  CC1101 teilen lassen.

Ich habe mir CC1101 Breakout Boards bestellt, sodass ich demnächst mal mit meinem Evalboard und den Chips beginnen kann.

Wenn sich jemand von den CUL Entwicklern melden würde, könnte man evtl in Erfahrung bringen, wie die bisherigen Erfahrungen sind mit "Multiprotocollling" auf CC1101.

Viele Grüße

Holger