www.mikrocontroller.net

Forum: Compiler & IDEs 16 Bit Timer


Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde dafür übrigens den input capture interrupt benutzen.

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :\

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur nochmal zur Sicherheit: TCNT1 ist also ein unsigned short int ?

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, signed macht natürlich nicht viel Sinn...

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
}

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
selbst wenn ich eine einzige Dummy Division mache, merkt man das schon 
deutlich an der Framerate... das kann doch nicht normal sein oder?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Framerate? Mitungeeigneter Programmierung kann alles mögliche 
passieren.

MFG
Falk

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
while(1)
{
  cli();
  sei();
  if(frame > 30000)
  {
  }
  else
     frame++;
}
ü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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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


Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Slater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.