Hi,
ich versuche ein Drehzahlsignal im Auto mit einem Atmega32 auszulesen.
Signal ist frequenzmoduliert mit 33,333 Hz pro 1000 Umdrehungen.
Die Drehzahl bewegt sich zwischen 600 und 7200 RPM.
Der Timer läuft mit 2 MHz.
Da ich den Timer für verschiedene Messwerte brauche, kann ich ihn nicht
resetten.
Also sieht das folgendermaßen aus:
ISR(SIG_INTERRUPT2)
{
rpm_time = TCNT1-rpm_extime+rpm_over*65536;
rpm_extime = TCNT1;
rpm_over = 0;
}
ISR(SIG_OVERFLOW1)
{
rpm_over++;
}
Nun ist das merkwürdige, dass das ganze bei Drehzahlen von ca. 1200 und
aufwärts recht gut funktioniert. Anscheinend ohne Störungen, auch bei
den overflows.
Aber sobald die Drehzahl unter 1000 fällt, kommt nur noch Schwachsinn
heraus.
Daraufhin habe ich überlegt, ob es daran liegen kann, dass TCNT1 ja
zwischen -32767 und 32768 schwankt. Das dürfte meine Formel falsch
machen. Wenn z.B. rpm_extime kurz vor dem overflow gemessen wird, hätte
es einen negativen Wert, sodass insgesamt in der Formel alle Werte
addiert würden und so ein falscher viel zu großer rauskommen müsste.
Ich bin nun total verwirrt, weil ich weder verstehe, warum der Code für
hohe Drehzahlen funktioniert noch warum er für geringe nicht
funktioniert.
Habe auch folgendes versucht:
rpm_time = (unsigned int)TCNT1-rpm_extime+rpm_over*65536;
rpm_extime = (unsigned int)TCNT1;
Hat aber auch nciht geholfen...
Hoffentlich weiß jemand Rat... bin am bekloppt werden -.-
Grüße
Slater
@Slater >ich versuche ein Drehzahlsignal im Auto mit einem Atmega32 auszulesen. >Signal ist frequenzmoduliert mit 33,333 Hz pro 1000 Umdrehungen. Komische Formulierung. Es ist schlich zwei Pulse / Umdrehung. 33,3 Hz -> 33,3 U/s = 1000 U/min >Die Drehzahl bewegt sich zwischen 600 und 7200 RPM. >Der Timer läuft mit 2 MHz. >Da ich den Timer für verschiedene Messwerte brauche, kann ich ihn nicht >resetten. Hää? >ISR(SIG_INTERRUPT2) Welcher Interrupt ist das? Externer Interrupt 2? >{ > rpm_time = TCNT1-rpm_extime+rpm_over*65536; Ich glaube hier fehlen Klamern rpm_time = TCNT1-(rpm_extime+rpm_over*65536); > rpm_extime = TCNT1; > rpm_over = 0; >} ISR(SIG_OVERFLOW1) { rpm_over++; } >Nun ist das merkwürdige, dass das ganze bei Drehzahlen von ca. 1200 und >aufwärts recht gut funktioniert. Anscheinend ohne Störungen, auch bei >den overflows. >Aber sobald die Drehzahl unter 1000 fällt, kommt nur noch Schwachsinn >heraus. Klingt nach Overflow. Siehe oben. Denn bei 2 MHz läuft dein Timer nach 32768 us = 0,032 Sekunden über. Und das sind merkwürdigerweise ~ 1000 U/min. >Daraufhin habe ich überlegt, ob es daran liegen kann, dass TCNT1 ja >zwischen -32767 und 32768 schwankt. Das dürfte meine Formel falsch Falsch, deine Timer ist vorzeichen los 0..65535. >Ich bin nun total verwirrt, weil ich weder verstehe, warum der Code für >hohe Drehzahlen funktioniert noch warum er für geringe nicht >funktioniert. Deine Overflowverarbeitung stimmt nicht. >Hoffentlich weiß jemand Rat... bin am bekloppt werden -.- Locker bleiben, Füsse hoch, Kopf tief. Wenn du alt genug dafür bist hilft ne Hopfenkaltschale ;-) MfG Falk
Slater wrote: > > Nun ist das merkwürdige, dass das ganze bei Drehzahlen von ca. 1200 und > aufwärts recht gut funktioniert. Anscheinend ohne Störungen, auch bei > den overflows. Es ist genau anders rum: Bei den hohen Drehzahlen, kommen die Pulse öfter, daher hast du fast nie einen Overflow und wenn doch, dann ist das ein Messwert unter vielen, der falsch ist. Erst wenn die Drehzahl sinkt, nimmt der Anteil der Messungen, bei denen ein Overflow beteiligt war zu. > > Aber sobald die Drehzahl unter 1000 fällt, kommt nur noch Schwachsinn > heraus. Weil dann bei jeder Messung ein Overflow im Spiel ist :-) > > Daraufhin habe ich überlegt, ob es daran liegen kann, dass TCNT1 ja > zwischen -32767 und 32768 schwankt. TCNT1 ist unsigned, hat also kein Vorzeichen. Allerdings: C-Regel eine Berechnung wird im höchsten Datentyp vorgenommen, der in der Berechnung vorkommt. rpm_time = TCNT1-rpm_extime+rpm_over*65536; Wenn rpm_over ein unsigned int ist, und davon gehe ich mal aus, dann wird dir die Berechnung rpm_over * 65536 überlaufen. Du musst die Berechnung schon als long Berechnung erzwingen rpm_over * 65536L oder gleich alle Datentypen (rpm_over, rpm_extime, etc.) auf long ändern.
Falk wrote: >> rpm_time = TCNT1-rpm_extime+rpm_over*65536; > > Ich glaube hier fehlen Klamern > > rpm_time = TCNT1-(rpm_extime+rpm_over*65536); Nach zugegebenermassen kurzer Überlegung denke ich, dass die originale Berechnung schon richtig war. Er dürfte aber mit Overflows im int-Bereich kämpfen. > Locker bleiben, Füsse hoch, Kopf tief. Wenn du alt genug dafür bist > hilft ne Hopfenkaltschale ;-) Ein Hopfblütentee ist auch nicht zu verachten :-)
Ich würde dafür übrigens den input capture interrupt benutzen.
Hi, also erstma danke, dass ihr euch Gedanken macht! Den Timer verwende ich um an insgesamt 4 Pins Signale zu vermessen -> daher kein TCNT1 = 0; möglich. Die Formel sollte wirklich soweit richtig sein. Das ich dachte, dass TCNT1 zwischen -32... uznd 32... liegt, war dann mein Fehler, weil ich sprintf geglaubt hab, bzw in sprintf %i statt %u benutzt habe... Leider sind im Moment schon alle Variablen long ... das mit dem L hinter der Konstanten werde ich gleich nochmal testen... Hab diesen ganzen Kram ansich schon probiert, aber meistens übersieht man ja immer die eine Kleinigkeit, die dann reicht, um total unnachvollziehbare Fehler zu provozieren :\
TCNT1 ist ein 16-Bit-I/O-Register und hat in dem Sinne keinen Datentyp. Ob man die darin befindlichen Daten als signed oder unsigned interpretiert, ist dem Anwender überlassen. unsigned macht nur nicht viel Sinn...
So ich hab nochmal getestet: alle Variablen long und 65536L. ich habe TCNT1 so gecasted: (long)TCNT1 - ist damit sichergestellt, dass es als positiv also unsigned interpretiert wird? Auf jeden Fall hab ich dann noch folgenden Test gemacht: Ich hab einfach die Timer Frequenz auf 16 Mhz erhöht, womit ich dann bei 1500 RPM schon 300000 Timerwerte bekomme und entsprechend viele overflows. Da aber wiederum alles über 1000 RPM wunderbar funktioniert, kann es ja nicht an den overfloes liegen. Einzige Erklärung ist für mich, dass das Signal unter 1000 RPM sprich 33 Hz gestört ist. Ich hab dummerweise im Moment kein Oszilloskop zur Verfügung :\ Ich denke mal, da das Signal vom OBD Interface kommt, dass es ursprünglich schon richtig ist. Demnach müsste es irgendwo auf dem Weg vom OBD Interface bis zum micro (2m im Auto verlegt) gestört werden, aber eben nur unter 33 Hz. Haltet ihr das für möglich?
Slater wrote: > > Haltet ihr das für möglich? > Möglich ist alles. Möglich ist auch, dass du einen Fehler im Programm hast. Da du aber leider dein Programm nicht herzeigst (*), kann das hier niemand abklären. (*) und damit meine ich das vollständige Programm, nicht nur einige Ausschnitte, bei denen man sich die Hälfte dazuerfinden muss.
Nun ist mir etwas anderes aufgefallen:
bei diesem Code braucht der Atmega32 @ 16 Mhz ewig für die 30000 frames.
Sobald ich
a_z = (((double)a_time1/16000.0-0.5)/0.04+0.6);
a_y = (((double)a_time2/16000.0-0.5)/0.04);
auskommentiere, ist er so schnell wie normalerweise. Ich weiß aber, dass
es auch mit der Fließkommaberechnung schonmal normal schnell lief! Sehr
komisch...
#include <avr/delay.h>
#include <avr/pgmspace.h>
#include "lcd.h"
#include "helpers.h"
#include "button.h"
#include "sd_raw.h"
char cur_line1[17] = " ";
char cur_line2[17] = " ";
double a_z = 0.0;
double a_y = 0.0;
volatile char a_over1 = 0;
volatile char a_over2 = 0;
volatile unsigned int a_time1 = 0;
volatile unsigned int a_time2 = 0;
volatile unsigned int a_extime1 = 0;
volatile unsigned int a_extime2 = 0;
int frame = 0;
ISR(SIG_INTERRUPT0)
{
if(MCUCR & (1<<ISC00))
{
a_extime1 = TCNT1;
a_over1 = 0;
MCUCR &= ~(1<<ISC00);
}
else
{
a_time1 = TCNT1-a_extime1+a_over1*65536;
MCUCR |= (1<<ISC00);
}
}
ISR(SIG_INTERRUPT1)
{
if(MCUCR & (1<<ISC10))
{
a_extime2 = (long)TCNT1;
a_over2 = 0;
MCUCR &= ~(1<<ISC10);
}
else
{
a_time2 = TCNT1-a_extime2+a_over2*65536;
MCUCR |= (1<<ISC10);
}
}
ISR(SIG_OVERFLOW1)
{
a_over1++;
a_over2++;
vx_over++;
rpm_over++;
}
int main(void)
{
lcd_off();
lcd_init();
lcd_cmd(LCD_DISP_ON);
sei(); // interrupts aktivieren
// Beschl. messung
TIMSK |= (1<<TOIE1);
TCCR1A = 0x00;
TCCR1B = 1<<CS11;
DDRD &= ~( 1 << PD2 );
DDRD &= ~( 1 << PD3 );
PORTD |= ( 1 << PD2 );
PORTD |= ( 1 << PD3 );
GICR |= (1<<INT0) | (1<<INT1);
MCUCR |= (1<<ISC10) | (1<<ISC11);
MCUCR |= (1<<ISC00) | (1<<ISC01);
while (1)
{
cli();
a_z = (((double)a_time1/16000.0-0.5)/0.04+0.6);
a_y = (((double)a_time2/16000.0-0.5)/0.04);
sei();
char temp[16];
char temp2[16];
if(frame > 30000)
{
sprintf(temp,"%0.3f %0.3f ",a_z,a_y);
sprintf(temp2,"%u %u %i ",a_time1,a_extime1,a_over1);
LCD_update(temp2,temp,&cur_line1,&cur_line2);
frame = 0;
}
else
frame++;
}
return 0;
}
Optimierung eingeschaltet? Der Cast nach (long) macht übrigens eine vorzeichenbehaftete Zahl draus. Das willst du nicht. Du willst nach (unsigned long) casten, oder nimm gleich (uint32_t) aus <stdint.h> für alles.
Hi, ich hab jetzt herausgefunden, dass die ungenauigkeit der Messungen daran liegt, dass der Prozessor mit der Berechnung der beiden double überfordert ist. WEnn ich die Berechnung weglasse, sind auch die Messungen genau. Bleibt die Frage, warum die Berechnung so lange dauert. Wielange dürfte denn a_z = (((double)a_time1/16000.0-0.5)/0.04+0.6); a_y = (((double)a_time2/16000.0-0.5)/0.04); dauern? Die Framerate wird bei mir mindestens um den faktor 300 gesenkt.
@Slater >a_z = (((double)a_time1/16000.0-0.5)/0.04+0.6); >a_y = (((double)a_time2/16000.0-0.5)/0.04); 4 Divisionen und 3 Subtraktionen/Additionen. Schon mal simuliert? MFg Falk
selbst wenn ich eine einzige Dummy Division mache, merkt man das schon deutlich an der Framerate... das kann doch nicht normal sein oder?
Welche Framerate? Mitungeeigneter Programmierung kann alles mögliche passieren. MFG Falk
Also, wenn du mit frame-rate die Durchlaufzeit der while-schleife meinst, und in der mal die Berechnung von a_z auskommentierst, dann bleibt genau
1 | while(1) |
2 | {
|
3 | cli(); |
4 | sei(); |
5 | if(frame > 30000) |
6 | {
|
7 | }
|
8 | else
|
9 | frame++; |
10 | }
|
übrig. Ich hab jetzt hier keine Compiler zur Hand, aber das dürfte in Summe so um die 15 Assemblerbefehle ergeben. Eine double-Division braucht da einge Grössenordnungen mehr. Natürlich läuft das Programm damit viel langsamer. Oliver
Jo stimmt... habe das Problem mit der Auslastung gelöst in dem ich nur entpsrechend selten die Werte berechne - klappt nun. Zurück zu dem Ursprungsproblem: Signal wird nicht richtig gelesen unter 1000 RPM / 33 Hz Hab folgende Entdeckung gemacht: Habs mir heute mit nem Oszi angesehen und war in Ordnung. Dann hatte ich zufällig Oszi und Microcontroller gleichzeitig dran und siehe da alles wunderbar auch im Micro. Sprich irgendwie der Widerstand oder die Kapazität des Oszis haben das Signal so gefiltert, dass es hinkommt. Ich hab leider nicht genug Ahnung um nun zu sagen, was genau die Filterung erzeugt... Vielleicht kann mir da ja jemand von euch weiterhelfen... Is nen uraltes Röhrenoszi. Grüße Slater
Hmm Kondensator als Tiefpassfilter für bis ca. 300 Hz mit 20n müsste doch gehen oder? Ich weiß nur leider nicht was für eingangsfilter das oszi hat...
@Slater >Hmm Kondensator als Tiefpassfilter für bis ca. 300 Hz mit 20n müsste >doch gehen oder? RC-Filer, fehlt noch das R. >Ich weiß nur leider nicht was für eingangsfilter das oszi hat... Der hat keinen Filter, wohl aber ne Eingangskapazität. Wahrscheinlich has du mit nem 1:1 Tastkopf gemessen, da kommen so ca. 150 pF zusammen (die dann parallel am Eingang vom AVR hängen). MFG Falk
Hi, jo die Eingangskapazität meinte ich. Der Kopf war auf 1:1 soweit das bei dem alten Teil noch wirklich hinkommt. Allerdings hatte ich das Signal nich vorne an der Spitze sondern an ner Krokodilklemme die seitlich an dem Kopf is... ich hatte testweise mal 100n (viel zu viel) und 22p parallel zum avr eingang auf ground geschaltet... im ersten Fall kein Signal mehr logisch und im zweiten keine Änderung... Hab im Mom leider keine Kondensatorenauswahl hier -.- Aber theoretisch müsste ich doch mit 10n - 20n richtig liegen oder? Bei einer maximalen Frequent von 250 Hz.
@Slater >Aber theoretisch müsste ich doch mit 10n - 20n richtig liegen oder? Bei >einer maximalen Frequent von 250 Hz. Du brauchst noch einen Vorwiderstand! 1K-10k Dann kanst du über f = 1/(2*Pi*R*C) das auf ungefähr 200-500 Hz trimmen (ein paar kHz sollten auch gehen, es sind wahrscheinlich "nur" ein paar unsaubere Flanken) MFG Falk
Hi, jo hab inzwischen entdeckt, dass auf dem Oszi ja steht was für einen Eingangswiderstand es hat: 1 MOhm und 40 pF Habe nun mir einen Hochpass gebaut mit 33 pF und 1,2 MOhm. Es hilft zwar schon minimal, aber jetzt misst er meistens eine Drehzahl von ca. 1500 wobei die echt von 800 auch ab und zu gemessen wird. Ich versteh einfach nicht, wo nun der Unterschied zu der Filterung des Oszilloskops liegt... das Oszi ist übrigens auf Wechselstrom eingestellt, daher wohl die Hochpass Filterung. Bald dreh ich durch... jetzt sitz ich schon seit 3 Tagen an dem Problem :( Grüße Slater
Angehängte Dateien:
-
tiefpass.png
1,6 KB
@Slater >1 MOhm und 40 pF Normal. >Habe nun mir einen Hochpass gebaut mit 33 pF und 1,2 MOhm. Es hilft zwar AHHHHH! Was soll das denn nun wieder? Waren wir nicht schonmal beim TIEFpass? 1k Ohm und 100pF...10nF sollten es tun. Und auch noch die hohen Drehzahlen durchlassen. >Bald dreh ich durch... jetzt sitz ich schon seit 3 Tagen an dem Problem >:( Was kein Wunder ist, dir fehlen die Grundlagen. Tut mir leid, ist aber so. Siehe Anhang. MFG Falk
Richtig wir waren beim Tiefpass - da aber anscheinend der Hochpass des Oszis hilft, hab ich natürlich versucht diesen zu bauen. Einen Tiefpass habe ich auch schon ausprobiert. Hilft auch nicht. Viel Erfahrung habe ich in der Tat nicht - beschäftige mich mit Elektronik erst seit einem halben Jahr... Aber vielleicht kannst du ja mal analysieren, warum das Oszi als Filter funktioniert: Erdungsklipp (!) ist also an Signalquelle (Kabel) angeklemmt. Micro normal dran. Oszi auf AC Kopplung. -> Signal wird von Micro wunderbar gemessen. Stecker von Tastkopf aus oszi rausziehen -> Micro hat wieder Messfehler.
@Slater >Richtig wir waren beim Tiefpass - da aber anscheinend der Hochpass des >Oszis hilft, hab ich natürlich versucht diesen zu bauen. Ohne Grundverständnis wird das nix. >Einen Tiefpass habe ich auch schon ausprobiert. Hilft auch nicht. Dann liegt das Problem wahrscheinlich woanders. >Erdungsklipp (!) ist also an Signalquelle (Kabel) angeklemmt. Micro Was heisst an der Signalquelle? Am SIGNAL selber? Oder am Masseanschluss an der Signalquelle? Ich hoffe du hast zwei Kabel (Adern) von der Signalquelle zum uC. Masse und Signal. >normal dran. Oszi auf AC Kopplung. -> Signal wird von Micro wunderbar >gemessen. >Stecker von Tastkopf aus oszi rausziehen -> Micro hat wieder Messfehler. Klingt nach Masseproblem. Mfg Falk
Nein hab nur eine Ader - hab zwar auch die Automasse, aber fürchte das bringt nicht viel... bei den Signalen im Auto bekommt immer nur das Signal, Masse ist halt die Karosserie. Der Erdungsklipp war tatsächlich am Signal selber. Merkwürdigerweise konnte ich das Signal auf diese Weise auch besser mit dem Oszi messen. Könnte daran liegen, dass der Tastkopf noch aus UDSSR Zeiten vll nicht mehr so ganz richtig arbeitet...
@Slater >Nein hab nur eine Ader - hab zwar auch die Automasse, aber fürchte das >bringt nicht viel... bei den Signalen im Auto bekommt immer nur das >Signal, Masse ist halt die Karosserie. AHHHH, wusste ichs doch! Tu dir einen Gefallen und zieh eine zweite Ader mit Masse vom Controller zum Sensor. Am besten ein zweiadriges geschirmtes Kabel. Gerade im KFZ ist so ziemlich alles EMV-verseucht. Und bau den Tiefpass wieder ein, du wirst ihn brauchen. >Der Erdungsklipp war tatsächlich am Signal selber. Merkwürdigerweise Aua! >konnte ich das Signal auf diese Weise auch besser mit dem Oszi messen. Häää? Wenn der Erdungsclip auf dem Signal selber hängt, wo hast du dann den Tastkopf angeschlossen? >Könnte daran liegen, dass der Tastkopf noch aus UDSSR Zeiten vll nicht >mehr so ganz richtig arbeitet... Nene. Du hattest mehr Glück als Verstand. Sorry, das musste jetzt sein. Durch die AC-Kopplung hast du wahrscheinlich einen Kurzchluss des Signals verhindert. Ich sags immer wieder! Grundlagen, Grundlagen, Grundlagen! Gerade im HighTec Zeitalter, wo viele denken das Ohmsche Gesetz hätte ausgedient. MfG Falk
Hehe ^^ mehr Pech als Verstand aber auch... Also Tastkopf ist nirgendwo angeschlossen! Nur der Erdungsclip - ich hab mich selber gewundert, dass das funktioniert hat!! Es gibt keinen Sensor. Es gibt lediglicht eine Steckerbuchse, an der alles möglich ankommt. Ich kann an der ganzen Verkabelung ohne riesigen Aufwand auch leider nichts mehr ändern. Einzige Möglichkeit is also Filterung. Mit dem Oszi klappts ja, sprich irgendwie muss es möglich sein. Frage ist noch wie. Kann es sein, dass, wenn man sinnloser weise so wie ich den Erdungsclip als Tastspitze missbraucht, das ganze Tastkabel inkl. Tastkopf etc. und AC Hochpass des Oszis als Bandfilter wirken?
@Slater >Es gibt keinen Sensor. Es gibt lediglicht eine Steckerbuchse, an der >alles möglich ankommt. Und sicherlich ist auch ein Pin davon Masse. Such mal. > Ich kann an der ganzen Verkabelung ohne riesigen >Aufwand auch leider nichts mehr ändern. Einzige Möglichkeit is also >Filterung. Du bist gerade dabei, eine verdammt faulen Kuhhandel einzugehen. Sei gewarnt! Was du auf jeden Fall brauchst ist ne Masseverbindung. Und zwar ne ordentliche. Ideal ist ein zweiadriges Kabel mit Masseanschluss am Sensor. Zweitbeste Möglichkeit ist ein Masseanschluss nahe dem Sensor an der Karosserie. Schlechteste Wahl ist Masseverbindung zur Karosse am uC (und damit weit weg vom Sensor). >Kann es sein, dass, wenn man sinnloser weise so wie ich den Erdungsclip >als Tastspitze missbraucht, das ganze Tastkabel inkl. Tastkopf etc. und >AC Hochpass des Oszis als Bandfilter wirken? Ne, als Masseverbindung. MFG Falk
Aber ehrlichgesagt versteh ich noch nicht, was daran falsch sein soll, einfach die Filterung, die das Oszi bewirkt nachzubauen... Denn ein Massekabel kann ich definitiv nicht verlegen aus verschiedenen Gründen. Die ganze Sache wird auch designtechnisch verbaut und das ist alles shcon gelaufen - da kann ich leider garnix mehr ändern. Das muss irgendwie gehen! ^^ Es ist ja auch nicht so, dass ich garkein Signal bekommen würde...
@ Slater >lichgesagt versteh ich noch nicht, was daran falsch sein soll, >einfach die Filterung, die das Oszi bewirkt nachzubauen... Denn ein DU weisst aber nicht, WIE das Oszi hier wirkt. Und ICH kann es aus der Distanz nicht genau sagen. Dazu müsste ich vor Ort sein und mir die Sache anschauen. >Massekabel kann ich definitiv nicht verlegen aus verschiedenen Gründen. Du musst zumindest vom uC eine Masseverbindung zur Karrosserie schaffen. Ohne das geht GAR NIX, egal wieviel gejammert wird. Ein Draht ist kein Lichtleiter, da braucht man schon HIN- und RÜCKleiter. Heisst ja schliesslich auch StromKREIS! Wie wird die Schaltung denn versorgt? Aus dem Bordnetz? Dann hast du ja ne Masseverbindung. Ich hoffe du hast einen GUTEN Filter in die Spannungsversorgung gebaut. >Die ganze Sache wird auch designtechnisch verbaut und das ist alles >shcon gelaufen - da kann ich leider garnix mehr ändern. Du wirst, wenn der Schmerz gross genug ist. ;-) >Das muss irgendwie gehen! ^^ Es ist ja auch nicht so, dass ich garkein >Signal bekommen würde... McMurphy verarscht dich. MFG Falk
Also ich bin grad noch dabei das Gehäuse fertigzustellen - morgen kommt da alles rein und dnan läuft die Spannungsversorgung des µc auch über das Autonetz, sprich Masse is dann auch Automasse. Außerdem sind Kabel kürzer - mal sehen, ob sich was verändert.
So, du hattest Recht: Ich hab mehr Glück als Verstand - nachdem ich alles schön verbaut habe und sich somit die Kabellängen minimiert haben, sind alle Probleme verschwunden! :D
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.