Rauchmelder V2.4 auf ARM portiert

Fragen und Diskussionen zur Entwicklung von neuen Geräten. Sowohl Hardware als auch Software. English is welcome.
Hendrik
Beiträge: 167
Registriert: 3. Aug 2015, 15:16
Wohnort: Heidelberg

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Hendrik »

Doumanix hat geschrieben: wenn ich in den Warenkorb schaue, sehe ich diese Diode. Kann es sein, dass die im Warekorb die für die RB060M in der BOM ist?
Wenn Du einen Blick in den von mir verlinkten Thread wirfst, siehst Du, dass ich mich dort auch auf genau diese Diode beziehe. Ja, sie ist im Warenkorb. Ja, sie sitzt auf der TS-ARM. Ja, sie ist zu breit für den Footprint auf dem 4TE Controller, bei dem die RB060M eingeplant ist. Ja, deswegen habe ich beim Aufbau meiner 4TE in die Bastelkiste gegriffen und etwas anderes verlötet. Ja, auf den ersten Blick sieht mir das Layout des Rauchmelders genauso eng aus.

Deswegen die Frage.

Tags:
Doumanix
Beiträge: 508
Registriert: 7. Nov 2017, 16:33

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Doumanix »

Alles klar, hast ja recht, ich hatte deinen inzwischen ja schon etwas älteren Beitrag nicht nochmal aufgerufen...

Tja, irgendwie ist die Controllerplatine halt im DEV Stadium hängen geblieben, so wie es auch drauf steht, behaupte ich mal.
Die ganzen optionalen Widerstände, die ja nur 0805 groß sind, sind ja auch nur optional, wie es im Wiki steht.
Und ja, die MURS 110 bzw. MBRS 1100 sind einfach zu dick für die Controllerplatine.

Ich denke, deine Anmerkungen kann man alle so übernehmen, ich könnte auch mal einen aktualisierten Warenkorb aufsetzen ... aber wir sollten trotzdem überlegen, was wir mit der D5 im speziellen und mit der Platine im Allgemeinen machen. Meiner Meinung nach sollten wir die mal überarbeiten und eine finale Version 1.0 draus machen.
Mag sein, dass da noch unausgeschöpftes Potenzial auf der Straße liegen bleibt, aber dann könnte man es auch sinnvoll mit den Standardkomponenten nutzen.

Ich würde zum Beispiel schon mal den Quarz weg machen und voll auf ARM + Oszi gehen. Das verringert die Vielfalt in den zu besorgenden Bauteilen, läuft zuverlässig und schafft nebenbei Platz auf der Platine, den man verwenden könnte, um die anderen Bauteile anders anzuordnen.
Hendrik
Beiträge: 167
Registriert: 3. Aug 2015, 15:16
Wohnort: Heidelberg

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Hendrik »

Ich möchte gerne in diesem Thread beim Rauchmelder bleiben. Alles, was den 4TE Controller betrifft, sollte auch dort diskutiert werden. Ich habe nur deswegen darauf verwiesen, weil für den Rauchmelder die 4TE Stromversorgung übernommen wurde (mindestens der Schaltplan, das Layout habe ich nicht im Detail angeschaut) und ich vermeiden wollte, dass diese Punkte untergehen, bevor Platinen in größerem Maßstab produziert werden. Vielleicht gibt es z.B. für den Spannungsteiler ja eine gute Erklärung, und ich kenne sie einfach nicht.
Hendrik
Beiträge: 167
Registriert: 3. Aug 2015, 15:16
Wohnort: Heidelberg

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Hendrik »

Doumanix hat geschrieben: D8 ist außerdem nicht beschriftet in den Eagle Dateien ... ist das die SMAJ40, die wir sonst verwenden?
Bin mir gerade nicht sicher, worauf Du schaust. In Rauchmelder 3.4 ist D8 eine 1N4148 und D5 die SMAJ40. Beides beschriftet.
Doumanix
Beiträge: 508
Registriert: 7. Nov 2017, 16:33

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Doumanix »

Ja ne, passt schon. Ich war gestern dann zu sehr von der Controller Platine abgelenkt.
D8 auf der Controller ist die SMAJ.

Aber bleiben wir hier mal bei der RM.
Wenn, dann wird wohl Andreas etwas zum Spannungsteiler sagen können.
Olli
Beiträge: 70
Registriert: 12. Aug 2014, 20:52
Wohnort: Moormerland / Ostfriesland

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Olli »

Hallo,

ich habe mir die aktuellen RM 3.4 Platinen machen lassen und werde nun mal beginnen die zu testen. Die Software lief nach meiner Portierung sehr ordentlich mit bisher keinen bekannten Problemen.

Zu dem Spannungsteiler am EN Pin des BD9G101:
Der EN Pin benötigt mindestens 2V, um garantiert die Arbeit aufzunehmen. Unter 0,8V wird garantiert abgeschaltet. Was dazwischen ist, wird nicht definiert.
(Daten aus dem Datenblatt des BD9G101)

Bei dem Spannungsteiler von 390k/43k ergibt sich eine Busspannung von ca. 20V ab dem der Spannungsregler sicher arbeitet.
Gibt es eine Vorschrift für KNX Geräte, die fordert, dass die Geräte ab einer gewissen Spannung abschalten müssen? Dann wäre das die wahrscheinliche Erklärung für den Spanungsteiler.

Ich werde berichten, wenn ich alle Teile beisammen habe und eine Platine testen konnte.

Grüße,
Olli
Hendrik
Beiträge: 167
Registriert: 3. Aug 2015, 15:16
Wohnort: Heidelberg

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Hendrik »

Hi!
Olli hat geschrieben: Zu dem Spannungsteiler am EN Pin des BD9G101:
Der EN Pin benötigt mindestens 2V, um garantiert die Arbeit aufzunehmen. Unter 0,8V wird garantiert abgeschaltet. Was dazwischen ist, wird nicht definiert.
(Daten aus dem Datenblatt des BD9G101)

Bei dem Spannungsteiler von 390k/43k ergibt sich eine Busspannung von ca. 20V ab dem der Spannungsregler sicher arbeitet.
Mmm, das schrieb ich beim 4TE Controller ja auch schon. Allerdings hat der BD9G101 einen internen pull-down von 550k, d.h. effektiv haben wir hier einen Spannungsteiler von 390:39.9 und erreichen die 2V am Eingang erst bei etwa 21.6V (EDIT: In Wahrheit sogar noch um den Spannungsabfall an D8 (1N4148) höher, also eher 22.3V Busspannung bei 6mA Strom). Laut http://www.knx.org/media/docs/Flyers/KN ... ics_en.pdf müssen KNX-Geräte aber bis hinunter zu 21V laufen.
Olli hat geschrieben: Gibt es eine Vorschrift für KNX Geräte, die fordert, dass die Geräte ab einer gewissen Spannung abschalten müssen? Dann wäre das die wahrscheinliche Erklärung für den Spanungsteiler.
Ich weiß nicht, ob es eine Anforderung gibt, unterhalb einer bestimmten Spannung abzuschalten (EDIT: siehe unten). Aber selbst wenn, ist dieser Spannungsteiler keine zuverlässige Abschaltung. Denn was zwischen 0.8V und 2V passiert, ist halt nicht definiert. Wenn wir unter z.B. 20V Busspannung abschalten wollen, muss das der uC über die Busspannungsüberwachung tun. Nur dann haben wir einen wohldefinierten Schwellwert. Damit der uC das tun kann (und je nach Applikation auch in der Lage ist, beim Abschalten noch irgendwelche Zustände zu speichern), braucht er aber Strom. Das heißt, der Regler muss weiterlaufen.

Daher fände ich es schön, wenn derjenige, der den Spannungsteiler designt hat, etwas dazu sagen könnte. Ich weiß halt nicht, wer das war.

Viele Grüße,

Hendrik

EDIT: KNX System Specifications, Kapitel 3/2/2 "Twisted Pair 1", Abschnitt 1.2.2.2 "Switch off behaviour" sagt für Geräte, die vom Bus versorgt werden: Wenn die Busspannung unter 20V fällt, soll das Gerät ein "Usave"-Signal erzeugen, um Daten zu speichern und das Verschicken von Telegrammen zu beenden. Sobald die Spannung nicht mehr reicht, um das Gerät zu betreiben, soll es in einen Idle-Modus gehen, wo der Regler tatsächlich abgeschaltet wird.

So wie ich das lese, ist der Spannungsteiler in seiner jetzigen Form tatsächlich ungeeignet, diese Ziele zu erreichen (zumindest gemäß der Angaben im Datenblatt des Reglers). Ich denke, ohne Veränderung des Layouts bzw. der grundsätzlichen Schaltung müsste man:
  • Den Spannungsteiler so anpassen, dass man bei 6.5V am in-Pin 0.8V am enable-Pin hat, damit man beim Einschalten sicher über der Mindestspannung des Reglers liegt (6V). Also z.B. effektiv 390:55 unter Berücksichtigung des internen pull-down. Dann erreicht man 2V an enable bei 16.2V an input.
  • Busspannung in Software überwachen und bei einem Messwert von weniger als 20V-0.7V=19.3V die CPU runterfahren. Ich weiß nicht, wie lange man dann noch Zeit hat, um Daten zu speichern (falls nötig).
Nett wäre natürlich, wenn man sich das Zeitfenster, um Daten zu speichern, maximieren könnte, indem man den Regler aktiv ein- und ausschaltet. Also z.B. den Spannungsteiler durch einen Schmitt-Trigger ersetzt, der den Pin unterhalb von 7V auf Masse und oberhalb von 20.3V auf die Eingangsspannung zieht. Das ist aber eine echte Änderung der Schaltung.

So weit erstmal, ohne tatsächlich etwas gemessen zu haben.
oldcoolman
Beiträge: 645
Registriert: 17. Mai 2013, 20:57
Kontaktdaten:

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von oldcoolman »

Für den Bus sind 20V als Minimum definiert, für Busteilnehmer gar 19V.
Zumindest habe ich das von den Relaisen her noch so in Erinnerung.
Ich wollte was zur Shottky Diode anmerken. Ich habe mir das mal angesehen.
Wir sollten den Footprint SMA hernehmen. Dieser ist auf der TS ARM und auch auf dem Taster schon drauf. War für die Zukunft gedacht, wurde wohl bei der RM Platine noch vergessen.
liebe Grüße
Andreas
Hendrik
Beiträge: 167
Registriert: 3. Aug 2015, 15:16
Wohnort: Heidelberg

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Hendrik »

Moin!
oldcoolman hat geschrieben:Für den Bus sind 20V als Minimum definiert, für Busteilnehmer gar 19V.
Zumindest habe ich das von den Relaisen her noch so in Erinnerung.
21V Bus und 20V Teilnehmer: https://my.knx.org/en/shop/knx-specifications -> "03_02_02 Communication Medium TP1 v01.02.02 AS.pdf":

"In an installed system the DC voltage at every device shall be at least 21 V" (1.2.2) und "For bus powered devices, this Usave signal shall be generated when the bus voltage drops below 20 V max., thereby taking into account a hysteresis of at least 1 V." (1.2.2.2). Außerdem Abschnitte 1.1.1 bis 1.1.3 (da sind die Signale definiert).

Diode: SMA SMB klingt gut. Passt alles drauf, was man will.

Ciao,

Hendrik
Zuletzt geändert von Hendrik am 6. Apr 2018, 12:18, insgesamt 1-mal geändert.
Hendrik
Beiträge: 167
Registriert: 3. Aug 2015, 15:16
Wohnort: Heidelberg

Re: Rauchmelder V2.4 auf ARM portiert

Beitrag von Hendrik »

Nachtrag:
Hendrik hat geschrieben:Diode: SMA klingt gut. Passt alles drauf, was man will.
Ich sehe gerade, dass die MBRS1100 SMB ist. Auf der TS-ARM haben wir dafür allerdings einen SMA Footprint und die Diode passt gut drauf. Keine Ahnung, wie die courtyards in der Eagle-Bibliothek aussehen und ob das zuverlässig klappt oder bei der TS-ARM einfach nur großzügig genug Platz gelassen wurde. Man sollte es aber im Hinterkopf behalten, wenn man ein neues Layout macht.
Antworten