erste Moddings fertig

[Astrowolfgang]

Moin,
mal ein kurzer Zwischenbericht. Die ersten drei Lampen sind fertig
War ein ganz schön steiniger Weg - die, die sowas auch gemacht haben, wissen wovon ich spreche.
Es handelt sich um eine:
1. Fandyfire 501B mit SSC-P7 ( 1x 18650)
2. Ultrafire WF 501B mit Cree XR-E R2 (1x 18650)
3. Aurora AK-47 (original mit SSC-P7) jetzt mit CREE-XML-T6 (2x 18650)

Alle Lampen wurden thermisch optimiert, d.h. durch anfertigung diverser Zwischenringe, Adapter, Koni ist der Wärmeübergangswiderstand vom Emitter bis zum Klicky optimiert. Bei Lampe 1 stand im Labor bei Vollastmessung nach 14 min. nur eine Temperaturdifferenz von ca. 1K an. ( Lampenkopf 61°C, hinten 60°C) Dies fand allerdings bei heißem Wetter statt ("kalter" Host hatte schon ca. 30°C)
Bei Lampe 3 Geht durch den großen Lampenkopf mit den Kühlrippen sehr viel vorn ab, sodaß das hintere Lampenteil deutlich kühler ist.

Wie schon gesagt, die Lampe 1 behielt ihren SSC-P7 (Flooder) die Lampe 3 auch, da aber ein kleiner Chip verbaut ist, ist es ein Thrower. Er wirkt subjektiv - trotz nur ein drittel der Emitterleistung - deutlich heller. Im Wald sieht das schon wieder ganz anders aus. Das ist auch der Grund, warum ich keine Beam-Fotos mache. Die sind ganz einfach nichtssagend.

Natürlich habe ich die Lichtstrom in Lumen bei allen Lampen gemessen (ohne Kugel, durch umrechnung der Beleuchtungsstärke und des Hauptbeamwinkels).

Zu den Treibern. Entgegen meiner Einstellung "gegen Linearregler" habe ich aus Wirkungsgradgründen die hier von einigen vertretene Meinung als richtig akzeptiert. Die Vf meiner Emitter paßte ganz gut zur Entladekurve meiner Akkus.

Hauptziel bei mir war ja, ein absolut konstanter Maximallichtstrom bis zum Ende des Akkus :teuflisch Ich weis ja vorher nicht , wozu ich es mal brauche.
Also habe ich einen NANJ-105 sowie einen NANJ-AK-47 genommen. Trotz Schottkydiode laufen die Emitter konstant bis zum "Entladeschluß". Der Entladeschluß liegt bei mir so um 3,1V (ist von mir so festgelegt). Da ich nur "protected" verwende, schalten die sowieso bei ca. 3V ab.
Zum Glück arbeiten die NANJ mit dem ATtiny13, sodaß es da keine weiteren Probleme gab.
Viel mehr Arbeit machte mir da meine Lampe 3. Der Treiber ist ein DC/DC Buckregler (DX-Nr. 106303), der leider einen PIC verbaut hat. Nun gut, also den PIC gegen den ATmel "getauscht". War viel Arbeit unter dem Stereomikroskop! Außerdem mußte der Treiber noch auf 3A getunt werden, da die XML-T6 ja max. 3A verträgt. Das ging heute früh relativ schnell. (aktuell 3,06A)

Nun kam die Software. Nach einigen Tests mit Tino's in C geschriebenen Programm, hatte ich Probleme mit dem Modenwechsel etc. Das Programm von "DrJones" (basiert auf Tidos Software) ließ sich einfach mit meinen Compilern nicht compilieren. (Fehler im Programm wurden angemeckert)
Inzwischen habe ich Kontakt zu Tido - mal sehen, was daraus noch wird
Nun habe ich mich mit dem Basic-File von rsfyfy beschäftigt. Dies ist ja gut dokumentiert. Dieses ganze "Geblinke" ist mir persönlich ein extremes Gräuel, wurde also sofort restlos entfernt.
Die lampe hat jetzt 5 Modi. Max.(dimmt um 5% nach 1min.) - 70% - 40% - 10% - Rampdownmodus mit anfänglich 70% nach ca.5min. auf 20%. Bisher läuft das linear, ich denke aber über eine logarithmische Kurve nach, da die besser der Augenadaption angepaßt ist.

3-stufiges Batteriemonitoring:
- Bei ca. 3,2V (für die einzelligen Lampen) blitzt die Lampe 3x mit Wiederholung alle 30sec.
- Ab ca. 3.05V (schwankt je nach Modus etwas) dimmt die Lampe ohne Blitze! binnen 30 sec. auf ein Notlicht (ca.1%), mit dem ich noch ca. 1-2 Stunden Licht habe (30mA) .
- Für Benutzung von "unprotected" Akkus schaltet sich der Prozessor bei ca. 2.7V ganz ab.

Bei der Lampe 3 gestaltete sich das Ganze wesentlich komplizierter, da erst entsprechende Spannungsteiler eingebaut werden mußten. Außerdem waren die Messungen sehr schwierig, da durch den DC/DC Wandler sehr hohe Stromspitzen auftreten, die sogar mein großes 10A/30V Labornetzteil von Statron ins "Stolpern" brachten. So gestaltete sich die Ermittlung der ADC-Parameter recht mühselig. Durch an den AD-Wandlereingängen eingefangene Störstrahlung (hochfrequente Fourieranteile) des DC/DC Wandlers, stimmt die Theorie schon gar nicht mehr mit der Praxis überein. Mit Akkus sah's dann noch mal anders aus, mußte die Software noch mal korrigieren.

Inzwischen bin ich mit meiner ersten Stufe des moddings rundherum zufrieden. Die Lampen werden im Vollastbetrieb teilweise so heiß, daß man sie selbst Nachts kaum länger als 5-8 min. in der Hand halten kann.

Kleiner kosmetischer Effekt am Rande. Die Aurora war teilweise mit Zweikomponentenkleber verklebt. Da ich sie ganz auseinander nehmen mußte (Wärmemanagement), habe ich den Lampenkopf mit dem Brenner erwärmt. Nun ist der Lampenkopf schon Kupferfarben geworden, während der Batteriegriff schwarz ist. Die Bezel habe ich dann heute noch mit erwärmt, damit sie auch kupfern wird.

Apropos Emitter:
Die XML-T6 habe ich von der deutschen Fa. LED-Tech portofrei nach 1 Tag geliefert bekommen. Das sogar noch 2 Euro/Stück preiswerter als bei DX. Emitter werde ich wohl nur noch von dort beziehen, und am XML-T6 kommt ja augenblicklich kaum was vorbei.

Soviel vorerst von der Moddingfront bei mir. Drei andere Lampen warten schon auf mich, bevor ich meine 4D MagLite in Angriff nehme.

Danke an rsfyfy für die Basis Entwicklung der Software.

Noch ein Tip zum "Brennen" der uC's . Ich kompiliere mit BASCOM-AVR, und brenne mit Atmel-Studio. Es gibt wesentlich weniger Fehler, da Atmel-Studio wohl am Besten mit seinem ISP MK2 umgehen kann.
Den EEPROM - Inhalt habe ich übrigends als *eep Datei abgelegt, so läßt er sich unkompliziert jedemal mit flashen, was die Fehlerquote (frisch programmierter Chip macht gar nichts oder nur Dauerlicht..) enorm senkte.

Gruß
Wolfgang

 

[rsfyfy]

Bisher läuft das linear, ich denke aber über eine logarithmische Kurve nach, da die besser der Augenadaption angepaßt ist.

Ja, das ist mir in Praxistests auch aufgefallen, hab daher eine Version mit exponentiell vergrößernden Zeitabständen der Dimmschritte gemacht.
Ist allerdings vor den u.a. durch palladinsche Rückmeldungen eingeflossenen Änderungen entstanden.

http://dl.dropbox.com/u/59558816/nacht_exp.bas.txt

 

[Astrowolfgang]

Danke für den Link. Kannte ich so noch gar nicht.
Du hast das mit einer exp. Reihe entwickelt. Ich persönlich dachte mehr an die mathematischen Befehlssätze:

Seite: 6/12 Einführung in die AVR-Programmierung mit BASCOM
Rev. 2; Stand: 04/06
Laser & Co. Solutions GmbH
Mathematische Funktionen:
AND, OR, XOR, INC, DEC, MOD, NOT, ABS, BCD, LOG, EXP, SQR,
SIN, COS, TAN, ATN, ATN2, ASIN, ACOS, FIX, ROUND, MOD, SGN,
POWER, RAD2DEG, DEG2RAD, LOG10, TANH, SINH, COSH.

Ich weis natürlich nicht, wieviel Code der Compiler da erzeugt, und ob der Speicher des Tiny13 reicht.
Im Moment stehe ich bei 92%.
Um noch ein bischen Speicher zu sparen, habe ich die Register auf:
$hwstack = 16
$swstack = 8
$framesize = 8
gesetzt. Funktioniert gut. Ggf. kann man noch weiter runter.

Vielleicht probiere ich es mal mit Tiny 25/45, da hätte ich ja wesentlich mehr Speicher, und pinkompatibel ist er auch. Zusätzlich hat er einen eingebauten Temperatursensor, wenn der sich nicht auch noch "mißbrauchen" ließe ...

Aber trotz aller Dimmung nach math. Funktionen - die letzten Schritte bleiben einfach Scheiße, weil die Schrittweite der PWM gleich bleibt. Das gibt immer gewaltige "Dämmerungsschritte" zum Schluß.
In dem Fall würde nur ein separates PWM-Modul helfen, das dann vom Tiny mit seinen 255 Schritten lediglich angesteuert wird, aber einen ganz anderen Pulsbreitenverlauf hat. Ob das noch in die Pill paßt

Im Moment ärgert mich doch schon wieder meine Aurora AK-47 (2x 18650). Das Akkumonitoring funktioniert im zusammengebauten Zustand nicht richtig. Ich denke mal, das die Kabelage vom Labornetzteil, die viele HF und der relativ hohe dynamisch Innenwiderstand des Versuchsaufbaus zu den Verfälschungen geführt hat.
Muß also noch mal alles raus, die Lampe fährt aktuell schon bei 7,4V runter.
Außerdem werde ich an Pin7 des Tinys gegen Masse einen keramischen 1nF Stützkondensator löten. Mal sehen, ob die HF da weniger Einfluß nimmt. Das Problem ist der hochgezüchtete 2,5A Treiber. Mit 3,08A macht der schon ganz schön "unsaubere" Spannungsverläufe. Aber wer will schon eine T6 mit 2,5A betreiben
Ich werde mal einen dicken Elko (so um 5000-10000uF mit parallel geschaltetem 10nF Keramik) direkt am Fußpunkt des Treibers anschließen. Mal sehen, ob ich dann die Messung stabiler kriege.

Gruß
Wolfgang

 

[rsfyfy]

Die durch PWM gestörten Spannungsmessungen sind bei diesen Treibern leider so ein Thema für sich, mit dem ich mich zwischenzeitlich nochmal intensiv befasst, aber bislang nur mit Palladin per Mail ausgetauscht habe. Hier nochmal zusammengefasst:

Die Störungen (umso größer je höher LED-Strom und Frequenz) werden hauptsächlich über das unterseitige Pluskontakt-Pad empfangen und heben das Spannungsniveau hinter der Diode (Stützkondensator, Tiny, Spannungsteiler). Ein höherer Stromverbrauch (z.B. durch 9,6MHz Taktung) wirkt der "Aufladung" etwas entgegen.

Der ADC-Kondensator bringt nichts, da er - kaum effektiver als die Mittelwertbildung per SW - nur die bereits verfälschte Spannung glättet.

Ein anderer Ansatz brachte leichte Erfolge: Da mein gleitender Mittelwert nicht korrekt dividiert, sondern Bits einfach "rausschiebt", driftet er bei schwankenden Werten etwas nach unten ab. Das wird vor allem deutlich, wenn man den ADC nur mit 8Bit ausliest. Dieser "falsche" Mittelwert kann die durch Störungen angehobene Spannung halbwegs kompensieren. Vermutlich nur in recht begrenztem Rahmen, für meinen Testaufbau mit XM-L und 4*7135 Board hat das jedenfalls mit 9,6kHz PWM ganz gut gepasst:
https://dl.dropbox.com/u/59558816/ADC_8bit.bas.txt

 

[Astrowolfgang]

Die Störungen (umso größer je höher LED-Strom und Frequenz) werden hauptsächlich über das unterseitige Pluskontakt-Pad empfangen und heben das Spannungsniveau hinter der Diode . Ein höherer Stromverbrauch (z.B. durch 9,6MHz Taktung) wirkt der "Aufladung" etwas entgegen.

Ich habe das noch nicht gemessen, aber sollte die HF über diese kleine Koppelkapazität (von einer Antenne kann man hier nicht reden, da die "Lambdabeziehung" weit außerhalb des sinnvollen liegt) eine so deutliche Spannungserhöhung bewirken? Der Innenwiderstand liegt doch auch nicht im mehrstelligen MegOhmbereich. Außerdem haben wir vom Spannungsteiler 4,7K nach Masse.
Selbst wenn da ein paar Millivolt Spannungserhöhung wären, das würde doch bei einem Meßbereich 4V zu 3V von Delta 390 mV unbedeutend sein.

Der ADC-Kondensator bringt nichts, da er - kaum effektiver als die Mittelwertbildung per SW - nur die bereits verfälschte Spannung glättet.

Wenn Du von der obigen Annahme ausgehst, stimmt das akkurat.

Ein anderer Ansatz brachte leichte Erfolge: Da mein gleitender Mittelwert nicht korrekt dividiert, sondern Bits einfach "rausschiebt", driftet er bei schwankenden Werten etwas nach unten ab. Das wird vor allem deutlich, wenn man den ADC nur mit 8Bit ausliest. Dieser "falsche" Mittelwert kann die durch Störungen angehobene Spannung halbwegs kompensieren. Vermutlich nur in recht begrenztem Rahmen, für meinen Testaufbau mit XM-L und 4*7135 Board hat das jedenfalls mit 9,6kHz PWM ganz gut gepasst:

Bei den 7135er Boards habe ich damit gar nicht so die Probleme. So genau ( auf ein paar 10 Millivolt) muß die Akkuspannung gar nicht ausgewertet werden. Erstens ist die Akkuspannung (in der Kurzzeitbetrachtung) auch nicht zeitlich völlig konstant (Elektrochemie) , zweitens sind die Examplarstreuungen viel größer. Ganz zu schweigen von den Produktstreuungen, da müßte man wieder mehrere Monitoring_Modes für die unterscheidlichen Akkuhersteller implementieren

Aber ich sehe, Du gibst Dir da extrem viel Mühe - da ich "nur Hardwaremann" bin, komme ich da nicht mit - zumindest was die Code Entwicklung anlangt - verstehen tue ich den fertigen Code schon
Sicher, das ganze ist Hobby - und wo treibt man das Hobby manchmal schon hin...

Nein, ich habe die echt ernsten Probleme bei den 26mm 2,5A Buck Boards. Dort glaube ich viel mehr, daß die Störstrahlung (Harmonische der Induktivitätsentladung) eine wesentlich gewichtigere Rolle spielt. Die harten Schaltimpulse durch den 10A HexFet machen was ziemlich rechteckiges, mit entsprechendem Spektrum.
Dann kommt noch dazu, daß der Prozessor über einen Spannungsteiler gespeist wird (Vcc ca. 5V) und somit nicht mehr nur über die Schottky am niederohmigen Innenwiderstand des Akkus hängt. (übrigends ich schmeiße die Schottkys raus, da ich die Lampen nur selbst verwende, scheidet Verpolung fast aus)
Normalerweise müßte man den Prozessor auf einem separaten Board betreiben.
Wie schwierig sich die Labormessungen gestalten, muß ich Dir ja nicht erklären. Leider kann man von den Dingern keinen externen Versuchsaufbau realisieren, das läuft dann im kompakten wieder ganz anders. Und nun miß mal... Kabelinduktivitäten, Kabelwiderstände zum Verbraucher (Testweise natürlich möglichst keine teure LED) - einfach ein Dilemma.
Dazu kommt, daß diese Boards alle PIC's verbaut haben. Der Umbau auf AVR ist, trotz Equipment, eine sehr mühselige Fummelei.
Ich habe mir heute schon mal prophylaktisch einen PIC Basiccompiler installiert. Das ist aber doch wieder eine ganz neue Umgebung
Nun muß ich doch für Testzwecke wieder ein Board umbauen, da ich nicht die Lampe ständig malträtieren will. Wir bleiben am Ball

Edit:
Nun ist mir noch ein negativer Effekt aufgefallen. Bei meiner Version des Codes blinkt die Lampe dreimal bei Akkualarm und fährt dann ohne blinken recht schnell auf ca. 1% Lichtleistung bei weiterer Spannungsunterschreitung herunter. Da gibt es Probleme bei dem oben erwähnten Buck-Regler. Die Blinkpulse sind strommäßig so stark, daß auf dem Board (trotz kapazitiver Stützung mit 10000uF) kleine Spannungseinbrüche auftreten, die zur Auslösung des "Runterfahrmodus" führen, obwohl dessen Schwellspannung noch gar nicht erreicht ist.
Ich muß mal sehen, ob ich das Auslesen des ADC's während der Warnblinkphase stoppen kann. oder die Blinkpulse nur mit einer gedimmten Pause und nicht ganz aus versehe.
Korrektur: eigentlich werden die Werte für das Herunterdimmen doch gar nicht ausgelesen, sind doch gosub Unterroutinen beim "Blinken" - oder irre ich da?

Edit 2:
Nun blicke ich gar nicht mehr durch. Ich habe in die Routine eine Warteschleife gesetzt, damit ändern sich aber alle Triggerwerte für die Spannungen so rapide....
Der Einsprung in die "Runterfahrroutine erfolgt trotzdem sofort nach den ersten drei Blitzen.

Hier ein Ausschnitt:

'*********** ADC
U2adc = U1adc
Shift U1adc , Left , 5
U1adc = U1adc - U2adc
U1adc = U1adc + Getadc(1)
Shift U1adc , Right , 5 'Widerstände sind oben im Impressum angegeben

Waitms 500

If U1adc < 280 Then 'schaltet die Lampe (Prozessor)ab ca. 5.6V kpl. ab
Ddrb.1 = 0
Adcsra = 0 'ADC aus
Mcucr = Bits(se , Sm1)
Sleep 'Tiny schläft
End If

If U1adc < 300 Then 'dimmt die Helligkeit ab ca. 6,05V
Do
If 10 < Ocr0b Then 'min. Helligkeit (Dimmung stoppen)
Ocr0b = Ocr0b - 10 'Runterzählen der Dimmschritte
Wait 1 'Warteschleife 1 sec.
Loop ' nicht durch Spannungsschwankungen beeinflußbar
End If

Elseif U1adc < 350 Then 'blinkt drei mal ab ca. 6,2V
If Ftime = 0 Then
Gosub Flash
Gosub Flash
Gosub Flash
End If
Ftime = Ftime + 128 'Blink-Abstand 32=102s, 64=51s, 128=26s, 256=13s, keine Zwischenwerte!
End If


'********** /ADC

Loop


'*******************************

confused:confused:confused:

Man sieht, diese Probleme treten mit Linearreglern nicht auf, da der ganze "Versorgungsstrang" eine viel niedrigere Impedanz hat.
Wer aber in der Zukunft auch mehrzellige Akkulampen, oder einzellige Batterielampen modden will, wird früher oder später auf diese Probleme stoßen - zumindest wenn sie mit einem "vernünftigen" Emitter so um die 3A ziehen.

Gruß
Wolfgang

 

[rsfyfy]

Do
If 10 < Ocr0b Then 'min. Helligkeit (Dimmung stoppen)

...

Loop ' nicht durch Spannungsschwankungen beeinflußbar
End If

Keine Ahnung ob's daran liegt, aber mit der Reihenfolge scheint etwas nicht zu stimmen.

Bedenke auch, daß der Tiny die Abfrage zwecks Abschaltung nicht erreicht, wenn er in einer Do-Loop Schleife festhängt.

 

[Astrowolfgang]

Keine Ahnung ob's daran liegt, aber mit der Reihenfolge scheint etwas nicht zu stimmen.

das verstehe ich nun nicht. Der Tiny arbeitet doch bis zum "Loop" alles der reihe nach ab - oder? Da sollte doch lediglich der erreichte Triggerwert von Bedeutung sein, damit das jeweilige Unterprogramm aktiv wird.

Bedenke auch, daß der Tiny die Abfrage zwecks Abschaltung nicht erreicht, wenn er in einer Do-Loop Schleife festhängt.

das ist klar, erklärt aber trotzdem das eigenartige Verhalten nicht, wenn ich eine "Waitschleife" einbaue, damit die Spannungswerte des DC/DC nach der Blitzerei sich wieder einpegeln können.

Ich werde nachher mal einen Zweikanal-Oszi an den ADC-Port sowie an die Betriebsspannung des Tinys klemmen, und die Versorgungsspannung linear herunterfahren, bis eine Auslösung erfolgt. Mal sehen, ob da irgendwas zu sehen ist, insbesondere HF am ADC.

Edit:

So, nun habe ich erschreckendes gemessen.

[/IMG]

Kanal A ist Vss direkt am Tiny gegen GND am Tiny . Kanal B ist der ADC Eingang (PIN 7) des Tiny.
Der DC/DC Wandler arbeitete bei ca. 6,4V mit knapp 2A Laststrom ( 3A am Emitter ohne PWM!!).
Betriebsspannung war zusätzlich direkt am Board mit 10000uF gestützt, sonst kann man es gleich vergessen.

Wie man gut erkennen kann liegt das Störspektrum mit einer Vss Amplitude von ca.400mV fast genauso hoch, wie der gesamte DC - Regelbereich ( von 980mV bis 589mV) :dispirited:
(Die drei Oszillogramme stellen drei verschiedene Frequenztbereiche dar.)
Da kann der Tiny noch so viel messen, er mißt immer Mist!
Ich sehe nur einen Ausweg (irgendwelche Hardwaremaßnahmen fruchten bei dieser massiven Störung nichts) ein Tiefpaßfilter ( so um 0,1Hz) . Extreme Mittelung der Meßwerte könnten auch was bringen.
Jetzt sind die Softwareleute wieder gefragt.

Gruß
Wolfgang

 

[rsfyfy]

Nun blicke ich gar nicht mehr durch. Ich habe in die Routine eine Warteschleife gesetzt, damit ändern sich aber alle Triggerwerte für die Spannungen so rapide....
Der Einsprung in die "Runterfahrroutine erfolgt trotzdem sofort nach den ersten drei Blitzen.

Waitms 500

Falls du das Sub "Flash" nicht verändert hast, besteht mit 400ms eine vollkommen ausreichende Zeit sich nach dem kurzen Aus wieder einzupegeln -> nimm deine 500ms mal wieder raus. (Zumal sie an einer unsinnigen Stelle stehen)
Die bewirken nämlich eine extreme Trägheit bei dem gleitenden Mittelwert. Womöglich liegt es auch daran, daß die Werte gleich unaufhaltsam "abrutschen".

@Reifenfolge
Die zitierten Befehle gehören zusammen. Und das passt so wie gesagt nicht, das Do müsste hinter's If bzw. das EndIf vor das Loop. Sonst macht der Compiler irgendeinen Unsinn daraus.

 

[Astrowolfgang]

Falls du das Sub "Flash" nicht verändert hast, besteht mit 400ms eine vollkommen ausreichende Zeit sich nach dem kurzen Aus wieder einzupegeln -> nimm deine 500ms mal wieder raus. (Zumal sie an einer unsinnigen Stelle stehen)
Die bewirken nämlich eine extreme Trägheit bei dem gleitenden Mittelwert. Womöglich liegt es auch daran, daß die Werte gleich unaufhaltsam "abrutschen".

sorry, ich wußte nicht, daß die letzte (die dritte) Subroutine "Flash" eine 400ms Pause nach sich zieht.
Die Trägheit wollte ich gezielt, um dem DC/DC Regler die Zeit zu geben, wieder richtig einschwingen zu können.

@Reifenfolge
Die zitierten Befehle gehören zusammen. Und das passt so wie gesagt nicht, das Do müsste hinter's If bzw. das EndIf vor das Loop. Sonst macht der Compiler irgendeinen Unsinn daraus.

Die Reihenfolge ist von Dir, resp. von Palladin. Daran habe ich nichts verändert. Natürlich fehlen in dem kleinen Abschnitt 'ne Menge Befehle - ich hatte gezielt nur den ADC-Teil in den Forenbeitrag reinkopiert. Die Routinen funktionieren ja mit 7135-Konstantstromquellen problemlos. Ich habe hier zwei Lampen mit 7135 fertig, die laufen tadellos.
Das Problem ist der DC/DC Wandler, bzw. dessen Störstrahlung. da hilft auch Deine aktuelle Mittelwertbildung nicht wirklich.

 

[Astrowolfgang]

So, ich will mal an dieser Stelle meinen alten Thread wieder beleben.
Ich denke, es paßt hier besser rein, als wenn ich in dem Anfragethread zur Trustfire TR-J17 weiter poste.

Der Mod meiner Trustfire TR-J17 ist nun fertig.
Meßergebnisse liegen vor.
Wie ich schon in dem anderen Thred schrieb, ist der Originaltreiber definitiv nicht zu gebrauchen. ( Schalttransistor statt HEXFET mit viel zu hohem "Innenwiderstand", zu kleiner Ferritkern, der bei den Strömen in die Sättigung gehen wird)

Deshalb habe ich bei KD den SKU_S020166_7 LED Series und den SKU_S020165_9 LED Series geordert.
Beide sind schaltungstechnisch, bis auf zwei unterschiedliche Widerstandswerte, identisch.

Die gemessenen Werte bestätigen die Leistungsfähigkeit des neuen Treibers.
Sekundärseitig wurde ein Strom von 3,2A durch die LED’s gemessen. Die primäre Stromaufnahme bei 12V beträgt - examplarabhängig - 6,6 - 7A , was 79-84W entspricht. Abzüglich der Verluste (rechnerisch lediglich 10%) sind das 72-76W an den LED’s.
Boost-Treiber ist ein LTC 1871 (LTSX), der auf einen Leistungs-FET (NTMFS_4835N) arbeitet.

Diese Regler haben konstruktionsbedingt (es wird von KD als "tolles Temperaturmanagement" beworben ) den Nachteil, die Lampenleistung deutlich herunter zu regeln.
Das dauert zwischen 20-60 sec. (je nach Treiber und Kopfausgangstemperatur)
Die ungekühlte Leiterplatte erreicht durch die Verlustwärme des FETs und der beiden Schottkydioden binnen 20sec. über 50°C.
Da der LTC 1871 sehr temperaturempfindlich ist, regelt er die Leistung herunter.

Die interne Treiberauflage des Lampenkopfes erreicht zu dieser Zeit erst 47°C.
Die Heatsink der Lampe erreicht vorn binnen einer Minute Temperaturen von 60°C. (Bei Umgebungsluft-Zimmertemperatur)

Erste Lösung:
• „Thermal Potting“ des gesamten Treibers in einem speziellen paßgenauen Alu-Heatsink, mit einer Mischung von 70% Siliziumcarbid mit 2K-PUR Harz, Epoxidharz oder 2K Silikonkleber (nicht essigvernetzend) (BLF-Forum) Zumindest wird der Treiber so lange maximall arbeiten, bis der gesamte Lampenkopf die 50°C Marke erreicht hat. (ca. 1-2 min.) Danach dauert es aber auch entsprechend lange, bis wieder volle Leistung erreichbar ist. Laut den amerikanischen Foren BLF und CLP ist das „potting“ nicht sehr effektiv, und man erreicht kaum nenneswerte Brennzeitverlängerungen.

Zweite Lösung:
• aktive Luftkühlung durch einen kleinen 20-25mm 12V Lüfter im Lampenkopf.. Platz ist im Lampenkopf genügend. Dazu müssen durchgehende Lüftungsschlitze in das Gehäuse gefräst werden. (Verlust des Feuchteschutzes)


Dritte Lösung:
• Den FET , der thermisch komplett auf die Leiterplatte gekoppelt ist (Rückseite voll verlötet) thermisch an die Heatsink koppeln.
• Die Schottkydioden durch eine Doppeldiode ersetzen, und ebenfalls thermisch an die Heatsink koppeln.

Erste Versuche mit einer kräftigeren Schottkydoppeldiode (MBR 2045) sowie einem leistungsfähigen (extrem niederohmigen) N-Kanal MOSFET (D60NF) , der auf einen externen Kühlkörper gelötet wurde, verliefen erfolgversprechend. Beide Elemente wurden , isoliert durch ein Wärmeleitpad, im Lampenkopf auf die Rückseite der Heatsink geschraubt.



Probleme:
Durch die extreme Brenndauerverlängerung kann die Heatsink die Verlustwärme von ca.50W nicht mehr abführen, und heizt sich hoch. In einem Fall führte das zum Auslöten einer XML mit Strompfadunterbrechung, was zum sofortigen „Tod“ des FETs führte, Die Stromaufnahme der Elektronik steigt durch den „FET-Kurzschluß“ extrem an, was im Betriebsfall mit LiPo-Akkus zum Brand und Explosion führen könnte. Deshalb ist bei der Gesamtkonstruktion noch eine zusätzliche 10A Sicherung vorzusehen.

Messwerte:

Zeit Temperatur [°C] Primärstrom [A] bei 12V Leistung gesamt [W]
0 9,2 5,7 68
30 20 6,5 78
60 (1min) 26 6,5 78
90 35 6,5 78
120 (2min) 42 6,5 78
150 48 6,2 74
180 (3min) 55 4,5 54
210 56 4,0 48
240 (4min) 59 3,3 40


(leider rutschen die Tabellenwerte immer wieder zusammen....)

Der Lampenkopf wurde im Freien auf die „Starttemperatur „ heruntergekühlt. Nach 2,5 min. ist die interne Grenztemperatur erreicht, und die Elektronik regelt langsam (viel langsamer als beim Originaltreiber) innerhalb von 1,5 min. die Leistung herunter, um die Kopftemperatur konstant zu halten.
Experimente mit herausgezogenem Treiber, führten sehr schnell zu Kopftemperaturen von über 74°C.

Fazit:
Durch diese Modding werden die 7 XML's für einen Zeitraum von knapp 2,5min. voll mit 3A bestromt. Danach erfolgt eine langsame Leistungsreduzierung, die allerdings die steigende Kopftemperatur nicht vollständig kompensiert.
Bei niedrigen Aussentemperaturen ist sicher eine deutlich längere Maximalbrenndauer zu erzielen. Ich werde diese Nacht einen subjektiven Test im Freien durchführen. Der Einsatz der "Herunterregelung" ist nur leider visuell kaum wahrnehmbar, weil er erstens schleichend erfolgt, und es für das menschliche Auge schlicht weg egal ist ob da 70W oder 50W von den LED's verbraten werden.

Bilder werde ich wahrscheinlich nicht einsetzen , wie schon gesagt, mich stört der externe Hoster.

Auf jeden Fall kann ist diese Lampe schon ein gewaltiger Scheinwerfer. Die Lichtleistung ist so extrem, daß aus meinem, ca. 10cm vom Lampenkopf entfernt gelegenen, dunklen Pulloverärmel Rauch aufstieg - das ist kein Scherz! Was meint ihr, wie ich erschrocken meinen Arm weggezogen habe.

Ein Modding des Prozessorteils, wie bei allen meinen Lampen geschehen, ist hier nicht vorgesehen. Diese Lampe hat so oder so keinen praktischen Gebrauchswert für mich, also kann sie ruhig mit den drei Standardhelligkeiten weiterlaufen.

Das war's erst mal.

Wolfgang

 

[Astrowolfgang]

Will ich mal den Moddingthread wieder etwas auffrischen: Ein paar Impressionen zum Modding meiner TR-J18.

Der "stolze" anfängliche Strom durch die 7 XML ging innerhalb kürzester Zeit bis auf 1,1A zurück. Das ist kein Licht, zumindest nicht bei einem solchen Prügel.

Bei diesen Treibern sieht es doch schon ganz anders aus. Leider hielt KD auch nicht was er verspricht.
Schon nach ca. 30sec. dimmte der Treiber auf ca. 50% Lampenstrom herunter. Ein weiteres Exemplar dimmte "erfreulicherweise" nicht sofort und nicht so stark, ging aber dann nach ca. 4 min. ganz aus

Wenden wir uns dem Innenleben der KD-Treiber zu:

Hier sieht man sehr schön den LTC1871 , der das "intellektuelle" Herz der BOOST-Endstufe darstellt. Die beiden eingekreisten Widerstände sind der einzige Unterschied zwischen dem 7x und dem 9x XML Treibern.

Hier entsteht die Verlustwärme, welche für das runterregeln des Treibers in so kurzer Zeit verantwortlich ist.

Und hier die eigendliche Moden-Ansteuerung, noch mit dem PIC 12F629. Ich habe dieses vorerst belassen, da ich mit den 3 Modi klar komme, und bestimmt keinen "Nachtwandermodus" etc. mit dieser wuchtigen Lampe realisieren werde.

Was macht man mit den kaputten Treibern, man sucht die Fehler und ersetzt die defekten Bauelemente duch ähnliches.

Power-FET entfernt. Ließ sich erstaunlich leicht auslöten, obwohl die Pins (fast) unter dem Chip sind.

anderer PowerFet probehalber eingelötet. Bin mit der Leistung nicht zufrieden, zu hoher Kanalwiderstand. Das Ganze brauchte auch keine Brenndauerverlängerung.

Nun gehts ans "Eingemachte". "Richtige" Leistungsbauelemente rausgesucht, und thermisch korrekt auf der Heatsink befestigt. Achtung: auf elektrische Isolierung vom Lampenkörper achten!

Tja, anders bekommt man den "Kabelsalat" kaum hin, wenn es noch genug flexibel , und natürlich in den Kopf passen soll. Ausschließlich Silikonummantelte Kabel nehmen! 0,75mm² reicht.

Der Pluskontakt sollte auch einer sein, die Originalfeder ist direkt am Labornetzteil ausgeglüht. Also habe ich schnell einen passenden Messingstutzen gedreht und angelötet.

So sieht eine ordentliche Leistungsaufnahme aus.

der Treiber ist hier zur thermischen Entkopplung aus dem Kopf gezogen.

Was dann passiert, sieht man hier. Das "Lämpchen" läuft zur Höchstform auf, und wurde von mir "zwangsabgeschaltet".

Natürlich muß auch der Clickie, resp. die Kontaktfeder etwas niederohmiger gestaltet werden. Ansonsten wird es über kurz oder lang dort schmoren.

Das sind die eigentlich defekten Bauelemente des KD Treibers, die ersetzt wurden.

Nun noch was für die Hardcore-Leute. Das ist die "reverse ingenieurte" Schaltung des KD-Treibers .

Bitte keine Kommentare zum "zeichnen". Ich habe das nur mit einem einfachen Grafikprogramm gemacht. Natürlich habe ich auch ein Layoutproggy aber das müßte ich erst wieder lernen.

Wolfgang