24V 1ms Impuls verlängern

Wenn es um robuste störsichere Auswertung geht kann man mit einem transistor und einen widerstand einen kondensator entladen, zeitkonstante 0.25ms und dann mit einem weiteren R aufladen, zeitkonstante 50ms Das ganze dann per adc mit 10 khz sampeln

Das wäre eine sehr robuste störsichere lösung bei der man viel lernen kann

Andernfalls was auch gut ist, interrupt auslösen mit fallender flanke und dann den digitalausgang mit z.B 8 khz 10 mal hinzereinander abfragen

Wenn dann die mehrheit low ist als puls erkannt, das ganzen kann man mit einem tiefpass mit 2-5us zeitkonstante noch entstören, ist auch sehr robust

Eine weitere lösung ist den digitaleingang permanent zu sampeln, wieder z.b 10khz und mittels ringspeicher länge 10 den gleitenden mittelwert zu berechenen, bzw auf integer level die summe, für digital high wäre die 10 und für low 0, fällt der wert unter 3 oder 4 ist low erkannt

Für den fall, das dein code für einen schleifendurchlauf länger als 1 ms benötigt, was durchaus sehr wahrscheinlich ist

Die robuste und rechenzeitoptimierze lösung wäre z.B mittels tomerinterrupt den eingang mit 16 khz abzufragen und einen ringbuffer mit 16 speicherplätzen anzulegen, für den summe schaut man immer wie der älteste wert war und entfernt den aus der summe und addiert den neuesten dazu, wenn man von low aktiv für das klappensignal ausgeht, dann wäre 16 klappe zu, und wenn sie öffnet läuft der bis 0 und dann wirder hoch, legst du die schwelle z.B bei 6, dann würde man bei diesem wert ein flag setzen, klappe auf, das passiert alles in der timerinterruptroutine

Wenn du in deiner programmschleife das flag abfragt, wirst du wenn es aktiv ist in die entsprechende routine springen, und auch gleichzeitig das flag zurücksetzen, das ist dann wie die angefragte pulsverlängerung, nur besser/eleganter

Was beim programmieren hilft und fast fertigen code für die interruptroutine bereitstellt ist auch chatgpt, wenn du sagst wie du es machen willst als ringbuffer interrupt gleitende summe über 16 flag setzen usw, dann ist der code fast fertig

Michael B. schrieb:

Lern programmieren an statt die Defizite mit Extrahardware vor dir herzuschieben.

Was ich hier nie verstehen werde, wenn man nicht helfen möchte, wieso man dann zeit investiert für solche Kommentare

Jeder fängt mal an und hat noch nicht das notwendige wissen und dann sind die ideen wie man etwas löst eben nicht optimal

Aber ich habe festgestellt, je weniger fundiertes wissen umso mehr werden andere diffamiert

Wers braucht, Männer

Michael B. schrieb:

Chantalle schrieb:

Jeder fängt mal an und hat noch nicht das notwendige wissen und dann sind die ideen wie man etwas löst eben nicht optimal

Und du sagst dem Verirrten der seinem Navi folgt und langsam am Weg zweifelt: du bist auf dem richtigen Weg, dein Navi leitet dich, da hinterm Feldweg über den Fluss und die Mauer rauf ist schon richtig.

Von mir kriegt der Verirrte ein klares "Falsch" und eine Arduino-Library. Von Chantalle nix

Ich habe eine lösung beschrieben, ist deiner wahrnehmung entgangen, vielleicht ja bewusst, wer weiß das schon

Popcorn! Noch jemand ohne Popcorn!?

Michael B. schrieb:

Auch ein Arduino kann PinChange Interrupts auswerten, da darf der Impuls so kurz sein wie er will.

Lern programmieren an statt die Defizite mit Extrahardware vor dir herzuschieben.

Sagt einer der es offensichtlich selber nicht kann, per interrupt wo die pulse so kurz sein dürfen wie sie wollen

Das ist definitiv falsch, genauso wie die verwendung flankengetriggerter monoflops

Der will ja nur auf das lffnen der klappe teagieren, nicht auf jede Störung

Chantalle schrieb:

Für den fall, das dein code für einen schleifendurchlauf länger als 1 ms benötigt, was durchaus sehr wahrscheinlich ist

Die robuste und rechenzeitoptimierze lösung wäre z.B mittels tomerinterrupt den eingang mit 16 khz abzufragen und einen ringbuffer mit 16 speicherplätzen anzulegen, für den summe schaut man immer wie der älteste wert war und entfernt den aus der summe und addiert den neuesten dazu, wenn man von low aktiv für das klappensignal ausgeht, dann wäre 16 klappe zu, und wenn sie öffnet läuft der bis 0 und dann wirder hoch, legst du die schwelle z.B bei 6, dann würde man bei diesem wert ein flag setzen, klappe auf, das passiert alles in der timerinterruptroutine

Wenn du in deiner programmschleife das flag abfragt, wirst du wenn es aktiv ist in die entsprechende routine springen, und auch gleichzeitig das flag zurücksetzen, das ist dann wie die angefragte pulsverlängerung, nur besser/eleganter

Genau so!

Chantalle schrieb:

Was ich hier nie verstehen werde, wenn man nicht helfen möchte, wieso man dann zeit investiert für solche Kommentare

die meisten, die hier 24 Stunden im forum sind, wollen nicht primär helfen, sondern ihr ego aufbessern. Mit freundlicher Hilfe für andere durch Fachwissen gelingt das nur wenigen. Andere niedermachen, als unfähig bezeichnen und beleidigen ist für die meisten die einzige Möglichkeit.

Nuri O. schrieb:

ich bekomme aus einer Hühnerklappensteuerung einen 24V Impuls von ca. 1 ms, welchen ich mit einem Arduino über einen Optokoppler Auswerten möchte.

Diesen möchte ich, damit ich den auch sauber auswerten kann, auf 100 ms verlängern.

Du brauchst den Impuls nicht zu verlängern, Du kannst einen Hardware-Zähler vom Arduino verwenden, um die externen Impulse zu zählen.

In der loop()-Schleife liest Du den Zähler aus, und vergleichst ihn mit dem letzten Wert. Hat sich der Wert verändert, gab es einen (oder mehrere) Impuls(e). Du weißt dann zwar nicht wann genau der Impuls war, aber das dürfte bei der Hühnerklappe egal sein, ob Du in 10 Millisekunden oder 100 Millisekunden reagierst.

Wegen Störung und Prellen wirst Du Dir kaum Sorgen machen müssen, da der Impuls sicherlich elektronisch (ohne Relais) erzeugt wird.

Ein Beispiel, wie das mit dem Hardware-Zähler geht, findest Du unter:

https://deepbluembedded.com/arduino-counter-timer/

Michael B. schrieb:

Lutz schrieb:

Der will ja nur auf das lffnen der klappe teagieren, nicht auf jede Störung

Boh, Entprellung wurde erfunden, und im Gegensatz zu dir habe ich zur Kenntnis genommen, welche Aussenschaltung er derzeit verwendet:

Nuri O. schrieb:

welchen ich mit einem Arduino über einen Optokoppler Auswerten

und Nein, der schaltet keine femtosekunden, sondern immer behäbig genug damit ein AVR PinChange auf jeden Fall mitkommt.

Also Lutz: lern programmierrn.

Du scheinst wirklich sehr ahnungslos zu sein, wie kommt man auf entprellen wenn man von einem sensor einen 1ms puls bekommt

Aber störungen über lange zuleitungen sind real

Sicher es kommt auf den anspruch an, wem 99.9% als Zuverlässigkeit hoch genug ist, und für das hobby ist dies ausreichend, der macht das so

Wenn man etwas entwickelt, das zig hunderttausendfach produziert wird und jeweils tausende stunden fehlerfrei laufen soll, der sieht das anders

Und ja, auch bei denen die das beruflich machen sind sehr viele die das nicht gut machen, >90%

Ich weiß wovon ich da schreibe, weil irgendwer sucht dann ja die ursachen

Ich weiß wovon ich da schreibe

Offensichtlich nicht

Schau dir einfach Peter Danneggers Entprellroutine an, die hier im Forum so prominent ist. Da lernst du noch was beim programmieren.

Das schöne ist ja wenn man so arrogante besserwisser persönlich im beruflichen umfeld trifft, die sind dann nach 3 wochen so klein, man sieht sie nicht mehr. Aber ja die glauben ja tatsächlich das sie so gut sind, bis das gegenteil unausweichlich vorliegt

Nuri O. schrieb:

Nemopuk schrieb:

1 ms ist doch nicht zu schnell für deinen Arduino (egal welcher).

Dann hast du mich noch nicht programmieren sehen! Ich bin froh wenn mein code die 100ms sieht :D

Muss aber auch sagen, dass ich an programmieren nicht ganz so viel Spaß habe. Dafür umso mehr an Schaltung aufbauen, rumspielen, messen und vor allem neues lernen.

in dem Fall würde ich ein RS-Flipflop nehmen, das von dem 1ms Impuls gesetzt wird und vom Arduino zurückgesetzt werden kann. An den Ausgang des Flipflops kommt ein Eingang vom Arduino und eine LED. Dann hast du alle Zeit der Welt, um den Zustand einzulesen und das Flipflop zurückzusetzen. Mit der LED hast du auch noch eine Funktionskontrolle. Wenn alles funktioniert, kannst du es immer noch eleganter in SW lösen.

Nemopuk schrieb:

Ist schon im Arduino drin und nennt sich Counter.

Er geht auf 1, wenn ein Impuls erkannt wurde. Und per Software kann man ihn wieder auf 0 zurück setzen.

mein Vorschlag war auch nicht für dich, sondern für den TO

Nuri O. schrieb:

Chantalle schrieb:

Die robuste und rechenzeitoptimierze lösung wäre z.B mittels tomerinterrupt den eingang mit 16 khz abzufragen und einen ringbuffer mit 16 speicherplätzen anzulegen

Das klingt sehr weit außerhalb meiner Kompetenz, aber kannst du gute Literatur empfehlen, um sich da reinzulesen?

also ChatGPT ist da eine gute quelle, wenn du deine Aufgabe sauber formulierst bekommst du Code mit Erklärung, und man kann auch nachfragen und ganz wichtig ChatGPT ist immer sehr höflich und macht einen nicht blöd an

Wenn du die Frage so formulierst

"ich möchte mit arduino mit arduino IDE per Timer Interrupt mit 16 kHz einen Digitaleingang abfragen und in einen Ringbuffer der länge 16, für high einen 1 eintragen und für low eine 0, dann soll nach jeder Abfrage die gleitende Summe ermittelt werden, d.h. von der Summe den ältesten Wert aud dem Ringbuffer entfernen und den aktuellen dazuaddieren. Wenn die Summe unter 4 fällt soll ein Flag gesetzt werden Im Hauptloop will ich bei jedem Durchlauf das Flag abfragen und wenn gesetzt in die Routine springen, in der Routine wird das Flag dann auch wieder zurückgesetzt, kannst du den Code schreiben"

spuckt er den Code raus, ich habe im dann aber gesagt das es besser wäre den Ringbuffer mit 1 zu iniiaisieren und die summe sum mit 16, weil beim start ja nicht aktive sein soll, aber das ist das erste Ergebniss, weiter unten nochmal die Korektur

// === Konfiguration === const uint8_t INPUT_PIN = 2; // Digitaleingangspin const uint8_t BUFFER_SIZE = 16; // Länge des Ringbuffers const uint16_t SAMPLE_RATE = 16000; // 16 kHz

// === Ringbuffer & Logik === volatile uint8_t ringBuffer[BUFFER_SIZE]; volatile uint8_t bufferIndex = 0; volatile uint8_t sum = 0; volatile bool flagLowSignal = false;

void setup() { pinMode(INPUT_PIN, INPUT); // Eingangspin konfigurieren Serial.begin(9600); // Optional für Debugging

// Buffer initialisieren for (uint8_t i = 0; i < BUFFER_SIZE; i++) { ringBuffer[i] = 0; }

// Timer1 initialisieren für 16 kHz Interrupt noInterrupts(); TCCR1A = 0; TCCR1B = 0;

// Timer-Berechnung: 16 MHz / (Prescaler * TargetRate) - 1 // Prescaler = 1 → 16 MHz / 16000 = 1000 → OCR1A = 999 OCR1A = 999; TCCR1B |= (1 << WGM12); // CTC-Modus TCCR1B |= (1 << CS10); // Prescaler = 1 TIMSK1 |= (1 << OCIE1A); // Interrupt aktivieren interrupts(); }

ISR(TIMER1_COMPA_vect) { // Eingang lesen uint8_t value = digitalRead(INPUT_PIN);

// Gleitende Summe berechnen uint8_t oldValue = ringBuffer[bufferIndex]; sum = sum - oldValue + value;

// Ringbuffer aktualisieren ringBuffer[bufferIndex] = value; bufferIndex = (bufferIndex + 1) % BUFFER_SIZE;

// Flag setzen, wenn Summe < 4 if (sum < 4) { flagLowSignal = true; } }

void loop() { if (flagLowSignal) { // Flag zurücksetzen noInterrupts(); flagLowSignal = false; interrupts();

1

// Behandlung der Bedingung (z. B. Ausgabe)

2

Serial.println("Signal unter Schwellwert!");

3

// Hier kann deine Routine aufgerufen werden

}

// Sonstige Logik im Loop }

hier dann noch mal die Korrektur

// === Konfiguration === const uint8_t INPUT_PIN = 2; // Digitaleingangspin const uint8_t BUFFER_SIZE = 16; // Länge des Ringbuffers const uint16_t SAMPLE_RATE = 16000; // 16 kHz

// === Ringbuffer & Logik === volatile uint8_t ringBuffer[BUFFER_SIZE]; volatile uint8_t bufferIndex = 0; volatile uint8_t sum = BUFFER_SIZE; // Anfangssumme = 16 volatile bool flagLowSignal = false;

void setup() { pinMode(INPUT_PIN, INPUT); // Eingangspin konfigurieren Serial.begin(9600); // Optional für Debugging

// Buffer initialisieren mit lauter 1en for (uint8_t i = 0; i < BUFFER_SIZE; i++) { ringBuffer[i] = 1; }

// Timer1 initialisieren für 16 kHz Interrupt noInterrupts(); TCCR1A = 0; TCCR1B = 0;

// Timer-Berechnung: 16 MHz / (Prescaler * TargetRate) - 1 // Prescaler = 1 → 16 MHz / 16000 = 1000 → OCR1A = 999 OCR1A = 999; TCCR1B |= (1 << WGM12); // CTC-Modus TCCR1B |= (1 << CS10); // Prescaler = 1 TIMSK1 |= (1 << OCIE1A); // Interrupt aktivieren interrupts(); }

ISR(TIMER1_COMPA_vect) { // Eingang lesen uint8_t value = digitalRead(INPUT_PIN);

// Gleitende Summe berechnen uint8_t oldValue = ringBuffer[bufferIndex]; sum = sum - oldValue + value;

// Ringbuffer aktualisieren ringBuffer[bufferIndex] = value; bufferIndex = (bufferIndex + 1) % BUFFER_SIZE;

// Flag setzen, wenn Summe < 4 if (sum < 4) { flagLowSignal = true; } }

void loop() { if (flagLowSignal) { // Flag zurücksetzen (kritischer Abschnitt) noInterrupts(); flagLowSignal = false; interrupts();

1

// Behandlung bei Unterschreitung des Schwellenwerts

2

Serial.println("Signal unter Schwellwert!");

3

// Hier kannst du deine spezielle Routine aufrufen

}

// Andere Aufgaben im Loop... }

jetzt kann dein Hauptprogramm so langsam sein wie du möchtest, das Flag wird per Interrupt im "Hintergrund" gesetzt, ganz so wie mit Hardware. Ich hatte auch anfangs immer die Tendenz Hardware zu nutzen statt Software, aber die geschickte Kombination, jetzt nur die Störungen entsprechend wenn vorhanden reduzieren mit einem RC Glied und es ist ein gute Lösung.

Mit ChatGPT kann man schon einiges erreichen, man muss aber auch genau schraiben was man will und kontrollieren und evtl. mit Ideen ergänzen. Weil die KI lernt aus dem Internet und "lernt" auch die Fehler oder schlechten Programmierstil wenn er denn weit genug verbreitet ist. Aber zum Glück scheint er die offiziellen Applikationen stärker zu gewichten als Foren

Peter D. schrieb:

Lutz schrieb:

Aber ja die glauben ja tatsächlich das sie so gut sind, bis das gegenteil unausweichlich vorliegt

Und die über hunderte hier im Forum, die von meinem Code begeistert sind, habe ich dann wohl alle hypnotisiert.

Du kannst Dich gerne auch sachlich zu meinen Beispielen äußern, aber das wird Dir nicht gelingen.

Das kan man so machen und für viele hobbyprojekte ok

Aber trotzdem 2 nachteile 1 wenn das hauptprogramm beschäftigt ist dann bekommt man kurze tsstendrücke nicht mit, ich habe für einen steuerung mal ausprobiert, tastendrücke mit einer dauer unter 200ms sind möglich, davon war am anfang fast 50ms prellen Das programm könnte also einen solchen tastendruck nicht mitbekommen wenn der loop 100ms benötigt, weil in deiner schleife ja auch delay sind

2. Die debounce funktion zält den counter runter und hat dazwischen immer ein delay, das bedeutet das sie solange den hauptprozess blockiert

Ich hatte ja alternativen geschrieben über ringbuffer und interrupt, das ist im professionellen bereich weitesgehend standard, man bekommt es immer mit und blockiert nicht den hauptprozess

Das erst mal zur debounce funktione In dem folgenden beispiel, das kann ich nicht 100% am handy bewerten, müsste man zumindest mal ausdrucken, schöner wären einmal durchtesten und emulieten um alle zustände eindeutig nachzuvollziehen. Aber ich sehe keine merkmale auf anhieb , das zustände gespeichert werden, so dass das hauptprogramm diese auch verzögert noch abfragen kann wenn der taster wieder losgelassen ist. Auch hier, für dies code gibt es auch die berechtigung wenn man abfragen will ist jetzt ein taster gedrückt. Wenn man aber die aufgabe hat, wenn ein taster gedrückt wird dann soll... Dann ist es ohne speicherung die falsche lösung Cantalle2000 hatte dazu ein beispielcode gepostet,und ich muss gestehen, der ist noch ein schritt weiter gedacht, natürlich ist ringbuffer der Länge 2^n besser, weil man dann schnellere rechenoperationen eines 8 bitters nutzen kann mittels maske statt if else

Nichts für ungut, der code ist ok und in vielen Projekten benötigt es nicht mehr. Aber warum immer so überheblich als die alten hasen hier im forum das mass der dinge darstellen.

Otto K. schrieb:

wäre ein RS-Flip-Flop mit nachgeschaltetem Optokoppler hier angebracht, denn ein 24 Volt Impuls hat am Arduino nichts zu suchen!

der Optokoppler wäre vor dem Flipflop besser aufgehoben. Also die LED vom Optokoppler am 24V Impuls und der Rest an der Versorgung vom Arduino.

Peter D. schrieb:

Vielleicht solltest Du mal verlinken, welche Lib Du denn eigentlich meinst

Hier auf der seite unter artikelübersicht entprellung

Aber zum kommunikationsstiel, wenn man schreibt " Du kannst Dich gerne auch sachlich zu meinen Beispielen äußern, aber das wird Dir nicht gelingen" Hättest du ja auch einen link posten können und die Annahme das niemand in deinem code verbessereungsporential sieht, ehrlich das ist schon sehr arrogant

Ich kenne meine position als ingenieur, zeig da schon sehr vielen wo es lang geht, ich würde aber nie behaupten das es für meine lösungen nicht noch bessere gibt

Anders wie manche Idi***n hier im forum die sich für sonst was halten, aber sowas von offensichtlich in der kindergartenliga unterwegs sind

Und das soll keine kritik an hobbyelektroniker sein, das ist doch auch als hobby schön und dann muss auch nicht alles perfekt sein, das ist ok

Aber manche hier, naja, da fehlen mir die Worte

Und sollten die das beruflich machen, ja die kenne ich, ganz große klappe aber nach 3 Wochen unsichtbar

Peter D. schrieb:

Lutz schrieb:

1 wenn das hauptprogramm beschäftigt ist dann bekommt man kurze tsstendrücke nicht mit

Vielleicht solltest Du mal verlinken, welche Lib Du denn eigentlich meinst.

Wenn von "Peter Danneggers Entprellroutine" geredet wird, dann ist typisch diese hier gemeint: Beitrag "Universelle Tastenabfrage"

Ich habe noch eine Macroversion ohne Timerinterrupt gepostet, aber auch klar deren Limits genannt.

Aber noch mal zum punkt der Abfrage eines digitaleingangd Es gibt da schon die zwei unterschiedlichen zustände die man wenn man in de r schleife an den punkt kommt abfragen kann

• ist der Eingang aktiv
• war der Ekngang seit der letzten Abfrage aktiv

Entsprechend ist der Code unterschiedlich, und wenn man für die falsche Aufgabenstellung nicht die richtige methode benutzt ist das falsch

Aber dss sagt ja nichts über die routine selber aus

Die habe für die jeweilige Aufgabe ihre Berechtigung

Nemopuk schrieb:

Spätestens wenn man Code zum dritten mal neu schreibt oder kopiert, sollte man wach werden

bei einem Anfänger sieht das meistens anders aus. Wenn er einen Code für die gleiche Funktion zum 2. oder 3. mal schreibt, ist das schon so viel besser und strukturierter, dass er den Murks vom ersten Versuch sowieso nicht mehr nehmen würde, egal wie universell es hätte werden sollen. Ausnahmen sind die Lernresistenten, da wird es beim 3. Mal auch nicht besser, und die allwissend geborenen, da ist es beim ersten Mal schon perfekt.

Peter Danneggers Entprellroutine ist definitiv eine elegante und bewährte Lösung, die in vielen Hobby- und einfachen Mikrocontroller-Anwendungen sehr gut funktioniert. Sie ist kompakt, effizient und kommt ohne aufwändige Hardware aus – genau das macht sie für viele Projekte attraktiv.

Allerdings ist die Routine aus einer Zeit, in der Speicher knapp und Rechenleistung limitiert war – man könnte sie daher als etwas „oldschool“ bezeichnen. Das heißt nicht, dass sie schlecht ist, sondern eher, dass es heute auch modernere Methoden gibt, die in bestimmten Situationen robuster sein können.

Wenn man tiefer in die Materie einsteigt, lohnt es sich, Fragen zu stellen wie:

• Wie robust ist die Entprellung bei kurzen Störimpulsen in beide Richtungen (z.B. kurze High-Spikes bei Low-Erkennung)?
• Kann die Routine mit einer Hysterese oder gleitenden Mittelung noch stabilere Ergebnisse liefern?
• Wie verhält sie sich in stark gestörten Umgebungen oder bei längeren Leitungslängen?
• Eignet sich die Methode für viele Taster oder komplexere Eingabegeräte?

Für viele einfache Anwendungen im Hobbybereich ist Danneggers Code absolut ausreichend und pragmatisch. Wer jedoch in raueren Umgebungen arbeitet oder höchste Zuverlässigkeit braucht, sollte überlegen, ob er mit modernen Filtermethoden – z.B. gleitende Summen mit Hysterese – noch besser fahren kann.

Abschließend sollte man auch erwähnen, dass es wichtig ist, sich als erfahrener Entwickler neuen Ideen und Methoden zu öffnen, anstatt Kritik mit Beleidigungen oder herablassenden Kommentaren abzutun. Konstruktiver Austausch fördert den Fortschritt – und davon profitieren letztlich alle.

Roland F. schrieb:

Hallo, Lutz schrieb im Beitrag #7895737:

Wer jedoch in raueren Umgebungen arbeitet oder höchste Zuverlässigkeit braucht, sollte überlegen, ob er mit modernen Filtermethoden – z.B. gleitende Summen mit Hysterese – noch besser fahren kann.

Interessant. Zeig doch mal wie man sowas (vorzugsweise in C) programmiert.

rhf

Es wurde mehrfach hier schon beschrieben, aber wenn ihr euch darauf nicht einlassen wollt weil das euren Ego verletzt, da ist jede mühe umsonst

Ich kann auch gar nicht nachvollziehen warum mein beispielcode so negativ bewertet wurde

Lothar M. schrieb:

Welcher Kasper hat eigentlich diese unsinnige Stör- und Prelldiskussion ins Spiel gebracht? Wenn ich die Aufgabenstellung des TO lese, kommt rein gar nichts davon vor. Wozu Nebelkerzen werfen?

Thomas B. schrieb:

Was ist das eigentlich für eine Hühnerklappensteuerung. Gibt es da einen Schaltplan oder einen Link? Oder selber gebaut?

Und woher kommt aus dieser Steuerung der besagte 1ms-Impuls?

Nur darum geht es. Und erst wenn man das weiß, kann man sinnvoll über eine Lösung diskutieren.

Das kam auf, weil lösungen vorgeschlagen wurden die probleme bereitet hätten

Warum kann man das nicht auf sachlicher Ebene belassen

Monoflop war einer der ersten votschläge und jeder mit ein wenig erfahrung sollte wissen welche probleme flankengetriggerte monoflops bereiten können

Aber wie ich hier ja schon gelesen habe und aus eigenet bisheriger erfahrung bestätigen kann, wenn für eine einzige anwendung 99.9% zuverlässigkeit reichen kann man das machen

Aber ich denke hier gibt es ein paar, die weiter denken.

Und ganz ehrlich, es macht doch Sinn sich auszutauschen und dann mit gleichen Aufwand bessere lösungen zu generieren

Das ist nicht korrekt, er hat danach und nach einer anleitubg gefragt

Und selbst wenn nicht, warum dann negativ bewerten

Ich bekomme langsam zweifel ob ich hier richtig wenn ich sehe was hier unterwegs ist

Mani W. schrieb:

Chantalle schrieb:

Aber wie ich hier ja schon gelesen habe und aus eigenet bisheriger erfahrung bestätigen kann, wenn für eine einzige anwendung 99.9% zuverlässigkeit reichen kann man das machen

Nein, man tut es ohne µC...

Weil es zu 100% ohne geht...

Natürlich gibt es anwendungen wo es geht, sonst würde es solche ic ja schließlich nicht geben, aber es gibt auch anwendungen wo die probleme bereiten

Mani W. schrieb:

Die Schaltung ist locker mit einem 4093 zu realisieren, 100% funktionstüchtig und ohne Fehler...

Der TE will einen Optokoppler verwenden, und mehr als ein/zwei Widerstände und einen Kondensator braucht man drum herum nicht.

Roland F. schrieb:

Chantalle schrieb:

aber es gibt auch anwendungen wo die probleme bereiten

Kannst du mal ein Beispiel zeigen?

Ich kann mal aus meiner Anwendung ein Beispiel zeigen, das filtert direkt die Signale eines ganzen Ports, basiert auf dem gleichen Prinzip wie Chantalle2000 beschrieben hat, aber effizient mit BIT Arithmetik, der Interrupt benötigt auf einem ATMEGA328 mit 16MHz weniger als 10us (8us-9us), der wird je nach Signallänge und Anwendung mit 1kHz bei Signal 16ms oder bei kürzeren Signalen z.B. 1ms mit 16 kHz aufgerufen, Anpassung OCR1A und Prescaler

Das ganz funktioniert sehr robust auch mit Störungen, im Loop ist jetzt nur ein Demo statt der Code meiner Anwendung, das delayMiscoseconds steht beispielhaft für den restlichen Code. Zur Kontrolle mit dem Oszi wird der "erkannte Low Pegel" portDLow auf portB ausgegeben. im Ausdokumentierten Teil wird es Bit Selektiv bewertet, ist von der Anwendung abhängig was man möchte

In meiner Anwendung liest ein mega2560 3 Ports ein von digitalen Signalen, Schaltkontakte Modellbahn, die bis zu über 20 Meter parallel zu den DCC Fahrstromsignalen liegen, ohne Probleme.

Getestet mit einer Arbiträr Sequenz wo die Auslösedauer Nutzsignal der minimal Dauer / 2 entspricht und die Störpulse 50 mal länger sind als das was ich gemessen habe Grün unterstrichen ist das Signal was erkannt werden soll und blau unterstrichen ist der Bereich mit den Störrungen, die Störungen machen aber keine echten Nullpegel, die gehen vielleicht auf 1.5V bis 2V runter, das ist das Testsignal für die Software. Ein weiteres "analoges Testsignal" um dann incl. der RC Tiefpass Filterung zu testen gibt es ebenfalls

Lutz schrieb:

Roland F. schrieb:

Chantalle schrieb:

aber es gibt auch anwendungen wo die probleme bereiten

Kannst du mal ein Beispiel zeigen?

Ich kann mal aus meiner Anwendung ein Beispiel zeigen, das filtert

Bei der Anpassung das es auf UNO auch läuft und Reduzierung auf ein einfaches Beispiel hat sich ein Fehler eingeschlichen, die Variablen in Zeile 5 portDLow und 6 portDHigh stehen auf BOOL, muss aber uint8_t sein, gerade gemerkt das es nur auf Pin D0 läuft

Lutz schrieb:

Lutz schrieb:

Roland F. schrieb:

Chantalle schrieb:

aber es gibt auch anwendungen wo die probleme bereiten

Kannst du mal ein Beispiel zeigen?

Ich kann mal aus meiner Anwendung ein Beispiel zeigen, das filtert

Bei der Anpassung das es auf UNO auch läuft und Reduzierung auf ein einfaches Beispiel hat sich ein Fehler eingeschlichen, die Variablen in Zeile 5 portDLow und 6 portDHigh stehen auf BOOL, muss aber uint8_t sein, gerade gemerkt das es nur auf Pin D0 läuft

Ok, zur Kenntnis genommen, Code geliefert und negativ bewertet, aber im Vergleich zu Peters Routine läuft diese nun mal robuster

Beide Routinen so den Interrupt eingestellt das bei Peters Routine bei einem 4ms Puls 4 mal abgetastet wird und da ich ja mehr werte abfrage das 12 mal abgetastet wird. Mit einer Testsequenz, 4ms Puls 3.5ms Puls 4.4ms plus + pos Störung 4.4 ms pos Störfolge

bei meiner Routine werden die 4ms erkannt die 3.5ms bewusst nicht mehr, die 4.4ms + Störungen werden beide immer zuverlässig erkannt bei Peters Routine werden die 4ms erkannt die 3.5ms manchmal genauso wie die Pulse mit Störungen, die werden manchmal erkannt

Das sind Fakten, aber wer nichts lernen möchte weil er alles weiß, darf gerne seinen Frust abbauen und negativ bewerten weil ich sein Ego verletzt habe

Alexander W. schrieb:

Vielleicht wäre es an der Zeit, dass du uns mal deinen Code zeigst und wir dir Verbesserungsvorschläge machen. Eventuell kommst du dann schneller deine Hühnerklappe richtig ausgewertet wird, als wenn du einen Umbau deiner Hardware machst.

Der Code ist doch im Anhang, was willst du eigentlich

hier noch der vergleich vom Ergebnis https://youtu.be/K2aZe2dSWbM

meine Routine, der erste Puls ist 4ms soll erkannt werden, der zweite ist 3.5ms soll nicht mehr erkannt werden, die beiden nächsten haben Störungen sollen aber erkannt werden weil ja auch 4.4ms lang, also min 4ms low

das ist Peters Routine https://youtu.be/vDS2BaqkluQ

der 4ms Puls wird sauber erkannt (habe den IRQ schneller laufen lassen wegen Vergleichbarkeit auf 1 kHz) die drei anderen werden mal erkannt mal nicht https://youtu.be/vDS2BaqkluQ

Jörg R. schrieb:

Du hast nicht zur Kenntnis genommen dass der TO keine SW-Lösung möchte.

Er ist allerdings scheinbar an gar keiner Lösung mehr interessiert. Ansonsten hätte er längst mal Hintergrundinformationen geliefert.

Das sind Fakten, aber wer nichts lernen möchte weil er alles weiß, darf gerne seinen Frust abbauen und negativ bewerten weil ich sein Ego verletzt habe

Du beweihräucherst dich vor allem am liebsten selbst, gehörst ja zu den privilegierten <10% die es können und richtig machen.

Nein, beweihräuchern tun sich hier andere, die haben aber wie du ein Problem damit wenn man ihren Ego verletzt

Es wurde mehrfach von denen geschrieben, "dann zeig mal den Code" obwohl er zigfach geteilt wurde

Der TO war nicht an Software interessiert weil er es lieber in Hardware macht und weil er in Software nicht weiß wie es geht. Es wurden schlechte Hardwarelösungen vorgestellt, Monoflop, RS FlipFlop, was bei Störungen mit langen Leitungen, die ich erst mal annehmen würde und nicht ideale Welt voraussetzen würde, niemanden glücklich macht.

Und dann wurde ja auch auf eine Software Routine verwiesen, wozu man ja sagen muss, für Schalter abzufragen in der Nähe des Boards ist die ok, und wenn es langsam sein darf, kann man Filter davorschalten.

Für kurze Signalpulse zu entstören ist diese Routine aber weniger robust als heutige Stand der Technik, deswegen hatte ich diese Lösung aufgezeigt.

Und trotzdem war dann eine der Antworten, "Du kannst Dich gerne auch sachlich zu meinen Beispielen äußern, aber das wird Dir nicht gelingen." Es ist so offensichtlich ...

Lutz schrieb:

Der TO war nicht an Software interessiert weil er es lieber in Hardware macht und weil er in Software nicht weiß wie es geht.

genau so ist es.

Lutz schrieb:

Es wurden schlechte Hardwarelösungen vorgestellt, Monoflop, RS FlipFlop, was bei Störungen mit langen Leitungen, die ich erst mal annehmen würde und nicht ideale Welt voraussetzen würde, niemanden glücklich macht.

denkst du wirklich, dass man das Problem in Hardware nicht lösen kann, oder kannst nur du es nicht? Es ist zwar nicht der Stand der Technik, aber für jemand, der Probleme mit der SW und Spaß am Basteln hat, keine schlechte Lösung.

Und bei langen Leitungen mit unbekannten Störungen wirst du um Hardware nicht herumkommen, weil du bei einen zerstörten µC-Eingang mit SW nichts mehr korrigieren kannst.

R. L. schrieb:

denkst du wirklich, dass man das Problem in Hardware nicht lösen kann, oder kannst nur du es nicht?

Und schon wieder so eine unglaubliche arrogante Bemerkung weil ihr ja alles solche Helden seid.

Ich weiß wie man das Problem in Hardware lösen kann, deswegen weiß ich, dass die vorgeschlagenen Lösungen wenn Störungen im Spiel sind nichts taugen, weil alles was irgendwie flankengetriggert ist löst eben auf Störungen aus, was letztendlich bedeutet das man erst mal filtern muss Schmitt Trigger mit Hysterese dahinter und dann mit der Flanke aufs FlipFlop, auch hier wäre dann ein RS FlipFlop die bessere Wahl als ein Monoflop, weil wenn der Puls so lange ist wie meine längste Programmlaufzeit und das Programm keine feste Durchlaufzeit hat, könnte ich den gleichen Puls auch 2x zählen, mit einem RS kann man es wie bei der Softwarelösung nach der Abfrage zurücksetzen, benötige ich dann 2 IO Pins um ein Signal abzufragen, ist spannend, ja, und für Spass kann man es so machen, aber wenn wir hier Lösungen diskutieren sollte es auch den Raum geben Verbesserungen aufzuzeigen. Somit, wenn das Signal auf einen µC geht dann gibt es bessere Lösungen in Software und auch da sind die Überlegungen zum Filter in Zusammenspiel mit der Software eine spannende Sache wenn man es optimieren will in puncto Robustheit. Peters Code für einen ATiny Tasten abzufragen ist ja genau für den Zweck auch eine gute Lösung, weil es im Zusammenspiel mit einem RC Tiefpass eine robuste Lösung liefert, für Signale die schneller sind und mehr Störungen haben ist es dann nicht mehr so robust aber mit ein klein wenig mehr Speicher und Rechenleistung kann man es deutlich robuster realisieren.

Das muss man ja aufzeugen dürfen, aber dann heist es direkt "sachlich wird mir nicht gelingen" als ob diese Code so perfekt ist. Er ist gut wofür er gemacht wurde, genauso wie mein Code gut dafür ist, wofür er gemacht wurde, was aber ja nicht bedeutet das man damit jetzt jedes Problem lösen kann. Neue Probleme erfordern oft auch neue Lösungen, wobei es immer gut ist etwas über den Tellerrand zu blicken das man Lösungen für einen weiteren Bereich einsetzen kann

Lutz schrieb:

Und schon wieder so eine unglaubliche arrogante Bemerkung weil ihr ja alles solche Helden seid.

das sagt der richtige.

Lutz schrieb:

das man erst mal filtern muss Schmitt Trigger mit Hysterese dahinter

hat jemand behauptet, dass man in HW nichts filtern muss, um Störungen zu eliminieren?

Lutz schrieb:

Neue Probleme erfordern oft auch neue Lösungen, wobei es immer gut ist etwas über den Tellerrand zu blicken das man Lösungen für einen weiteren Bereich einsetzen kann

das ist sicher nicht das primäre Anliegen des TO.

R. L. schrieb:

Lutz schrieb:

Und schon wieder so eine unglaubliche arrogante Bemerkung weil ihr ja alles solche Helden seid.

das sagt der richtige.

Im Gegensatz zu deinen Aussagen sind meine nachvollziehbare Fakten und keine aus dem Zusammenhang gerissenen Halbwahrheiten

Aber wenn du das nötig hast, dann tust du mir Leid

Lutz schrieb:

Alexander W. schrieb:

Vielleicht wäre es an der Zeit, dass du uns mal deinen Code zeigst und wir dir Verbesserungsvorschläge machen. Eventuell kommst du dann schneller deine Hühnerklappe richtig ausgewertet wird, als wenn du einen Umbau deiner Hardware machst.

Der Code ist doch im Anhang, was willst du eigentlich

hier noch der vergleich vom Ergebnis https://youtu.be/K2aZe2dSWbM

meine Routine, der erste Puls ist 4ms soll erkannt werden, der zweite ist 3.5ms soll nicht mehr erkannt werden, die beiden nächsten haben Störungen sollen aber erkannt werden weil ja auch 4.4ms lang, also min 4ms low

das ist Peters Routine https://youtu.be/vDS2BaqkluQ

der 4ms Puls wird sauber erkannt (habe den IRQ schneller laufen lassen wegen Vergleichbarkeit auf 1 kHz) die drei anderen werden mal erkannt mal nicht https://youtu.be/vDS2BaqkluQ

habe gerade mal geschaut, 3 Leute habe sich die Videos angeschaut aber 5 haben den Post negativ bewertet

Das sagt doch alles über euch aus

Lutz schrieb:

Das sagt doch alles über euch aus

Das Verhalten dieser Community in diesem Fall erfüllt nicht den Anspruch eines Technikerforums.

Es geht offenbar nicht mehr um: -Inhalte oder Lösungen, -Nachvollziehbare technische Argumente, -Faktenbasierte Diskussion,

sondern viel zu oft um: -Dominanzgehabe, -Abwertung anderer, -Verteidigung des eigenen Weltbildes.

im übrigen, ich hatte mir die Videos angeschaut und keine Bewertung zum Beitrag abgegeben, soviel dazu Interessanter Test um die Unterschiede der beiden Routinen aufzuzeigen

Joachim B. schrieb:

dann sollte man halt dafür sorgen das diese nicht auslösen, in PeDas Software ist schon mal ein guter Anfang und dafür sorgen das Störungen eben nicht einkoppeln.

Wer den Sinn einer Testsequenz nicht versteht sollte da erst mal bei sich selber anfangen und nicht herablassend erklären was man machen sollte.

Es gibt keine Erwartung wann der nächste Puls kommt

Die kürzesten gemessenen Pulse sind 8 ms, die längsten über 200ms

Die Testsequenz dient einem objektiven Vergleich für die Trennschärfe zwischen Falschauslöung und Nichterkennung. Also warum soll man an einem vernünftigen Test was ändern

Rainer W. schrieb:

Willst du jedes Funkenfeuer, dass sich über mehr als 4ms erstreckt, als gültigen Puls ansehen? Oder nach welchen Kritierien soll ein gültiger 4ms-Puls von 4ms Störkram unterschieden werden?

ź Nichts verstanden

Die Pulse sind 8ms minimum, aber ab 4ms lass ich sie erkennen, alles schon beschrieben, und die Störpulse sind deutlich kürzer wie beschrieben, das ist die synthetische Testroutine, wird sozusagen übertestet, dann hat man Reserven

Funkenfeuer, haha, lustig, kein Plan, DCC ist das digitalprotokoll, mit einer robusten Routine muss man die Kabel nicht separieren

Mir zu erklären das etwas was zuverlässig funktioniert nicht funktionieren kjann weil ich das falsch mache, starke Nummer

Joachim B. schrieb:

Lutz schrieb:

Also warum soll man an einem vernünftigen Test was ändern

ok ich wollte nur helfen, aber du weißt es besser es sind deine Störungen. Du erklärst auch nicht wo sie herkommen und wie man sie fernhalten kann, hier an Tastatur und Monitor kann das niemand für dich richten.

Wieso willst du mir helfen, ich habe zu der Fragestellung wie man Pulse empfangen und entprellen meine funktionierende Lösung vorgestellt

Und wieso sagst du ich hätte nicht erklärt wo die störungen her kommen Das hatte ich beschrieben und auch das bei der Testsequenz die Störungen um Faktor 50 länger sind als gemessen Ursache der Störung auch beschrieben genau wie die Kopplung

Für mich muss keiner was richten, meine Routine arbeitet robust

Peters Routine nicht so robust

Rainer W. schrieb:

https://youtu.be/K2aZe2dSWbM ...

Tolle Links: Video nicht verfügbar Dieses Video wurde vom Uploader entfernt

Wie soll man da über irgendetwas diskutieren :-(

Heute willst du diskutieren, sah gestern anders aus

Gestern habe ich die Videos gesehen