Zum Inhalt springen

Nexus665

Members
  • Gesamte Inhalte

    11
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    1

Nexus665 hat zuletzt am 6. März 2018 gewonnen

Nexus665 hat die beliebtesten Inhalte erstellt!

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Leistungen von Nexus665

newbie

newbie (1/12)

12

Reputation in der Community

  1. Hi Werner, genau diesen Gedanken hatte ich auch gleich, als ihr Doppelzündung erwähnt habt. Wenn das nächste detektierte Intervall so stark kürzer ist als das vorige, dann kann man das filtern bzw. den Wert einfach einfrieren anstatt ihn springen zu lassen. Am WE habe ich evtl. mal Zeit mir ein bißchen HW aufzubauen und selber das Oszi und den Signalgenerator anzuwerfen.
  2. Hm, ohne HW ist das noch ein bißchen blöd mit Code ^^ Leider sagen mir die Daten aus dem Log genau gar nix - bzw. weiß ich nicht, was da plausibel ist an Daten - springende Frequenzen aber wohl nicht. Im File oben ist das noch nicht geändert von ATOMIC_BLOCK, aber ein paar Konstanten sind drin statt Variablen. Kann sein, daß da noch ein paar Typecasts fehlen und deswegen die Berechnungen inkorrekte Ergebnisse liefern. Denke, wenn ich die HW habe ist das schnell debuggt. Habe einen Flüchtigkeitsfehler gefunden - RINGSIZE4/5 waren in der Berechnungsschleife vertauscht, mea culpa. In der attachten Version sind auch die Timer nun einzeln deaktiviert statt alles in einer ATOMIC_BLOCK Anweisung. MEGA_PSTfreq_BME280_v1_nexus665.zip
  3. Hi, sagt mal - die Berechnungen im Loop mit ATOMIC_BLOCK, das ist ja eigentlich nicht die feine englische Art...gibt's einen relevanten Grund dafür, warum alle Interrupt Flags währenddessen aus sein sollen? Das kann zu einigen Problemen führen. Da hier ja im Wesentlichen nur einzelne Timer (Timer4/Timer5) bearbeitet werden, könnte man doch die jeweils separat anhalten/starten stattdessen? Es kann ja eigentlich nur darum gehen, dass sich die Daten nicht während der Auswertung ändern, oder? lG, Simon MEGA_PSTfreq_BME280_v1_nexus665.zip
  4. Hi, hatte grade kurz Zeit, mir den Sketch reinzuziehen. Anmerkungen: Viele Konstante sind als Variablen definiert, das verbraucht unnötig RAM - defines funktionieren da besser. Auch wenn hier ein MEGA zum Einsatz kommt, der Speicher und Schnittstellen zuhauf hat, sollte man sich das nicht angewöhnen :) Wenn man mal mit einem etwas limitierteren Mikrocontroller arbeitet, lernt man das schnell zu schätzen. Ebenso ist die Abarbeitung von Interrupts so nicht ganz ideal; wenn bei Timer4 oder Timer5 der ICP feuert, dann laufen trotzdem alle anderen Interrupts weiter, da sie nicht mit cli() oder ähnlichem deaktiviert wurden. Es kann vorkommen, dass man mitten in einer ISR dann von einer anderen ISR unterbrochen wird - wahrscheinlich nicht sinnvoll. Wie viel Zeit da zwischen solchen ICP events verstreicht oder ob die wirklich gleichzeitig passieren - noch nicht getestet, dafür fehlt mir noch Hardware. Der Ringpuffer ist als int mit 50 Elementen angegeben, alle Puffer-Vars haben aber 50 hardcoded drin stehen (15-20x bei den Var-Definitionen). Sowas verringert die Wartbarkeit drastisch ;) Ebenso wird nur Serial.begin() verwendet - der Mega hat aber 4 Serials! Analog dazu gibt es hier auch Serial1.begin(), Serial2.begin, Serial3.begin() - wird wirklich nur eine (die erste, die auch USB debug macht) verwendet? Fände ich verbesserbar, eben weil ja 4 COMs vorhanden sind und der BME eine ganz eigene bekommen könnte, was auch die Latenz verringern könnte (die UARTs werden parallel ausgewertet). Ich hab' da mal ein bißchen rumeditiert am Code - da ich nicht im Repo bin kann ich auch nichts committen, also hab' ich den Sketch hier als Attachment angehängt. Die einzigen Änderungen sind der Übersichtlichkeit und Speichernutzung geschuldet - defines statt Variablen, Ringpuffer-Variablen statt hardcoded 50 RINGBUFFER_SIZE usw. Was die Detektion von Doppelimpulsen usw. angeht, muß ich erst die ISRs bzw. den Programmlauf genauer analysieren, noch keine Zeit gehabt :) Basiert auf 2.0.1. MEGA_PSTfreq_BME280_v1.zip
  5. @Werner Amort: genau so hatte ich das gemeint im Post oben ;) ADC über SPI oder I2C auslesen, dazu eine U_ref, das geht schön hardwareunterstützt im Hintergrund am Arduino auszuwerten.
  6. Hi, MEGA 2560 ist vorhanden. Ich bin da weiterhin interessiert mitzuarbeiten, Lambda via Arduino hatte ich vor ~5 Jahren bei einem DIY Projekt (Tuning) mit einem Low-Cost Daughterboard problemlos umsetzen können. Müßte nochmal nachsehen, was das genau war. <edit>das war dieses hier: http://www.breitband-lambda.de/cj125.html - es gibt von Bosch und TI ein paar auf Lambdasonden-Auswertung getrimmte ICs, mit denen das viel simpler und schneller machbar ist als es analog aufzubauen. Der Preis ist inzwischen allerdings höher als er war ^^ Mit den vorhandenen ICs das in den Datenblättern angegebene Referenzdesign umzusetzen wird viel günstiger möglich sein, wenn es eh schon eine Platine gibt die gezeichnet wird. <edit>Wegen analogRead() - es gäbe dazu auch dedizierte ADCs, die konvertieren a) genauer b) schneller haben c) mehrere Kanäle parallel, d) schnelle serielle Interfaces und e) eine Referenz optional. Wenn wirklich analoge Messungen interessant sind, ist das eine - recht günstige - Alternative. Die kann man im Hauptprogramm auswerten und die Interrupts weiter bedienen.
  7. Hi, Lambda habe ich für mein Automotive DIY Telemetrie/Logger Projekt (ebenso auf Mega 2560 Basis) auch schon umgesetzt, damals über eine andere Treiberschaltung. Hab' nur die Karre nicht mehr ^^ Ich warte mal, was @chili023 vor hat an Hardware- oder Software-Umsetzung - Ideen gibt's ja genug.
  8. Hi Leute, leider bin ich grade erst auf dieses Topic gestoßen, Respekt! Hab' mir weil's so spannend war den ganzen Thread auf einmal reingezogen und frage mich, ob ihr noch Unterstützung braucht? Fit bin ich auf Arduinos, auch auf LV zumindest grundsätzlich ausgebildet (wenn ich damit auch noch viel zu wenig Erfahrung gesammelt habe), Elektronik, EAGLE kabeln und layouten, Custom Libraries usw. auch kein Ding. Denke, daß ich euch da in einigen Bereichen unterstützen könnte - natürlich nur, wenn ihr auch noch aktiv Unterstützung wollt :) lG, Simon
  9. Hab nun auch den ganzen Thread gelesen...eine Stunde wird wohl nicht gereicht haben... In jedem Fall: geiles Ding. Werde in näherer Zukunft zumindest die mobile Version testen bzw. dem lokalen Scooterclub einen Rollenprüfstand einreden...bis auf die Rolle selbst ist die finanzielle Seite ja echt lächerlich billig. Weiter so und danke daß Du dieses Tool frei verfügbar machst! :love: Edith sagt, daß sie den "Not for Sale" Hinweis kaum lesen konnte... größer rendern?
×
×
  • Neu erstellen...

Wichtige Information