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

LJ_Skinny

Hallo zusammen,

meine CC1101 Tranceiver  habe ich nun bekommen. War nun doch einfacher als erwartet. Jetzt gilt es mal die beiden Komponenten zu verheiraten und sich den Protokoll-Stack anzuschauen. Ich halte euch auf dem Laufenden...

Viele Grüße

LJ_Skinny

Hallo zusammen,

kleines Update. Bin nun erfolgreich weitergekommen, so dass ich den CC1101 erfolgreich über SPI ansprechen kann.

(http://imag0006.jpg)

Werde nun versuchen mit der AskSin Library zu arbeiten und entsprechend zu portieren. Hoffe das gestaltet sich entsprechend einfach.

hermannk

Hallo Holger,
Zitat von: Holger F am 04 Mai 2014, 17:01:48
Werde nun versuchen mit der AskSin Library zu arbeiten und entsprechend zu portieren.

einfach ist anders. Das Design der AskSin Library ist weitgehend gut, hat aber seine Schwächen, wenn es an die Hardwareanbindung geht. Da wird hemmungslos in CPU-Registern gepopelt und Adressen sind natürlich uint16_t. Ist ja Arduino. Dabei gibt es keinen Grund, warum die AskSin nicht auch auf einem RPi (oder irgendeinem anderen System mit SPI Interface) läuft.

Ich hoffe, die Schnittstellen in den nächsten Tagen entwirrt zu haben und werde dann STM32L0-Treiber implementieren. Bist du noch am Ball?

Beste Grüße
Hermann

LJ_Skinny

Hallo Hermann,

Ja bin am Ball. Sogar sehr weit. Habe die AskSin als Grundlage genommen und mit ein paar Überarbeitungen und mit objektorientiertem Design inkl HAL Treiber angepasst. Der Stack läuft sehr performant und harmoniert bei den STM32 prima mit dem Event-Interrupts. So kann man einfache stromsparende Design umsetzen.

Zumal nun Keil für die STM32 F0 /L0 frei verfügbar ist.


Viele Grüße

Holger

hermannk

Hallo Holger,

Zitat von: Holger F am 11 März 2015, 09:01:52
Habe die AskSin als Grundlage genommen

das war auch mein Ausgangspunkt. Inzwischen habe ich die Schnittstellen zur Hardware etwas entwirrt und habe das Ganze mal in Richtung C++14 bewegt. Es hat sich gelohnt, denn AskSin hat einen guten Kern. Ich finde es immer wieder erstaunlich, dass durch größere Abstraktion und Nutzung der Sprachmöglichkeiten das übersetzte Programm immer kleiner wird. Es bleibt immer noch Einiges zu tun.

Ein anderer Ausgangspunkt wäre http://homegear.eu/packages/Debian/wheezy/homegear_0.5.24.orig.tar.gz gewesen. Die Software sieht mir recht systematisch aus. Die Programmierer kommen vom "anderen Ende": POSIX-konforme Schnittstellen.

Ich drücke dir die Daumen für deine Implementation. Ich melde mich beizeiten wieder.

Beste Grüße

Hermann

noxx

Wie sieht die Entwicklung aus?
Suche eine günstige Möglichkeit für einen CUL :)

LJ_Skinny

Hallo noxx,

HW- Design habe ich nicht mehr weiter gemacht, aber aber auch kein großer Akt ist. Man sollte mal ein HM Gerät aufschrauben und schauen was da verbaut ist. Hui, da wundert einen dann das eine oder andere Verhalten nicht mehr.

Der SW-Stack wurde nun komplett auf Basis des AskSin neugeschrieben und läuft sehr performant. Da macht eher der USB Konfig-Stick oder eines der HM Geräte mit den AVRs schlapp. Man merkt schon die mehr Power gerade beim Übertragen von Peering-Listen hat sich der Taster von HM öfters aufgehängt so dass man diesen komplett Reseten musste.  Mit meiner SW überhaupt keine Probleme.

Die SmartHome-Schiene liegt erstmal auf Eis, da die Entwicklung in einen anderen Markt interessanter ist.

Was brauchst du denn genau für einen CUL?







Ranseyer

Hallo HolgerF,

wenn deine Arbeiten im Nirvana verschwinden würden wäre schade. Gibt es ein Software-Repo ? (Oder wäre es möglich den SRC nach GitHub & Co zu legen ?)


PS; Ich bin inzwischen ein großer Fan von Programmern als HW Basis geworden. Die ST-Link V2 gibt es unter 3€ und sind eine klar definierte Plattform wenn wenige IOs ausreichen:
(http://www.lctech-inc.com/Images/Product/3104f16a-5401-4a9b-8102-9270a54e2cb7.jpg)
Bei mir sind es die LCSoft-Teile  die verbaut werden für etwas mehr Geld,

Wenn mehr IOs gebraucht werden gibt es für ~5€ größere Boards.

Mal ein Beispiel (funktioniert, aber Design verbesserungswürdig): http://www.neuby.de/wp/moderner-ir-receiver-mit-arm-32-bit-microcrontroller/
Das SW-Konzept wurde im VDR-Portal entwickelt.
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

LJ_Skinny

So bin wieder da. Mein Account wurde gelöscht.

Das coole ist unser Stack läuft stabiler als der von Homematic. :-) wir haben da mal ein paar Stresstests gemacht. Gerade viele Nachrichten und dann noch an Peeringlisten arbeiten, da kann man das Homematikdevice schon mal in den FactoryReset zwingen.

Mal sehen wie es jetzt weiter geht.