Autor Thema: RS485: Busauslegung und alternativ: CAN-Treiber-Chips?  (Gelesen 3893 mal)

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #90 am: 14 Juni 2018, 10:46:20 »
Moin,

ein paar Fragen/Anmerkungen zum Schaltplan:
(Du weißt aber schon, dass das nicht zu meinen Kernkometenzen gehört, oder?!? Also nicht lachen, wenn's völlig daneben ist *grins*)

- 3.3V: Einen Regler habe ich nicht so richtig ausgemacht; soll das "IC2" sein? (Dann müßte aber der 3.3V-VCC-Ausgang separat ausgewiesen/geroutet werden, oder?)
- ATSHA: Macht der hierdrauf Sinn? Und evtl. hätten wir dann doch Probleme mit der Message Length (müßte man prüfen), da die verschlüsselten Nachrichten bei nRF24 jedenfalls das maximale der Payload ausnutzen.
- Option, den Busabschluß draufzulöten? Also SMD-Widerstände GND-B und 5V-A (??)?
- Das "unten links" verstehe ich nicht so recht; wenn das eine Sicherung mit Brückenoption ist, müßte der Eingang doch "IN" sein (kommend vom Connector) und "UREG" out?

Aber die Anschlüße des MCP sehen für meine Augen ok aus...
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1142
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #91 am: 14 Juni 2018, 15:32:51 »
Ich würde gerne später Antworten. Aber vorab:

Wir reden vom CAN Bus, und du schlägst die Option vor den Bus auf GND und VCC zu pullen ?
Das würde heissen CAN_L nach GND und CAN_H auf VCC ? (Der Wert wäre ja erst mal egal und ich würde 680R in den Schaltplan schreiben)
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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #92 am: 14 Juni 2018, 16:11:52 »
Laß dir Zeit!
Schon richtig: Der im Moment bei mir installierte Bus hat neben 120 Ohm am GW und an der letzten Node noch zwei weitere Widerstände à 2.000 Ohm.

Genau mit diesem Hardware-Setup läuft es jetzt seit Anfang der Woche stabil...

Und zur Klarstellung nochmal: Eine Zeitlang hatte ich MAX485, MAX487, TJA1050 und MCP2551 bei 57600 Baud in einem gemischten Betrieb, wobei das GW Software-Serial nutzte. Ich bin ziemlich sicher, dass - neben dem Stabilisieren der Spannungsversorgung (da waren einige LMS1117 kaputt) - alleine der Patch ausgereicht hätte, um damit einen problemfreien Betrieb zu haben. Der Kommunikationslayer an sich war jedenfalls funktional.

Spannend ist jetzt aus meiner Sicht nur, ob

- auch ein Software-Serial-Betrieb mit den CAN-Transceivern klappen würde und
- die MCP2551 auch bei 9600 Baud noch funktionieren ;) .

Werde ich beides bei Gelegenheit - mit oder ohne Grill - mal testen :P . Wenn weiter keine negativen Vorkommnisse mehr sind, würde ich dann irgendwann mal bei Gelegenheit die gesammelten Erkenntnisse in's Wiki (Abschnitt im Starter-Guide?) packen.
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1142
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #93 am: 14 Juni 2018, 17:31:16 »
Zitat
- 3.3V: Einen Regler habe ich nicht so richtig ausgemacht; soll das "IC2" sein? (Dann müßte aber der 3.3V-VCC-Ausgang separat ausgewiesen/geroutet werden, oder?)
Habe ich jetzt auch noch spendiert. (neu)

Zitat
- ATSHA: Macht der hierdrauf Sinn? Und evtl. hätten wir dann doch Probleme mit der Message Length (müßte man prüfen), da die verschlüsselten Nachrichten bei nRF24 jedenfalls das maximale der Payload ausnutzen.
Ist weg. Der macht m.E immer Sinn. Aber man sollte die Kirche im Dorf lassen und seinen Kabeln vertrauen.

Zitat
- Option, den Busabschluß draufzulöten? Also SMD-Widerstände GND-B und 5V-A (??)?
Neu: Wieder mit Pull gedöns...

Zitat
- Das "unten links" verstehe ich nicht so recht; wenn das eine Sicherung mit Brückenoption ist, müßte der Eingang doch "IN" sein (kommend vom Connector) und "UREG" out?
Ich habs mal etwas verständlicher gemalt. Von der Funktion her hat sich nix geändert. Nur die Hohlbuchse muss dran glauben (Heul!)



Das Ergebnis gefällt mir schon ganz gut. Denke davon lass ich mal ein paar produzieren.
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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #94 am: 14 Juni 2018, 18:14:58 »
Vielleicht noch eine Sache: Da ich zwischenzeitlich wieder 5V statt 12V verteile: Jedenfalls bei mittleren Kabellängen wäre das evtl. eine Option entweder eine Ader aus den verbliebenen als 5V-Option vorzusehen, oder RAW zu kappen und nach UREG zu 5V zu brücken, oder?
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1142
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #95 am: 14 Juni 2018, 18:36:48 »
Find ich gut und bau ich ein.

Allerdings wäre ich dafür lieber 48V (m.E. leider teuerer) zu verteilen statt 5V. Da hast du weniger Verluste und kannst somit auf der selben Leitung mehr Energie übertragen.
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.

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1142
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #96 am: 15 Juni 2018, 08:54:11 »
Btw. Eine Platine für beide Chips ist kein Problem. Ich denke ich werf lieber bei größeren Versionen die DIL Bauart runter und ersetze diesen Chip durch das CAN Teil.
Ich denk ich würde das erst mal so lassen: https://github.com/ranseyer/MySensors-HW/tree/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/5-GW-Sens-CAN-ProMicro
(ggf. minimale Optimierung der Beschrifung, aber das sehe eigentlich erst für eine spätere V0.2)
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.

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1142
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #97 am: 15 Juni 2018, 16:56:33 »
URL geändert, leichte Anpassung. Wenns dabei bleibt, dann ggf noch etwas bessere Beschriftung...
https://github.com/ranseyer/MySensors-HW/tree/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/5-GW-Sens-RS485-CAN-ProMicro
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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #98 am: 15 Juni 2018, 17:22:16 »
Hab jetzt nicht nochmal intensiv drüber gesehen, aber das Ding sieht schnuckelig aus, ist ja wirklich winzig.
Was die Beschriftung angeht, könnte insbesondere klarer gemacht werden, wo die 3.3V dann abzugreifen sind? Auf den top/bot.png's kann ich das nicht so richtig ablesen, gehe aber davon aus, dass der "kleine" in der Mitte für 3.3V ist und der große auf bot.png links angeordnet, oder?
 
Zu der zentralen Versorgung: Du hast schon recht, 5V sind auch nicht sooo das Gelbe vom Ei, mehr wäre eigentlich besser. Dazu hätte ich noch folgende Idee: Recht weit verbreitet sind z.B. die LM2596S-Module. Da kannst du mit allem möglichen rein (bis 30V, meine ich), die passende Ausgangsspannung muß halt eingestellt werden.
Wenn jetzt die Teile an sich ok sind (habe da auf die Schnelle keine weiteren Infos zu) und auch mechanisch von allen Quellen identisch, könnte man die optional als Huckepack-Steckmodul drunter klemmen. Sind halt relativ groß...
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #99 am: 15 Juni 2018, 18:10:50 »
Nachtrag: Buck Converter scheint es auch in deutlich kleiner zu geben; da wir hier keinen HF-Teil haben, dürfte das eigentlich die bessere Variante sein, hier einen (optional) reinzudesignen.

Effizienter... Habe nur auf die Schnelle keinen gefunden, der so einen großen Bereich abdeckt, aber z.B. https://www.ebay.de/itm/1-2-5X-DC-DC-4V-12-24V-To-5V-3A-Adjustable-Step-Down-Power-Module-Buck-Converter/272718668610?hash=item3f7f4ca342:m:m6kjPR7ItoH4BMSybE6CUig scheint denselben "footprint" zu haben wie einige andere, die bis 23V vertragen. Wären 4 Pins, die (nach unten?) noch vorzusehen wären, Bemaßung kenne ich aber leider nicht.
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1142
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #100 am: 15 Juni 2018, 23:53:37 »
Genau den kannst Du doch am Ende links verbauen... (Ist evtl nicht so doll dokumentiert, neues hat in dem knappen Design eher keinen Platz mehr...)
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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #101 am: 16 Juni 2018, 13:52:20 »
...hätte ich mir eigentlich ja denken können ;D .
Beschriften würde vermutlich den Einstieg für Interessierte erleichtern ;) .
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #102 am: 17 Juni 2018, 12:10:43 »
Spannend ist jetzt aus meiner Sicht nur, ob

- auch ein Software-Serial-Betrieb mit den CAN-Transceivern klappen würde und
- die MCP2551 auch bei 9600 Baud noch funktionieren ;) .
So, kurze Rückmeldung zum ersten Test dazu: beides scheint problemlos zu funktionieren.
Ergänzend die Info: Im Unterschied zu den MAX48x mögen die MCP2551 es nicht, wenn man die Kanäle irgendwo vertauscht, es muß strikt CANhi auf CANhi gehen.
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN

Offline Ranseyer

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 1142
    • Homepage
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #103 am: 17 Juni 2018, 12:13:03 »
Zitat
mögen die MCP2551 es nicht, wenn man die Kanäle irgendwo vertauscht

Verabschiesen sich diese dann feige aus dem Leben ?
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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 4003
Antw:RS485: Busauslegung und alternativ: CAN-Treiber-Chips?
« Antwort #104 am: 17 Juni 2018, 13:16:19 »
Ganz so drastisch ist es nicht. Einfach keine Kommunikation....
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.1-beta@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW@MQTT2 | zigbee2mqtt@MQTT2 | SIGNALduino | MapleCUN