'Nabend.. ich bin irgendwie heute besonders vernagelt, und müsste mir mal kurz Euer Brecheisen leihen.. Ich fang mal vorne an: ich hab vier MPX5050DP mit denen ich den Unterdruck der vier Ansaugkanäle in meiner Mofa auslesen will. jetzt hätte ich gerne 120 Samples pro Sensor über alle vier Takte also jeweils 6° Kurbelwellendrehung voneinander entfernt. (2 volle KW Umdrehungen) Mit nur wenig overhead Mathezeug brauch ich zum auslesen eines Sensors etwa 124µs sodass ich mit Leerlaufdrehzahl (1200 U/min) genug Zeit hab (138.8µS pro Grad an der Kurbelwelle) und die einzelnen Sensorergebnisse nur etwa ein Grad voneinander verschoben sind.. kein Problem bis hier. Aaaber ich möchte eben gerne auch wissen ob sich am Druckverlauf was ändert wenn der Motor sich, na sagen wir in 'spielfreudigeren' Gefilden dreht. Und da mein maximaler Drehmoment erst bei 11000 U/min anliegt.. naja eben auch gerne bis zum Drehzahlbegrenzer (13500 U/min) weil es ja kaum mehr einen Unterschied macht. Nun wird das mit der Zeitspanne dann aber merklich knapp, da jedes Grad auf der Kurbelwelle bei 13500 U/min schon nurnoch 12.45µS dauert und das auslesen eines einzelnen Sensors damit schon 10° auf der KW verschlingt. Heisst natürlich im Umkehrschluss, dass ich meinen Datenspeicher eben länger als Zwei Umdrehungen füllen muss, mein Problem nun ist es den jeweils (drehzahlabhängig) möglichst kürzesten Weg zu finden. Immer in Hinsicht darauf, dass zwei aufeinanderfolgende Werte im Speicher eines Sensors 6° voneinander entfernt sein sollen. Und voneinander halt möglichst geringen Abstand haben Im extremfall (da ich eh 16 Umdrehungen brauche) auch gerne Im Abstand von 720° versteht sich. Irgendwie fällt es mir grade echt schwer mich durch die ganzen Kurbelwellenwinkel und microsekunden zu fressen ohne aus den Augen zu verlieren dass der 16MHz getaktete Atmega328p microsekunden eh nur in vielfachen von 4 wahrnehmen kann. Ein vermutlichst triviales Problem, aber -wie gesagt- bin grad echt nicht in der Lage das aufzudröseln. Könnte jemand kurz auf die richtige Herangehensweise zeigen Danke!
Man kann mich gerne korrigieren aber ich glaube das kannst du mit dem Atmega vergessen. Die 12.45µS pro Grad glaube ich dir jetzt mal hab es nicht nachgerechnet. Das sind ca. 80Khz. Der Atmega328p hat einen ADC der 15Ksp/s hat, da du 4 Kanäle gemultiplext misst, bleiben dir pro Sensor 3,75Ksp/s. Das heißt dir steht nur alle 200µs eine neue Messung zur Verfügung.
Hab mich vertrippt. 260µs Abstand zwischen den Messungen.
>ich hab vier MPX5050DP mit denen ich den Unterdruck der vier >Ansaugkanäle in meiner Mofa auslesen will. Ein Vierzylindermofa. Bei uns hatten die früher nur einen Zylinder mit kleiner 50ccm. Poste doch mal deine Meßkurven und das Programm, damit man mal sehen kann, ob überhaupt was zeitlich aufgelöst wird.
Bei 6° ergeben sich bei 1200U/min eine Samplerate von 1200Hz, bei 13500U/min entspr 13500Hz. Pro Kanal. Sollte machbar sein, entweder einen Kanal nach dem anderen (insg 8U), oder evtl mit ein paar Abstrichen und Tricksereien auch parallel in 2U. Wie bekommst du denn die Drehzahl rein? Das einfachste wäre natürlich direkt nen 6°-Puls aus nem Drehencoder ;-) Bei nem 360°-Puls (1 pro Umdrehung), müßtest du dessen Abstand messen, durch 60 Teilen und das als Trigger-Intervall setzen. Aber: sind die Drucksensoren für die hohen Drehzahlen überhaupt schnell genug? Der Hersteller empfiehlt ne RC-Filter mit 650Hz am Ausgang um den Dreck wegzufiltern ...
> Ein Vierzylindermofa. Bei uns hatten die früher nur einen Zylinder mit > kleiner 50ccm. Hab ich mir auch gedacht - und 13500U/min haben die auch nicht geschafft, trotz 2-Takt ;-)
sid schrieb: > Ein vermutlichst triviales Problem Mathematisch schon. fs = 13500/60*60*4 = 54000 Das Problem ist: bei dieser Samplerate kannst du mit dem eingebauten AD-Wandler nur noch knapp 7 verwertbare Bits erwarten. Außerdem sind 16MHz Takt recht ungünstig. Um deine Samplerate zu erreichen, mußt du einen Timer zu Hilfe nehmen und den AD-Wandler durch den triggern lassen. Weil: 54000*13 = 702000 ADC-Takt 16000000/16 = 1000000 16000000/32 = 500000 Der gewünschte ADC-Takt läge also ziemlich genau in der Mitte zwischen den beiden allein mit den Mitteln der ADC tatsächlich erreichbaren.
sid schrieb: > ich hab vier MPX5050DP > Mit nur wenig overhead Mathezeug brauch ich zum auslesen eines Sensors > etwa 124µs sodass ich mit Leerlaufdrehzahl (1200 U/min) > genug Zeit hab (138.8µS pro Grad an der Kurbelwelle) Der MPX5050DP hat eine response time (10% -> 90%) von 1ms. Schnellere Druckänderungen erscheinen erst erst gar nicht am Ausgang. https://www.nxp.com/docs/en/data-sheet/MPX5050.pdf
abalo schrieb: > Der MPX5050DP hat eine response time (10% -> 90%) von 1ms. Schnellere > Druckänderungen erscheinen erst erst gar nicht am Ausgang. War schneller ... #Response Time(7) 7.Response Time is defined as the time for the incremental change in the output to go from 10% to 90% of its final value when subjected to a specified step change in pressure. tR — 1.0 — ms Datenblatt lesen hilft oft :-) https://www.kistler.com/?type=669&fid=101576&model=document
:
Bearbeitet durch User
Und es gibt sowieso nicht "den Druck" bzw Unterdruck im Saugrohr, das ist eine oszillierende Gassäule. Sprich: Ort des Sensors, Frequenz (also Drehzahl) und garantiert auftretende Resonanzen und Übersprechen aus den anderen Saugrohren via Airbox haben entscheidenden Einfluss auf den Messwert. Mit den passenden math. Modellen kann man das aber gut "geraderechnen", das funktioniert aber garantiert nicht auf nem ATMega online. Aber wenn schon der Sensor keine ausreichende Bandbreite hat ist sowieso alles sinnlos.
Hey, dank Euch schonmal.. Guest schrieb: > Die 12.45µS pro Grad glaube ich dir jetzt mal hab es > nicht nachgerechnet. Das sind ca. 80Khz. Der Atmega328p hat einen ADC > der 15Ksp/s hat ja sind aber lustigerweise 12._3_45µs (klingt ausgedacht, ich weiss) denn ich muss mich leider an floats klammern und die sind langsamer als ints.. sodass ich bei 132µS pro Lesezugriff lande, nicht 124 :( (analog read ~109µS plus zählerschleife plus float Zeug) Christoph M. schrieb: > Ein Vierzylindermofa. Bei uns hatten die früher nur einen Zylinder mit > kleiner 50ccm. > Poste doch mal deine Meßkurven und das Programm, damit man mal sehen > kann, ob überhaupt was zeitlich aufgelöst wird. zwei Räder.. macht bräppbräppbräpp und rollt = Mofa.. Kann später die Jungs mal Freiluft atmen lassen, aber anklemmen mag ich sie grad nicht; Müsst ich ne Stunde das Mofa für zerlegen bis ich überall drankomm, da hab ich nur so Mittel Lust zu für 'aus Spass' ;) Aber klar n demo-read kannste kriegen denk ich. zeitliche Auflösung ist aber kein grosses Thema, ich schreib die Werte nur in ein Array und zeig den Plot später statisch an.(also semi-statisch hab mich noch nicht für ein Sinnvolles Aktualisierungsintervall entschieden) foobar schrieb: > Bei 6° ergeben sich bei 1200U/min eine Samplerate von 1200Hz, bei > 13500U/min entspr 13500Hz. Pro Kanal. Sollte machbar sein, entweder > einen Kanal nach dem anderen (insg 8U), oder evtl mit ein paar > Abstrichen und Tricksereien auch parallel in 2U. Wie bekommst du denn > die Drehzahl rein? Das einfachste wäre natürlich direkt nen 6°-Puls aus > nem Drehencoder ;-) Bei nem 360°-Puls (1 pro Umdrehung), müßtest du > dessen Abstand messen, durch 60 Teilen und das als Trigger-Intervall > setzen. Drehzahl ist ein echt heikles Thema grad.. Kaggomobil möchte mich dahingehend ärgern.. ich hab aber n digitales 5V Drehzahlsignal am Tacho, im schlimmsten Fall greif ich das ab... hate gehofft ich hätte n Servicestecker, der verändert aber nur das Einsprtzmapping... na Hauptsache... :() der KW Positionssensor triggert nur einmal pro Umdrehungen leider, kann also keine Winkelgenaue KW Position auslesen. Ich bin auch nicht zu pingelig was die 6° angeht ehrlich gesagt. mir geht's nur darum eine sinnvoll hohe Auflösung (120 werte) über den vollen viertaktzyklus (720°) zu bekommen, und möglichst gleichmässige Abstände zu haben versteht sich. (das sind rechnerisch eben 6°) der mir wichtigste Fall (Leerlauf zum Drosselklappenabgleich der Einspritzanlage) funktioniert mit Trigger Intervall ganz ordentlich (4-8µs Fehler über 4x120 samples finde ich akzeptabel grade) Ich messe die Zeit zwischen zwei Umdrehungen ehrlich gesagt garnicht, ich 'erwarte' mathematische Übereinstimmung und errechne direkt den Abstand der 'Lesungen' anhand der Drehzahl (also bei 1200U/min 833.3µS für zwei Abfragen an Sensor 1) und Sensoren 2,3 und 4 passen halt da bequem noch zwischen, also laufen die in derselben Schleife mit. Das ist die Schleife die mir Momentan die Stirn vernagelt.. denn das funktioniert so bis maximal 2000 rpm (bei ints statt floats komm ich wie gesagt auf 124µs und hab n Leseabstand von 500µS pro sensor [und die anderen drei passen noch dazwischen]) Das hilft mir halt nur für den Drosselklappenabgleich, nicht aber um Fehler in der Einspritzanlage zu erkennen oder undichte Ventile oder oder oder... dafür brauch ich halt deutlich mehr Drehzahl. foobar schrieb: > Aber: sind die Drucksensoren für die hohen Drehzahlen überhaupt schnell > genug? Der Hersteller empfiehlt ne RC-Filter mit 650Hz am Ausgang um > den Dreck wegzufiltern ... Ja das hab ich aber ehrlich gesagt auch zu spät gelesen, weiss ich noch nicht wie ich das realisieren kann sinnvoll.. Weiss garnicht genau.. irgendjemand hatte die MPX in nem Selbstbau Zweizylinder Synchrontester auf youtube... und das hat mir schon gereicht um sie als versuchsobjekt in Betracht zu ziehen ;) Der Atmega selber ist ja schon nicht schnell genug.. 109µS braucht er für's auslesen eines Sensors.. deswegen muss ich das Auslesen ja sinnvoll auf mehrere Umdrehungen verteilen, Sensor eins sollte lesen 0, 6, 12, 18, 24...Grad ich bin aber mit 0, 726, 12, 738, 24 .. Grad einverstanden oder jedem notwendigen addieren von 720°, es soll halt nur zeitlich so kompakt wie möglich passieren c-hater schrieb: > Das Problem ist: bei dieser Samplerate kannst du mit dem eingebauten > AD-Wandler nur noch knapp 7 verwertbare Bits erwarten. Ne das kommt leider auch nicht wirklich in Frage Deswegen will ich die Samplerate ja im "verfügbaren" Bereich halten und die Lesezyklen lieber etwas ausdehnen, ich hab lieber n sinnhaftes Bit mehr als ne zehntel Sekunde Zeit gespart ;) (bei 225 U/s sind n paar Umdrehungen eher verschmerzbar als ne bescheidenen Auflösung, nicht wahr ;)) Rechnerisch sollten bis etwa 1850 U/min alle vier Sensoren in zwei Umdrehungen je 120 mal gelesen werden können (2000U/min bei ints... egal) bei 2700 U/min passen noch drei Sensoren in mein Zeitfensterchen von dann 370µs zwischen zwei Primärsensorlesungen bei 3750 U/min würden knapp noch zwei Sensoren gelesen werden können und bei 7550 U/min komm ich auf ziemlich exakt 6° pro 132µS und ab da wird's dann echt spannend weil ich pro Sensor mehr als 2 Umdrehungen brauche (und ich bin ja noch n gaaaanzes Stück von der Drehzahl weg die spannend wird)
sid schrieb: > Der Atmega selber ist ja schon nicht schnell genug.. > 109µS braucht er für's auslesen eines Sensors.. > deswegen muss ich das Auslesen ja sinnvoll auf mehrere Umdrehungen > verteilen, Dein Sensor kann gar nicht so schnell messen - liest Du eigentlich alle Beiträge?
:-) Ansonsten: externe A/D-Wandler, dann kanst du alle 4 Kanäle gleichzeitig messen und hast dann Zeit genug, die in den 6° auszulesen. -entweder ein Chip mit tatsächlich 4 Wandlern -Chip mit 1 Wandler, aber 4 S/H -4 Wandlerbausteine SPI kannst du mit 10MHz takten, das reicht locker.
Hugo H. schrieb: > sid schrieb: >> Der Atmega selber ist ja schon nicht schnell genug.. >> 109µS braucht er für's auslesen eines Sensors.. >> deswegen muss ich das Auslesen ja sinnvoll auf mehrere Umdrehungen >> verteilen, > > Dein Sensor kann gar nicht so schnell messen - liest Du eigentlich alle > Beiträge? zu viel von dem Output des Mofas eingeatmet
Hugo H. schrieb: > Dein Sensor kann gar nicht so schnell messen - liest Du eigentlich alle > Beiträge? Heul doch nicht gleich... abalo's und Deinen Beitrag hatte ich NICHT gelesen (hatte vor meiner Antwort die Seite nicht neu geladen und sie nicht gesehen) Und weil das Antworten länger gedauert hat als gedacht bin ich danach auch los... Ich brauch keine 80% range von dem Chip.. ich denke ich werd eh nie wirklich mehr als 30kPa vakuum ziehen trotzdem blöd ~750µS bei maximal zu erwartender Änderung bei laufendem Motor wird die Änderung sich eher im Bereich von 1-2kPa abspielen; nichts desto trotz, bei langen Sättigungsphasen ist eben schon bei knapp über Leerlauf Schluss und ich muss über mehrere Umdrehungen zählen.. doof.. aber abgesehen davon dass es die Dringlichkeit der Frage erhöht ändert sich doch nicht viel am Inhalt, oder? Also, was meinste.. haste dazu n Vorschlag oder wollste mit der kleinen Waldfee zu Mami um ihr zu sagen dass ich Euch nicht hab mitspielen lassen? H.Joachim S. schrieb: > Ansonsten: externe A/D-Wandler, dann kanst du alle 4 Kanäle gleichzeitig > messen und hast dann Zeit genug, die in den 6° auszulesen. > -entweder ein Chip mit tatsächlich 4 Wandlern > -Chip mit 1 Wandler, aber 4 S/H > -4 Wandlerbausteine Das würde ja leider nicht viel ändern in dem Fall, ausser dass ich das misalignment loswürde, Da ja offenbar der Flaschenhals direkt im Sensor liegt. hier MPX21-er... zweizylinder aber dennoch beruhigend zu sehen erstmal ;) (danke Arno!) Beitrag "Synchrontester für Drosselklappen" back to Schüppe...
> Der Atmega selber ist ja schon nicht schnell genug.. > 109µS braucht er für's auslesen eines Sensors.. Wie kommst du auf diese Zahl?
foobar schrieb: >> Der Atmega selber ist ja schon nicht schnell genug.. >> 109µS braucht er für's auslesen eines Sensors.. > > Wie kommst du auf diese Zahl? Der Typ ist ganz sicher ein Arduidiot. Und genau so ist er an diese Zahl gekommen. Er hat einfach einen AnalogRead()-Aufruf in loop() plaziert. Jede Wette...
foobar schrieb: > Wie kommst du auf diese Zahl? c-hater schrieb: > Der Typ ist ganz sicher ein Arduidiot. Und genau so ist er an diese Zahl > gekommen. Er hat einfach einen AnalogRead()-Aufruf in loop() plaziert. > Jede Wette... Der Typ haut Dir ganz sicher n paar aufs Maul solltest Du ihm irgendwann übern Weg laufen.. Aber Recht haste.. hab in der Schleife gelesen (glaub 10k mal) und dann dividiert mal mit, mal ohne banal Mathe (hab sogar überflüssige Mulitplikation und Division vorher gegeneinander gekürzt, was wahrhaften Idioten schon schwer fällt selbst bei so simplen Dingen wie /60*60 ;)) mal mit linearer Arraybefülllung mal mit phasenverschobener.. solange bis ich ne Dauer hatte die mir stabil und vorhersehbar genug schien.. wie sonst möchtest Du den Durschnittswert errechnen? Und ja mal per ADC Register tatsächlich auch per ArduinoLibrary (ich bin alt.. ich mag bequem!) und da ich eh auf die Konvertierung warten muss war der Unterschied wirklich nicht nennenswert . Aber damit macht der 4Wandler AD Chip fast wieder Sinn, muss ich nochmal n bisschen drüber nachdenken. die Phasenverschobenen Arrays haben mich übrigens auf die Lösung gebracht. oder zumindest eine vertretbare Lösung ohne aufgerüstete Hardware. brauch ja nur die kleinstmögliche Winkeldistanz als 6x dann kann array[x] = ADC .. uups 'tschuldige .. analogRead(A0) :D bei allen (asser der magischen 7) verlier ich pro 720° an der Kurbelwelle 1000000/RPM an µs also insgesamt maximal 528µs dauert der ganze Kram also 64ms oder weniger egal bei welcher Drehzahl.. Damit kann ich sicherlich leben oder was meint Ihr? könnte mich sogar fast dazu hinreissen lassen es mal mit der millisekunde zu testen (121ms klingt auch nicht so als würde mein Bart dadurch grauer)
Du könntest auch akzeptieren das für deine Anwendung das Teil zu langsam ist und einen Controller verwenden der ADCs besitzt die schnell genug sind. Dann müsstest du doch tatsächlich keine Abstriche machen und nicht noch ein extra IC benutzen. Wenn du unbedingt bei Arduino bleiben willst nimm ein BluePill der F103 hat meine ich 1Msps und wenn es auch normales C sein darf bei dem man keine Arduino Libs hat nimm ein Nucleo32/64 da gibts F3 und co mit 3-5Msps. Teilweise haben die sogar 2 oder 3 ADCs. Ich meine sogar die Nucleos lassen sich mit der ArduinoIDE programmieren? Zumindest teilweise bin da nicht so auf dem laufenden.
Guest schrieb: > Du könntest auch akzeptieren das für deine Anwendung das Teil zu langsam > ist und einen Controller verwenden der ADCs besitzt die schnell genug > sind. Dann müsstest du doch tatsächlich keine Abstriche machen und nicht > noch ein extra IC benutzen. Mein Nano wurde höchstwissenschaftlich ausgesucht.. "pseudo randomly generated sample" glaub ich nennt man das (kurz: er ist mir aus der Schublade gefallen... tadaaa :D) Ist mir völlig Hupe welcher Prozessor dranklemmt, ich hatte ihn halt grade in der Hand, liess sich kurz an den USB Port klemmen (ich hatte ja gesagt, dass ich bequem erstmal gut finde ;)) und er schien mir alles zu haben was ich glaubte zu brauchen. Wie ich vielleicht schon angemerkt habe ist das mehr Prokrastination als alles Andere.. will halt wissen wie weit ich es so treiben kann mit Code (falls jemand das SynX von X-log kennt... ) quasi wie nah man mit 'nix' and die Funktionen kommt.. vielleicht ein zwei Andere; Also n billiges Display geschossen, n paar Sensoren geordert (alles nahezu genauso wissenschaftlich.. das Erstbeste was mir in die Finger kam) Auf Lochrasterkarten gespuckt und mal gucken... SOLLTE das in irgendeiner Form dauerhaft brauchbar sein, also es statt "Tonne" das Label "Verbesserungswürdig" erhält, dann mach ich mir n Kopf um 'vernünftige' Hardware; wie ordentliches PCB, n besseres Display (nextion find ich zum würgen, wollte das aber mal probiert haben) ordentliche Signalfilter, Stromversorgung, eventuell n SignalAmp und son Zeug (hätte auch lieber 12bit ADWandler ehrlich gesagt) Aber mal ernsthaft, ich find jetzt ~64ms garnicht sooo schlimm (ohne extra ad wandler), im Gegenteil, bin ja sogar Willens (in der Hoffnung auf ein klareres Signal der Sensoren) 121ms zu tolerieren. und beides kann der Kleine noch locker verarbeiten. bei 15ksps sind das 480 von 960 respektive 1815 möglichen Samples die ich nehme oder hab ich mich da verrechnet? Ist der BluePill nicht n ARM Cortex? klingt mir overkill n bisschen.. egal.. guck ich mir mal an für den Fall dass ich noch was in besagte Schublade werfen will :D (ne ernsthaft ich hab da gerne solch Spielzeug drin) ich guck erstmal wie lange sone Schleife in Wirklichkeit braucht.. (ja .. loops.. schon wieder.. und jaaa mehrere zum Durchschnitt rechnen... uiuiui.. kicher) Nächster Schritt wär dann glaub ich n Datenlogger (der SD Slot im Nextion ist ja leider wertlos) In der Schublade staubt noch n NodeMCU vor sich hin kicher... mal sehen
> Aber Recht haste [...]
War das jetzt unbedingt nötig, c-hater in allen Punkten zu bestätigen?
:-/
Der 328 ist nicht zu langsam, du benutzt ihn nur falsch. Mit deiner
Aufgabe bist du an die Grenze gekommen, was mit Arduino (dem
SW-Framework, nicht den Boards) sinnvoll machbar ist. Das ist, als wenn
du versuchst, mit Fischertechnik ein Meßgerät zu bauen. Schnapp dir das
Datenblatt des Atmega328 und schau, was das Teil wirklich kann.
PS: Man muß nicht unbedingt an der kritischsten Stelle langsame
Rechnoperation machen, wenn man sie auch gemütlich im Anschluß
durchführen kann.
PPS: Falls du in Kode von mir irgendwo etwas wie "/60*60" siehst: lass
es drin - der "Idiot" wusste, was er tut!
sid schrieb: > 124µs > ... > 138.8µS > ... > 12.45µS Guest schrieb: > 12.45µS > ... > 15Ksp/s > ... > 3,75Ksp/s c-hater schrieb: > fs = 13500/60*60*4 = 54000 Wer findet die Fehler? Tip: https://de.wikipedia.org/wiki/Elektrischer_Leitwert https://de.wikipedia.org/wiki/Hertz_(Einheit)
@sid: dubist mir aber eine knalltüte. Nimm doch jeden 5ten Order 10ten Messwert, du alle Zeit der Welt im Gegensatz zu Controller.
sid schrieb: > Also, was meinste.. haste dazu n Vorschlag oder wollste mit der kleinen > Waldfee zu Mami um ihr zu sagen dass ich Euch nicht hab mitspielen > lassen? Ein bisschen schwer von Begriff und ein loses Mundwerk - eine schlechte Kombination. Da ist auch ein Link Beitrag "Re: Hilfe beim Brett von Stirn lösen [Analoge Sensoren Atmega328p]"
P.Isa schrieb: > Wer findet die Fehler? Erleuchte uns? Ich sehe den Zusammenhang mit dem Leitwert und der Sampelrate grade nicht.
foobar schrieb: > Der 328 ist nicht zu langsam, du benutzt ihn nur falsch. Mit deiner > Aufgabe bist du an die Grenze gekommen, was mit Arduino (dem > SW-Framework, nicht den Boards) sinnvoll machbar ist. LOL, das erste ist mit Sicherheit korrekt :D Ich hab die Register nicht alle im Kopf und noch weniger die dazugehörigenden Bits.. nichts desto trotz findet das meiste in Bitregistern statt (cheatsheets sei dank ...) der 'abgenickte' code steckt in nem AVR-Studio Projekt, nicht in dem Arduino Ding (obschon ich da den serial plotter mag ;)) Nach n paar Durchläufen durch den ADC (register notiert) und n paar durch das lazylibrary hab ich kaum Unterschiede in der Geschwindigkeit festgestellt. gebe aber zu dass ich für die Schleifen viermal denselben Pin las und jeweils auf den ADC gewartet hab und eben nicht auf ne ISR gesetzt hab. Wüsste jetzt auch nicht wie ich vier sensoren 'zeitgleich' in eine Konvertierungswarteschlange schickte, wenn du da n snippet hast, danke ich Dir für den Tipp. Dieter schrieb: > Erleuchte uns? Ich sehe den Zusammenhang mit dem Leitwert und der > Sampelrate grade nicht. er nimmt mir übel dass ich das s gross-schrieb Sekunde ist kleines s.. Siemens Grosses. ksps (kilo-spmples-per-second) hat kein Schrägstrich klingt mir etwas Kleinlich... aber das wär jetzt das einzige was ich an den Zitaten da 'falsch' sähe. und 13500/60*60*4 = 54000 abgesehen von 60-ern (was im Grunde nicht falsch ist sondern nur überflüssig) seh ich da nix denn 13500 * 4 ist tatsächlich 54000. Ich gehe aber davon aus, dass P.Isa mit amerikanischem PEMDAS Mist denkt und es damit als 13500/14400 liesst (also 13500/(60*60*4)) was 0.9375 wär. könnten dann aber fast auch schon 13500/(60*60) * 4 sein also 15... man weiss es nicht :D
sid schrieb: > ksps (kilo-spmples-per-second) hat kein Schrägstrich Wozu der Strich das p heißt doch schon per / pro :D Ich kenn das auch nur so "ksps" Naja Hauptsache er konnte sich mitteilen :D
Ich trenn das mal: sid schrieb: > und 13500/60*60*4 = 54000 > abgesehen von 60-ern (was im Grunde nicht falsch ist sondern nur > überflüssig) > seh ich da nix denn 13500 * 4 ist tatsächlich 54000. Und ja ich weiss Gedankenfehler lassen sich schwer kommunizieren manchmal. Ich versuch mal zu erklären, was ich glaube c-hater gemeint hat: 13500 U/min sind (DURCH 60s) 225 U/s die vier ordne ich den vier Sensoren zu, und die 60 nehme ich an hat er aus den Zwei Umdrehungen pro Verbrennungszyklus und den 120 Ablesungen gebastelt (120/2 halt) Das ist jdf was ich daraus verstanden hatte.. sodass man rechnerisch auf 54000 Ablesungen pro Sekunde kommt was meines erachtens mit der *13 später (Takte pro ADC konvertierung) bestätigt wird.. hiesse 18.518µs zur Verfügung pro Ablesung... was n bisserl knapp ist vorsichtig formuliert. c-hater kann mich da gerne korrigieren, aber so hatte ich ihn verstanden
sid schrieb: > und 13500/60*60*4 = 54000 > abgesehen von 60-ern (was im Grunde nicht falsch ist sondern nur > überflüssig) Es ist in diesem Fall zufällig überflüssig. Es ist nämlich nur in dieser konkreten Anwendung zweimal derselbe Zahlenwert. Die Bedeutung ist aber völlig verschieden. Die erste 60 dient zur Umwandlung von U/min in U/s und kommt daher, weil eine Minute nunmal 60 Sekunden lang ist. Die zweite 60 hingegen steht dafür, das halt die gewünschten 6° in 360° genau 60 mal vorkommen, pro Umdrehung also 60 Samples nötig sind. > Ich gehe aber davon aus, dass P.Isa mit amerikanischem PEMDAS Mist denkt Die Sache ist aber: genau danach stimmt es. Klammern gibt's keine, alle vorkommenden Operationen sind gleichrangig, also wird der Ausdruck schlicht von links nach rechts ausgewertet. Und dann kommt auch genau das Richtige raus. Ist doch nicht meine Schuld, wenn hier nur mathematische Vollidioten unterwegs sind, die nicht mal das Grundschulwissen anwendungsbereit haben...
c-hater schrieb: >> Ich gehe aber davon aus, dass P.Isa mit amerikanischem PEMDAS Mist denkt > > Die Sache ist aber: genau danach stimmt es. Klammern gibt's keine, alle > vorkommenden Operationen sind gleichrangig, also wird der Ausdruck > schlicht von links nach rechts ausgewertet. Ne bei PEMDAS ist Multiplikation höherrangig... oder wurd das eingedeutscht und mir hat keiner was gesagt? Egal.. Werte ohne Einheiten sind aber ... eben 'Bedeutungslos' Egal was P.Isa da als Fehler sieht ich hatte Dich ja verstanden, ging von 120 Samples/2 Umdrehungen aus statt von 360°/6gradprosample (was hier nicht ganz zufällig dieselben 60 Samples pro Umdrehung ergibt ;)) Was ich vielleicht Eingangs nicht ordentlich kommuniziert habe war folgendes: ich will ja garkeine 54ksps erreichen.. ich bin mit bequemen 7,58ksps durchaus zufrieden, wollt von Euch wissen wie das am einfachsten zu realisieren ist dennoch möglichst effizient das Array zu füllen.. aber das hat sich ja vorerst erledigt :D Guck grade wie ich ne schwingende Luftsäule auf meinen Schreibtisch gebastelt bekomme ohne selber ins Röhrchen hecheln zu müssen ... Luftballon und vibrationsmotor? defekter PC Lüfter und venturi rohr? Stethoskop und eigener Puls? ich geh Schublade...
sid schrieb: > Ne bei PEMDAS ist Multiplikation höherrangig... Unsinn. https://www.mathsisfun.com/operation-order-pemdas.html
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.