RS485: Busauslegung und alternativ: CAN-Treiber-Chips?

Begonnen von Beta-User, 22 Februar 2018, 15:14:12

Vorheriges Thema - Nächstes Thema

Beta-User

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-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

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.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

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-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

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.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

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-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

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.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

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.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Ranseyer

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!

Beta-User

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-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

Beta-User

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-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

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.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

...hätte ich mir eigentlich ja denken können ;D .
Beschriften würde vermutlich den Einstieg für Interessierte erleichtern ;) .
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

Beta-User

Zitat von: Beta-User am 14 Juni 2018, 16:11:52
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-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

Zitatmö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.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Beta-User

Ganz so drastisch ist es nicht. Einfach keine Kommunikation....
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