GizZilla vs. IBF, Delldog, Normen, Bugs, ...

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Da habe ich mich nicht darauf verlassen. Zum Testen benutze ich die Conrad-Test-PWS (sind ein Poti mit einer kleinen SMD-Platine drauf, da kann man dann eine Pulsweite von 0,8ms bis 2,2ms einstellen). Wenn man zwei von diesen Dinger verwendet, kommen die Pulse garantiert nicht nacheinander.
      Nun, das ist richtig... Solange es nur 2 Kanäle sind bin ich dagegen auch unempfindlich, ich bin INT gesteuert... Die Jungs die jedoch pollen werden es als lustig empfinden...

      Vielleicht habe ich jetzt eine passende Antwort zur falschen Frage: Wenn mir bei einem Projekt die Ports ausgehen, dann nehme ich immer ein paar Latches her.
      Bei mir darf es aber kein IC Grab werden... Max 3: uC, Treiber und OP (Bei Dual Version natürlich 4, weil zweiter Treiber). Ich hab kein Problem mit der Anzahl der Pins, eher mit dem Timing...
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • Ok ... also ich setze einen ATMega32 mit 16Mhz ein.
      Was ich nachfolgend schreibe funktioniert definitiv bei mir!

      1. RC-Signal digitalisieren
      Einen der 4 Timer (8Bit) habe ich als interne Uhr mit einer Auflösung von 0,01ms geschaltet (long-Counter-Variable).
      Da das RC-Signal pro Kanal zw. 1ms und 2ms liegt (je nach Stick-Position) bedeutdet das eine AUflösung von 100 Schritten ... das reicht dicke zum Steuern.

      Als Eingang zum uC verwende ich auch die INT-Eingänge. Über ein externes OR-Gatter habe ich Kanal 1&3 und an einem Zeiten Gatter 2&4 zusammengeführt. (DAS KLAPPT!)
      Laut meinem Oszi liegen die fallende Flanke des Kanal 1 und die steigende Flanke des Kanal 2 bei entsprechender Stick-Position so nahe beisammen dass eine Interruptbehandlung das teilweise nicht mehr erfassen kann.

      In der Interruptroutine speichere ich einfach den Zählerstand der oben beschriebenen Uhr. In der Main-Scheife (also nicht in der Intterruptroutine) berechne ich dann die Stickposition und steuere damit den PWM Ausgang.

      Kreuzmischer und Failsafe sind auch schon eingebaut und funktionieren.

      2. PWM Ausgang
      Um nicht pollen zu müssen haben ich zur Steuerung die beiden 16Bit-Timer-Pwm-Einheiten des ATMega32 auf 4KHZ eingestellt.
      Um aber auch individuell steuern zu können , will ich jede Seite der H-Bridge über einen HIP direkt vom uC ansteuern ansteuern. D.H. 4 Pins mit den Steuersignal vom uC zum HIP plus eine Disable-Leitung (Also die PWM-Ausgangssignale werden hardwareseitig nicht benutzt!).
      Die Hardware-PWM Signale generieren jeweils einen Interrupt beim Match des PWM-Counters mit dem Vergleichsregister und beim Überlauf. Das reicht, um in den Interruproutinen die entsprechenden Pins zm HIP manuell korrekt zu setzen (2 Zeilen Code!).

      Die Waffen-steuerung mach ich analog über den 4ten Pwm-Timer allerdings nur mit 1KHZ bis jetzt .. den will ich aber noch aufbohren.

      3. Performance
      Um einschätzen zu können, wieviel Rechenkapazität ich noch habe, zähle ich die Main-Schleifen-Durchgänge und gebe die Pro Sekunde aus: mit den beschriebenen Funktionalitäten durchlaufe ich die Mainschleife immer noch ca. 12500 mal pro Sekunde. Das reicht dicke zum Steuern und noch für evtl. zusätzliche Aufgaben .... Kanal 4 des RC-Signals ist schon erfasst ... aber noch ungenutzt.

      4. Wie gehts weiter
      In einem älteren Testaufbau klappt der HIP mit den MOSFETS und dem Motor dran.
      Diese werden nun angeschlossen und die Schaltung an einem Motor erstmal auf Herz und Nieren geprüft.
      Das Ganze ist im Moment für unsere Raptoren gedacht.
      Ich mache KEINE Strombegrenzung .. da die Akkus überhaupt nicht den Strom bei 12V liefern können (wie gesagt ... muss ich noch genau testen.... bis herläuft die Logik und die H-Bridge aus einem älteren AUfbau ... zusammen hab ich sie noch nicht laufen gehabt.)

      5.Hardware
      Meine Logik-Abteilung brauch also bisher (abgesehen von dem ISP-Anschluss, Quarz usw.) nur den uC und Gatter-Baustein mit 2-OR-Gattern.
      Hinzukommen noch: Optokoppler für alle uC-Signale zum Hip + den HIP selbst.
      Mit weniger Hardware geht es kaum noch.
      Der Hip hat den Vorteil, dass der das Detail-Timing der H-Bridge übernimmt (Totzeit zwischen dem Umschalten). Diese Aufgabe übernehme ich im uC nicht (ist mir im Moment zu heiß das Thema und er HIP kann es ja!)


      Gruss Delldog.
      [COLOR=sky blue]Besucht unsere Website![/COLOR]
      "Wer kämpft kann verlieren, wer nicht kämpft hat schon verloren!"
      (Berthold Brecht)
    • 1. RC-Signal digitalisieren
      Einen der 4 Timer (8Bit) habe ich als interne Uhr mit einer Auflösung von 0,01ms geschaltet (long-Counter-Variable).
      Da das RC-Signal pro Kanal zw. 1ms und 2ms liegt (je nach Stick-Position) bedeutdet das eine AUflösung von 100 Schritten ... das reicht dicke zum Steuern.
      Ein ATmega32 hat nicht 4 sondern nur 3 Timer, 2x 8 bit und 1x 16 bit...

      ls Eingang zum uC verwende ich auch die INT-Eingänge. Über ein externes OR-Gatter habe ich Kanal 1&3 und an einem Zeiten Gatter 2&4 zusammengeführt. (DAS KLAPPT!)
      Das ist schön, kommt aber nicht in Frage weil das einen externen Baustein verlangt der absolut unnötig ist... Da gibts elegantere Varianten mehr als 2 RC Signale einzulesen, auch ohne externe Logik...

      Laut meinem Oszi liegen die fallende Flanke des Kanal 1 und die steigende Flanke des Kanal 2 bei entsprechender Stick-Position so nahe beisammen dass eine Interruptbehandlung das teilweise nicht mehr erfassen kann.
      Das geht alles wenn man die externen INTs benutzt...

      In der Interruptroutine speichere ich einfach den Zählerstand der oben beschriebenen Uhr. In der Main-Scheife (also nicht in der Intterruptroutine) berechne ich dann die Stickposition und steuere damit den PWM Ausgang.
      Auch als free running timer bekannt... Das mach ich übrigens genau so...

      Um nicht pollen zu müssen haben ich zur Steuerung die beiden 16Bit-Timer-Pwm-Einheiten des ATMega32 auf 4KHZ eingestellt.
      Nur ein 16bit Timer mit 2 16 bittigen output compare Einheiten die sie jedoch beide auf den 16 bit Timer beziehen und damit auf der gleichen PWM Frequenz laufen. Hier ja aber nicht tragisch, sogar erwünscht...

      Um aber auch individuell steuern zu können , will ich jede Seite der H-Bridge über einen HIP direkt vom uC ansteuern ansteuern. D.H. 4 Pins mit den Steuersignal vom uC zum HIP plus eine Disable-Leitung (Also die PWM-Ausgangssignale werden hardwareseitig nicht benutzt!).
      Die Hardware-PWM Signale generieren jeweils einen Interrupt beim Match des PWM-Counters mit dem Vergleichsregister und beim Überlauf.
      Das hab ich am Anfang auch gemacht, bin dann aber dazu übergegangen die beiden freien Timer zu benutzen um die PWM für Modus 2b selbst zu erzeugen... Das geht aber nicht weil die eine PWM ins stocken gerät wenn gerade die andere berechnet wird. Also zurück zu den OC Einheiten... Da wird die PWM auch dann weiterlaufen wenn gerade die andere berechnet wird...

      Das reicht, um in den Interruproutinen die entsprechenden Pins zm HIP manuell korrekt zu setzen (2 Zeilen Code!).
      Ich weiß ja nicht welchen Modus du fährst, aber 2b ist sicherlich nicht (ohne externe Logik) in 2 Zeilen zu machen ...

      3. Performance
      Um einschätzen zu können, wieviel Rechenkapazität ich noch habe, zähle ich die Main-Schleifen-Durchgänge und gebe die Pro Sekunde aus: mit den beschriebenen Funktionalitäten durchlaufe ich die Mainschleife immer noch ca. 12500 mal pro Sekunde. Das reicht dicke zum Steuern und noch für evtl. zusätzliche Aufgaben .... Kanal 4 des RC-Signals ist schon erfasst ... aber noch ungenutzt.
      Mein ATmega32L kann max mit 8 MHz laufen und rennt aktuell auf 7,3728 MHz... Dazu kommt noch mein I2C und mein LCD Display... Aber selbst das funktioniert wenn man da behutsam vorgeht...

      Mit weniger Hardware geht es kaum noch.
      Das ist so nicht richtig... Das ODER Gatter und die Optokoppler lassen sich weg optimieren...

      Der Hip hat den Vorteil, dass der das Detail-Timing der H-Bridge übernimmt (Totzeit zwischen dem Umschalten). Diese Aufgabe übernehme ich im uC nicht (ist mir im Moment zu heiß das Thema und er HIP kann es ja!)
      Das ist eigentlich nur als Schutz und nicht als Dauerfeature gedacht... Meiner Meinung nach grob fahrlässig wenn man sich da aussschließlich auf den HIP verläßt...

      Ich mache KEINE Strombegrenzung .. da die Akkus überhaupt nicht den Strom bei 12V liefern können (wie gesagt ... muss ich noch genau testen.... bis herläuft die Logik und die H-Bridge aus einem älteren AUfbau ... zusammen hab ich sie noch nicht laufen gehabt.)
      Das finde ich ehrlich gesagt schon fast unverschämt fahrlässig... Nimm ein Multimeter (aber ein gutes!) oder besser eine (gute) Stromzange, schließ deinen 12V/3Ah NiCD Akku kurz und miss den Strom... Aber nicht zu lange! Gewisse exotherme Rekationen sind nich auszuschließen, und warum? Weil ein nicht zu verachtendes "Strömchen" fließt....
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • Laut meinem Oszi liegen die fallende Flanke des Kanal 1 und die steigende Flanke des Kanal 2 bei entsprechender Stick-Position so nahe beisammen dass eine Interruptbehandlung das teilweise nicht mehr erfassen kann Das geht alles wenn man die externen INTs benutzt..

      Ich nutze doch zwei externe Interrupts ... ich könnte natürlich jedem Kanal seinen eigenen INT-EIngang spendieren .... ich will diesen MEchanismus auch bei den Heavies nutzen. Dort brauche ich wegen der Strombegrenzung aber noch einen freien INT-Eingang.


      Das hab ich am Anfang auch gemacht, bin dann aber dazu übergegangen die beiden freien Timer zu benutzen um die PWM für Modus 2b selbst zu erzeugen... Das geht aber nicht weil die eine PWM ins stocken gerät wenn gerade die andere berechnet wird. Also zurück zu den OC Einheiten... Da wird die PWM auch dann weiterlaufen wenn gerade die andere berechnet wird...

      Ich berechne die PWM-Signal aber nicht im Interrupt (das hatte ich probiert, war absolut tödlich für das Timing der anderen interrupts)! die Berechne ich in der Main-Schleife.

      Das reicht, um in den Interruproutinen die entsprechenden Pins zm HIP manuell korrekt zu setzen (2 Zeilen Code!). Ich weiß ja nicht welchen Modus du fährst, aber 2b ist sicherlich nicht (ohne externe Logik) in 2 Zeilen zu machen ...

      Wo gibts diese Auflistung der Modi? ich kann sie nicht finden.
      Ich setze die 4 Pins mit einem Befehl. Ist doch immer das gleiche Schema.

      Mein ATmega32L kann max mit 8 MHz laufen und rennt aktuell auf 7,3728 MHz... Dazu kommt noch mein I2C und mein LCD Display... Aber selbst das funktioniert wenn man da behutsam vorgeht...

      Wieso die L-Variante? Erst schreibst du, dass du Timing-Probleme hast, und dann nutzt du die langsamere Low-Voltage-Variante.
      wegen SMD?

      Das ist so nicht richtig... Das ODER Gatter und die Optokoppler lassen sich weg optimieren...

      Die Optokoppler lass ich im Testaufbau vorsichtshalber mal drin, ... ich messe dass dann mit dem Oszi durch ... mal sehen, ob ich darauf verzichten kann. Am ANfang des Threads habt ihr dazu noch anders geklungen.

      Strombegrenzung Das finde ich ehrlich gesagt schon fast unverschämt fahrlässig... Nimm ein Multimeter (aber ein gutes!) oder besser eine (gute) Stromzange, schließ deinen 12V/3Ah NiCD Akku kurz und miss den Strom... Aber nicht zu lange! Gewisse exotherme Rekationen sind nich auszuschließen, und warum? Weil ein nicht zu verachtendes "Strömchen" fließt....

      Ich teste es durch !
      Zum Testen verwende ich erstmal billig-Mosfets!

      Mal schauen ;)

      Delldog.
      [COLOR=sky blue]Besucht unsere Website![/COLOR]
      "Wer kämpft kann verlieren, wer nicht kämpft hat schon verloren!"
      (Berthold Brecht)
    • Ich berechne die PWM-Signal aber nicht im Interrupt (das hatte ich probiert, war absolut tödlich für das Timing der anderen interrupts)! die Berechne ich in der Main-Schleife.
      In meiner Main Schleife bleibt durch oben genannte Peripherie im Moment nicht viel übrig... Des Rätsels Lösung, alles raus nehmen was nicht unbedingt rein muss, aber erst wenn alles andere fehlgeschlagen ist...

      Wo gibts diese Auflistung der Modi? ich kann sie nicht finden.
      Ich setze die 4 Pins mit einem Befehl. Ist doch immer das gleiche Schema.
      Ahja, das bei dir nicht vorhandene Problem der zeitgerechten Ansteuerung der FETs...

      Wieso die L-Variante? Erst schreibst du, dass du Timing-Probleme hast, und dann nutzt du die langsamere Low-Voltage-Variante.
      In erster Linie ist es "nur" ein Prototyp mit dem ausgetestet werden soll was alles geht und was nicht... Zweitens hab ich die Module zufälligerweise in nicht geringer Anzahl aus ehemaligen Projekten zur Verfügung...

      Am ANfang des Threads habt ihr dazu noch anders geklungen.
      Zu Optokopplern? Ich kann in meinem Thread hier nichts dazu finden... An anderer Stelle wurde das mal diskutiert, aber das bezog sich auf Optokoppler zwischen uC und Treiber, und das geht nun mal gar nicht weil die Flanken dabei langsam werden....
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • Die Atmel-Fraktion schlägt zu.... :engel:
      Ihr verrennt euch nicht mit euren Interrupts-Orgien? Was passiert, wenn mal ein bißchen Störung auf den Empfangsleitungen eintrifft? Keine Sorgen, dass das ganze Timing aus dem Ruder läuft?
      (Ich habe die ganze Trickserei mit den Interrupts bewußt vermieden, um im Programm genau das abzufragen, was ich gerade wissen will. Vielleicht nicht ganz elegant und ich auch brauche auch ein paar ICs mehr, aber es funktioniert narrensicher.... =) )

      Trotzdem viel Glück bei euren restlichen Entwicklungen!
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Ihr verrennt euch nicht mit euren Interrupts-Orgien? Was passiert, wenn mal ein bißchen Störung auf den Empfangsleitungen eintrifft? Keine Sorgen, dass das ganze Timing aus dem Ruder läuft?
      Gar nichts, weil der Impuls dann als Fehler gewertet wird wenn er nicht innerhalb der Spezifikation eines RC Pulses ist... Deweiteren müssen erst 3 gültige Impulse eintreffen bevor was passiert, die Methode kennst du, ist doch bei dir geklaut ;)

      aber es funktioniert narrensicher....
      Tschuldige, aber das gilt es erst noch zu beweisen... Je mehr ICs desto mehr mögliche Fehlerquellen...

      Trotzdem viel Glück bei euren restlichen Entwicklungen!
      Danke dir auch... Nächste Revision bei dir schon raus?
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • Gar nichts, weil der Impuls dann als Fehler gewertet wird wenn er nicht innerhalb der Spezifikation eines RC Pulses ist... Deweiteren müssen erst 3 gültige Impulse eintreffen bevor was passiert, die Methode kennst du, ist doch bei dir geklaut

      Die drei gültigen Pulse wurden auf vier erweitert, damit die Mittelwertbildung anschließend ein bißchen flotter über den Prozessor geht (vier Char in eine Integer addiert, dann zweimal rechts geshiftet... das geht schneller als geteilt durch 3 =) ) => Das ist der Nachteil bei der Hausfrauenmethode (=Polling): man muß kurze und schnelle Subroutinen haben.

      Tschuldige, aber das gilt es erst noch zu beweisen... Je mehr ICs desto mehr mögliche Fehlerquellen

      ok, ok..... sollte meinerseits nicht überheblich klingen. Nur hat meine bisherige Praxis gezeigt, je mehr man einem Prozessor aufbürdet, desto leichter treten irgendwelche Nebeneffekte auf, die leider nicht im Proz.-Handbuch beschrieben sind. Bei diskreten Lösungen kann man mit dem Oszi seine Fehler suchen und ggf. durch ein paar Hardwaretricks beseitigen.

      Nächste Revision bei dir schon raus

      Kommt morgen noch dran, wenn Roland den Rapi nach Amsterdam mitnimmt. Trotz der vierfach-Überprüfung von gültigen Werten läuft der Motor stellenweise kurz an. Aber nur, wenn die Fernbedienung nicht eingeschaltet ist. Der Empfänger gibt also bei fehlendem Trägersignal von den Nachbarkanälen kleine Fehlsignale heraus. Die möchte ich noch abfiltern. Wir so laufen, dass ich nicht nur auf vier gültige Signale schaue, sondern diese Signale müssen alle die gleiche Größenordnung haben.
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Die drei gültigen Pulse wurden auf vier erweitert, damit die Mittelwertbildung anschließend ein bißchen flotter über den Prozessor geht (vier Char in eine Integer addiert, dann zweimal rechts geshiftet... das geht schneller als geteilt durch 3 ) => Das ist der Nachteil bei der Hausfrauenmethode (=Polling): man muß kurze und schnelle Subroutinen haben.
      Tja, dann nimm doch mal nen vernünftigen Prozessor der Additionen und ggfs. auch Multiplikationen in einem Takt schafft... RISC rulez, gelle? :engel:

      ok, ok..... sollte meinerseits nicht überheblich klingen. Nur hat meine bisherige Praxis gezeigt, je mehr man einem Prozessor aufbürdet, desto leichter treten irgendwelche Nebeneffekte auf, die leider nicht im Proz.-Handbuch beschrieben sind. Bei diskreten Lösungen kann man mit dem Oszi seine Fehler suchen und ggf. durch ein paar Hardwaretricks beseitigen.
      Ja ich gebs zu, manchmal gibts da unvorhergesehene Effekte... Allerdings hat die Variante so viel wie möglich in Software zu erledigen gewisse Vorteile... Einer davon ist der schon angesprochene und der andere ist dass nicht gleich ne neue Revision der Hardware her muss wenn ein nicht hackbarer Hard Wired Fehler drauf ist...

      Der Empfänger gibt also bei fehlendem Trägersignal von den Nachbarkanälen kleine Fehlsignale heraus. Die möchte ich noch abfiltern. Wir so laufen, dass ich nicht nur auf vier gültige Signale schaue, sondern diese Signale müssen alle die gleiche Größenordnung haben.
      Solche Scherze sind mir bisher noch gar nicht aufgefallen, da ich immer mit meinem Joystick RC Pulse Gen experimentiere... Lustig ;)
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • Solche Scherze sind mir bisher noch gar nicht aufgefallen, da ich immer mit meinem Joystick RC Pulse Gen experimentiere...

      So gings mir auch, bis ich bei MMMV2 den Rapi mal eingeschaltet habe, während in der Arena gerade Kämpfe liefen. Da zuckten die Motoren, während zuhause im heimischen Labor die Welt in Ordnung war.
      (Gut dass bei MMMV2 die beiden Fernsteuer-Ausgabeberechtigten ein Herz hatten und die Fernsteuerung zur Fehlersuche herausrückten.... :engel: )
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • [Update]

      So, jetz jetz weiß ich wohl wozu man Optokoppler verwendet... Gerade ist das CPU Modul "grundlos" abgeraucht... Und zwar wollte ich nach einer kompletten Überarbeitung des RC Decoders den Failsafe austesten indem ich wie immer den Strom des RC Pulsgenerators unterbrach... Das war wohl ein Fehler...

      Wir schreiben zwar jetzt die neue Minor Versionsnummer 1.1.4, aber Freude wollte sich doch nicht so recht einstellen...
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • aber Freude wollte sich doch nicht so recht einstellen...

      nicht entmutigen lassen, Zähne zusammenbeißen und dann weiter-entwickeln.... ! Irgendwann ist der break-even zwischen Freunde und Frust, dann bereut man nichts mehr. Durchhalten! Ich kann ja auch ein paar Frust-Stories posten, vielleicht faßte dann wieder neuen Mut ?

      jetz jetz weiß ich wohl wozu man Optokoppler verwendet...

      Tja, das wäre der Vorteil von diesem Testpunkt gewesen. Aber auch nach dem Optokoppler kann man beim Testen noch was falsch machen (z.B. den Treiber-IC herausziehen, alle vier MOS-FEts der H-Bridge werden dann gleichzeitig durchgesteuert... :smilybrennt: )
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Um das Thema nicht in Vergessenheit geraten zu lassen:

      mcmanis.com/chuck/robotics/pr...e/h-bridge.html

      vieleicht sind hier wichtige Infos verborgen.


      Schon lustige Sachen die der da macht. Allerdings erachte ich hier die Spannungspumpe als Problem, da sie vermutlich nur ein paar mA liefern kann. In anderen Worten heißt das dass die FETs wieder nur mäßig schnell angesteuert werden können. Ausserdem die Problematik mit den Optokopplern. Optokoppler sind zwar ne tolle Sache, aber zu langsam. IBF kann ein Lied davon singen...
      .: Formerly known as GRA Administrator, now OUT OF ORDER :.
    • IBF kann ein Lied davon singen...

      Hehe... Negativerlebnisse prägen sich in der Gemeinde ein ... =)
      Ich habe mir die Schaltung auch mal kurz angeschaut. Der Bub scheint nicht viel vom Lesen der Applikationsbeschreibung und Handbücher zu halten. Z.B. Den Reset-Pin des PIC eiskalt gleich an VCC gehängt. Wenigstens einen 4.7K hätte er ihm spendieren können, wenn es schon nicht die vorschriftsmäßige Reset-Belegung sein darf.
      Die Optokoppler werden eine Verschleifung der Gate-Spannung bringen (ohne jetzt kontrolliert zu haben, ob es sich bei den OpCoups um HighSpeed-Versionen handelt). Wenn die 100K Gate-Pull-Down-Widerstände (z.B. RP1a) etwas verringert werden würden, könnte es schneller gehen. Aber dann muss die Ladepumpe ein bißchen Dampf liefern. In die Gate-Zuführung des Low-Zweigs auch noch zusätzlich 4.7K zu bringen, halte ich für übertrieben. Irgendwas zwischen 270 und 560Ohm hätte ich verstanden, um den Strom des Optokopplers zu begrenzen (50mA max bei 12V bzw. 24V). Naja... vielleicht muss ich es auch nicht verstehen. Jedenfalls würde ich in unserer Gemeinde davon abraten, diese Schaltung nachzubauen.
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Bis ich bei diesem Thema mitreden kann wird wohl noch soviel Wasser den Rhein runterfließen daß man damit mehrere Ozeane auffüllen könnte. Bis dahin werde ich wohl weiter auf handelsübliche Regler zurückgreifen. Sollte allerdings mal jemand einen Tester suchen, so erkläre ich mich gerne bereit dafür ein "Versuchskaninchen"zu bauen.

      Dirk
      haben ist besser als brauchen
    • Sollte allerdings mal jemand einen Tester suchen, so erkläre ich mich gerne bereit dafür ein "Versuchskaninchen"zu bauen.

      Gerne ! Ob ich jetzt noch eine Version bis MMMV3 fertig kriege, ist mehr als fraglich. Aber im Oktober würde ich gerne darauf zurückkommen. Wäre mal interessant, den Regler an einem Rapi mit kräftigen Motoren zu testen. Bis mein Feather-Schrott fertig wird, haben wir MMMV9 (oder noch später)...
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Genau dem ist so! ich habe ja ein paar Mini EV Warrior (größe Speed 900) die ich unbedingt in ein besonders "krankes" featherweight Projekt stecken will. Da kann man mit den Conrad Reglern oder ähnlichen Derivaten wohl nicht mehr so viel anfangen. (Bin mir auch nicht sicher ob die Helen bec 60 VR da besser sind, schein aber fast so zu sein, kosten 79 Euronen)

      hlne.de/index-Modellbau.html

      Gruß Dirk
      ....ein Event muss her