Posts by Gizmo

    Das ist schon richtig, jedoch definiert sich die Haltbarkeit eines solchen Setups für mich an den Schutzmechanismen und deren Wirksamkeit.
    Für so einen eher extremen Einsatz wie hier wäre dafür das Prädikat "gut" angebracht...

    Jetzt ist es nunmal so dass gerade die Schutzmechanismen knifflig und oft noch deutlich teurer als vernünftige LowESR Elkos sind. Dazu kommt noch der erhöhte Platzbedarf auf der Platine.
    Also Konsequenz wird so etwas meist stümperhaft umgesetzt ODER noch schlimmer oft auch gar nicht erst vorgesehen bzw. eingebaut.

    Nunja, eine klassische IBF Konstruktion die vermutlich wie immer gut funktionieren wird... :)

    Bei den Heavies ist das aber halt eine andere Hausnummer als sonst so üblich, daher:

    • Rubycon ZL Serie hat sich als LowESR Elko bisher immer recht brauchbar geschlagen.
    • Irgendwas um die 100A also, in dem Betriebsfall hier vielleicht aber etwas mehr als nur ein paar Sekunden. Wie verhinderst du das Überhitzen der Lötstellen zwischen FET und Platine und damit das ungewollte auslöten?
    • Da ich keine Schaltpläne finden konnte, frage ich mich was für Bauteile verwendet wurden und wie die Parallelschaltung funktioniert falls es die gleiche Technik wie bei 4_5 ist?
    • Beim Testen von sowas hat sich doch eigentlich ein Auto oder Kraftrad Akku bewährt, die sind da etwas robuster.
    • An und für sich ein gute Idee mit den M4 Schrauben, nur ob das im Hochstromzweig so praktikabel ist? Bei gedachten 1mOhm sind das noch 10W Verlustleistung, bei 10mOhm sogar schon 100W.
    • Von der Mechanik her könnte es ggfs. zu Brüchen kommen bei den Heavy üblichen heftigen Erschütterungen. Besonders der obere Teil der Sandwich Bauweise könnte hier anfällig sein.
    • Ich würde Luftleitbleche aus Blech, Pappe oder Plastik vorsehen, da ich mir nicht sicher bin ob der 60er Lüfter bei Vollast noch genug Luft furch die Kühler bläst.

    Floppotron: The Final Countdown

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Gibt noch ein paar mehr und auch andere Computer Teile Orchester...

    Wie genau meinst Du das?
    Für alle Leistungsklassen ein "einheitliches Prinzip"? Oder speziell jetzt nur für diesen Fahrtregler in der Beetleweight-Klasse?

    Prinzipiell könnte das schwierig werden. Sobald irgendwas geändert werden muss, könnte sich der Platzbedarf ändern.

    Ja, für alle Klassen ein Prinzip, sowie wie bei z.B. Arduino oder Raspberry Pi. Es könnte "schwierig" werden, aber aufgrund der Erfahrungen du du bisher sammeln konntest, lässt sich daraus nicht das Gröbste bereits ableiten?
    Die Idee ist halt dass du nicht jedesmal immer wieder die gleichen Sachen wie CPU und PPM Eingänge auf die unterschiedlichen Regler designen und layouten musst, sondern das nur einmal machst, quasi modular und standardisiert.

    Ok, mit P-FETs entgeht man natürlich den Schmerzen. Das und das Weglassen der Strombegrenzung verringert die Komplexität und die Kosten, ist aber mehr Aufwand auf der Software Seite.
    Wenn du P-FETs verbaust, geht dann nicht eine klassische Low Side Treiber Einheit (z.B. TC4468) auch für die High Side? Damit hättest du einen weiteren Freiheitsgrad für die Ansteuerung der Brücke.

    Das mit den Schraubklemmen ist schon aufgefallen und sicherlich schön aufgeräumt im Bot, kostet halt aber Platinenfläche. Das ist ein klassischer Trade-Off... :)

    Ich hab die Modulbauweise gestern noch mit meinen alten Entwürfen verglichen:

    • CPU/Logik auf Baseboard: Mikrocontroller, Logik, Spannungsversorgung für Treiber und Logik, Kommunikation, Eingänge, Low Power Schaltkanäle
    • Power/High Current auf Modul: Absicherung, FETs, Treiber, Aufbereitung Analogmessungen, High Power Schaltkanäle

    IBF, denkst du man könnte das Format und Belegung standardisieren...? ;)

    Ok, jetzt verstehe ich. Gut finde ich mehr Funktionen zentralisiert und der modulare Ansatz. Selbiger wäre mir aber noch zu wenig ausgeprägt und das hätte ich anders gemacht. Bei meinen letzten Designs (ganze anderes Hobby/Thema als RW) war meine Idee mit der ich gut und günstiger gefahren bin: Das Arduino Konzept kopieren. Dinge die man immer benötigt kommen zusammen auf eine Platine, bei mir wäre das das CPU Modul. Dinge für die Anwendungsfälle sind entweder ein Aufsteckmodul für das CPU Modul ODER das CPU Modul zum aufstecken auf das Baseboard.

    Jetzt die üblichen Kernfragen die kommen müssen wenn man sowas diskret baut... :)

    • Das Design ist diskret. Wie ist die Brücke aufgebaut? 2x P und 2x N oder 4x N?
    • Wenn 4x N wie werden die Gates befeuert? Das wäre dann ja wieder die Ladungspumpe für die 15V Überhöhung auf Vcc um die oberen N Fets zu steuern. Da war doch das Problem mit der einbrechenden Versorgungsspannung.
    • Wie hast du die Strombegrenzung gemacht?

    Eine schicke Konstruktion, aber IBF ich hätte da eine Anmerkung:

    Du hast hier noch weniger Platz als bei deinen großen Reglern Fahrtregler V4.x, baust aber diskret mit mehr Bauteilen. Warum bist du also von dem sehr erfolgreichen Konzept der Smart Half Bridge Familie (BTS7960) abgewichen? Gibts die nicht für kleinere Ströme im D2PACK?

    Ich meinte natürlich keine 3W Luxeon LED, sondern ne High Efficiency LED mit maximaler Helligkeitbei bei bereits 3 mA...

    Ok, was isses eigentlich, X oder + Konfiguration? Bei + würd ich die "Front" mit ner Neon Farbe lackieren...

    Quote

    Hört auf einen Dinosaurier und macht die Schaltung bzw. das Softwaredesign "wasserdicht". Sonst geht's euch wie vielen Fahrtregler-Entwicklern hier im Forum... => nie mehr wieder etwas gehört von den Projekten. Augenzwinkern

    Quote

    Lies einfach mal die "uralt-Beiträge" von den Roboteers, die sich leider hier im Forum nicht mehr sehen lassen. X-Anläufe mit den Fahrtreglern gemacht, aber leider so "genial" ausgedacht, dass der erste Fehlschlag schon zum Frust und Abbruch geführt hat.

    => Ich will hier niemanden angreifen! Aber anders als in der Politik kann man bei uns ja aus der Vergangenheit lernen. Augenzwinkern


    Boah IBF... War das eine Herausforderung...? :D

    Anonsten muss es fpr die SoftwarePWM natürlich NICHT so komplex wie in meinem Link sein. Es geht glaub ich auch noch einfacher als das was Alex da kurz runterprogrammiert hat, aber das hat so schon Hand und Fuß...

    Ich persönlich bin mit beiden Abschnitten von Alex einer Meinung. So gehe ich grundsätzlich vor wenn das gesamte Konstrukt das zulässt, allerdings bewege ich mich nur noch auf AVR und AVR32, evtl. mal noch auf Cortex-M. Spätestens wenn Echtzeitbetriebssysteme (oder auch schon einfache Scheduler) dazu kommen wird im Idle Task eigentlich immer die CPU schlafen gelegt. Der OS Tick wird über Interrupt des Timers generiert, der dann auch immer die CPU weckt...

    Ich persönlich würde einen AVR mit mehr PWM in Hardware nehmen. Bei dem Projekt geht aber auch die Software PWM Variante. In dem Fall muss man nicht immer das Rad neu erfinden und ich würde deswegen folgendes mal genauer lesen:
    http://www.mikrocontroller.net/articles/Soft-PWM

    Für welche Art...?

    2 N Channel in der High Side und 2 N Channel in der Low Side: AVR => TDA340 => 4 N-FETs

    2 P Channel in der High Side und 2 N Channel in der Low Side: AVR => Quad Low Side Driver (gibt ne Menge davon) => 2 N-FETs und 2 P-FETs

    Jede andere Kombi: AVR => Transistor Array => 2 N-FETs und 2 P-FETs

    Für die kleinen FETs eines ANT Reglers muss der Treiber nicht so fett sein. Eine Transistorstufe reicht schon, muss noch nicht mal Push-Pull sein. Ein paar Mikrocopter fliegen mit nem AVR der direkt über die Ports die 12A FETs befeuert ohne irgendene Art Treiber dazwischen...

    Mit ein wenig Logik ist einiges zu machen für ne 4Q Ansteuerung, es geht aber auch ganz ohne wenn man mutig ist. Software PWM mit 8 Channels geht fast mit jedem AVR der genügend Pins hat...

    Lassen sich die XBees seriell ansprechen, also über den UART? Das wäre ein Vorteil. Die HopeRFs sind low level direkt mit SPI anzusprechen und das kann echt nervig und fehleranfällig sein. Ich hab manchmal echt gezweifelt ob der Weg der Richtige ist; bis heute bin ich nicht 100% zufrieden. Sicher, beim HopeRF hab ich volle Kontrolle über alles, aber dementsprechend muss ich mich auch um Dinge kümmern von denen ich Ahnung haben sollte und die ich mir dementsprechend aneignen muss. Kurzum: Mit den HopeRF was zuverlässig zum Funken zu bekommen kostet echt Nerven. Ich bin dann irgendwann in die üblichen Quellen von mikrocontroller.net und das-labor.org abgedriftet. Das funktioniert, aber wie es implementiert ist macht mich persönlich nicht glücklich...

    Achja, eventuell auch interessant, hier noch ein Link zum Wi232:
    http://www.radiotronix.com/products/proddb.asp?ProdID=198

    Ich arbeite mit den RFM12B von Pollin auf 433 MHz und 868 MHz. Die gibts mittlerweile auch für 2,4 GHz aber durch WLAN, Blauzahn und ZigBee uninteressant wegen Einkopplung. Für die 433 MHz gilt dass jeder billige China Brenner aus Wetterstationen und dergleichen auf den Äther drückt.

    IBF hat zwar wegen der Oberwelle nicht unrecht, trotzdem würde ich am ehesten noch zu 868 MHz tendieren. Die HopeRF Dinger funktionieren, sind aber bei der Kombieinheit (Transceiver) am Empfägner nicht ganz so empfindlich, weswegen da die Reichweite leidet. Die XBees sollen da besser sein. Die sind aber auch deutlich teurer. Für meine Zwecke (kein Roboteers Einsatz) reichen die RFM12B weil ich mit XTEA verschlüssle, mit CRC16 absichere, kurze Telegramme, niedrige Datenrate und Quittierung (ACKs) verwende. Des Weiteren ist es bei mir nicht so tragisch wenn mal ein Messwert eines Sensors verschwindet.

    Ich würde dir vermutlich zum 868 MHz SRD Band mit hochwertigen Modulen, also eher XBees oder besser raten. Wenn du es dir leisten kannst, dann wär die Krönung natürlich ein DSSS oder FHSS (Spektrum FBs) Modul ideal auf das du dein eigenes Protokoll dübelst! :]

    Quote

    Ich empfinde drei zu speichernde Konstanten und die beschriebenen 2 Multiplikationen und Subtraktionen nicht als hohen Aufwand Augenzwinkern

    Mit der entsprechenden Vorarbeit natürlich nicht... :]

    Quote

    @Marco: wenn Du jetzt Urlaub hast, dann wird an dem Ant weitergebaut? Augenzwinkern Augenzwinkern Augenzwinkern

    Nee, am Moped... :]

    Quote

    Schön von Dir Marco, dass Du technisch wieder mitpostest. Deine Beiträge hatte ich schon schwer vermisst.

    Ich hab Urlaub... Und bin über meine alten Regler-Jugendsünden gestolpert... :rolleyes:

    Quote

    Floating-Point-Operationen scheiden aus.

    Auf jeden Fall immer dann wenn es zeitkritisch wird. Davor und danach geht aber. Was Alex da so erklärt kann man machen, es gibt aber auch Fixed Point Libs für 8-Bitter ohne FPU die man verwenden kann. Das ist zwar deutlich schneller aber niemals so schnell wie einfache billige Shifts. Ich kann daher nur empfehlen sowas VOR oder NACH einer langen oder zeitkritischen Operation durchzuführen...

    Quote

    Soweit verstanden, wie ich das vorhabe?

    Ja, aber mir ist bei den Lösungen von euch beiden noch nicht klar warum der Aufwand so hoch sein muss? Reicht denn eine 2 dimensionale Tabelle für den Kreuzmischer nicht aus? Apropos EEPROM Mangel, zur Not ein externes EEPROM per I2C oder SPI anklemmen...

    Quote

    Das ist eine vorgefertigte Routine aus dem mitgelieferten AVR-Baukasten?

    Vom avr-gcc, also vom Compiler...