VM-Bordelektrik mit Arduino

RaptoRacer · 29.03.2018

Hallo,

ich mache mal einen neuen Thread auf damit das Threadthema besser zum Inhalt passt:

Wolfgang ( @Gear7Lover ) hat eine schöne Bastelarbeit mit dem Arduino gemacht:
https://www.velomobilforum.de/forum...ung-am-pc-entwickeln.44145/page-2#post-903104

Es ist zwar etwas mit Kanonen auf Spatzen geschossen, aber eine schöne Sache sich mit dem Arduino auszutoben.

Ich habe mir jetzt mal zum Arduino Uno noch einen Nano besorgt und werde mal versuchen diese Seriell (war die Empfehlung von @Reinhard https://www.velomobilforum.de/forum...ung-am-pc-entwickeln.44145/page-3#post-903521 ) zu verbinden und dann ein Lämpchen anszusteueren.

Im Gegensatz zu Wolfang würde ich eher nur mal das nacherstellen wollen was ein Quest kann.
Mehr kann man dann schauen.

Tschö
René

RaptoRacer · 31.03.2018

Grad wegen eigener Dämlichkeit einen Nano gebrezelt....

Das Blink Programm hab ich aber schon mal zum Laufen bekommen,
hatte aber etwas Probleme von der IDE Programm zu dem China-Nano hochzuladen.

Heiko · 01.04.2018

Moin Rene,
ich klinke mich mal mit ein. Habe mich bisher nur in den Arduino eingearbeitet. Habe alles zu Hause liegen und auch genug Erfahrung im Programmieren.
Kannst du beschreiben, was das Quest kann/macht? Wie es ausgestattet ist?
4 Blinker ist klar... Bedienbar über einen Kippschalter mit drei Stellungen (Mitte=kein Blinken) ?

Grüße
Heiko

RaptoRacer · 01.04.2018

Hallo Heiko,
dann sind wir ungefähr auf dem gleichen Stand...

Quest kann:
Licht an/aus
Tagfahrlicht an/aus (wobei mir das nicht wichtig wäre)
Bremslicht an/aus
Blinker links/rechts
Hupe
Innenraumbeleuchtung (könnt ich auch drauf verzichten)

Also weit weniger als @Gear7Lover in seine Schaltung integriert hat.
Ich würde auch erstmal mit der Programmierung des Seriellen Bus anfangen,
da ich vermute, das dieser die Programmierung deutlich ändert und und man die LEDS vermutlich nicht über PWM vom HauptArduino ansteurn sollte.

Derzeit denke ich : Ein HauptArduino zum ansteuern und 2 Neben Arduinos für Schalten der Lichter vorne und hinten.
Ich habe mir zu meinem UNO diese Nano's bestellt:
https://www.amazon.de/gp/product/B0713ZRJLC/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1

Ich würde auch mal prüfen inwieweit man Entfernungen mit dem Arduino messen kann.
Bei Entfernungen von unter 1m könnte dann ja eine Hupe anspringen

Heiko · 02.04.2018

Tach,
habe eben RJ45-Buchsen mit Kabeln dran und auch nur zum Löten bestellt. Damit kann ich dann mal eine RJ45-Strecke zwischen einem Nano und dem normalen Arduino aufbauen und mir die serielle Kommunikation angucken. Was ich bisher an Code gesehen habe, war nicht wirklich wild. Reinhard hatte da auch schon was verlinkt. Ich habe aber auch noch das dicke Buch zum Arduino liegen. Da schau ich auch nochmal rein.
Ich würde von den 8 Litzen einer RJ45-Verbindung die Stromversorgung über jeweils zwei Litzen führen. Dann sind vier weg. Die anderen 4 sind dann für RS232. Man braucht nur drei, also ist eine übrig. Paßt doch ganz gut?!

Grüße
Heiko

Heiko · 02.04.2018

So in etwa?

RaptoRacer · 02.04.2018

Hallo Heiko,

Dann guck mal wieviel Querschnit du zb für Hupe oder Frontlicht benötigst, mit 2 Ampere benötigst.
Das würde ich nicht über ein Netzwerkkabel ansteuern.
Absolutes Minimum sind denke ich 0,5mm^2.
Mein erstes Q16 hatte RJ45, ich habe das ausgebaut.
Daher ja die serielle Schnitstelle mit 2 Datenleitungen zb 0,14mm^2 und 2 Strom- Schaltleitungen mit 0,75mm^2

Ich musste aber auch heute wieder feststellen, das ich viel vom Arduino vergessen habe.
Letztes mal intensiv ausprobiert ist schon 2 Jahre her.

Tschö
René

Heiko · 02.04.2018

RaptoRacer schrieb:
Dann guck mal wieviel Querschnit du zb für Hupe oder Frontlicht benötigst, mit 2 Ampere benötigst.

0.14mm^2 hat pro Meter einen Widerstand von 0.12Ohm (Klick).

Bei 2A macht das einen Spannungsabfall von U=R*I=0.12*2A=0.24V. Bei Verwendung von zwei Litzen sind das nun noch 0.12V. Finde ich nicht dramatisch. Aber ok. Wenn Du mehr nehmen möchtest: Willst Du dann zwei Kabel verlegen? 1x 3-adrig für RS232 und 1x 2-adrig für Power?
Wäre natürlich irgenwie nett, wenn man das in einem Leiter hätte. Muss ich mal gucken, ob es sowas gibt.

Grüße
Heiko

RaptoRacer · 02.04.2018

Hier kommt die Seite auf einen Spannungsabfall von 8,5% bei 2A, 12V, 2m länge und 0,14er Leitung
https://campofant.com/kabelquerschnitt-leitungsquerschnitt-berechnen/
Ok soviel Watt wird man nicht dauernd haben, aber der Leitung sollte schon Blinker, Hupe und Frontlampe zusammen verkraften ohne zu schmelzen.

0,5mm^2 sollte man denke ich schon nehmen.
Aber beim Kabel ist man ja frei auch was dünneres zu nehmen.

Und ja ich hatte an 2Kabel gedacht, Datenkabel 2 dünne Adern und Stromkabel 2 dickere Adern.
Ich denke mal sowas gibt es nicht fertig zu kaufen.

Gerade eben habe ich vergeblich versucht Einen String von einem Arduino zum anderen zu schicken.
Vermutlich mache ich was bei der Stringverarbeitung falsch. C ist da ja etwas sperrig.

Heiko · 03.04.2018

Ich baue das nach der Arbeit mal auf. Melde mich am Abend wieder. Das Proggen bekommen wir schon hin.

Gear7Lover · 03.04.2018

2A auf 0.14mm^2 ist ein bisschen grenzwertig was das überhitzen betrifft. Vor allem bei mehradrigen Kabeln könnte das schief gehen.

Du willst nicht wirklich RJ45 Stecker verwenden, oder?

Heiko · 03.04.2018

Gear7Lover schrieb:
2A auf 0.14mm^2 ist ein bisschen grenzwertig was das überhitzen betrifft. Vor allem bei mehradrigen Kabeln könnte das schief gehen.

War nur eine Idee, weil ich dachte, dass René sich das so vorstellte. Hat sich aber mittlerweile geklärt (s.o.).

Gear7Lover schrieb:
Du willst nicht wirklich RJ45 Stecker verwenden, oder?

Mir ist egal, wer was an Kabeln und Steckern verwendet. Das kann ja auch jeder für sich frei wählen. Ich habe aktuell auch gar kein VM. Für den Laboraufbau werde ich schauen, wie ich es verdrahte. Erstmal "easy" anfangen. Mir geht es mehr um die Programmierung.
Im VM könnte ich mir auch MPX-Stecker vorstellen (Klick). Immerhin 6-polig, verpolungssicher, recht stramm und im Modellflug seit Jahren für Ströme bis kurzzeitig 30A bewährt (dann über drei Pole).

Grüße
Heiko

Gear7Lover · 03.04.2018

Heiko schrieb:
im Modellflug

gibt es keine salzhaltige korrosive langanhaltende Nässe. Aber ja, das wären nur Spielverderber des Hauptthemas.

RaptoRacer · 03.04.2018

Heiko schrieb:
Das Proggen bekommen wir schon hin.

Das denke ich auch. C ist aber schon so 20 Jahre her.
Und das was ich jetzt programmiere hat gar nichts mit Mikrokontroller zu tun.
..mitlerweile kann man sich ja auch aus dem Internet viel 'klauen'.
Problematischer ist eher die Zeit zu finden...

Heiko · 03.04.2018

Der erste Durchschuss ist fertig. Mein UNO sendet ein "A" und danach ein "\n" (Newline) an den Nano. Dieser zeigt den Empfang mit dem Aufblinken der LED an. Aufbau:

Wichtig!! : Beide Arduinos müssen von der seriellen Schnittstelle zum PC getrennt werden. Der UART kann nur den PC bedienen (z.B. zum Hochladen der Software) oder die PINs!

Bei meinem UNO sieht man, dass das USB-Kabel nicht steckt. Stromversorgung über Hohlstecker.
Bei meinem Nano steckt zwar ein USB-Kabel, aber dieses kommt lediglich von der kleinen Powerbank rechts oben im Bild. Also auch nur Versorgung!

RX und TX gehören natürlich gekreuzt.

Der Code auf dem UNO (Sendeseite):

Code:

int LED=13;  // Status-LED auf dem Board

void setup() {
  pinMode(LED, OUTPUT);
  Serial.begin(9600); 
}


void loop()  {
  digitalWrite(LED, HIGH);
  Serial.print("A");
  Serial.print("\n");
  delay(2000);
  digitalWrite(LED, LOW);
  delay(2000);
}

Und der Code auf dem Nano (Empfangsseite):

Code:

int LED=13;  // Status-LED
String inputString = ""; // a string to hold incoming data
boolean stringComplete = false; // whether the string is complete + expand sourceview plain

void setup() {
  pinMode(LED, OUTPUT);
  Serial.begin(9600); // initialize serial
  inputString.reserve(200); // reserve 200 bytes for the inputString
}

void loop() {
  // print the string when a newline arrives:
  if (stringComplete) {
    digitalWrite(LED, HIGH);  // mit Hilfe der LED anzeigen, dass was angekommen ist
    inputString = "";     // clear the string
    stringComplete = false;
    delay(1000);
    digitalWrite(LED, LOW);
  }
}


/*
  SerialEvent occurs whenever a new data comes in the
  hardware serial RX. This routine is run between each
  time loop() runs, so using delay inside loop can delay
  response. Multiple bytes of data may be available.
*/
void serialEvent() {
  while (Serial.available()) {
    char inChar = (char)Serial.read();  // get the new byte:
    inputString += inChar;  // add it to the inputString:

    // if the incoming character is a newline, set a flag
    // so the main loop can do something about it:
    if (inChar == '\n') {
      stringComplete = true;
    }
  }
}

Wie sieht das Ergebnis aus?
UNO: Beim Senden geht die LED auf dem Board an und bleibt 2sek an. Dann wird sie für 2sek ausgeschaltet.
NANO: Beim Empfangen leuchtet die LED auf dem Board für eine Sekunde.

Bitte Rückmeldung, wenn es bei dir funktioniert, René!
Wenn nicht, dann keine Rückmeldung

Grüße
Heiko

RaptoRacer · 04.04.2018

Heiko schrieb:
Wichtig!! : Beide Arduinos müssen von der seriellen Schnittstelle zum PC getrennt werden. Der UART kann nur den PC bedienen (z.B. zum Hochladen der Software) oder die PINs!

OK, das allein war schon bei mir nicht der Fall....
Danke auch fürs Coding!

Heiko · 04.04.2018

Gerne!
Nächster Punkt wäre sicherlich, die Datentelegramme festzulegen. Grundsätzlich würde ich nicht den Weg wählen, direkt den Soll-Zustand eines Lämpchens (z.B. Blinker) zu senden. Ich würde eher die Betriebsarten senden (z.B. "Blinken links", oder "Warnblinker"). Was dann am Nano für diese Betriebsart angesteuert wird, ist damit erstmal egal. Das sorgt für eine gewisse Kapselung der einzelnen Aspekte. Außerdem reduziert das den Datenverkehr ungemein, weil immer nur bei Betriebsartenwechsel ein update gesendet werden muss.
Ich überlege mir mal ein Beispiel und poste es dann.

Grüße
Heiko

Nobbi · 04.04.2018

Heiko schrieb:
Ich würde eher die Betriebsarten senden

Wenn es wirklich synchron blinken soll müssten dann alle Blinker einer Seite am gleichen Arduino hängen. (ok, ein paar ms Versatz sind vermutlich irrelevant)
Was wichtiger ist: nur die Statusänderungen zu übertragen setzt eine verlässliche Verbindung vorraus (oder man muss alle Messages Quittieren, so á la TCP). Kann man natürlich auch selber implementieren, aber ob sich der Aufwand lohnt?

Heiko schrieb:
Ich überlege mir mal ein Beispiel und poste es dann.

Am einfachsten ist immer noch nichts neues zu erfinden, sondern ein schon vorhandenes Protokoll verwenden. Wie oben schon erwähnt z.B. Modbus. Ist eigentlich genau für so einen Anwendungsfall entworfen (Steuerung von über serielle Schnittstellen vernetzten Geräten, stammt noch aus der Zeit bevor TCP/IP über Ethernet Mainstream wurde). Muss man ja nicht über die eigentlich dafür vorgesehenen Spannungspegel und Stecker über tragen, eine direkte serielle Verbindung tut's genauso. Und fertige Libraries gibt's auch dafür auf denen man direkt aufsetzen kann.

TimB · 04.04.2018

RaptoRacer schrieb:
zusammen verkraften ohne zu schmelzen.

Daumenregel von unseren Hardwerkern: Dauerstrom nicht über Querschnitt * 10 A/mm². 0,14 mm² sollten also nur 1,4 A Dauerstrom sehen. Kurz mal hupen ist nicht schlimm.
Ah, hier ne Tabelle:

Code:

Leiterquerschnitt mm²    max. Widerstand je Meter mm n/mm    zul. Dauerstrom bei +30°C in A    zul. Dauerstrom bei +50°C in A
1                        18,5                                19                                13,5
1,5                        12,7                                24                                17
2,5                        7,6                                    32                                22,7
4                        4,71                                42                                29,8
6                        3,14                                54                                38,3
10                        1,82                                73                                51,8
16                        1,16                                98                                69,6
25                        0,743                                129                                91,6
35                        0,527                                158                                112
50                        0,368                                198                                140
70                        0,259                                245                                174
95                        0,196                                292                                207
120                        0,153                                344                                244

Ist jetzt eher für die Leute mit echten Stromstärken (tm)

Ich hab bisher nur einmal was zum Schmelzen gebracht: Absichtlich zur Abschätzung einer Gesamtstromtragfähigkeit eines Stecksystems. 105°C Umgebungstemperatur, 7,5A pro Pin bei 52 Pins (390 A) hats die Daisychainprototypenplatine ausgelötet.

Gruß,

Tim

RaptoRacer · 04.04.2018

Heiko schrieb:
. Ich würde eher die Betriebsarten senden (z.B. "Blinken links", oder "Warnblinker").

Sehe ich auch so

Nobbi schrieb:
Wenn es wirklich synchron blinken soll müssten dann alle Blinker einer Seite am gleichen Arduino hängen. (ok, ein paar ms Versatz sind vermutlich irrelevant)
Was wichtiger ist: nur die Statusänderungen zu übertragen setzt eine verlässliche Verbindung vorraus (oder man muss alle Messages Quittieren, so á la TCP). Kann man natürlich auch selber implementieren, aber ob sich der Aufwand lohnt?

Naja einen Tod wirst du sterben: Entweder immer die Zustände übertragen oder die Betriebsart setzen und wenn nötig kontrollieren....

Nobbi schrieb:
Am einfachsten ist immer noch nichts neues zu erfinden, sondern ein schon vorhandenes Protokoll verwenden. Wie oben schon erwähnt z.B. Modbus. Ist eigentlich genau für so einen Anwendungsfall entworfen (Steuerung von über serielle Schnittstellen vernetzten Geräten, stammt noch aus der Zeit bevor TCP/IP über Ethernet Mainstream wurde).

Ja so eine Protokoll ist schon sinnvoll. Evtl in kürzerer Form.
Allerdings ist das, wenn ich das richtig verstehe, nur das Protokoll und nicht die Art und Weise wie du die übertragenen Daten händelst.