Einfacher Umbau des Busch & Müller Luxos auf Cree XM-L fürs E-bike

[_Barracuda]

Danke fuer die weiteren Aufklaerungen!


Was mich noch etwas verwirrt ist, inwiefern eine Eingangsstrom-Messung notwendig ist, wenn wir die Stromaufnahme des Reglers doch sowieso sinusfoermig modulieren. Letzten Endes folgt aus

effizienz * I_in * U_in = I_out * U_out​

mit I_out ~ U_dac doch

U_dac ~ effizienz * I_in * U_in / U_out​

. Wenn man die Sinusfoermigkeit von Eingangsspannung U_in = U_0 * sin( 2*pi*f_ac*t ) und Eingangsstrom I_in = I_0 * sin( 2*pi f_ac t - phi ) hinzuzieht, erhaelt man

U_dac ~ effizienz * I_0 * U_0 * sin( 2*pi*f_ac*t ) * sin( 2*pi f_ac t - phi ) / U_out​

. Mit den naeherungsweise konstanten Groessen I_0 = 0.7A, effizienz = 0.9 und U_out = 3V haette man schliesslich

U_dac ~ U_0 * sin( 2*pi*f_ac*t ) * sin( 2*pi f_ac t - phi )​

. U_0 koennte man in Abhaengigkeit von f_ac einem experimentell ermitteltem Look Up Table entnehmen. Die Frequenz der Eingangsspannung f_ac wird ja sowieso aus dem zeitlichen Abstand aufeinanderfolgender zero-crossings ermittelt und t ist lediglich die seit dem letzten zero-crossing vergangene Zeit.

Mithilfe der letzten "Gleichung" koennte man die Stromaufnahme des Bucks doch ohne Messung des Eingangsstroms und mit beliebiger Phase sinusfoermig modullieren? Die Messung des Eingangsstroms waere dann doch nur zur Ermittlung des Look Up Tables fuer den geschwindigkeitsabhaengigen Vorfaktor (der unter anderm U_0 beruecksichtigt) interessant?


Hoffentlich liege ich nicht allzu weit daneben

 

[nikolauzi]

...
Was mich noch etwas verwirrt ist, inwiefern eine Eingangsstrom-Messung notwendig ist, wenn wir die Stromaufnahme des Reglers doch sowieso sinusfoermig modulieren. ...

Jein, das gilt bei einem linearen, konstanten System. Das ist der Dynamo aber nicht, da gibt es eine Rückwirkung auf das B Feld in Abhängigkeit vom Strom, somit ändert der Dynamo sein Verhalten. Könnte man natürlich mit Uin, Iout und eta rückrechnen, aber um das zu regeln mit einem PID bräuchtest Du eine noch kürzere Zykluszeit bzw. mehr Rechenaufwand in der Regelung, da ja der Eingangsstromregelung noch eine Ausgangsstromregelung in Abhängigkeit von Uin übergeordnet ist Das könnte eng werden mit einem 8-Biter.
Aber Versuch macht kluch

 

[_Barracuda]

Das könnte eng werden mit einem 8-Biter.
Aber Versuch macht kluch

So ist es. Dachte mir der ATtiny ist ein guter Einstieg in die Mikrokontrollerwelt. Ich werde mich erst an einer widerstandsartige Regelung versuchen... dafuer reicht der 8-Biter hoffentlich noch aus. Und danach kann ich mich dann (hoffentlich) an eine kondensatorartige Regelung wagen. Im Nachhinein waere wohl ein 32-Biter mit floating point unit (z.B. irgend ein Cortex M4F) optimal gewesen... evtl etwas fuer die Zukunft.

Jetzt heisst es fuer mich erstmal auf Testplatinen warten. Berichte hier dann sobald ich erste Ergebnisse habe!

 

[nikolauzi]

Man kann viel aus den Atmels rausholen, hab's bei mir mit einem STM8S gemacht, ist ähnlich und klappt gut
Und vom Widerstand zum Kondensator ist's nur ein Offset bei der Stromtabelle, zumindest beim Eingangsstrom.
Wenn ich Zeit finde, gucke ich mal, ob sich Dein DCDC auf Eingangsstromregelung umändern läßt.

 

[nikolauzi]

So, gerade mal nachgeguckt. Der Stromverstärker ist ein rail to rail, kann aber anscheinend auch beyond arbeiten, denn es wird explizit der Eingangsstrom erwähnt, S.11, 2. Abschnitt+S.20.
Ergo ISN an den Kerko+IC, ISP an den Gleichrichter, dann regelt er auf die Stromaufnahme des DCDC, theoretisch...

 

[_Barracuda]

Erste Schritte mit dem ATtiny3217

Ich konnte bereits erste Gehversuche mit dem ATtiny3217 machen und die grobe Basis des Codes fertigstellen. Fuer meine aktuellen Tests dient ein 10Ohm Wiederstand als Last und angeschoben wird das Vorderrad per Hand.

Gleich nach kraeftigem Anschieben gibt mir der ATtiny eine Frequenz (vor Gleichrichter) von etwa 45Hz aus, was bei mir etwa 7km/h entspricht. Die ausgegebene Frequenz sinkt dann wie zu erwarten ab. Der AC und die beiden Timer TCB0 und TCB1, die ich hierfuer verwende, kommunizieren via Event System (d.h. im Hintergrund). TCB0 und TCB1 erzeugen bei Zero Crossings im Wechsel Interrupts woraufhin der Wert des jeweiligen Zaehlers kopiert wird.

Um eine sinusfoermige Stromaufnahme des Bucks zu modulieren nutze ich den Timer TCA0 in Kombination mit dem DAC. TCA0 erzeugt periodische Interrupts, deren Frequenz nach jedem Zero Crossing angepasst wird.

Beispiel:

1. Fahrtgeschwindigkeit: 30km/h (f~200Hz)
2. TCB0/1 zaehlen zwischen Zero Crossings hoch bis etwa 500kHz/200Hz=2500
3. Interrupt-Frequenz von TCA0 (mit 500kHz getaktet) wird angepasst, indem festgelegt wird wie hoch TCA0 zaehlen darf. Soll die Sinus-Halbwelle in 12 Schritten moduliert werden ergibt das 2500/2/12~104. (Es wird zusaetzlich durch zwei geteilt, da TCB0/1 die Periode vor Gleichrichter abzaehlen...)
4. Bei jedem TCA0 Interrupt wird die DAC-Ausgangsspannung per LUT angepasst

Damit ist die Zahl mathematischer Operationen denke ich aufs Minimum reduziert. Es wird nach jedem Zero Crossing lediglich einmal geteilt und nach jedem TCA0 Interrupt einmal inkrementiert. Der uC kann bei 3.3V mit 8MHz laufen.



Naechste Schritte

Leider hab ich voellig vergessen Test-Platinen fuer den Buck zu bestellen. Von daher konnte ich bisher noch keine komplette Schaltung austesten.

Ich konnte ein paar SAMC21E18 (ARM Cortex-M0+, 32-Bitter, 48MHz) ergattern. Eventuell lohnt es sich gleich ein paar Test-Platinen fuer den mitzubestellen.

 

[nikolauzi]

Klingt doch schon gut!
Kleiner Tipp für die Modulation: schiebe die Periodendauer (von 0 zu 0) +8 (für die Rundung) 4 mal nach rechts als Zielwert für den DAC, dann hast Du 16 Werte pro Halbwelle, ohne Division
Und Du brauchst nur beim beliebigen Flankenwechsel H/L oder L/H zu triggern, dann hast Du 180°, das reicht für die Regelung, da nach dem Gleichrichter ja das Signal die doppelte Frequenz hat. Damit folgt die Regelung auch schneller bei dV/dt. Den Strom kann man dann in einem Feld ablegen und mit (Zeiger+Verschiebung) and 15 den passenden Strom holen. Verschiebung ist dann die Phase, die Du hinzugibst.

 

[_Barracuda]

So sollte ich das in etwa umgesetzt haben ! Das mit dem vier mal nach rechts schieben hoert sich gut an, werd ich austesten!


Hab mal einen Test in LTspice gemacht um zu schauen, ob der LT8613 (@2.2MHz) auf so schnelle Signale reagieren kann:

In blau sieht man das (ideale) Signal, das aus dem DAC des ATtiny kommt und die Stromaufnahme des Bucks moduliert. In gruen erkennt man die Stromaufnahme des Bucks. Das Signal hat eine Frequenz von 400Hz was in etwa 30km/h entspricht. Fuer die Simulation wurden eine Konstant-Spannungsquelle und 10uF (keramisch) vor dem Buck verwendet. Wie man sieht scheint der LT8613 in der Theorie auf so schnelle Signale reagieren zu koennen.


Zeit die Testplatine fuer den Buck in Produktion zu geben:

 

[_Barracuda]

Kurzes Update :


Die Testplatine fuer den Buck ist angekommen:

Ein kurzer Test ohne Dynamo sieht ganz gut aus:

Am Wochenende gehts hoffentlich weiter

 

[_Barracuda]

Es wird spannend:

Ich hab die einzelnen Komponenten mal zusammengestoepselt und ans Fahrrad angeschlossen. Das Fahrrad ist umgekehrt auf Lenker und Sattel aufgestellt, sodass sich das Vorderrad mithilfe einer Bohrmaschine drehen laesst (bis zu 40km/h kann ich so leicht simulieren).

Der uC (ATtiny3217) reguliert die Stromaufnahme des LED-Spannungsreglers (LT8613) aktuell in 64 Phasenwinkelabschnitten und noch in Phase zur Spannung. Leider krieg ich die Stromaufnahme noch nicht vernuenftig hin. Wenn ich die "Fahrtgeschwindigkeit" langsam erhoehe, sehe ich am Multimeter wie die Stromaufnahme auf etwa 200mA steigt. Erhoehe ich die Geschwindigkeit weiter, sinkt die Stromaufnahme wieder. Bei einer "idealen" sinusartigen Stromaufnahme mit 600mA Peak sollte mir das Multimeter ja etwa 380mA Anzeigen... ich koennte schwoeren das war bei einem kurzen Test gestern der Fall.

Auch die Eingangsspannung steigt nicht richtig an. Wenn ich nur uC-Spannungsregler (LT3008) und uC anschliesse, steigt die Spannung schoen mit der Geschwindigkeit weiter an. Mit LED-Spannungsregler tut sie das nicht. Auch hier koennte ich schwoeren, das das gestern nicht der Fall war

Da ich grad kein Oszilloskop da habe, werd ich die Tests naechstes Wochende mal weiterfuehren. Der Teststand steht jedenfalls

 

[_Barracuda]

Mini-Update:

Ich konnte diesem aufregenden Projekt seit dem letzten Update zwar nur wenig Zeit widmen, aber moechte dennoch mal ein kurzes Update geben .

Die Ursache fuer das Problem aus dem letzten Post war wohl ein defekter Gleichrichter. Mit einem Ozsilloskop konnte ich messen das die beiden gleichgerichteten Halbwellen komplett unterschiedliche Amplituden hatten. Mit einem andern Gleichrichter, den ich rumliegen hatte, war dieses Problem dann beseitigt.

Weiter getestet wurde mit dem Ersatzteil aber nicht mehr. Stattdessen hab ich, wie sich in den vorherigen Posts bereits angebahnt hat, den 8-Biter gegen einen 32-Biter ausgetauscht. Neue Software ist schon geschrieben und funktioniert mittlerweile wie gewuenscht.

​

Auf dem Foto oben erkennt man in blau die gemessene Spannung an einem 1-Ohm Widerstand, der hinter Gleichrichter am Dynamo angestoepselt ist. In gelb sieht man die vom DAC des 32-Biters ausgegebene Spannung, welche spaeter zur Eingangsstrommodulation an den Buck weitergegeben wird. Hier erzeugt der DAC 256 Samples pro Halbwelle. Die Phase kann ich natuerlich beliebig einstellen.

Fuer einen kurzen Test, hab ich den Buck mal mit angeschlossen. Auf den beiden Fotos unten erkennt man in blau die vom DAC an den Buck ausgegeben Spannung und in gelb die daraus resultierende Stromaufnahme des Bucks. Der Buck wurde dabei hinterm Gleichrichter am Dynamo angeschlossen. Die Fotos entsprechen glaub ich einmal 5 km/h und einmal 10km/h. Sieht doch garnicht schlecht aus.

Jetzt frag ich mich nur ob der ganze Kabelsalat (siehe Fotos aus vorherigen Posts) nicht zu stoerenden Koppelungen fuehrt ...

Weiteres folgt

 

[nikolauzi]

Ok, 32bit ist ja schon eine Menge Rechenpower, sollte Spielraum zum Spielen geben
Signalverlauf sieht aber schon ganz gut aus
Das Kabelwirrwar ist nicht gerade vorteilhaft, mußt halt gucken, daß Du Dir keinen Masseversatz einhandelst. Also am Besten mit einem Sternpunkt arbeiten, dann wird das für die ersten Tests gehen. Ev. den Leistungspfad kurz und fest verdrahten, den Controller dann fliegend.

 

[_Barracuda]

Hier mal meine letzten Messungen ohne Phasenverschiebung:

v (km/h)	f_dc (Hz)	U_in (V)	I_in (A)	I_out (A)
10	37	4,5	0,27
20	74	14,2	0,38
30	111	17,8	0,45	1,5

Bei Spannungs- und Stromwerten handelt es sich um ungefaehre RMS-Werte. Beim ganzen Geschalte des Bucks, frag ich mich wie genau die sind. Wenn die Werte einigermassen stimmen, dann ist denke ich noch viel Luft nach oben da.

Irgendwo ueber 30 km/h hat es den Gleichrichter wieder zerlegt, gleiches Problem wie vorher. Fuer die naechsten Tests nehme ich mal andere Schottky Dioden, die ich noch da hab.

 

[KDEossi]

für eine phasenverschiebung wirst du einen gesteuerten 4-quadranten-steller am eingang brauchen, also z.b. einen boost-converter mit zwei mosfet-paaren.

wie nikolauzi schon gesagt hat, ist der dynamo keineswegs linear - die magnete sättigen die statorbleche im leerlauf, wogegen bei stromfluß das magnetfeld "rausgedrückt" wird und ein lineareres verhalten zu beobachten ist (deshalb sind strom und spannung bei ohmscher vollast recht sinus-förmig, wogegen die leerlaufspannung nur entfernt daran erinnert).

daher wird es mit phasenverschiebung wahrscheinlich nicht getan sein - du wirst eine optimierte wellenform brauchen, um das meiste rauzuholen.

d.h., du wirst ein recht realistisches modell des dynamos brauchen.

dann kommt das problem dazu, daß du den nulldurchgang nicht mehr mal einfach so messen kannst, weil du ja aktiv spannung "reinpumpst". jetzt kannst du einen präzisen positionssensor montieren (z.b. große scheibe mit vielen kleinen schlitzen und eine lichtschranke, oder du klebst auf die felge viele kleine magnete und einen hall-sensor oder reed-schalter an die gabel), oder du bist im bereich der positionssensor-losen positionsbestimmung.

letzteres ist eine echte herausforderung, weil a) dir nur eine phase zur verfügung steht und b) du die genaue momentan-induktivität des dynamos brauchst, womit wir wieder bei dem genauen modell sind.

wenn du erstmal praktisch nur bahnhof verstanden hast, liegt das daran, daß das alles themen auf dissertations-niveau sind. von denen habe ich etliche gelesen, und einen teil davon sogar verstanden.

ich bin mit meinem projekt an dem punkt "realistisches modell des dynamos" ...

(p.s., irgendwie sind die benachrichtigungsmails der letzten jahre verschütt gegangen, daher die späte reaktion.)

 

[_Barracuda]

Hoert sich sehr interessant an, danke fuer die Rueckmeldung!

daher wird es mit phasenverschiebung wahrscheinlich nicht getan sein - du wirst eine optimierte wellenform brauchen, um das meiste rauzuholen.

Hab mir schon gedacht, das hinter dem Verschieben der Phase mehr steckt als eine kleine Softwareaenderung , daher auch erstmal ohne Phasenverschiebung. Erst wenn ich das gut hinkriege, wage ich mich an die Verschiebung heran.

ich bin mit meinem projekt an dem punkt "realistisches modell des dynamos" ...

Handelt es sich dabei um ein oeffentliches Projekt?

 

[KDEossi]

Handelt es sich dabei um ein oeffentliches Projekt?

ja, wird es. ich will aber erstmal konkrete ergebnisse vorzuweisen haben.

zur messung erzeuge ich ein erreger-signal mit dem pc, blase es über einen regulären audio-verstärker in den probanten, dann wird der strom über einen shunt-widerstand gemessen, und zusammen mit der tatsächlichen erreger-spannung über einen kleinen impedanzwandler/vorverstärker in stereo wieder dem pc zugeführt.

ich habe eine gebrauchte emu0404-pci-soundkarte erworben und und auf gleichstrom umgebaut (weil wir sehr nieder-frequente signale sehr genau messen müssen, und zur eichung brauche ich auch DC), allerdings ist der linux-treiber für das ding nicht ganz so gut wie es schien, deshalb bin ich gerade am kernel-hacking.
mit billigen sb128-pci ist nur müll rausgekommen, weil die einfach zu nicht-linear sind. und der on-board-sound moderner motherboards ist typischerweise nicht auf DC umbaubar (die codec-chips enthalten einen digital-hochpass, der sich nicht abschalten läßt).

ich habe erstmal diverse "reguläre" spulen vermessen, um zu sehen, wie das so klappt. dabei zeichnet sich schon ab, daß selbst diese sehr nicht-linear sind, also sehr viel "spaß" beim modellieren, und hohe anforderungen an die meßqualität.

in der nächsten stufe wird der dynamo vermessen. dafür bastele ich einen extrem langsamen antrieb, damit die position schön gleichmäßig fortschreitet und die emf die messung nicht verfälscht.

das mit der bohrmaschine für den schnellen antrieb habe ich auch schon durch. nach einer langen meßreihe taten mir handgelenke und ohren weh, und automatisieren läßt sich das auch nicht. daher habe ich einen modell-hubschrauber-motor (außenläufer, wirkt direkt auf den reifen) und eine ESC (electronic speed controller) erworben (gibt's bei dx.com für 'n appel und 'n ei) und über einen raspberry pi mit dem pc gesteuert.

dazu habe ich einen haufen python-code zum steuern, signal-generieren, aufzeichnen, auswerten und visualisieren produziert. alles nicht so schön.

 

[_Barracuda]

Erfreuliches Update:

Hier mal das aktuelle Setup:

Nachdem ich aus Interesse einfach mal einen Elko parallel zum Buck geschaltet habe, scheint die Geschichte ohne Phasenverschiebung jetzt "gut" zu funktionieren (was sagt ihr?). Mir ist auch aufgefallen, das der Buck mit Elko aufhoert wie ein kleines Schweinchen zu quiecken .

In diesem Post hatte ich ja bereits Messungen des Eingangsstromes ohne Elko (siehe Bild 2 und 3) gezeigt. Streng genommen handelt es sich nicht direkt um den Eingangsstrom sondern um die Spannung an nem Wiederstand in Serie zum Buck (hat ja eh beides dieselbe Form). Auf den Bildern sieht man das die Halbwellen farblich ausgefuellt sind, was ja am Geschalte des Bucks liegt.

Auf dem Bild oben sieht man das Ganze jetzt fuer den Fall mit Elko. Dieses Mal verschluckt der Elko das Schalten des Bucks, daher hier ein "saubererer" Eingangsstromverlauf. Mit Elko scheint die Regelung in Phase etwas besser zu funktionieren.

Die Werte aus der folgenden Tabelle wurden bei einem Buck-Takt von 200kHz gemessen:

v (km/h)	f_dc (Hz)	U_in (V)	I_in (A)	U_out (V)
10	37	4.0	0.46	2.83
20	74	8.0	0.46	2.97
30	111	11.4	0.45	3.04

Bei 30 km/h fliessen in etwa 1.6A durch die LED. Oberhalb von 30 km/h scheint sich nicht mehr allzu viel zu tun . Wenn ich den Buck-Takt auf 800kHz erhoehe, dann messe ich bis 30km/h nur murks. Ab 30km/h messe ich dann sprungartig 14V Eingangsspannung und dann mit zunehmender Geschwindigkeit wieder mehr bei gleichem Eingangsstrom wie oben.

Auf den ersten Blick scheint die Leistung mindestens auf Supernova M99 DyPro Niveau zu sein. Als naechstes schaue ich mir das mit dem Buck-Takt mal genauer an.

 

[KDEossi]

du meinst den elko am buck-eingang? das empfiehlt sich bei dieser frequenz ohnehin, denn sonst hast du wahnsinns-verluste im dynamo und einen super störsender obendrauf.

"richtige" maschinen werden normalerweise im nf-bereich getaktet, daher hört man sie auch heulen oder fiepen. das hält die schaltverluste der großen halbleiter in grenzen, und man spart sich die passiven teile zur glättung. außerdem hat man direkten "zugriff" auf den spulenstrom, was eben für die "sensorlose" positionsbestimmung nützlich ist.

angehängt ist ein schon etwas älterer entwurf für einen aktiven eingangskreis. wie du siehst, habe ich auch einen abblockkondensator für die hohe frequenz vorgesehen. die werte sind für 250khz ausgelegt, was ich bei meiner ersten solchen schaltung mit einem attiny so rausholen konnte. dahinter käme dann der große ladekondensator und der buck-regler.

als mosfet-paare empfehlen sich im übrigen vollintegrierte GaN-bauteile wie LMG5200 - kosten zwar ein vermögen, sind aber rundum-sorglos-pakete, und man kann sie "ungestraft" sehr hoch takten (bei Si-transistoren wirst du bei hoher frequenz viele gate-drive-verluste haben, und das merkt man bei kleiner leistung des gesamtsystems dann schon).

als controller sind iirc eher ATSAM-D geeignet, weil die auf motorsteuerung ausgelegt sind und somit den ganzen pwm-schnickschnack eingebaut haben.

 

[nikolauzi]

@_Barracuda
Das sieht doch soweit schon gut aus Hattest Du im Buck keinen Eingangskerko dran? So 20-60uF Kerko direkt am Buck sollten da schon reichen. Elko hat Probleme bei den hohen Frequenzen, es sei denn, Du nimmst Hybridelkos.
Aktuelle Leistung ist so zu erwarten, ohne Phasenverschiebung. Jetzt wird's interessant. Was modulierst Du als Spitzenstrom auf den Buck?

 

[_Barracuda]

Hattest Du im Buck keinen Eingangskerko dran?

Ich hatte zwar einen dran, aber einen mit nur 10u.

Was modulierst Du als Spitzenstrom auf den Buck?

Das muessten ~610mA sein.

Hab mal etwas mit dem Buck-Takt herumgespielt:

v (km/h)	10	20	30	40
buck takt (kHz)	200	400	600	600
P_in (W)	1.8	4.3	7.2	9.4

Ab etwa 30 km/h hat der DAC teilweise Aussetzter. Ansonsten bin ich sehr zufrieden was die Leistung angeht. Evtl. ist ja der Elko da zu lahm.

Edit: Hab grad mal zwei weitere 1000uF 50V Elkos parallel dazugeschaltet. Die Aussetzer waren deutlich wengier, bzw. kaum da.

 

[KDEossi]

mit so gigantischen elkos nach dem gleichrichter macht die quellstrom-modulation kaum noch sinn. nikolauzi hat schon ganz recht, daß du dafür einen kerko (MLCC) nehmen solltest - wenig ESR bei relativ wenig kapazität.

was hat der DAC mit der geschwindigkeit zu tun? dessen output-rate ist doch sicher halbwegs konstant? kann es sein, daß du bei steigender leistung einfach so viele störungen verursachst, daß die schaltung instabil wird? bei dem kabelwust wäre das ja nicht so unwahrscheinlich. evtl. einen kleinen abblockkondensator am DAC-ausgang installieren.

den buck-takt mit der leistung (oder genau genommen, der maximalen eingangsspannung) zu variieren hat insofern sinn, daß du eine kleinere induktivität nehmen kannst, und die treiber-verluste bei kleinerer leistung auch kleiner sind. ob es praktisch eine rolle spielt, mußt du ausprobieren.

 

[KDEossi]

übrigens, ein historischer und immer noch weitgehend relevanter thread zu dem thema: https://www.mtb-news.de/forum/t/step-down-wandler-f-dynamo.267778/ (von meinen eigenen ausführungen ist das sinnieren über die effizienz bei höheren spannungen jetzt völlig obsolet - auf GaN-basis kann man auch bei 100v noch kleine leistungen effizient umsetzen. und ich kenne jetzt die antworten auf viele der fragen von damals. ).

 

[nikolauzi]

...
Edit: Hab grad mal zwei weitere 1000uF 50V Elkos parallel dazugeschaltet. Die Aussetzer waren deutlich wengier, bzw. kaum da.

1000uF+ sind definitiv zuviel, damit begrenzt Du die Leistung eher, da die Phasenbeziehung flöten geht. 40uF Kerko oder Folie zum Test. Direkt an den Buck, ohne Kabel.
Bricht die Versorgung des uC ev. ein?
Setz mal den Spitzenstrom auf 450mA, damit steigt die Spannung, ergo mehr Leistung. 4W sind schon ab 10km/h möglich

 

[_Barracuda]

Bricht die Versorgung des uC ev. ein?

Das kann ich dir leider nicht sagen. Ich hab den uC bisher stets am Spannungswandler des Programmierers (Seeduino XIAO) betrieben. Der Programmier ist per USB am Rechner angeschlossen. Bis 30km/h lief der uC fehlerfrei, ab 30 km/h haben dann vereinzelt Halbwellen des DAC-Ausgangs gefehlt (der Buck hat mit leichtem LED-Flimmern gemeckert). Bei meinen letzten Tests mit 40-50km/h hat sich der uC irgenwann komplett aufgehangen (DAC-Ausgang komplett zusammengebrochen, musste Software neu aufspielen damit der uC wieder funzt). Ich glaub der DAC-Ausgang ist hinueber, kommt nichts mehr raus . Der Rest des uC scheint noch zu funktionieren.

Ob der DAC-Ausgang evtl zu viel Strom liefern musste? Vlt ware ein 330Ohm Widerstand in Serie als Ueberstromschutz eine gute Idee fuers naechste Mal. Die DAC-Samplerate sollte am Ende mit 40-50km/h bei etwa 50kHz gelegen haben (bis zu 350kHz sind laut Datenballt moeglich).

Erstaunlicherweise ist der Buck unversehrt. Der LT8613 war zwar nicht ganz guenstig, scheint aber gute Arbeit zu leisten.

Gerade wo es richtig spannend wurde

 

[nikolauzi]

Nicht, daß Du durch die Verkabelung einen Masseversatz hast und damit der DAC über die Bodydiode clamped? Versuche es mal mit klarem Sternpunkt, kein Strom über die uC Masse.
Und wenn Versorgung des uC über den Programmer (USB), immer die Oszimasse mit berücksichtigen, das kann auch ganz böse Masseschleifen ergeben Das war das erste, was ich meinem Padavan auf der Arbeit beigebracht habe und er dennoch manchmal wieder versaubeutelt, z.B. durch das Lankabel vom Oszi zum PC