Goniophotometer selber bauen?

[Borax]

Ein passendes Gehäuse müsstest Du wohl drucken. Ich bin aber kein großer Freund von Steckverbindungen. Die machen gerne mal Kontaktprobleme. Ich würde eher eine Lochraster/Streifenrasterplatine empfehlen und da alles drauf löten. Für die Verbindungen zum Sensor, Motor, Netzteile dann Schraubklemmen. Oder möglicherweise so was: https://www.hwhardsoft.de/deutsch/proje ... x-nodemcu/ (das kommt meiner Vorstellung davon schon sehr nahe )
Für die NodeMCU bräuchtest Du aber die 'alte' Version dieses Gehäuse-Kits. Ob es die noch gibt weiß ich nicht (im Shop ist sie nicht mehr zu sehen). Oder statt NodeMCU ein Wemos D1 mini board nehmen. Das gäbe es in dem Shop (für 6€) auch...

[JackyDean]

Habe jetzt das NodeMCU und den DRV8834 bestellt und werde es einfach erstmal auf dem Steckbrett zusammen bauen um zu testen.

Könntest du mir deinen aktuellen Code für das NodeMCU senden? Eventuell muss ich da noch etwas anpassen, weil ich ja einen anderen Motortreiber habe.

Ich habe aber auch noch einen 12V Stepper hier gefunden, den ich an einem A4988 betreiben konnte. Das kann ich ja auch erst einmal nutzen für den ersten Test.

[Borax]

Ich verwende momentan einen ESP8266 Generic (also nur die 'Kernkomponente' des NodeMCU). Das ist aber nicht weiter wichtig. Du musst nur in der Arduino IDE eben NodeMCU auswählen und nicht ESP8266 Generic. Code bleibt quasi gleich (ist auch bis auf die Microstep Einstellung die ich bisher auch noch nicht impementiert habe für beide Treiber identisch). Hast Du schon eine NodeMCU am Laufen? Sprich 'Blink' funktioniert?

Ich habe aber auch noch einen 12V Stepper hier gefunden, den ich an einem A4988 betreiben konnte. Das kann ich ja auch erst einmal nutzen für den ersten Test.

Kannst Du. Der A4988 und der DRV8834 sind ja fast Pinkompatibel. Nur die Steuerung der Microstep Einstellung ist ein wenig anders. Und der A4988 braucht zusätzlich zur Motorspannung noch Logik Spannung (5V oder 3.3V). Würde ich vom NodeMCU am 3.3V Anschluss aus versorgen. Wie schon mal gesagt ist der Kondensator (mind. 47 µF und mind. 25V) zwischen Masse und VMOT am Motortreiber wichtig. Aber auch das gilt für A4988 und DRV8834 gleichermaßen. Wie sieht es mit dem BH1750 aus? Hast Du den auch schon?

[JackyDean]

Ja. Den BH1750 habe ich schon und auch erfolgreich am Arduino getestet. Tut, was er soll, denke ich. Würde ich bei Gelegenheit noch mal mit dem Lighting Passport gegenprüfen, ob die LUX-Werte plausibel sind. Sah aber erst einmal alles gut aus.

NodeMCU habe ich noch keine am laufen. Hatte bisher nur die Arduinos zum Testen. Die NodeMCU hatte ich erst gestern bestellt.

[Borax]

...und auch erfolgreich am Arduino getestet...

An welchem? Nano oder Uno? Und mit welcher Lib?
Du kannst auch den Arduino verwenden um den Schrittmotor zu testen. Mit Motortreiber ist das recht einfach. Such dir zwei Pins am Arduino aus (z.B. D5 und D6), die Du als Output deklarierst. Die werden dann mit Step und Dir am A4998 verbunden. Ferner werden am A4998 die Pins: RESET und SLEEP verbunden. Und den Kondensator nicht vergessen!
Beschaltung ist hier schön erklärt: https://www.pololu.com/product/1182
12V und Motor anschließen und schon kann es losgehen...

Minimal Program (dreht 100 Schritte vor und zurück):

Code: Alles auswählen

 int STEPDir = 5;
 int STEP = 6;
 
 void setup(){
  pinMode(STEPDir, OUTPUT);
  pinMode(STEP, OUTPUT);
 }
 
 void loop(){
 int i;
   digitalWrite(STEPDir, LOW);
   for (i = 0; i <= 100; i++) {
      digitalWrite(STEP, HIGH);
      delay(10);
      digitalWrite(STEP,LOW);
      delay(10);
      }
   digitalWrite(STEPDir, HIGH);
   for (i = 0; i <= 100; i++) {
      digitalWrite(STEP, HIGH);
      delay(10);
      digitalWrite(STEP,LOW);
      delay(10);
      }
}

[JackyDean]

Beim BH1750 bin ich nach der Anleitung und dem Code von Wolfgang Ewald vorgegangen:
https://wolles-elektronikkiste.de/bh175 ... ensormodul

Das scheint gut zu funktionieren.

Den Stepper konnte ich am CNC Shield V3 auch schon schön in 0,9° Schritten drehen (Halbschritt). Der Aufbau mit dem Steckbrett hat noch nicht so geklappt, aber da setze ich mich noch mal dran. Muss halt immer schauen, wenn mal Zeit ist ...

Was ich dann noch gar nicht weiß, wie ich die Werte in eine Datei bekommen, z.B. als CSV, so dass ich sie auswerten oder auch in eine EULUMDAT umwandeln kann.

[Borax]

Beim BH1750 bin ich nach der Anleitung und dem Code von Wolfgang Ewald vorgegangen

Ok. Hast Du den 'rohen' code verwendet oder die Lib?

wie ich die Werte in eine Datei bekomme

Beim Arduino kannst Du die Werte über den seriellen Monitor ausgeben lassen (oder auch ein anderes RS232 Terminal Programm wie z.B: HTerm: https://www.heise.de/download/product/hterm-53283 ). Dann da raus kopieren (bei HTerm kann man auch den Output einfach als Text Datei speichern) und in Excel o.ä. einfügen. Mit dem ESP geht das dann komfortabler. Der hat immerhin 4 MB eigenen Flash-Speicher. Da kann man dann die Ergebnisdatei intern speichern (ggf. auch gleich in diesem EULUMDAT Format) und über eine Web-Oberfläche als Download zur Verfügung stellen. Da bin ich gerade noch dran (und kämpfe mit Javascript)...

[dieterr]

Javascipt? Du kennst https://fipsok.de/Esp32-Webserver/Esp32?

[Borax]

Ja. Mit dem code arbeite ich gerade. Respektive mit der ESP8266 Version: https://fipsok.de/Esp8266-Webserver/esp8266
Wobei in der ESP32 Version schon einige Sachen berücksichtigt sind, die in der ESP8266 Version noch nicht drin sind (z.B: die Verwendung von async function - die habe ich inzwischen bei der ESP8266 Version selbst heraus gefunden und angepasst)...
Aber so richtig wohl fühle ich mich bei der Javascript Programmierung (noch) nicht. Und auch nicht wann welche CSS Formatierung wie genutzt wird...

[dieterr]

Ich glaube, ich habe damals mit einem onlne html-builder gearbeitet. CSS und Javascipt brauchte ich eigentlich nicht.

[Borax]

Und was hast du da gemacht? Der html Teil ist das geringste...
Ich glaube aber, ich habe jetzt den 'Durchbruch' ... Der Weltzeit Sketch!
Der ermöglicht eine kontinuierliche Darstellung von Werten (z.B. Winkel und Lux) UND interaktive Elemente (hier eine Liste, aber prinzipiell auch alles andere wie z.B. Messung starten)
Was nicht heißt, das ich da alles verstanden habe, aber wahrscheinlich hinreichend für dieses Projekt...

[dieterr]

War tatsächlich nur ein slider über den ich einen Wert übergeben habe, und ausgelesen weil ja diverse Geräte den Wert ändern können. Also interaktiv. Plus einfache Digitalanzeige des Wertes. Aber wie gesagt auf dem ESP32, keine Ahnung wie sehr der sich dabei vom ESP8266 unterscheidet.
Genau, die diversen Beispiele könnten weiterhelfen. Ich bin da zumeist maximal pragmatisch und schreibe nr selber was ich nirgends finde.
Ansonsten kannst du den Code mir ja mal schicken, versprechen kann ich aber nichts.

[Borax]

Alles gut. Wie gesagt, der Weltzeit Sketch hat es gebracht. Ich schreibe auch gerne code selbst, aber wenn beim 'Trial and Error, nur noch Error kommt, macht das irgendwann keinen Spass mehr. Aber jetzt läuft es.

Aber wie gesagt auf dem ESP32, keine Ahnung wie sehr der sich dabei vom ESP8266 unterscheidet.

Eigentlich überhaupt nicht. Wie gesagt, die Probleme liegen (für mich) beim CSS und Javascript Teil. Und den führt der Browser aus, nicht der ESP.
@JackyDean
Gibt es eigentlich beim EULUMDAT Format eine Konvention, was Winkel 0° ist?

[Borax]

Hier mal ein paar Bilder vom aktuellen Stand...

Goniophotometer1.png (37.3 KiB) 10791 mal betrachtet

Goniophotometer2.png (58.28 KiB) 10791 mal betrachtet

Goniophotometer3.png (26.73 KiB) 10791 mal betrachtet

Goniophotometer4.png (45.29 KiB) 10791 mal betrachtet

Goniophotometer5.png (32.55 KiB) 10791 mal betrachtet

[JackyDean]

Das sieht doch schon super aus!

Es gibt bei EULUMDAT und generell bei der Lichtmessung keine Definition, dass beim Maximum der Lichtstärke immer automatisch 0° sind. Wie gesagt gibt es ja auch Leuchtenarten, bei denen das erheblich abweicht (Cyclos, Batwing-Optiken u.ä.).

Letztlich ist das Lot - also der 90°-Winkel - vom Mittelpunkt der Leuchtfläche aus gesehen, 0° bei EULUMDAT (u.a). Bei einem Panel ist die Leuchtfläche klar, aber auch jede Linsenoptik hat ja eine klar definierte Front, zu der man ein 90°-Lot bilden kann. Die optische Achse sozusagen.

Die allermeisten Leuchten haben natürlich bei ca. 0° auch ihr Maximum. Bei ARRI haben wir die Leuchten per Hand auf dem Drehtisch ausgerichtet, so dass möglichst dieses Lot genau auf den Sensor zeigt. Dann lief die Messung von z.B. -90 bis +90°. Nicht selten war das Maximum der Beleuchtungsstärke dann leicht verschoben, z.B. bei -1° oder +2°, weil man eben doch nicht ganz präzise das Lot getroffen hat. In der Software hat man das dann noch verschoben, so dass wirklich bei 0° auch das Maximum war und z.T. hat man sogar die "schönere" Hälfte einfach noch gespiegelt, dass sich für das Marketing ein schöne, absolut symmetrische Lichtkurve ergab. Wenn's nicht gerade für's Marketing ist, würde ich das mit dem Spiegeln aber schön sein lassen und nur den 0-Punkt korrigieren.

[dieterr]

Es macht ja auch keinen Sinn das Maximum auf 0° zu fixieren. Ich denke da zB an die PKW-Abblendleuchte, die ja extrem asymmetrisch ist. Aber bei symmetrischen macht es sicherlich Sinn, der Optik des Ergebnisses wegen nachher das Maximum auf 0° zu korrigieren.

Du kennst https://de.wikipedia.org/wiki/EULUMDAT?

[Borax]

Yep. Gefällt mir selbst auch schon recht gut

Dann lief die Messung von z.B. -90 bis +90°. Nicht selten war das Maximum der Beleuchtungsstärke dann leicht verschoben, z.B. bei -1° oder +2°, weil man eben doch nicht ganz präzise das Lot getroffen hat. In der Software hat man das dann noch verschoben, so dass wirklich bei 0° auch das Maximum war

Soll ich so was auch noch vorsehen?
So wie ich dieses EULUMDAT Format verstanden habe, gibt es da keine negativen Winkel. Die paar Dateien die ich mit angeschaut habe, starten immer bei Winkel 0°. Meist gehen sie nur bis 90° (es wird also sowieso schon eine Symmetrie verwendet). Hier ist mir noch nicht ganz klar, wie die Messung von -90 bis +90° da drauf abgebildet wird...
Zur Erstellung einer 'finalen' EULUMDAT Datei kann man ja dieses QLumEdit verwenden. Das berechnet ja auch vieles selbst (z.B. Ausnutzungsfaktoren). Zwingend erforderlich wären wohl noch Abstand und Gesamtlichtstrom (damit man aus den gemessenen Lux-Werten die cd/klm berechnen kann um diese in der EULUMDAT Datei zu verwenden. Man bräuchte dann quasi so eine Art 'minimal Konfiguration' die nur das enthält was zwingend nötig ist und der Rest kann dann in QLumEdit eingetragen/berechnet werden.

[JackyDean]

Das ist korrekt. Bei EULUMDAT gibt es keine negativen Winkel.

Man arbeitet hier mit den C-Ebenen. Folgendes Bild zeigt es ganz gut:



D.h. die positiven Winkel sind dann z.B. in C0, die negativen in C180 - aber natürlich nicht als negative Werte.

In Zeile 4 definiert EULUMDAT, wie viele C-Ebenen gemessen wurden. In Zeile 5 könnte man noch angeben, welchen Winkelabstand es zwischen den C-Ebenen gibt. Mit einer 0 da, gibt man aber vor, dass es gleichabständig ist, was der absolute Regelfall ist.

Häufig werden 24 oder mehr C-Ebenen gemessen, was aber natürlich ein 2-Achsen Goniophotometer wie z.B. die von VISO SYSTEMS bedingt. Bei uns mit nur 1 Achse gibt es nur 2 C-Ebenen oder wer die Leuchte noch mal um 180° dreht könnte auch 4 Ebenen messen. In den Lichtberechnungsprogrammen wird alles dazwischen interpoliert und bei allen rotationssymmetrischen Leuchten wäre es sowieso verschwendet, mehr als nur 2 Ebenen (also 1 Achse) zu messen.

PS: Eine im Vergleich zu Wikipedia noch etwas präzisere Beschreibung des EULUMDAT Formats findet man bei DIALUX:
https://dialux4.support-de.dial.de/supp ... schrieben-

[Borax]

So ähnlich hatte ich mir das inzwischen auch 'zusammen gereimt'. Leider stürzt QLumEdit bei EULUMDAT Dateien mit nur einer C Ebene reproduzierbar ab, wenn man auf 'Diagramm' klickt.

oder wer die Leuchte noch mal um 180° dreht

Du meinst um 90° oder? Dann hätten wir C0 - C180 und C90 - C270. Leider ist auch das ein Schema, was QLumEdit nicht mag. Die Spalte C270 wird hier schlicht entsorgt und (IMHO fälschlicherweise) trotzdem Anzahl C-Ebenen auf 4 gesetzt.
So ganz sauber scheint das nicht zu sein...

[JackyDean]

Das scheint ein Problem / Bug in QLumEdit zu sein.
Du kannst z.B. mal die Datei im Anhang testen.

Das ist eine offizielle LDT vom bekannten Leuchtenfabrikanten FLOS mit Werten für nur 1 C-Ebene. Diese Ebene besteht hier aus 37 Lichtstärkewerten in 5°-Schritten. Geht also von 0° bis 180°. QLumEdit kann diese öffnen, aber beim LVK-Diagramm stürzt es ab.

In RELUX kann ich die Datei aber ohne Probleme verwenden. Es wird eine LVK angezeigt, ich kann alle Berechnungen durchführen usw. Und das ist ja am Ende entscheidend.

Die Datei können wir auch gut als Vorlage nutzen für unsere Messungen. Wichtig ist in Zeile 3 die "1". Diese steht für eine rotationssymmetrische Leuchte. Es sind dann in Zeile 4 dennoch 4 C-Ebenen vorgegeben, was aber vermutlich überhaupt keine Rolle spielt. Man könnte dort auch 100 oder 98356 hinschreiben. Wenn die Zeile 3 auf "1" steht, wird das komplett ignoriert und es gibt nur die Werte für 1 C-Ebene. So zumindest mein Verständnis von EULUMDAT.

[Borax]

Ok. Jetzt geht es noch um die Werte. Die Messwerte (in Lux - ggf. minus einen Hintergrundbeleuchtungswert) werden mit dem Abstand in Meter zum Quadrat multipliziert (=Umrechnung in cd) und durch (Gesamt)Lumen der Lichtquelle (in 1000 lm) geteilt. Passt das so? Und die (Gesamt)Lumen des Messobjekts muss man daher kennen...

[JackyDean]

Ja, das passt so.
EULUMDAT ist ja so angelegt, dass man durch einfache Veränderung der Gesamt-Lumenzahl (Zeile 26c) die Datei schnell für unterschiedliche Helligkeiten anpassen kann. So kann man im Prinzip einen LED-Streifen vermessen und hat dann durch Anpassung in 26c die passende Datei für quasi alle LED-Streifen, da sich diese in der Abstrahlcharakteristik nicht nennenswert unterscheiden.

Die Gesamtlumenzahl muss man kennen (ist ja häufig beim Hersteller mit angegeben, wenn man dem traut). Man könnte sie bei rotationssymmetrischen Leuchten auch aus den Lichtstärkewerten berechnen. Da steckt ja alles notwendige drin. Die Software, die wir da bei ARRI hatten, konnte das. Ist natürlich näherungsweise, aber bei annähernd rotationssymmetrischen Leuchten passt es gut. Hatte ein 2m U-Kugel da, um das mal gegenzuprüfen.

Frage mich aber nicht nach der Formel! Man müsste wohl zuerst Fourier-Transformation machen und dann über Integration den Flächeninhalt unter der LVK berechnen. Das sind ja die Lumen. Allerdings muss man das Ganze noch dreidimensional denken, denn die LVK ist ja nur 2-dimensional in 1 C-Ebene. Die wirkliche Lichtverteilung aber natürlich 3-dimensional, quasi als Kegel. Da bin ich leider raus und die Mathe-Kenntnisse viel zu sehr verblasst.

Kann man aber sicherlich mal dran bleiben und nach Hilfe suchen bei Mathe-Cracks. Schreib es mir mal auf die ToDo ...

[Borax]

Ok. Dann machen wir das erst mal mit der einfachen Eingabe. Wegen der Winkelauflösung: Ich würde die gerne variabel gestalten. Also vorgegeben wird dann Steps/360° als 'Motorkonstante' (i.a. 200 oder 400 Schritte pro Umdrehung). Zusätzlich dann eine Auswahl zu Microsteps (1 bis 16). Die Ansteuerung erfolgt dann vom ESP aus über entsprechende Ausgangspins an die Eingänge am Motortreiber. Diese Eingänge sind aber je nach Motortreiber (A4988 / DRV8834 / DRV8825) unterschiedlich. Ich sehe jetzt erst mal nur den DRV8834 vor. Wenn man einen anderen Motortreiber verwenden will, muss man das dann in der Software (und ggf. mit einem zusätzlichen Hardware-Pin) anpassen.

Man könnte sie bei rotationssymmetrischen Leuchten auch aus den Lichtstärkewerten berechnen. Da steckt ja alles notwendige drin.

Klingt spannend

[JackyDean]

Variable Winkelauflösung klingt sehr gut. Die kann bei breit streuenden Leuchten auch noch gröber sein. Wenn man z.B. einen LED-Streifen mit ca. 120° Streuwinkel hat, genügt es da sicher, nur 100 oder auch nur 50 Schritte auf 180° zu haben. Dann geht die Messung schneller.

[Borax]

Variable Winkelauflösung ist implementiert. Aber nur für Mikrosteps. Bei meinem 1,8° pro Step Motor sind das ja nur 100 Schritte auf 180°. Bei 0.15 Sekunden pro Messwert (der BH1750 ist nicht schneller) geht das in weniger als 20 Sekunden.
Wegen Symmetrie habe ich jetzt mal folgende Fälle angenommen / implementiert:
1. Symmetrie voll rotationssymmetrisch (Ityp = 1 und Isym = 1): Dann gleich nur von 0° bis 90° (oder auch 180°) messen. Gibt nur eine C-Ebene (0°) und entsprechende Messwerte.
2. Symmetrie prinzipiell vorhanden, aber es soll -90 bis +90 (oder auch -100 bis + 100 oder was auch immer) gemessen werden. Hier wird Ityp = 1 und Isym = 3 verwendet (also symmetrisch bzgl der C90-C270 Ebene). Abstand C-Ebenen = 180° Messwerte aus dem Bereich -90° bis 0° werden auf die Ebene C180 geschrieben.
3. Asymmetrisch: Ityp = 3 und Isym = 0: Ähnlich wie Fall 2, aber die Werte aus C0 + C180 werden zusätzlich als C90 und C270 geschrieben. Dann kann QLumEdit auch ein Diagramm anzeigen.
Ergebnisse meiner ersten Messung (alte Seoul P4 mit 80 lm einmal mit Linse und einmal ohne Linse) im EULUMDAT Format sind im Anhang...
Mit Linse:

daten_2022-04-29_18-19-38.png (47.64 KiB) 10194 mal betrachtet

Ohne Linse:

daten_2022-04-29_23-14-45.png (49.5 KiB) 10180 mal betrachtet