Posts by Franky07

Moinsen,

Quote from Fliegenhals

Eigentlich braucht es wenn nur um den Schutz vor Unterspannung geht, für so eine Aufgabe keinen Mikrocontroller. Das bekommt man auch mit nur einem OPV und etwas "Hühnerfutter" hin. Mögliche Suchworte wären: OPV als Spannungswächter bzw. OPV Komparator o.ä.

Damit sind wir wieder bei der Frage, was verbraucht eine solche Schaltung - auch wenn es nur ein Window-Komparator ist - im Dauerbetrieb ? Der Spannungsteiler wird hier wieder zum Zünglein an der Waage. Geht man sehr hochohmig ins Rennen, hat man den Nachteil, dass auch der Komparator auf diese Eingangspannungsschwankungen reagiert. Keine wirklich gute Idee, wenn dann der OPV willkürlich in Abhängigkeit irgendwelcher Störungen diese ganze Apparatur ein- und ausschaltet.
Nimmt man nun einen Tiefpass Filter, der je nach Umfeld was keiner von uns kennt, sogar aktiv ausgelegt werden muss, weil einfache RC Glieder nicht mehr ausreichen, benötigt man noch eine Spannunsgrefernezquelle, die auch gleich mal mit 280µ im Leerlauf zu Buche schlägt, dann noch je nach gewünschter Flankensteilheit des Filters nochmal bis zu 3 einzelnen OPV Elementen die nach dem Spannungsteiler zum Einsatz kommen müßten. Nimmt man hierfür einen typischen Vertreter wie den 6061 der auch wieder pro OPV Einheit 60µA verbrennt
Hier wird das mathematische Modell recht eng, um hier gegenüber einer µC Lösung bezogen auf den Dauerstromverbrauch bestehen zu können.
Man kann hier auch ganz schnell ohne die realen Umgebungsbedingungen zu kennen, und ohne zu wissen, ob der TO auf eine Visualisierung vai LED oder einer Echtwert-Spannungsanzeige wert legt nicht nur Funktionsstörungen herbeiführen, sondern auch sinnlos Strom verbrennen.

Moinsen,

was ist daran Komplex ?
Es ist ein Thema, wie jedes Andere was sich mit technischen Umsetzungen beschäftigt.
Dazu muss man erst einmal die genaue Aufgabe kennen, bzw definieren können was im Ergebnis herauskommen soll. Dazu zerlegt man nicht nur gedanklich das Thema, oder diese Aufgabe in Einzelpunkte /-schritte.
Das heißt, hier beginnt es mit der optischen Erfassung eines x-beliebigen Objektes. Dazu muss man die Grundlagen und Gesetze der Optik beherrschen, zumindest verstanden haben. Wenn man es einmal gesehen hat, wie es mir vergönnt war bei Pentacon, (ein ehemaliger Kamerahersteller der DRR, welcher neben Carl Zeiss Jena Weltruf für seine Qualität hatte) und gesehen hat was die für einen Aufwand besonders in der Fertigung und Endkontrolle ihrer selbst hergestellten Objektive betrieben haben wird einem klar, dass das nicht mit Standard- und Serienprodukten, die zudem einer viel höheren Fertigungstoleranz unterliegen umsetzbar ist. Dazu solltest du evt. mal in ein Labor / eine Forschungseinrichtung gehen, die sich mit Optik beschäftigt. Wenn du dann ein Objektiv mit minimaler Autokorrektur hast, wo der Strahlengang innerhalb dieses ( gut heute hätte man mehr Möglichkeiten, jedoch auf dem Rechenweg - siehe die Erfindung der adaptiven Optik ) wirklich zum Bildsensor passt. Aber was einem damals schon aufgefallen ist, dass dieser rein mechanische Aufbau eines Objektives mit der exakten Lagebestimmung aller optischen Komponenten eine Herausforderung ist. Diesen Weg müssen alle Hersteller gehen, die solche Systeme entwickeln, bauen und anbieten wollen. Das ist die elementare Grundlage für das spätere Auflösungsergebnis.
Dann muss man mathematische Modelle entwickeln wie man nicht nur Kanten, Positionen und andere Dinge zur Meßergebnisfindung ( Grundlagen wie erkenne ich eine Kante, einen Winkel, einen Radius zweifelsfrei ) immer wiederkehrend mit der gleichen Präzision erkennt. Damit kommt der zweite Punkt hinzu, wie ist die Ausleuchtung des Meßobjektes, passiert das über Konturschatten, oder muss man auf einer Fläche egal wie diese im Raum steht / liegt, Punkte rein anhand von Kontrastunterscheiden finden ? Und hier beginnt dann das Spiel mit der Mathematik. Dann muss man bedenken, was jeder wissen sollte, dass je näher man im Strahlengang der Randzone eines Linsensystems kommt, um so mehr beginnt auch die Parallaxe zu wirken.
Und dann beginnt das Spiel was oder wie gehe ich an eine spezielle Meßaufgabe heran. Für uns als Industrieelektroniker ein Gebiet, wo wir nur staunen konnten, welche Lösungswege man verfolgen kann. Dazu muss man auch die Fehler in den mathematischen Berechnungen im Auge behalten. So hat man uns auch gezeigt, welchen Unterschied es macht, und da kommen dann auch schon die kleinen Rundungsfehler mit ins Spiel wie bei einer Computerberechnung auftreten können. So hatte man netter Weise mehrere Auswerteverfahren vorgeführt. Einmal hat man das Meßobjekt als mathematisches Model nach der Lageidentifizierung in eine für die Auswertung günstigere Lage um die optische Achse eingedreht, und dann mit einfacheren Methoden Abstände ermitteln zu können. Im Vergleich dazu ohne diese mathematisch optische Ausrichtung alles über einen Wust an hochkomplexen Formeln mit Winkelberechnungen im Raum. --> Einmal hat man nur den Fehler, der sich dann aber auf alle Meßpunktbeziehungen auswirkt, dass jede Drehung eines Bildes abhängig von dem Rotationswinkel immer mit einer Wertverschiebung /-verfälschung einhergeht. Alternativ das Bild so gelassen, und alle Berechnungen von irgendwelchen Bildpunkten nur dann ausgeführt, wenn diese Ansammlung von Bildpunkten relevant wurde.
Als Vergleich hatte man die Aufzeichnungen eines Konturschreibers. Schlußendlich für diese Meßaufgabe war es bezogen auf die Wiederholbarkeit und Repoduzierbarkeit besser , günstiger, oder genauer, dass man erst diese mathematische optische Rotation des Einzelbildes über mehrere Mathematische Wegmodelle erzeugt hat, diese neuen neuen eingedrehten Objektbilder dann übereinander gelegt hat, und dann noch den Mittel, oder Durchschnittswert bestimmt hat, bevor man mit dem eigentlichen Meßvorgang, bzw erste einmal mit der Bezugspunktfindung begonnen hat. Daz hat man uns die Meßreihen gezeigt, dass man ein und das selbe Objekt immer und immer wieder neu in der Meßaufnahme eingespannt hat, und wiederkehrend vermessen hat. Hier jetzt für diesen einen Anwendungsfall war es besser, was die Reproduzierbarkeit angeht, dass man erst das Bild des Objektes mathematisch eingedreht hatte, bevor man die Bezugspunkte gesucht und anschließend erst ausgewertet / vermessen hat. Und somit muss man sehr wohl die Meßaufgabe schon kennen, ohne dass jetzt die äußeren Komponenten (Kamera mit Objektiv und Fokusiereinrichtung) noch einen Einfluß haben.
Deswegen jetzt zu sagen, ich habe dieses oder jenes Kameramodell mit dieser Optik, und kann alles messen, ist ein Illusion.

Wenn du ein gezeichnetes geometrisches Objekt auf einem ebenen Stück Papier einfach von oben halbwegs lotrecht abfotografierst, und dann vermisst, dass ist noch der einfachste Teil der Aufgabe. Ein echtes räumlich vorhandenes Objekt zu vermessen, dass ist die Kunst, die man nicht mal so aus dem Ärmel schütteln kann. Für unser Berufsbild war ja hauptsächlich der elektronische Teil, hier die Besonderheiten bei der Einrichtung und Wartung der Beleuchtungseinheit ausschlaggebend. Sowie die Vorgänge um den Kalibrierprozess zu verstehen. Der Rest, aber für deine Aufgabe Maßgebend, war für uns nur Wissens-Beifang.

Moinsen,

Und was hast du an der Sache nicht begriffen ?
Egal auf welchem Linux System du drucken willst, brauchst du wie auch unter Windows einen Spooler.
Wie das Kind nun heißt, ob CUPS , oder sonstewie ist vollkommen egal.
Den CUPS Dienst als Printserver mit Netzwerkfreigabe einzurichten macht nur dann wirklich Sinn, wenn mehrere Clients auch mit unterschiedlichen OS in einem Netzwerk vorhanden sind, bzw, wenn du darüber auch noch die volle administrative Kontrolle inkl. Protokollierung benötigst. Was in Firmen, besonders wenn es mehrere Drucker gibt, auf die nicht jeder oder nur auf Grund der Benutzerzugriffsregeln jeden Drucker benutzen darf.
Mit der Methode kannst du vielleicht Windows austricksen. Aber wenn der Netzwerkdrucker schon mit einem eigenen Network Interface sich im Netzwerk befindet, wird CUPS diesen auch immer wieder finden. Oder du mußt massive Eingriffe vornehmen. Zudem was soll das ganze werden ?
Ein 3er PI mit max 1GB RAM und dann noch einen Farblaser ? Junge dir ist schon bewusst, was ein solcher Druckauftrag an Rohdaten abwirft ? Geschwindigkeit wirst du damit keine erzielen, dann kommt noch der Datenträger im PI hinzu, den du ggf sogar dazu ermächtigen musst, Temp / oder SWAP zu schreiben. Auf einer SD Card keine besonders gute Idee !

Zu deinen anderen Problemen, die sind Hausgemacht.
Wer als erster kommt malt zu erst. Ist so. Wenn dann kannst du auch in der erweiterten Druckerauswahl- und Einstellungsmenü dem Auftrag eine Priorität einräumen, wenn es den Zentral sein soll. Und du wirst es ohne das Backend zu verbiegen nicht schaffen, dass ein laufender in Bearbeitung stehender Druckauftrag unterbrochen wird, nur das dein Prio 1 Gerät jetzt als nächstes Drucken darf.
Du kannst lokal dem PI eine Standardeinstellung mitgeben, dass es automatisch einen Auftrag mit höchster Priorität erzeugt, und der Rest ordnet sich dann halt dieser Prioritätsregel unter.

Als letztes noch, wenn man die realer Netzwerkdurchsatzgeschwindigkeit eines PIs hier einem 3er betrachtet, und der soll dann sowohl über diese eine Schnittstelle die Druckaufträge von den Clients entgegennehmen und aber auch über die selbe Schnittstelle die Daten zum Drucker senden, das ist wie 5 Schritte rückwärts mit anschließend noch einmal auf die "Fresse" fliegen.

Machbar ja, aber sehr aufwendig, vom Nutzen NULL, und von der Praktikabilität und Performance ein Schritt zurück ins Diskettenzeitalter.

Moinsen,

Was willst du betrachten, wenn du die Rahmenparameter nicht benennen kannst ? Schwachsinn ! (Entschuldigung für diese Wortwahl, aber was anderes ist es nicht )

Dann nimmt dir ein Physikbuch aus der "Sekundarstufe I" zum Thema Optik, und berechne mal den Strahlenverlauf an einer Sammellinse. Und dann übertrage diese Wertbeziehungen auf ein Objekt was sich nicht Lotrecht zur optischen Achse Kamerasensor -> Objektiv / Fokusiereinheit befindet. Schon wirst du merken, dass das alles nur Quatsch mit Vaniliesoße ist. Dazu musst du nur den Strahlengang durch das Objektiv als Abweichung zur optischen Mitte des Bildsensors betrachten. Was bei einem Foto nicht ins Gewicht fällt, wird hier der entscheidende Punkt ob und viele du als Bildausschnitt des Gesamtkamerabildes überhaupt verwenden kannst.
Und um es dir noch einfacher zu machen, ohne einen Maßbezug zu kennen kannst du nicht pauschal ohne die tatsächliche Entfernung zum Meßobjekt zu kennen eine Körpergröße eines Menschen bestimmen.
Man könnte jetzt theoretisch sagen, ja der Kopf eines erwachsenen Menschen hat in der Frontalansicht eine Breite von x1 bis x2 ! Das geöffnete Augen als Objekt größer als ein Kamerapixel wird ab der Entfernung zweifelsfrei bestimmbar. Und dann ? Damit ohne einen Kalibriermaßstab zu haben kannst du so nur auf etwa einen Dezimeter schätzen, aber nicht messen !

Und was diese Etiketten angeht, das ist nicht messen, das ist Objekterkennung. Bzw eine Informationsfilterung auf Grund von Bar- oder QR Code. Das sind zwei vollkommen unterschiedliche paar Schuhe. Denn bei eine Bar Code wird nur das Abstandsverhältnis aus Breite und Lücke zueinander betrachtet und ausgewertet. Hier ist nicht gefordert wie lang auf 1 mm genau ist ein solcher Strich. Das ist reines Verhäältnis gerechne, mehr nicht.

Moinsen,

Wo ist das Problem ?

Das Servo hat eine Betriebsspannung. Die muß größer sein als der Signal Pegel der vom PCA kommt. Also irgendwas zwischen 3,3 und 6 V - je nach Servo,
Dann hat jedes Servo hat 2 besser 3 Strome die kennzeichnend sind. Der Ruhestrom ohne mech. Last. ist immer der kleinste Wert. Dann der Haltestrom um eine Position bei max Drehmoment halten zu können, und der eigentliche Stell-Strom. Hier gibt es Unterschiede, bezogen auf die maximal Stellgeschwindigkeit, und dem Ausbrechpunkt wo das Servo mit maximalen Drehmoment eine entgegengesetzte Bewegung herbeiführen soll. Hier suchst du dir den größten Stromwert - oder Peak heraus, und packst dort noch einmal 15% drauf. Das multiplizierst du mit der Anzahl der Servos, die du gleichzeitig über diesen Decoder betreiben willst, und gehst mit diesem Wert Strom und Spannung auf die Suche. Wichtig ist nur das das Netzteil ein Gleichspannungsnetzteil sein muss ! Und das dieses Dauerstromfest sein muss. Wenn die Servos permanent an ihrem Leistungslimit ackern müssen sind Netzteile falls es sich um sicherheitsrelevante Baugruppen handelt ( hier die Betrachtung, was könnte passieren - möglicher Weise auch ein menschlicher Schaden, wenn das Netzteil ausfällt ) mit einer Thermosicherung ungeeignet.

Moinsen,

Was willst du den überhaupt messen ? Wie groß ist das Meßobjekt überhaupt, und wie viel Anteil hat dieses in deinem Kamerabild ?
Welche Meßgenauigkeit erwartest du, oder beabsichtigst du zu erzielen ?
Wie sind die Rahmenparameter für oder während des Meßvorgangs ?

Hier muss man allgemein sagen, das man sich erst einmal mit dem Vorgang einer Bildauswertung überhaupt beschäftigen muss, zudem auch die äußeren wie inneren Einflußfaktoren kennen muss.

Ich hatte vor Jahren mal im Rahmen meiner Berufsausbildung die Möglichkeit bei der Firma Pentacon in Dresden die Möglichkeit erhalten, mich darüber zu informieren. Hier ging es um InProcess Messungen mittels eines Kamera-Systems während einer mechanischen Produktion.
Billig- oder LowCost ist das nicht. Schon wenn du Ergebnisse mit einer reproduzierbaren Meßauflösung von unter 1 mm anstrebst, mußt du so viele Bedingungen alle aus dem Bereich Optik beachten, damit du überhaupt zu einem Ergebnis kommst.
Das beginnt mit der Kamera Optik selber, der exakten Abstandsermittlung zum Meßojekt selber, der Abweichung zur optischen Achse und endet mit der Lagebestimmung im Erfassungsfenster der Kamera selber. Dann kommen noch alle Fehler hinzu die durch den Kamerasensor wie auch durch die Fokusiereinheit entstehen. Weiterhin kommt ein möglichst schattenfrei Ausleuchtung des Meßobjektes hinzu. Dann kannst du auch nicht den gesamten Bildausschnitt des Kamerabildes verwenden, sonst werden die Meßfehler allein durch die Parallaxe exponentiell größer.
Eine Objekt-Erkennung und damit die Ausrichtung / Verdrehung des Objektes XY im Kamerabild kannst du noch mit OpenCV machen. Aber dann wir es richtig kompliziert.
Abgesehen davon, daß du dir für jedes zu messende Objekt eine eigene Kalibriermethode einfallen lassen mußt. Denn ohne die Ausrichtung / Verdrehung zu kennen, die du mind. anhand drei eindeutiger Identifikationsmerkmale festmachen mußt kannst du nur schätzen ! Dazu muß man auch den Aufbau des Kamerasensors kennen, weil du mußt die reale Pixelanordnung des Sensors auf die Meßfläche projizieren. Damit wird klar, das eine Körperkante nicht oder was du auch immer als Meßwertbezug nutzen möchtest niemals aus einer Linie, sondern immer aus einer Treppe ( Pixel ) besteht. Das kannst du mal auf einem Stück karierten Papier versuchen gedanklich nachzuvollziehen. Und damit wird klar, daß du dafür auch ein allgemeingültiges mathematisches Modell entwerfen mußt.
Damit kommen noch alle schon genannten Punkte hinzu die dir eine Meßungenauigkeit mehr oder minder erzeugen.

Nur um die mal ein Beispiel zu geben was uns bei Pentacon vorgeführt wurde. Ein zylindrischer Körper, und einer rotierenden Meßaufnahme mit den Abmessungen D=12 mm und einer Höhe von 45mm reproduzierbar auf 0,05 mm zu vermessen (Wiederholgenauigkeit), war zum damaligen Zeitpunkt eine 18 MPix Kamera nötig. Mit der damaligen PC Rechentechnik ( auch schon Mehrkern-Prozessoren ) hat diese Vermessung ausschließlich der Außenkontur fast 2 Minuten gedauert, bis eine vollständiges Meßprotokoll vorlag. Dabei wurden nur Abstände, Winkel und Radien im Konturverlauf vermessen.

Damit sollte klar werden, LowCost mit den Fertigungsfehlern /-toleranzen eines Serienproduktes wie der PiCamera, den möglichen optischen Aufsätzen ( Objektive ) macht dir hier möglicher Weise ganz schnell einen Strich durch die Rechnung.

Moinsen,

Hier muss man mal wieder, Entschuldigung hyle feststellen, daß Gnom in diesem Falle nur wieder an dem Thema vorbei diskutiert, und absoluten Unsinn verbreitet ! Was ich natürlich auch anhand eine Auflistung widerlegen möchte.
Dazu beziehe ich mich auf seine Aussage, daß das PICO als µController einen viel zu hohen Eigenstromverbrauch hätte.

Nach der Formel P = U * I erreichtet sich das ganze wie folgt:
laut Herstellerangabe
0,4 W bei Vc 5,0 Volt ergibt einen Strombedarf von 80 mA unter Vollast, und

0,006 W bei Vc 5,0 V ergibt einen Strombedarf von 1,2 mA im IDLE Modus.

Jetzt weiß ich nicht was sich Gnom darunter vorstellt, wie man ein Spannung messen und darstellen kann und das mit noch weniger Strom ? Also rechnen wir mal weiter.
Gut, wir brauchen noch eine Anzeige.
Was steht theoretisch zur Auswahl ?
- eine 4x7 Segmentanzeige mit TM1637, die schon mal ganz sportliche 30 mA bis 80mA verbraucht ( 2 Datenleitungen )
- ein einzeiliges LCD Display welches 3 mA ohne Hintergrundbeleuchtung, und bis zu 120 mA mit Hintergrundbeleuchtung verbraucht ( mit I²C Adapter auch nur 2 Datenleitungen )
- ein kleines OLED 0,96"" Display bei 3,3 Volt mit 12 mA ( 2 Datenleitungen )

- ein E-Paper mit einem Ruhestrom von 0 mA, und während der Änderungsphase das Darstellungsinhaltes von 5 mA ( Minimum 5 Datenleitungen für den SPI Bus )

( Nur um mal eine kleine Auswahl zu präsentieren )
Das sind Verbrauchswerte die vollkommen unabhängig der Meß- und Auswerteeinheit anfallen.
Nehmen wir jetzt mal einen anderen Vertreter aus der Reihe der µController - einen AVR ATTiny85, der auch alle Displays mit einer 2 Drahtanbindung ansteuern kann, geht aus dem Datenblatt hervor, das dieser in aktiven Phase ohne den IDLE Modus schon einmal 2,65 mA nur für den ADC verbraucht. Dazu kommt noch der Grundstromverbrauch von 1,3 mA mit einem aktiven GPIO als Input + 0,96 mA pro aktiven GPIO Ausgang (also mal 2 ). Damit liegt während der Meß- und aktiven Displaydarstellungsphase der Stromverbrauch unabhängig des Displayverbrauchs bei knapp 6 mA.
-> Gut kann man machen. Aber man benötigt hier noch einen Programmer, zudem muss man die Schaltung selber entwickeln sowie aufbauen. Aber auch der Stromverbrauch, der durch den Spannungsteiler fließt liegt ungefähr bei den Werten die Gnom genannt hat. Wie immer, das Display ist in dieser Berechnung noch nicht enthalten. Im IDLE Modus würde dann jedoch Stromverbrauch auf 20µA absinken. Beachtlich, aber nicht mit jedem Display-Typen möglich !
Ebenso ist ohne Adaptierung keine E-Paper Nutzung möglich. Denn dem Tiny85 fehlt, selbst wenn man den Reset-Pin Weg-Fused und als vollwertiger GPIO zur Verfügung stehen würde damit ein PIN ( 8 DIP ) minus Vc und GND = 6 GPIO-Pins minus ein GPIO als ADC Eingang wären 5 Pins für die E-Papersteuerung. Was aber nicht ausreicht um auch aktiv die Elektronik des E-Paper abzuschalten. Die meisten E-Paper benötigen 6 Datenleitungen + 2 Leitungen für Vc und GND.
Damit zu all den größeren Typen aus der Tiny bzw Mega Reihe / somit auch ein MEGA328 basierendes Arduino Board.
Wenn wir jetzt hier die Stromrechnung aufmachen, liegt Dank der nicht abschaltbaren virtuellen USB-Seriellen Schnittstelle der Gesamt- und Ruhestromverbrauch selbst bei aktiver und intensiv genutzten IDLE ( Stromsparmaßnahmen ) Modus hier sogar über dem was ein PICO verbrauchen würde.

Damit sollte der TO erst einmal die Entscheidung treffen, wie viel Strom ihm eine solche Anzeige Wert ist, wenn diese wie auch die Meßeinheit direkt mit aus oder über diesen "Solar-Akku" versorgt wird.

Bezüglich der Betrachtungen "Wie legt man einen Spannungsteiler aus ?" stimme ich den Ausführungen von SteffenMurks dahingehend zu, das ein niederohmiger Spannungsteiler, wenn dieser geschaltet ( OPV ) verwendet wird hier sehr wohl dazu beitragen kann äußere Störeinflüße zu minimieren. Jedoch würde ich dann den R2 (zu GND) sogar noch kleiner auslegen, und diesen in der Größenordnung um die 4 - 5KOhm dimensionieren.
Hier ist dann die Stromrechnung sehr einfach aufzumachen.
Für die eigentliche Messung steigt dann der Strombedarf auf 2mA die durch den OPV fließen, inkl. des Eigenbedarfs dieses - hingegen während der Ruhephase der Strombedarf auf ca. 10nA absinkt.
Um den Dauerstrombedarf von 50µA bei diesem hochohmigen Spannungsteiler ala Gnom darzustellen reicht hier ein Reduzierung der Meßzyklen je Zeiteinheit. Nehmen wir hier noch die aktive Verzögerungszeit des OPV nach dem Einschalten mit in diese Berechnung auf, die 0,01 µSek beträgt. Dazu die Meßzeit die der ADC zur Erfassung benötigt von 2 µSek , haben wir eine Stromverbrauch von 2,6mA / 2,1µSek für den OPV + Spannungsteiler. Rechnet man nun noch den Stromverbrauch des µControllers als aktives Element hinzu, kann man damit 23 Messungen pro Sekunde bei konsequenter Umsetzung des geschalteten OPV wie auch des Sleep-Modus des µControllers umsetzen, ohne das man diese permanent fließenden 50 µA über einen längeren Zeitraum betrachtet überschreiten würde. Auch diese Betrachtung rein theoretisch, ohne den Stromverbrauch des anzeigenden Displays mit einzubeziehen.

-> Wenn du, NiklasB also mit weniger als 23 Einzelmessungen pro Sekunde auskommst, oder sogar nur im Sekundentakt eine solche Messung und Darstellungsänderung beabsichtigst durchzuführen, ist die Methode von SteffenMurks sehr wohl geeignet den Stromverbrauch zu senken, wenn man den eingesetzten Spannungsteiler nicht permanent stromdurchflossen läßt.

Damit ist nicht der µController der Stromfresser, sondern ausschließlich die Auswahl des Displaytyps wird hier der entscheidende Punkt wie viel Strom eine solche Meß- und Anzeigeeinheit über den Akku abzieht und diesen dann vorzeitig leer saugt.

Moinsen __blackjack__

Ich gehe mal davon aus das du den Code aus #97 ? Aber schön das man sich für eine Antwort alles selber zusammensuchen darf !
Und hier bist du über die 68 gestolpert. Denn wenn du bemerkt hättest, was auch von FrauBerry so gesagt und wiedergegeben wurde, funktioniert das Programm auf dem Zero nur, wenn dieser Parameter auf False gesetzt bleibt und somit der Playcocde nur über die Zeilen 107 -110 ausgeführt wird.
Sobald hier in den Beispiel multiprocessing.Process ist Spiel kommt schafft es das Zero nicht mehr !
Somit hätte man bemerken können das dieser import multiprocessing gar nicht mehr vorhanden ist, und damit der Code falls der Parameter dennoch auf True gesetzt worden wäre gar nicht mehr lauffähig gewesen wäre. Somit sind die Zeilen ab 98 bis 104 und 117 gar nicht mehr ausführbar gewesen.

Das ist einfach nur ein unkorrigiertes Überbleibsel aus den vielen Annäherungsversuchen die zuvor stattgefunden haben.

Und ich habe definitiv nicht das alleinige Anrecht hier etwas zu sagen oder zu schreiben. Aber wenn man sich dann Wochen später hinstellt und so tut, als wäre man der Große Guru, dann habe ich sehr wohl ein Problem damit, weil deine Code in dieser dem eigentlichen beinhalteten Hardware Konfiguration nicht funktioniert.

Ich bin hier raus, mir egal. Soll der Nächste sich dann an dem Code die Zähne ausbeißen, wenn er mit der selben Konfiguration sich an deinem Tutorial Code abackert.

Franky

Moinsen __blackjack__,

ich gehe mal davon aus das du den Code aus #69 als Basis für deine Überarbeitung genommen hast !?
Aber bevor ich dir hier weitere Frage beantworten werde, bist du mir noch die Antwort schuldig, mit welcher Hardware-Konfiguration du diesen Code getestet hast ?
Vollständige HW Auflistung und alle SW Stände !

Franky

PS: Ich empfinde es der vielen Nachtschichten die hier nur Ich, sonder wie FrauBerry schon in ihrem Post #221schon aufgeführt hat, sich Wochen im nachhinein hinzustellen, und hier den großen Erklärbär spielen zu wollen ganz schön dreist.
Zumindest hätte man, was auch jeder mitbekommen haben dürfte, dass FrauBerry hier abrupt die Weiterbeteiligung eingestellt hat, mal nachfragen können, was der Abschlußstand war. Das ist jetzt nicht gegen deine Fähigkeiten als Programmierer oder wohlwollender Unterstützer anzusehen, eher an die Art des Vortrag. Es ist ein Code-Review / Re-Make was in der schon genannten modifizierten Basiskonfiguration nicht lauffähig ist !

Moinsen __blackjack__

es ist toll, was du als Code- Review hier aufgearbeitet hast. Für diese Zusammenfassungen
Aber dabei sollte man es auch belassen, bzw dem Code den du als Re-Make veröffentlicht hast mit dem Kommentar versehen, das dieser Code auf einem Single-Core RasPi nicht lauffähig ist !
Wenn du dein Augenmerk mal wohlwollend auf den gesamten Thread richten würdest und #70 von fred0815 gelesen hättest, würde dir auffallen, das diese MFRC522.read_id() Funktion diese Single Core CPU Last des RasPi Zero ( Version 1 ) fast auf 100% hoch treibt.
Da du in deinem Code weder die Hardware angeben hast, noch dieses Programm mit der Hardware der TO FrauBerry getestet hast, => Raspberry Zero , der Soundkarte, sowie dem RFID-Reader halte ich diese Abschlußaussage für verfehlt.
Ich habe auf meinem Zero mit Bullseye 32 Bit, 3.92 Python, 0.9.2 pyalsaaudio sowie diesem GitHub RFID Python- Code versucht deinen Code auszuführen. Genauso wie der Hardware Aufbau bei FrauBerry war.
Mit dem Ergebnis dein Code funktioniert nicht, bzw führt zu Abstürzen, oder sagen wir ganz einfach der Code hängt fest. Nach nicht einmal 3 Sek. Play einer Monospur Wave-Datei tritt das unvermeidliche ein -> die CPU keult am Anschlag und die Audiowiedergabe bricht ab. Auf einem 3er PI mit ausreichend CPU Reserven funktioniert der von dir überarbeitet Code zweifelsfrei.

Franky

Moinsen

Quote from __blackjack__

Ich habe mir mal die letzte Version

Du kannst hier an irgendwelchen Codes herumkritisieren was du willst Es ist Wursch um nicht zu sagen Wurschtegal.
Die Geräte - ja mehrere - sind fertig, die Kunstausstellung wofür sie erdacht waren ist erfolgreich eröffnet worden.
Laßt das Thema ruhen, es war sicherlich nicht aus jeder Sicht eine Stern-Stunde für dieses Forum. Die Beteiligung war überragend, nur gab es zu viele Akteure die immer wieder nur "reingequatscht" haben.

Wenn man auf diese Projekt zurück blickt, und weiß das FrauBerry hier mit einer Hardware-Ausstattung nach einem Tutorial angetreten ist. Zudem erkennen konnte das die Auswahl eines RasPi Zero in Verbindung mit einem USB !? (noch mit OTG-Adapter) RFID Reader und einem Soundausgabe-Modul welches mit dem dazugehörigen Python-Code nur *.Wav Dateien wiedergeben kann, hat eigentlich erkennen müssen, dass das Tutorial aus den Kindertagen des RasPi stammt.
Wenn man feststellt, dass der aus dem Tutorial übernommene Python-Code auf dem aktuellen RasbianOS "Bullseye" nicht mehr wirklich performt, zudem es zu ganzen Systemabstürzen gekommen ist, und somit FrauBerry wirklich nur Anfänger-Erfahrungen besaß, was auch die Kommentare meinerseits begründet, sollte sich überlegen, ob er Wochen später an irgend etwas herumkritisiert.
Ob FrauBerry sich hier nochmal melden wird, wage ich fast zu bezweifeln, nachdem man auf ihre Ausführungen nicht wirklich eingegangen ist, und sie immer wieder mit neuen Programmbeispielen zugedröhnt hatte, die in dieser und auch nach der Konfigurationsänderung während des Projektes trotzdem nicht performant lauffähig waren.

Du kannst gerne eine andere Schreibweise bevorzugen, überhaupt kein Problem, doch wenn ein Programm aus Stücken und Codeschnipseln hier auch über das Forum fast nach dem C&P Prinzip zusammengestückelt wurde, muss man den Anfänger der einen Großteil des gesamten Python Codes nicht wirklich versteht, irgendwie mitteilen, dass er an einigen Einstellungen nichts ändern darf. Wie man das nun gestaltet ist doch eigentlich auch Wurscht egal, Hauptsache durch die vielen Fehlversuche entstandene Zeit-Kanppheit hatte sie erst einmal ein funktionierendes System in der Hand.

Franky

Moinsen

Quote from llutz

Wie kommst du darauf?

Antennentyp - kein Kugelstrahler siehe Ergänzung Leistungskennziffer bei Richtantennen.

Moinsen

Quote from theesymon

450 kHz? Bist du dir da sicher? Das kommt mir gar sehr viel vor aber ich glaub dir schon...
Weil du sagst ich müsste 13 Pins auf einmal auslesen: eigentlich brauche ich in der Zeit, in der von der einen zur nächsten Digit gewechselt wird, "nur" 9 Pins auslesen. Ich kann gern den Python Code schicken. Aber wenn du sagst das mach sowieso keinen Sinn kann ich mir das auch sparn...

Ich bin bei den 450kHz vom Datenblatt des Matrixencoders TM1637 ausgegangen. Klar kann es sein, das der Mega das etwas langsamer macht Da in der Marix Ansprache ständig jedes Anzeigensegment einzeln für sich aber immer fortlaufend ein-und ausgeschaltet werden muss, sonst würde irgendwann mal nach paar µSek die Anzeige erlöschen, mußt du schon alle 13 Zugänge scannen, denn nur immer einer der oberen Pins mit einem der unteren Pins bringt ein solches Segment / Strich oder Punkt zum leuchten. Und wenn du etwas recodieren willst mußt du schon wissen über welchen der oberen Anschlüsse gerade Plus anliegt und wie der Strom zum Minus ( GND ) zu einem der unteren Anschlüsse läuft. Entweder alle, und du kannst anhand des Signalmusters eine Rekonstruktion machen, was nur eine Bit-Schieberei wäre. Oder du kannst nur den Segmentblock als 8 erfassen, oder du bekommst nur heraus welcher Strich leuchten soll, kannst ihn aber keiner Stelle zuordnen.
Deswegen mußt du schon alle 13 Pins im Auge behalten.

Dann wäre die Frage was hast du an Hilfsmitteln da ? zB ein Arduino ? oder Oszillographen, oder einen Frequenzzähler. Dann könnte man dir schon gezieltere Tpps geben.

Ffranky

Moinsen,

Da hier ja schon von Datenraten gesprochen wurde, und aber noch keine genauen Aussagen zu den Störungen in der Fresnelzone gesagt hast, aber sich Strukturstörungen am besten mit zirkular polarisierte elektromagnetische Wellen umgehen lassen, zudem die Sendeleistung im 2,4 GHz Band nicht ohne Ende nach oben geschraubt werden darf, würde ich mal dein Augenmerk auf das 5 GHz Band richten wollen. Hier sind in Deutschland bis 2 Watt zulässig, zudem kannst du mit einer Spiralantenne hier noch einiges Herausholen. Als Signalverbindungspunkt würde ich dir zu einem RouterBoard raten. Hier gebt es Modelle, die mit miniPCI, miniPCIe WLAN Karten im entsprechenden Frequenzband ausgestattet werden können.

Franky

Moinsen

Quote from hyle

Ob das auf elektronischem Weg per Software auszulesen ist kann ich nicht sagen. Ich hätte da nur eine andere, vielleicht umständliche (dämliche) Idee, die in eine völlig andere Richtung geht.

die Idee ist wirklich eine Alternative
Ich weiß nur nicht, ob das Flimmern selber von der Kamera mit wahrgenommen wird ? Die einzelnen Anzeige Segmente werden mit einem Durchlauf Takt von 450kHz ein- und ausgeschaltet ? Könntest du das mal wenn du hast mit einer PiCamera und einer solchen TM1637 Anzeige testen ?
Pi Camerra Kaufen und dann klappt es nicht ,weil es flimmert, oder die Momenthelligkeit nicht groß genug ist fände ich jetzt Blödsinn !?

Franky

@theesymon wie gerade erwähnt müssest du 13 Kanäle mit einer Samplingfrequenz von mind. 500Kps parallel und synchron einlesen können !!! Das schafft du auf du auf dem elektronischen Weg nur mit einem µDSP oder einem fetten µC ohne Betriebssystem.

Moinsen,

Diese Displays werden über einen Matrix Code gesteuert. Das übernimmt bei den fertigen Displays dieser TM1637 Chip und wird hier von dem Mega8 übernommen.

Wenn du schon einiges herausgefunden hast wäre es nicht schlecht alle Pins dieses Displays


Nachzuverfolgen, wie diese mit dem Mega verbunden sind, ggf hängt auch noch eine Transistor oder paar Vorwiderstände dazwischen.
Irgendwie mit Ausnahme der No PIn und No Connect müssen diese

auch direkt oder indirekt beim Mega ankommen.
Das Problem ist das die Ansteuerung über verschiedene An- und Auszeiten aus den oberen 5 Pins und den unteren 8 Pins erfolgt.
Diese insgesamt 5+8 Pins synchron abzugreifen ist mit rein dem PI völlig illusorisch.
Schau mal was du bei zB Reichelt aktuell noch an µDSP (Digitale Signal Prozessoren) bekommst, die über ausreichend Eingänge auch ADC verfügen und zudem noch frei Pins für eine Bus-Protokoll haben (I²C, SPI )

Welche der LEDs in den Segmenten gerade leuchtet ergibt sich aus den Pins die gerade einen Stromkreis bilden. Plus an der 1 und geschaltenes GND an 2 ergäbe erstes Anzeige Element - Element C würde jetzt leuchten. Nur erfolgt der Wechsel so schnell, das sich unsere Augen behumbsen lassen und das als Dauer an wahrnehmen.

Franky

Moinsen,

Wenn es diese 4 stellige Anzeige handelt, oder baugleich von einem anderen Anbieter, dann verwendet diese Anzeige ein I²C ähnliches aber nicht kompatibles Protokoll. Das kannst du nur schwerlich ohne eine Echtzeitsystem zu verwenden abfangen oder mitlesen.

Franky

Moinsen

Quote from hyle

69 oder 70 nicht 72! Dieser Moni kann laut hier nur 50-76 Hz.

Was solls ? Wenn man nicht einmal 3 Zahlenwerte aus einer Produktbeschreibung mit den verlinkten Definitionsparametern vergleichen kann !?
Zumal dieser Eingriff in die /boot/config.txt eigentlich gar nicht notwendig gewesen wäre. Vor allem ohne das diese Image jemals davor das PI gesehen hat.

Quote from S21

Ich habe die SD-Karte beschrieben, am PC die config.txt angepasst, dann den RPI gestartet.

Das macht mir schon bedenken, wie man auf solche Ideen überhaupt kommt.

Franky

Moinsen,

dann ganz klassisch die Karte plätten, noch einmal mit dem Imager das Image neu draufspielen, die Verifizierung abwarten ob dort ein Fehler kommt - wenn nein -> Karte ohne Manipulationen in das PI, zuerst den Monitor starten, dann das PI starten, das kann dauern. Einfach mal 10 min machen lassen.
Hat bei meinem Samsung 4K Flat auch fast 5 min gedauert bis es weiter ging, und er die passende Einstellung selber gefunden hatte.

Wenn du einmal über den Punkt weg bist, und die Grundeinrichtung dann schon in der GUI abgeschlossen hast geht es zukünftig ganz fix.

Franky

Moinsen,

Quote from S21

Monitor ist übrigens ein ASUS PB248Q. Vielleicht versuche ich einfach mal in der Nachbarschaft einen anderen Monitor.

->

->

Und nun erkläre uns mal diesen Schwachsinn ?

Quote from S21

Habe auch mal "hdmi_group=2" und "hdmi_mode=82" gesetzt, keine Änderung.

Lieber RASPI Gott, laß die Menschen lesen lernen und verteile reichlich Gehirn - Ahmen

jar beruhige dich wieder - machen sehen den Wald vor lauter Bäumen nicht !

Franky