Vernünftige VM-Elektrik (Ideen + Lösungen)

Ich meine mal gelesen zu haben, dass I²C, obwohl es dafür nicht ausgelegt ist, in der Praxis doch relativ gut geeignet ist um "längere" Strecken (zB im VM) zu verbinden. Hat da irgendwer Erfahrung mit?
Hab ich mir neulich aus anderen Gründen mal angeschaut, aber noch nichts mit gemacht. "Flanke im Signal bei High-Pegel im Takt" als Start- und Stoppsignal klingt nicht gerade fehlertolerant, zumindest die Stromversorgung der Hupe sollte da nicht in der Nähe verlaufen. :unsure:
Von einer UART-Schnittstelle auszugehen ist da glaube ich schon besser. Das ist zwar als Verbindung zwischen zwei Teilnehmern gedacht, aber wenn nur einer sendet, ist ja egal, wieviele Empfänger zuhören. Allerdings überträgt das nur Bytes, man muss also selber dafür sorgen, dass sich ein Empfänger in den laufenden Bytestrom einsynchronisieren und die an ihn adressierten Dinge herauslesen kann. Ob das praktisch robust genug gegen Störungen hinzubekommen ist, weiß ich aber auch nicht.

CAN ist eigentlich in vielen besseren Microcontrollern integriert, aber die kriegt man halt aktuell einfach nicht zu interessanten Preisen.
Gerade mal bei Digikey nach welchen mit AVR-Kern geschaut, da ist es billiger, einen µC und einen separaten CAN-Controller zu nehmen.
Wenn 5V-UART mit RC-Filtern funktioniert, kann man so einen Controller nehmen, der kostet ähnlich viel wie ein CAN-Controller, ist gerade 2x3mm groß und würde wohl reichen, um auf Kommandos zu horchen und 1-2 Schalttransistoren zu steuern.
 
Hab ich mir neulich aus anderen Gründen mal angeschaut, aber noch nichts mit gemacht. "Flanke im Signal bei High-Pegel im Takt" als Start- und Stoppsignal klingt nicht gerade fehlertolerant, zumindest die Stromversorgung der Hupe sollte da nicht in der Nähe verlaufen. :unsure:
I2C geht eben nicht davon aus, gestört zu werden, das etablierte "Protokoll" sieht auch keine Prüfsummen o.ä. vor. Man muß sich natürlich fragen, was denn die Auswirkungen sind, wenn eine Nachricht nicht richtig ankommt, d.h. verschluckt wird. Manchmal kann man das ertragen. Manchmal will man es aber eben so gut es geht vermeiden. I2C ist schon sehr praktisch, aber eben einfach nicht für Umgebungen entwickelt, die lange Strecken und potentiell Störungen haben. Natürlich gibt es ICs wie den LTC4331 oder PCA9615, mit denen das möglich ist, aber ich muß mir dann schon die Frage stellen, warum eigentlich. Anwendungen für solche Chips sind hauptsächlich I2C-Sensoren, die man irgendwo weit weg hinstecken will. I2C wurde für Fernseher entwickelt, für Autos (und andere Fahrzeuge) gibt's CAN. Na, wofür steht das C da wohl? ;)
Von einer UART-Schnittstelle auszugehen ist da glaube ich schon besser. Das ist zwar als Verbindung zwischen zwei Teilnehmern gedacht, aber wenn nur einer sendet, ist ja egal, wieviele Empfänger zuhören. Allerdings überträgt das nur Bytes, man muss also selber dafür sorgen, dass sich ein Empfänger in den laufenden Bytestrom einsynchronisieren und die an ihn adressierten Dinge herauslesen kann. Ob das praktisch robust genug gegen Störungen hinzubekommen ist, weiß ich aber auch nicht.
Das Synchronisieren macht ja glücklicherweise die UART-Peripherie. Man muß da dann eben ein Protokoll draufsetzen, da kann man aber sehr viel wählen. Die Frage ist da aber eben auch immer, wieviel man entwickeln will. Das finde ich ja bei CAN so attraktiv: Viele Dinge, die man gerne will (z.B. Fehlererkennung, CSMA/CA, uswusf.) sind da einfach schon immer mit dabei. Das macht den Controller aufwendig, aber den kaufe ich ja fertig und muß mich dann nicht mehr darum kümmern. Es ist jetzt auch technisch kein Problem, einen UART als Multi-Master-Bus zu realisieren, aber man würde da dann wahrscheinlich ein Token herumreichen, das entscheidet, wer denn nun senden darf. Ich geb's ja zu, ich bin faul und will mich ungern mit den schlimmen Hardwaredetails beschäftigen, erst recht, wenn's schon gut funktionierende Lösungen dafür gibt.
Gerade mal bei Digikey nach welchen mit AVR-Kern geschaut, da ist es billiger, einen µC und einen separaten CAN-Controller zu nehmen.
Wenn 5V-UART mit RC-Filtern funktioniert, kann man so einen Controller nehmen, der kostet ähnlich viel wie ein CAN-Controller, ist gerade 2x3mm groß und würde wohl reichen, um auf Kommandos zu horchen und 1-2 Schalttransistoren zu steuern.
Ich würde da die "neue" Attiny-Serie empfehlen (Hier eine Übersicht). Die ist einfach gut, hat auch Hardware-UART und andere nette Peripherie. Ein Attiny402 ist nur unwesentlich teurer, aber einfach so viel besser, da man ihn mit weniger Gewürge programmieren kann. Reich wird mit Velomobilzubehör niemand, und hobbymäßig kann ich mir auch tolleres vorstellen, als meine Software optimieren zu müssen, weil ich gern 10 cent sparen will. Ich bastel mir ja gerade neue Elektrik für den Milan und werde wahrscheinlich eine separate Blinkersteuerung realisieren und dafür einen der neuen Attinys nehmen. Die stehen dank großem Speicher und üppiger Peripherie meines Erachtens nach den ATMegas in nichts nach, sofern man nur "kleine" Anwendungen umsetzt. Und ja, CAN-Controller sind natürlich teuer, aber dafür kriegt man eben alle Vorteile von CAN gleich mit. Ich kann mir nicht helfen, ich bin halt Informatiker und fände es daher attraktiv, wenn man das System erweitern oder verkleinern kann, indem man Geräte mit dazuhängt oder eben abnimmt, ohne dann irgendwas neu programmieren zu müssen.
Meine Gedanken dazu sind noch nicht so 100% sortiert, das muß ich mal prototypisch aufbauen, doch zunächst kommt leider das Projekt, um die doch sehr grausame Elektrik des Milan SL Special Edition erträglich zu machen.
 
Das Synchronisieren macht ja glücklicherweise die UART-Peripherie.
Jein. Die erkennt Frames und Paritätsfehler, deshalb schrieb ich Bytestrom und nicht Bitstrom. Den Beginn einer Nachricht und die Adressierung muss man trotzdem noch selber erkennen, das ist ein Unterschied zu I²C, CAN, u.ä.
Edit: Mit sowas selbstgebratenen, aber auch mit einem "missbrauchten" I²C sollte man trotzdem die Nachrichten ständig wiederholen und nicht Änderungen (wie "Einschalten" oder "10% heller"), sondern Zustände ("Blinker ist jetzt an" oder "Scheinwerfer auf 70%") kommunizieren. Wenn was in die Hose geht, flackert ein Licht mal kurz, und mit der nächsten Nachricht ist es wieder OK.
Ich würde da die "neue" Attiny-Serie empfehlen (Hier eine Übersicht). Die ist einfach gut, hat auch Hardware-UART und andere nette Peripherie.
Stimmt, UART fehlt den sechsbeinigen Zwergen. :( Hatte ich mir falsch gemerkt.
Interessant finde ich bei denen v.a. die geringe Größe. SOIC kann man noch mit Lupe von Hand löten (SSOP zumindest ich nicht), und die fertige Platine mit Spannungsregler, µC, Transistor und etwas "Fliegendreck" bleibt trotzdem sehr klein. Ein 8-poliger µC mit CAN-Controller daneben ist schon wieder deutlich größer.
 
Mir ist gerade wieder eingefallen, wieso ich mir damals die sechsbeinigen ATTiny trotz fehlender UART angeschaut hatte: 1-Wire Da fängt jede Übertragung mit einem Reset-Puls an, und man muss sich nicht mit Clock recovery u.ä. beschäftigen.
Das ist zwar primär für Sensoren u.ä. mit geringer Leistungsaufnahme vorgesehen, aber es zwingt einen ja niemand, die Versorgung über die Datenleitung zu machen, wenn man sowieso 12V und Masse zu den Verbrauchern führt. Gibt auch fernsteuerbare Schalter wie den DS2413 dafür, allerdings ein Stück teurer als kleine ATTiny.
 
Du würdest wirklich den nackigen Chip kaufen und den Rest darum alles selber machen? :oops:
Sicher. Ich kann das, also mache ich es. Andere Leute kaufen sich einen Aluminiumblock und kriegen nachher ein Fräs- oder Drehteil raus, das ihre Anwendung erfüllt. Im Grunde nichts Anderes. Sieht erstmal kompliziert aus, ist es auch, aber man gewöhnt sich daran. Natürlich würde ich vermeiden, "alles" selber zu machen und auf möglichst viel vorhandene Funktionalität zurückzugreifen; nicht zuletzt deshalb, weil man davon ausgehen kann, daß die Sachen besser getestet sind als die Dinge, die man so für sich entwickelt. Ich muß meine Eigenentwicklung mal noch grundlegenden Komponententests durchziehen, dann kann ich auch ein wenig davon berichten.
Es ist sicher keine Lösung für alle, die V-Box funktioniert als Produkt sicherlich hervorragend, da sie in etwa so teuer ist wie eine hobbymäßige (d.h. Stundenlohn = 0) Eigenentwicklung. Der Velomobilekektrikmarkt ist so klein, daß man da kein Geld verdient, sobald man etwas von Grund auf entwickelt. Der Preis für das fertige Produkt wäre inakzeptabel hoch. Die V-Box wird sicher auch nur eine Version einer Motorradelektrik mit geänderter Software sein und daher auf diesen Preis kommen können. Aber hobbymäßig ist man an solche Wirtschaftszwänge nicht gebunden und kann das daher einfach machen.
Jein. Die erkennt Frames und Paritätsfehler, deshalb schrieb ich Bytestrom und nicht Bitstrom. Den Beginn einer Nachricht und die Adressierung muss man trotzdem noch selber erkennen, das ist ein Unterschied zu I²C, CAN, u.ä.
Äh ja, natürlich. Das habe ich falsch gelesen.
Edit: Mit sowas selbstgebratenen, aber auch mit einem "missbrauchten" I²C sollte man trotzdem die Nachrichten ständig wiederholen und nicht Änderungen (wie "Einschalten" oder "10% heller"), sondern Zustände ("Blinker ist jetzt an" oder "Scheinwerfer auf 70%") kommunizieren. Wenn was in die Hose geht, flackert ein Licht mal kurz, und mit der nächsten Nachricht ist es wieder OK.
Das ist eine praktische Lösung, elegant ist sie aber nicht. ;)
Aber natürlich alles Designentscheidungen. Dieser Ansatz würde natürlich bedeuten, daß in einem festen Zyklus der Zustand aller Knoten geschrieben wird. Der Zustand muß also zentral vorgehalten werden und gegebenenfalls kann man ja doch Fehlererkennung in die Nachrichten einbauen, daß nicht alle paar Stunden mal ein kurzer Hupton ausgelöst wird ;).
I2C kann ja durchaus über etwas längere Strecken funktionieren, wenn ich mich richtig erinnere, läuft beispielsweise in VGA- und SCART-Kabeln auch ein I2C noch mit (vielleicht auch in HDMI?).
Stimmt, UART fehlt den sechsbeinigen Zwergen. :( Hatte ich mir falsch gemerkt.
Interessant finde ich bei denen v.a. die geringe Größe. SOIC kann man noch mit Lupe von Hand löten (SSOP zumindest ich nicht), und die fertige Platine mit Spannungsregler, µC, Transistor und etwas "Fliegendreck" bleibt trotzdem sehr klein. Ein 8-poliger µC mit CAN-Controller daneben ist schon wieder deutlich größer.
Das sind natürlich Aspekte, die ich anders berücksichtige. Den SO8 löte ich ohne Lupe, interessant finde ich die größeren Attinys mit 21 I/O-Ports im 4x4mm-QFN-Gehäuse mit 0.5mm pitch. Einen externen CAN-Controller würde ich nur ungern anbinden, zumal das ja nicht ausreicht, da man noch einen Transceiver benötigt (oder einen Controller mit integriertem Transceiver kauft, die sind aber noch teurer). Viele etwas besser ausgestattete Microcontroller haben ja bereits CAN-Controller, die sind aber zugegebenermaßen nicht mehr allzu handlich, da sie meist im TQFP- oder QFN-Gehäuse kommen, üblich sind da 0.8 bis 0.5mm Kontaktabstand. Für mich ist das kein Problem, aber ich sehe natürlich, daß das sehr abschreckend sein kann, da dafür entsprechendes Werkzeug und Technik benötigt wird.

Mir ist gerade wieder eingefallen, wieso ich mir damals die sechsbeinigen ATTiny trotz fehlender UART angeschaut hatte: 1-Wire Da fängt jede Übertragung mit einem Reset-Puls an, und man muss sich nicht mit Clock recovery u.ä. beschäftigen.
Das ist zwar primär für Sensoren u.ä. mit geringer Leistungsaufnahme vorgesehen, aber es zwingt einen ja niemand, die Versorgung über die Datenleitung zu machen, wenn man sowieso 12V und Masse zu den Verbrauchern führt. Gibt auch fernsteuerbare Schalter wie den DS2413 dafür, allerdings ein Stück teurer als kleine ATTiny.
1-Wire ist eine interessante Möglichkeit, natürlich ein wenig langsam, aber zumindest hat jedes Gerät eine eigene Adresse und wenn man sich das mal programmiert hat, funktioniert es auch ganz ordentlich. Wie man sieht, gibt es tausend verschiedene Möglichkeiten, die Anforderungen zu lösen, zumal ja auch nicht einmal so klar ist, was die Anforderungen denn nun sind. ;)
 
"und fände es daher attraktiv, wenn man das System erweitern oder verkleinern kann, indem man Geräte mit dazuhängt oder eben abnimmt, ohne dann irgendwas neu programmieren zu müssen."

Das entspricht nicht unbedingt meiner Erfahrung mit CAN. Andererseits habe ich beruflich eine Reihe von Projekten auf Basis von RS485 realisiert und damit sehr gute Erfahrungen gemacht. Besonders übersichtlich und leicht zu implementieren sind Systeme mit nur einem Primary, der Takt und Timeslots auf dem Bus vorgibt. Möchte man mehrere Primaries zulassen, erhöht das die Komplexität des Protokolls. Man sollte sich also überlegen, ob man das wirklich benötigt...

Ihr redet hier schon sehr viel über technische Details der Implementierung (welchen Controller in welchem Gehäuse könnte man nehmen etc.). Ich gebe Euch recht, solche Details sind - am Ende - wichtig und man sollte ihnen Aufmerksamkeit schenken.

Trotzdem würde ich mich der Sache zunächst mal "von oben her" nähern, sprich, das Protokoll definieren.

Das kann ein sehr einfaches Request/Response Protokoll sein, d.h. der Primary sendet regelmässig Nachrichten an die einzelnen Secondaries und erwartet eine Antwort. Am Ende wertet eine Logik die Antworten aus und legt eine oder mehrere Reaktionen fest. Dies hat ggv. weitere Nachrichten zur Folge. ("Taster Licht ein gedrückt -> Nachricht an Licht").
Auf diese Zuordnung von Adressen / Adressbereichen zu Funktionen ("Hupe hat immer die Adresse 0x07", Lichttaster liegt auf 0x10 etc..) könnte man sich wahrscheinlich schon mal recht schnell einigen (und das würde ich auch als erstes machen ;) )
Da die Zuordnung fest ist, kann der Primary nach dem Einschalten alle Taster, Hupen etc. registrieren und in eine Liste eintragen.

Die möglichen Reaktionen des Primaries sollten einfach zu konfigurieren sein. Ich würde dem Primary einen uC mit USB-Schnittstelle spendieren.Bei Anschluss an einen PC (oder ein Tablet) wird ein Teil des internen Controller-Flash wie ein USB-Stick gemountet. Dann ist es möglich, dort eine Konfiguration in Form einer Textdatei oder ähnlich zu hinterlegen bzw. dort direkt zu bearbeiten.

Liegt das Protokoll einmal fest, dann kann es jeder auf dem Controller seiner Wahl programmieren.

Alle Implementierungen sollten dann ja miteinander reden können... ;)
 
Zuletzt bearbeitet:
Das kann ein sehr einfaches Request/Response Protokoll sein, d.h. der Primary sendet regelmässig Nachrichten an die einzelnen Secondaries und erwartet eine Antwort. Am Ende wertet eine Logik die Antworten aus und legt eine oder mehrere Reaktionen fest. Dies hat ggv. weitere Nachrichten zur Folge. ("Taster Licht ein gedrückt -> Nachricht an Licht").
Auf diese Zuordnung von Adressen / Adressbereichen zu Funktionen ("Hupe hat immer die Adresse 0x07", Lichttaster liegt auf 0x10 etc..) könnte man sich wahrscheinlich schon mal recht schnell einigen (und das würde ich auch als erstes machen ;) )
Da die Zuordnung fest ist, kann der Primary nach dem Einschalten alle Taster, Hupen etc. registrieren und in eine Liste eintragen.
"Alle Hupen" bedeutet, Du willst die einzeln ansprechen? Ich hätte jetzt gesagt, es reicht, wenn eine Meldung "Blinker links an" über den Bus fliegt, um alles einzuschalten, was sich für einen linken Blinker hält. Wenn dein Primary alle vorhandenen Geräte identifizieren soll, klingt das so, als ob er die einzeln bedient. Das klingt etwas umständlicher, kann aber bei der Fehlersuche helfen, weil man von jedem erwarteten Gerät eine Statusmeldung anfordern kann.
Die möglichen Reaktionen des Primaries sollten einfach zu konfigurieren sein. Ich würde dem Primary einen uC mit USB-Schnittstelle spendieren.Bei Anschluss an einen PC (oder ein Tablet) wird ein Teil des internen Controller-Flash wie ein USB-Stick gemountet. Dann ist es möglich, dort eine Konfiguration in Form einer Textdatei oder ähnlich zu hinterlegen bzw. dort direkt zu bearbeiten.
Auch die Endgeräte muss man irgendwie konfigurieren. Man will ja wahrscheinlich nicht Scheinwerfer, Blinker und Hupe nochmal mit Busanschluss neu erfinden, sondern kleine Zusatzplatinen an fertige Komponenten dranhängen, um deren Versorgung zu steuern. Davon wird's nicht viele verschiedene Typen geben. Das meiste kann man ja nur ein- und ausschalten, Scheinwerfer und Innenbeleuchtung vielleicht auch dimmen. Also muss man den Dingern irgendwie mitteilen, ob sie Blinker, Scheinwerfer, Hupe, Innenbeleuchtung oder was auch immer sind, und wenn sie mehr als nur schalten sollen, vielleicht auch noch, wie sie z.B. Prozentwerte umsetzen sollen.
 
"Alle Hupen" bedeutet, Du willst die einzeln ansprechen?
Ja, so würde ich das machen. Wenn der Primary links blinken will und in seiner Liste sieht, dass er drei linke Blinker hat, schickt er dem ersten Blinker eine Nachricht. Danach wartet er auf das "ACK" vom Blinker. Dann schickt er eine Nachricht an den zweiten Blinker usw.
Das klingt erst einmal ziemlich umständlich, ist aber sehr einfach zu programmieren (und zu debuggen, wie Du schon sehr richtig erkannt hast ;)).

P.S.: Ein Geschwindigkeitsproblem entsteht dadurch nicht. Bei z.B. 115200 Baud braucht eine Nachricht, die aus 4 Bytes besteht, 32/115200 s = 278 us. Selbst bei schnarchlangsamen 9600 Baud würde sie nur 3.3 ms benötigen.

Auch die Endgeräte muss man irgendwie konfigurieren.
Ja, das sollte man können. Z.B. über einen Dip-Switch oder ein paar kleine Lötbrücken auf der Platine.

Oder ebenfalls per Protokoll programmierbar. Dafür würde man dann ein paar extra-Kommandos reservieren. ("Setze den Typ von Endgerät #5 auf "Blinker/0x03".) Wahrscheinlich wäre es spätestens dann aber erforderlich, dass man die starre Verknüpfung von Adresse und Funktion aufgibt. Oder man reserviert jeweils Adressbereiche für die einzelnen Funktionen. Beispiel: "Alle Blinker haben eine Adresse zwischen 0x10 und 0x1F".
Das setzt für die Endgeräte voraus, dass deren uC zumindest ein paar Bytes permanent im Flash abspeichern kann. Können aber die meisten...
 
Zuletzt bearbeitet:
Ich habe bei mir, wie schon geschrieben, low power RS422/485 Treiber verwendet, ist ähnlich robust wie CAN vom physical Layer und es wird einfach seriell kommuniziert, bei mir ähnlich LIN, d.h. mit dynamischer Baudratenerkennung, dann benötigt man keinen Quarz/Resonator, das kann man auf jedem µC umsetzen, selbst auf 8048ern ;) Mit dynamischer Terminierung (wegen Stromverbrauch) und twisted Pair Kabeln hatte ich bislang noch keine Probleme (y)
 
Da sieht man halt, daß das alles keine exakte Wissenschaft ist und viele Designentscheidungen möglich sind. Nur eins ist sicher: Wie man's macht, macht man's verkehrt. ;)
Es wird mit jeder Entscheidung Dinge geben, die sich leicht umsetzen lassen und Dinge, die nervtötend schwierig werden. Wenn man Glück hat, hat man die "richtige" Entscheidung getroffen und kann alles umsetzen, was man will, ohne eines dieser nervtötend schwierigen Dinge zu erleben. ;)

Dezentrale Architekturen haben ihre Vorteile, aber natürlich auch ihre Nachteile. Ich persönlich sehe die Vorteile überwiegen, der Entwicklungsaufwand ist aber viel viel höher, da man höllisch aufpassen muß, damit das dann am Ende auch richtig funktioniert und nicht in Chaos ausartet. Natürlich spielt da auch immer eine Rolle, ob man lediglich Interesse daran hat, eine fertige funktionierende Lösung zu kriegen oder ob das Interesse gerade auch in der Überlegung zur Systemarchitektur und -Umsetzung besteht.
 
Werde da mal was detaillierteres zusammenfassen, bin allerdings gerade noch im Jahreswendstreß ;)

@nikolauzi Stimmt, Du wolltest Dein Setup ja mal etwas detaillierter beschreiben. Hatte ich da jetzt was überlesen ?

Ich habe bei mir, wie schon geschrieben, low power RS422/485 Treiber verwendet, ist ähnlich robust wie CAN vom physical Layer und es wird einfach seriell kommuniziert, bei mir ähnlich LIN, d.h. mit dynamischer Baudratenerkennung, dann benötigt man keinen Quarz/Resonator, das kann man auf jedem µC umsetzen, selbst auf 8048ern ;) Mit dynamischer Terminierung (wegen Stromverbrauch) und twisted Pair Kabeln hatte ich bislang noch keine Probleme (y)

Ich übertrage in einem anderen Projekt sehr hohe (> 8MBit/s) Baudraten per RS485 auf ner einfachen Flachbandleitung über wenige Meter. Ist vielleicht etwas leichter zu konfektionieren als Twisted Pair (einfach nur Stecker draufdrücken) .

Frage zur dynamischen Baudratenerkennung: Wie funktioniert die bei mehreren Endgeräten ? Untereinander müssten die ja schon die gleiche Baudrate haben, oder ? '

Statt einer dynamischen Terminierung (können meine Treiber nicht, glaube ich) betreibe ich RS485 mit 3.3V statt 5V. Ich schätze, dass das eine Leistungsersparnis um mehr als den Faktor 2 bringt (5/3.3)² .
 
Ja, Beschreibung hab ich verpennt, Danke für die Erinnerung;) Details kommen!
Dynamische Baudratenerkennung ist simpel: 7 Nullen+Stoppbit ergibt das Bytetiming (Capture Register), 3 mal nach rechts geschoben das Bittiming.
Nachricht besteht z.B aus 4 Bytes, Syncbyte, Servicebyte (z.B. Hupe), Optionbyte(z.B. laut/leise), Checksumme, Rückmeldung mit ACK vom Bus.
Twisted Pair ist simpel, zwei Kabelenden in den Akkuschrauber und aufdrehen.
Dynamische Terminierung: Abschlußwiderstand mit einem Kerko in Reihe, damit kein Ruhestrom fließt (y)
 
Ich find eure Ideen zu CAN Bus im VM toll! (primär theoretisch*)

Leider ist dieser Thread

Vernünftige VM-Elektrik (Ideen + Lösungen)​

benannt.

Mögt ihr bitte die Can-Bus-Nummer/Diskussion in einen eigenen Thread auslagern?


*praktisch will ich keine potentiellen Fehlerquellen in meinem VM, die ich nicht innerhalb 15-30 min (ohne Win/Mac/Linux/whatever-PC) auf nem Feldweg in der brandenburger Feldmark** beheben kann
**alternativ: JWD/in the boonies/am Arsch der Welt
 
Mögt ihr bitte die Can-Bus-Nummer/Diskussion in einen eigenen Thread auslagern?

Ich behaupte Mal frech nen paar Mikrocontroller zu programmieren ist heut definitiv für Hobbiisten machbar. Selbst wenn man da absolut keinen Plan von hat, ist das mit den Arduinos doch extrem einfach geworden.

Die Alternative sind halt immer dickere Kabelbäume, aber da gehen mittlerweile immer mehr Hobbyprojekte von weg. (Für meinen 3D Drucker gibt's zB mittlerweile nen Board das mit 4 Kabeln vom Mainboard zum Hotend geht, bei mir liegen da gerade noch 10 Kabel).

CAN ist mittlerweile als "EnergyBus" auch Standard in neueren EBikes wenn ich das richtig verstehe.

Dementsprechend würde ich glatt behaupten, dass es sich da durchaus um "Vernünftige VM-Elektrik (Ideen + Lösungen)" handelt.

Aber ... Ich hab trotzdem Mal nen neues Thema aufgemacht: https://www.velomobilforum.de/forum/index.php?threads/can-bus-im-vm.69363/
 
Zuletzt bearbeitet:
Ich behaupte Mal frech nen paar Mikrocontroller zu programmieren ist heut definitiv für Hobbiisten machbar.
Mag sein. Aber @Marc hat trotzdem Recht. Danke für den neuen Thread.
Vergleiche mit E-Bikes können, was Touren angeht, auch danebenliegen. Mit den Dingern muss man ja alle 1-2 Tage an die Steckdose, das klassische Fahrrad braucht sowas nicht. VMs, aber auch Fahrräder mit etwas Elektronik wie Navi, Handy etc., liegen wohl irgendwo dazwischen.
 
Ich find eure Ideen zu CAN Bus im VM toll! (primär theoretisch*)

Leider ist dieser Thread

Vernünftige VM-Elektrik (Ideen + Lösungen)​

benannt.

Mögt ihr bitte die Can-Bus-Nummer/Diskussion in einen eigenen Thread auslagern?


*praktisch will ich keine potentiellen Fehlerquellen in meinem VM, die ich nicht innerhalb 15-30 min (ohne Win/Mac/Linux/whatever-PC) auf nem Feldweg in der brandenburger Feldmark** beheben kann
**alternativ: JWD/in the boonies/am Arsch der Welt

Wenn es mittels RS-485 oder auch CAN-Bus gelingt, den derzeitigen Kabelverhau auf vier Leitungen einschliesslich Versorgungsspannung zu reduzieren, dann ist das ganz bestimmt ein Schritt in Richtung vernünftige VM-Elektrik. Schliesslich sinkt bei weniger Leitungen auch die Wahrscheinlichkeit von Kontaktproblemen / kalten Lötstellen etc.

Nun gibt es also einen neuen Thread zun Thema "CAN-Bus im VM", finde ich gut.

Damit auch das Thema RS-485 weiterdiskutiert werden kann, ohne das sich die nicht so Elektronik-Affinen in diesem Thread gestört fühlen, mache ich dazu auch mal einen Thread auf. Guckst Du hier: RS-485 im VM
 
Zuletzt bearbeitet:
Wenn es mittels RS-485 oder auch CAN-Bus gelingt, den derzeitigen Kabelverhau auf vier Leitungen einschliesslich Versorgungsspannung zu reduzieren, dann ist das ganz bestimmt ein Schritt in Richtung vernünftige VM-Elektrik. Schliesslich sinkt bei weniger Leitungen auch die Wahrscheinlichkeit von Kontaktproblemen / kalten Lötstellen etc.
Wow ... 2 Leitungen nach vorn und Eine nach hinten eingespart aber dafür etliche Fehlerquellen eingebaut ... kann man natürlich machen.

Wir sollten vielleicht mal die Bedeutung von -> vernüftig <- definieren.
;)

Gruß Jörg
 
Zurück
Oben Unten