OneWire Erweiterungsplatine für die REG1 Plattform

[MarcoLanghans]

Hallo zusammen,

ich habe eine OneWire Erweiterungsplatine für die REG1 Platform erstellt und teile diese gerne mit euch.
Dies war nur durch den super Modularen Ansatz von Ing-Dom und auch das Teilen aller Informationen möglich, dafür vielen Lieben dank !!!

Wichtig ist das es sich hierbei nur um die Erweiterungsplatine handelt, man benötigt noch einen REG1 Gerät mit BCU usw. Auch ist diese Platinen nicht vom OpenKNX Team erstellt worden und trägt daher auch kein OpenKNX Logo da es sich nicht um offizielle OpenKNX HW handelt.

Als Software habe ich die OAM-Raumcontroller 5.1.5 (mit Anpassungen in der platformio.custom.ini für die Hardware) verwendet, dafür auch ein grossen Danke an Waldemar !!!

Die Platine erweitert das REG1 Base um 2 Binäreingänge und OneWire für 30 Geräte (6er Buchse für 2x VCC/DATA/GND) beides ist über die Isolatoren auch galvanisch getrennt. Leider ist in der aktuellen Version noch ein Fehler da ich dummerweise die I2C0 anstatt den I2C1 Anschlüssen von dem APP Connector genutzt hatte und dann der I2C0 Anschluss auf der Basis Platte nicht mehr geht. Für mich passt dies erstmal aber bei einer neuen Revision werde ich dies beseitigen.

Die Platine soll keinen Konkurrenz zu dem schon vorhandenen OneWire GW von Masifi sein, davon habe ich selbst eins und es funktioniert super gut. Ich fand jedoch den Gedanken von dem Basis REG1 und dann einfach die passende Erweiterung einzubauen super, auch hatte ich mal wieder Lust etwas in Kicad zu entwerfen.

Die Erweiterung läuft bei mir nun schon seit einigen Tage stabil und sendet die Werte von zwei 1Wire Sensor auf den BUS, es bestehen daher noch keinen Langzeiterfahrungen.


image.png

IMG_4355.jpg
IMG_4354.jpg

Grüße und allen einen guten Rutsch morgen.

[mumpf]

Hey Marco,

ich finde das cool, was Du da gemacht hast. Ich kann Dir auch anbieten, beim Bauen vom RaumController noch eine Hardware-Variante hinzuzufügen, die den REG1 mit Deiner Erweiterung umfasst. Wir sollten uns dann nur einen passenden Namen für Deine HW ausdenken, damit es nicht zu Missverständnissen kommt.

Echt klasse!

Gruß und guten Rutsch,
Waldemar

[Ing-Dom]

Cool. Freut mich das der modulare Ansatz hier gegriffen hat, genau so war das REG1 System immer gedacht.
Gerne unterstütze ich bei einer vollen Integration und dass wir daraus ein "echtes" OpenKNX Gerät ableiten.

Ich hätte einen Änderungswunsch:
Der 4polige Stecker rechts durch einen 6poligen ersetzen und ggf. 3 BIs drauf machen. Denn diese Gehäusevariante mit 6p und 4p gibt es noch nicht.
Und der eine GPIO ist offensichtlich auch noch frei.

So wie ich das sehe ist OneWire galvanisch getrennt über einen Adum1250 (o.Ä.) und die Versorgung erfolgt über einen Koppler mit integ. DC/DC oder?

Hast du das schon irgendwo auf Github ?

[MarcoLanghans]

Hi,

habe es gerade hochgeladen https://github.com/MarcoLanghans/REG1-App-OneWire (Hoffe es ist komplett mache dies nicht so oft)

3 BIs waren bei der aktuellen Hardware leider nicht möglich da der CA-IS3643HVW keinen weiteren Kanal mehr übrig hatte. Aber man könnte das 1WIRE_FAULT Signal (wird soweit ich es gesehen habe ich aktuell eh nicht ausgewertet vom OneWire Modul) entfernen und dann dafür einen zusätzlichen BI einführen oder man fügt einfach noch einen Optokopler (z.B. einen LTV-217-B-G wie beim UP1 Modus Galway) für das 1WIRE_FAULT Signal hinzu und dann den zusätzlichen BI auf den freien Kanal des CA-IS3643HVW

Falls in der PCB Designfehler drin sind diese gerne melden, da ich dies nicht beruflich machen und somit alls nur auf meinen technischen Recherchen usw. beruht.

Grüße

Marco

[ralf9000]

Frohes neues Jahr, tolle Leistung, schönes Projekt! 🍸

Nur zwei (kleine) Anmerkungen falls noch etwas an der HW gemacht wird (aus meiner 1-Wire-Medizintechnik-Erfahrung heraus):

• Die Spannungsversorgung durch den CA-IS3643 ergibt eine nicht sehr stabile 5V-Spannung bzgl. Sensorversorgung, die bei 1-Wire Temperatur-Sensoren und -ADCs für Messungenauigkeiten abseits der Datenblätter-Typisch-Aussagen sorgen kann. Zudem ist der Leerlaufstrom ohne aktive Lasten (keine aktive 1Wire-Kommunikation) relativ hoch (Belastung der BCU & KNX-Bus). Abhilfe schafft der disktrete teurere Spezial-Trenner RECOM R05C05TE05S-CT mit 0,5W (nicht der R05CTE05S-CT mit 1W !!!) mit 240mA Input-Strom bei 50% Efficiency, Line Regulation +-0,5% und einer Ruhestrombelastung von nur 7mA hat bei 1-Wire-Sensoren und auch Last deutliche Vorteile, aber Kostenfaktor des Chips 2-4x.
• Bei 100mA Outputstrom wäre dann auch ein 100mA Limiter MIC2091 statt MIC2090 möglich (wahrscheinlich beim CA-IS3643 auch, nur da bricht die Spannung stärker ein). Die neuere NanoBCU bei 5V sollte die (zusätzlichen) 200mA primärseitig liefern können (wäre aber zu testen). Dies würde dann bei speziellen 1-Wire Sensoren von Vorteil sein (z.B. Thermoelement oder 4-fach ADC) oder vielen Sensoren.

Grüße, Ralf

[IPv6]

Ich würde auch in Richtung größerer isolierter DC/DC Wandler schauen, das Board scheint genug Platz zu bieten. Die hochintegrierten Isolatoren mit integriertem DC/DC sind eigentlich nur da wirklich sinnvoll, wo es um das letzte bisschen Platz auf der Platine geht. Da sind schon einige Kniffe im IC nötig, um auf dem Bauraum auch noch nennenswert Energie über die Isolationsbarriere zu transportieren, was sich negativ auf die Effizient und HF Müll auswirkt.
Zumal ich Chipanalog da EMV technisch absolut nicht über den Weg traue, deren einzige Vorgabe im Datenblatt sind eine Hand voll MLCCs. Von Analog Devices (deren iCoupler Technik Chipanalog vermutlich nachbaut) gibt es gute Appnotes über den Aufwand beim Layout, um die Dinger wirklich ruhig zu bekommen und verschiedene EMV Klassen einzuhalten, das ist mit ein paar Kondensatoren bei Weitem nicht getan.
Auch wenn das hier alles DIY ist und die Hardware vermutlich nie eine EMV Messkammer sehen wird, ist es dennoch ratsam, dem Thema ein wenig Beachtung zu schenken. Schließlich hängt da hintendran ein 1-Wire Bus, der sich über größere Distanzen erstreckt und eine gute Antenne bildet, was wiederum andere Geräte beeinflussen kann. EMV Grenzwerte sind schließlich nicht irgendwelche sinnlosen Vorgaben.

[ralf9000]

.... Analog Devices (deren iCoupler Technik Chipanalog ....

Zum R05C05TE05S-CT wäre auch Analog Devices ADuM1251 (unidirektionales SCL reicht hier, niedriger Strom, ansonsten dann ADuM1250) für I2C und ADuM1201 für GPIOs wäre auch meine Empfehlung hier.

Beim 1W-Chip würde ich auch den neueren DS2482-100 nehmen und dort einen zusätzlichen FET (BSS84/BS250) und 2x100Ohm strong PullUp realisieren, hilft bei langen 1W-Leitungen sehr.

StrongPullUp.jpg

[Ing-Dom]

ie neuere NanoBCU bei 5V sollte die (zusätzlichen) 200mA primärseitig liefern können

nope !

100mA@5V wäre das Maximum, also 500mW.
Mit höherer Spannung bekommt man etwas mehr raus, solange die Busspannung passt.
BCU gesamt: 40mA @30V = 1200mW abzüglich 3,3V Rail sowie Effizienz.. 200mA@5V sind aber utopisch.

Ich bin mit OneWire nicht fit, insofern hab ich keine Ahnung was typische Sensren brauchen und für welchen Strom man sowas designed.

den R05C05TE05S-CT gibts auch nicht mit anderem Vin. Aber SMD ist hier auch kein Muss, ein größeres Package SIL oder mit einer maximalen Höhre von ca. 11mm brigt man problemlos mit drauf.
zB... ein R0.5Z-1205
Strombegrenzung wäre dann aber wichtig um die BCU nicht zu überlasten.

[ralf9000]

100mA@5V wäre das Maximum, also 500mW.

Schade, dann geht nur 50mA-Begrenzung für 1W. Da aber die Ströme bei 1W nur bei Wandlung und Senden stark ansteigen, könnte man hinter dem Limiter auch eine schnelle, verlustarme Stützkondensatorschaltung vorsehen, das würde auch sehr helfen ....

z.B. R0.5Z-1205.

Der Output ist aber nur 5% genau, das schlägt dann bei 1W-Sensoren/ADCs auf die Meßgenauigkeit durch, deshalb hatte ich ja den mit 0,5% und 7mA Ruhestrom vorgeschlagen, der ist schon meines Wissens einzigartig.

[MarcoLanghans]

Ok ich sehe da gibt es dann doch etwas mehr zu beachten bei einer PCB als ich dachte 😱 Ist die PCB denn nun überhaupt zu gebrauchen oder soll ich diese lieber nicht weiter nutzen? (Dies ist eine ernstgemeinte Frage, da ich keine Folgeschäden verursachen möchte)

Da ich absoluter Laie bin bei so etwas haben ich mal geschaut was so ein Temperatursensor verbraucht und gesehen dies liegt laut Internet bei einem Temperatursensor in der Regel im sehr kleinen mA Bereich, aber dies kann natürlich auch falsch sein. Das es da noch andere 1Wire Sensoren mit wesentlich mehr Strombedarf gibt hatte ich garnicht auf dem Schirm. Daher dachte ich mir warum soll ich da einen DC/DC Wandler mit mehren Watt verbauen und dann noch weitere Teile für die Strombegrenzung.

Bezüglich des Chipanaloges bin ich ehrlich diesen habe ich aufgrund der aus meiner Sicht passenden Konfiguration und des schon sehr gutem Preises verwendet. Auch weil dieser Hersteller bei anderer OpenKNX HW verbaut ist dachte ich mir so schlecht kann es dann nicht sein, ebenso ist halt bei DIY ende beim Preis und man kann sich gleich was Kommerzielles kaufen, aber ich will da natürlich auch keinen Mist verwenden. EMV hatte ich da auch als Laie überhaupt nicht bedacht.

Sollte man von Chipanalog grundsätzlich einen Bogen machen? Und dann doch lieber zu Produkten von Texas Instruments, Analog Devises oder Recom greifen beim PCB Design?

Würde es daher Sinn machen z.B. einen ADUM5000ARWZ-RL oder UCC12040DVERals standalone isolated DC/DC zu verwenden und dann halt einen für die 3 BIs und einen für die I2C?

[Ing-Dom]

der ist schon meines Wissens einzigartig.

ok, das hatte ich übersehen.

Evtl. is es dann einfach grundsätzlich nicht sinnvoll ein OneWire Gateway busversorgt zu entwerfen, sondern man arbeitet lieber mit einer externen Versorgung..
zB. 9-30V und setzt die auf saubere 5V runter mit passender guter Glättung und Filterung..
Gerade bei einem REG Gerät.. irgendeine Hilfsspannung hat man ja im Verteiler idR zur Verfügung.

[ralf9000]

Evtl. is es dann einfach grundsätzlich nicht sinnvoll ein OneWire Gateway busversorgt zu entwerfen, sondern man arbeitet lieber mit einer externen Versorgung..

Für 0815 1W-Installationen ist Busversorgung über KNX schon sehr wünschenswert, dann aber gut stabilisiert. Der schnelle Stützkondensator über Ladebegrenzungswiderstand und Schottkydiode (z.B. BAT60A oder MBRS120) wäre schon gut.

Man kann aber für besondere 1W-Installationen die 5V-Leitung im 1W-Bus auch von einem externen guten Netzteil nehmen, wenn es dann nicht reicht, diese Alternative hat man ja immer. In dem Fall würde man 5V aus dem KNX-Gerät heraus nicht verbinden.

NACHTRAG: Im Falle des Stützkondensators hat dies auf der KNX-Seite des R05C05TE05S-CT zu erfolgen, von der 5V-BCU auf 100mA-Begrenzer, dann Widerstand (Begrenzung Kondensatorladestrom) mit Schottky-Diode vor "schnellem" Kondensator. Hier kann es ruhig bis 4,5V runtergehen, der R05C05TE05S-CT händelt das gut, sekundärseitig sind es wieder die sehr konstanten 5V. Man spart sich dann auch die Entkopplung der Reset & Status-Leitungen. Nachteil könnte sein, das dem 1W-Master mit die Spannung entzogen wird und er dann neu initialisiert werden müsste, das sieht man aber im SW-Code und wäre zu ändern ....

[mumpf]

wird soweit ich es gesehen habe ich aktuell eh nicht ausgewertet vom OneWire Modul

Doch, natürlich .
https://github.com/OpenKNX/OGM-Senso....cpp#L142-L143

Wirkt sich aber nach außen hin merkbar nur bei der Benutzung von iButtons aus, die machen nämlich gerne einen short bein an- und abstecken, da wird das Signal zur "Entprellung" genutzt.

Gruß, Waldemar

[MarcoLanghans]

mumpf Hi Waldemar danke fürs auflösen.

Dachte dies wäre nicht in Benutzung da ich zwar die Definition in der Hardware.h für die ONEWIRE_5V_SHORT gefunden habe aber die ONEWIRE_5V_SHORT habe ich dann nirgend mehr im Code gefunden. Auch war ich mir dann nicht Sicher ob die ONEWIRE_5V_SHORT Überhaupt etwas mit dem Error zu tun haben, da ich mit Short nix anfangen konnte.

[henfri]

Warum nicht beide Optionen in einem Gerät:
Busversorgung möglich aber ggf. per Jumper umschaltbar auf externe Versorgung.