RFM69 Gateway (868 oder 433 MHz)

Begonnen von Ranseyer, 12 Dezember 2017, 21:21:54

Vorheriges Thema - Nächstes Thema

Ranseyer

Hier mal ein Thread für Smalltalk zum RFM69 Gateway.

Motivation:
-Mit MySensors ist der Software-Teil für Standard-Sensoren recht easy umzusetzen
-Die Reichweite auf 2,4GHz nicht unbedingt ideal (NRF24L01*)

Ziel des Threads: MySensors mit RFM69 etwas mehr pushen....

Hinweis: Bitte im Regelfall für jede Frage einen einzelnen Thread aufmachen. Hier nur für allgemeine Infos und kurzen Smalltalk.

Der Grund warum ich mich mit den RFM69 befasse ist die Frequenz.
- 2,4 GHz ist mir zu schlecht in Bezug auf die Durchdringung von Wänden
- 433 MHz ist in Ballungsgebieten zugemüllt.
- Bei 868 MHz würde ich mal ca 2/3 Reichweite der 433 MHz Lösungen bei gleicher Auslastung der Frequenz (=Quatsch!) und Sendeleistung / Antennentyp erwarten
=> Also hoffentlich ein guter Kompromiss.

Die Basis sollte also hier gesucht werden: https://www.mysensors.org/build/connect_radio

Das Serielle-Gateway ist die einfachste Version und somit immer für den Start zu bevorzugen.
Ein Arduino Nano mit originalem FTDI Chip bietet die direkte Anbindung an einen USB Anschluss und jeder Chip verfügt im Gegensatz zu den CH34X Chips über eine eindeutige Seriennummer zur Erkennung. Das ist wichtig um verschiedene USB Geräte eindeutig zu FHEM-Devices zuordnen zu können.
Vorsicht: Die meisten günstigen Arduinos sind mit einem gefakten FTDI Chip ausgestattet. Da es verschiedenste Fakes gibt isat das Risiko unklar.

Mögliche Lösungen zur Umsetzung:
-Einfach siehe Bild das Funkmodul mit einem Arduino verbinden.
-Ein LAN Modul dranlöten siehe MySensors-Seite: https://www.mysensors.org/build/ethernet_gateway (Kann funktionieren, es wurden aber auch schon Probleme in Kombination mit RFM69 berichtet.)
-Eine fertige Platine nutzen siehe Anlage im nächsten Post
-Das ganze mit dem MAPLE-CUL kombinieren siehe nächster Post
-...

PS: LoRa Lösungen wären gesondert zu betrachten...
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!

Ranseyer

#1
Hier eine Umsetzung mittels fertiger Gateway-Platine
-Erweiterung um Sensor-Funktionen möglich, oder  Nutzung nur als Sensor

Doku: https://github.com/ranseyer/MySensors-HW/tree/master/Gateway-RFM-RS485
(Kann nebenbei auch RS485 per SMD-Chip, oder DIP Bauteil)


PS: Ich bin gerne bereit mit Platinen auszuhelfen soweit verfügbar. Bei höherem Bedarf kann auch gerne jeder selbst für den Eigenbedarf die Platinen herstellen lassen. 
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!

Ranseyer

Addon für den MAPLE-CUL
-Mechanisch passt das Addon direkt auf einen MAPLE-CUL Large ab V3
-Die Bilder zeigen
  -das Addon
  -Die Basisplatine
  -"andere" Nutzungsmöglichkeiten des AddOns
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!

hexenmeister

Ich bin mittlerweile auch nicht mehr so zufrieden mit der Reichweite von NRF24. Wenn ich (hoffentlich bald :D ) Zeit gefunden habe, will ich meine Gerätschaften auf RFM69 umrüsten. Daher werde ich das jetzt mit Interesse weiterverfolgen :)

P.S. MAPLE-CUL sieht wirklich interessant aus!
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

sash.sc

#4
Zitat von: hexenmeister am 12 Dezember 2017, 22:39:26
Ich bin mittlerweile auch nicht mehr so zufrieden mit der Reichweite von NRF24. Wenn ich (hoffentlich bald :D ) Zeit gefunden habe, will ich meine Gerätschaften auf RFM69 umrüsten. Daher werde ich das jetzt mit Interesse weiterverfolgen :)

P.S. MAPLE-CUL sieht wirklich interessant aus!
Dem kann ich nur beipflichten!

@ranseyer
Was hast du denn für 4 Radios drauf gelötet?
Gibt es dafür schon einen thread?

Gruß Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Beta-User

Gute Initiative!

Sofern wir erste gesicherte Erkenntnisse haben: Du darfst gerne im Wiki-Starter-Guide den RFM69-Teil mit einpflegen (oder wenigstens nach hierhin verweisen). Oder wird das zu verwirrend?
Wir können gerne auch zwei weitere Seiten anfangen - für RFM69&Co und RS485. Auch da gibt's schon Anlässe, manches doppelt zu schreiben ;) .

Kann zwar die Reichweitenprobleme bei nRF nur bedingt nachvollziehen (scheine Glück mit den Modulen gehabt zu haben), aber ich habe auch mal 3 RFM69-Module@433MHz daliegen, vielleicht setze ich die in meiner Wetterstation ein, wenn das endlich mal was wird ::) .

[OT] zum Maple: Ist wirklich ein Großschiff, so ein MapleCUN. Das bringt mich auf eine Idee:
"eigentlich" sollte es kein großes Problem sein, auf einem Maple ein Mehrfach-MySensors-GW zu realisieren, oder?
Das Ding kann ja mehrere USB-Geräte gleichzeitig (3 beim MapleCUN), hardwareserial für RS485 wäre möglich (sind ja auch mehrere vorhanden) und zwei SPI-Devices sollte man auch unterbringen können.
Die Idee wäre, den GW-Code quasi zu auf einem Gerät 3* zu klonen und parallel zu betreiben (keine Kommunikation zwischen den GW-Schienen, das darf weiter FHEM machen).
Ich habe aber keine Ahnung, wie man sowas angehen müßte...

Wenn das jemand sinnvoll findet, mehr Ahnung von Coding hat als ich und Chancen sieht: gesonderten Beitrag aufmachen! Bin als Tester dabei (auch wenn ich grade genug USB-Steckplätze habe und "sowas" nicht benötige).
[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ranseyer

OT:

Ich versuche mal zu Antworten.

Für den MAPLE-CUL prinzipiell gibt es den Thread von Telekatz: https://forum.fhem.de/index.php/topic,60458.0.html

Ich habe frühzeitig versucht das Thema zu unterstützen und auch zu nutzen. Die Infos und auch alte Varianten dazu gibt es hier: https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/Archiv
Mein Ansatz: Es soll easy sein, kein unnötiges SMD, keine komplizierten Bestückungsreihenfolgen.



Zitat"eigentlich" sollte es kein großes Problem sein, auf einem Maple ein Mehrfach-MySensors-GW zu realisieren, oder?
Denke die HW könnte es...

Wer schreibt die SW ? -HW Umsetzung kann ich machen.


ZitatWas hast du denn für 4 Radios drauf gelötet?
Gibt es dafür schon einen thread?
Das sind laut den Chinesischen Verkäufern CC1101 Module, also vermutlich meist die etwas günstigere ChipVersion mit ähnlichen Funktionen.
Einen Thread zur diesen Umsetzungen  gibt es nun hier: https://forum.fhem.de/index.php/topic,81083.msg731620.html#msg731620


PS: Bei Ideen werde ich das ganze gerne weiterentwickeln. Wer aktiv ist bekommt gerne "Samples", die Kosten dafür werde ich dann auf andere umlegen die nur eine Platine wollen...



Nun sollten wir aber wieder zum Topic kommen. Es gibt ja nun einen passenden Thread.
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!

Mathea

Zitat von: Beta-User am 12 Dezember 2017, 23:51:33

Kann zwar die Reichweitenprobleme bei nRF nur bedingt nachvollziehen (scheine Glück mit den Modulen gehabt zu haben), aber ich habe auch mal 3 RFM69-Module@433MHz daliegen, vielleicht setze ich die in meiner Wetterstation ein, wenn das endlich mal was wird ::) .


Dazu mal eine Frage: Wie versorgst du denn deine NRFs mit Spannung? Meine Erfahrung ist, dass eine gut funktionierende Kommunikation mit den NRF24L01 Transceivern immer durch eine saubere Versorgungsspannung kommt. Mittlerweile habe ich viele verschiedene Konzepte und Spannungsregler ausprobiert und festgestellt, dass gerade dieser Teil über Erfolg / Misserfolg entscheidet.

PeMue

Zitat von: Mathea am 26 Juli 2018, 10:54:14
Mittlerweile habe ich viele verschiedene Konzepte und Spannungsregler ausprobiert und festgestellt, dass gerade dieser Teil über Erfolg / Misserfolg entscheidet.
Postest Du bitte Deine (optimale?) Lösung für die Spannungsversorgung?

Danke + Gruß

PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Beta-User

Zitat von: Mathea am 26 Juli 2018, 10:54:14
Wie versorgst du denn deine NRFs mit Spannung?
Lustige Frage - mittlerweile laufen meine MySensors-Nodes nämlich fast alle mit RS485 :) . (An interessierte Mitleser anderer Threads: Keine weiteren Kommunikationsprobleme übrigens seit dem Patch, der kurz vor Erscheinen von V. 2.3.0 reingekommen ist).

"Ganz früher" hatte ich einige Nodes, die die nRF über einen separaten Spannungsregler versorgt haben (waren längliche Module). Später habe ich dann die Adapter-Boards verbaut (sowas wie auf dem mittleren Bild in der ersten Bildreihe hier: https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo) und bei entfernten Nodes und dem GW die "1.100m"-Variante verbaut. Meine Nodes sind bisher aber alle auch "non-sleeping" (außer meiner RFM-Test-HW).
Auch bei MySensors ist immer wieder der Kernsatz zu lesen: Kondensator verbauen! Viel mehr als zwei Kondensatoren und ein billiger Spannungsregler ist auf den Modulen übrigens auch nicht drauf.

Also genau was du sagst: Stabile Spannungsversorgung ist essentiell...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Mathea

#10
Zitat von: PeMue am 26 Juli 2018, 11:27:44
Postest Du bitte Deine (optimale?) Lösung für die Spannungsversorgung?

Danke + Gruß

PeMue

Leider habe ich immer noch keine optimale Lösung gefunden. Da ich die letzten zwei Wochen aber viel herumprobiert habe, könnte ich demnächst vielleicht mal einen längeren Post über meine Erfahrungen schreiben. Leider basiert meine Bastelei auch nur auf trial and error. Würde man es professionell angehen, sollte man die verschiedenen Kombinationen aus Netzteil, Spannungsregler, etc. mal mit einem Oszilloskop messen.

Was ich definitiv sagen kann: Die beste Kommunikation habe ich mit einem Node, bei dem das Transceiver-Modul über den 3.3V LDO des Arduino Pro Mini versorgt wird (inkl. 47µF Elko). Damit sieht die komplette Kette wie folgt aus:
AC/DC Netzteil von 230V AC zu 12V DC --> LM2596 Buck Converter von 12V auf 5V --> MIC5205 LDO des Arduino Pro Mini von 5V auf 3,3V --> NRF24L01 inkl. 47µF Elko.

Stellt man den LM2596 Buck Converter direkt auf 3,3V ein und speist den Transceiver direkt darüber, funktioniert gar nichts, da der Buck Converter eine zu unsaubere Spannung produziert. Der in den Arduino Pro Minis verbaute MIC5205 LDO hingegen ist ein Spannungsregler, der laut Datenblatt eine hohe Dämpfung der Störungen am Eingang und eine außergewöhnlich stabile Ausgangsspannung mit sehr geringem Noise-Faktor aufweist. Für den Otto-Normalverbraucher würde ich das also als Empfehlung aussprechen.

Ich habe allerdings noch nicht ausprobiert, den NRF24L01 mit Ausgangsverstärker und externer Antenne darüber zu versorgen (MIC5205 liefert max. 150mA, man liest im Internet, dass die großen Transceiver mit externer Antenne mehr brauchen). Für den Zweck nutze ich eines dieser AMS1117 Module. Meiner Meinung nach sind die aber auch nicht optimal. Gute Ergebnisse konnte ich erst erreichen, nachdem ich den Transceiver mit Aluminiumfolie abgeschirmt habe. Ich habe auch ein wenig mit einem RC- und LC Filter herumgespielt, fand es aber schwer, die Veränderung zu quantifizieren (manchmal funktionierte es besser, manchmal nicht, ...).

Was ich auch festgestellt habe: Viele Kondensatoren sind nicht zwangsläufig gut. In den Datenblättern von Spannungsreglern ist meistens exakt spezifiziert mit welchen Kondensatoren (Kapazität und ESR) sauber geregelt wird. An zwei Nodes konnte ich durch Ablöten der Elkos die Verbindung drastisch stabilisieren. Die von mir verbauten Elkos hatten anscheinend einen zu hohen ESR Wert, weshalb die Regelung wieder instabil wurde (LP2950 ACZ Festspannungsregler).

Im Moment ist eine Lieferung mit verschiedenen low-ESR Elkos mit hoher Kapazität zu mir. Ich werde die mal ausprobieren und schauen, ob ich was bewirken kann.

Mathea

Zitat von: PeMue am 26 Juli 2018, 11:27:44
Postest Du bitte Deine (optimale?) Lösung für die Spannungsversorgung?

Danke + Gruß

PeMue

So, ich habe heute den ganzen Tag verschiedenste Ansätze ausprobiert und bin mit folgenden zwei Kenntnissen erfolgreich geworden:

1. Zum Glätten der Netzteil-Ausgangsspannung vor dem Spannungsregler der Versorgung des NRF24L01+ so viele und unterschiedliche Kondensatoren wie möglich verwenden. Ich habe direkt am Spannungsregler einen 100nF Keramikkondensator und auf der Platine graduell größere Kondensatoren aufgelötet (im Falle meines Gateways: 1µF, 2x10µF Keramik und 47µF, 100µF, 220µF, 470µF Elektrolyt). Die ESR Werte scheinen hier nicht so wichtig zu sein, aber verschiedene Größen bewirken wohl ein optimaleres Filtern auf verschiedenen Frequenzbändern.

2. Hinter dem verwendeten Spannungsregler gemäß Datenblatt penibel auf ESR der verwendeten Kondensatoren achten, aber ebenfalls viel Kapazität auf verschieden große Kondensatoren verteilen. Auf meinen Nodes ist nun ebenfalls direkt am Transceiver Modul ein 100nF Keramik-Entkoppel-Kondensator aufgelötet und auf der Platine reicht es von 1µF Keramik bis 220µF Tantal. Elkos funktionieren aufgrund der höheren ESR Werte nur gut bei Spannungsreglern, die in diesem ESR Bereich arbeiten. Zu geringe ESR Werte können darüber hinaus ebenfalls problematisch werden.

Ich konnte auf diese Weise sämtliche meiner Netzteil-betriebenen Nodes optimieren und habe seither keine Outstanding ACKs mehr. Auch Nodes, die vorher gar nicht funktioniert haben kommunizieren nun ordnungsgemäß.

Allerdings werde ich das die nächste Zeit nochmal genau beobachten, da ich Angst habe, dass sich der Zustand nicht hält. Nach meiner Erfahrung steigen Nodes ab und zu einfach aus und funktionieren dann erst am nächsten Tag wieder...