Wilssen PCB/hardware, brainstorming for first alpha

Low cost, compatibility and (cost-, energy-) efficiency are key aspects.
In my opinion, everything should be in SMD. It will make the PCB more space efficient, ie. smaller, and cheaper to produce (less holes) and populate (even at DIY level)
The only downside IMHO is, that a fried chip is harder to replace compared to an MCU in a DIL socket. However, it’s not impossible to fix a fried chip, nor is it likely, that the MCU will be fried, especially when using the Arduino bootloader.

  • MCU: Atmel Atmega 168 running at 8Mhz with an external crystal due to the system voltage of 3.3V. (NRF24L01, sdcards… work with 3.3V)
    I would go for the 328 (more space) or even a newer one from the U series with hardware-USB, but those are significantly more expensive. We don’t need USB at the controller.

  • microSD card slot (optional to populate)

  • header for the wireless module with the Nordic NRF24L01

  • ISP-header

  • multiple headers for SPI output?

  • direct battery connection to ADC through a stabilized voltage divider to measure the logic power supply battery voltage.

  • I am still searching for a 4xAA charging IC. I found some expensive ones at National, but those seem too sophisticated and… expensive! :unamused:

  • How should we multiplex the phase voltage and current measurements? Analog multiplexing IC after the Amplifier stage or before?

  • Should there be OpAmps onboard with configurable gain through jumpers or unpopulated pads or should those also be outsourced to the e.g. current sensor boards.

  • Should we incorporate the footprint of an Arduino nano or something like that and bring out all the pins in the same manner?

I started to layout an alpha version of the schematics. I think I will include the MAX1555 or MAX1551 LiPo 1c charger onboard, it doesn’t take up much space. It’s optional to populate then. One can use a single LiPo cell as a logic board power supply then and charge it with an USB connection.
20121124LXM2357__LX-M.de__-002.jpg

(work in progress)

PS: Someone may please install an image resize and thumbnail plugin for phpBB. :unamused:
201211270426_Wilssen_core_schematic4.png

Hi Alex.

Cool!

Handelt es sich bei „Bat_Sens“ und U2 um das was Du mit „direct battery connection to ADC through a stabilized voltage divider to measure the logic power supply battery voltage.“ meintest ?

Programmiert wird das ganze vermutlich über JP4/ISP_Header zum flashen des Bootloaders und über JP9 zum hochladen der Programme in den Bootloader, mittels FTDI-Breakout-Shield, ja ?

Wäre es vielleicht möglich JP4 so auszulegen, das man den wahlweise auch mit nem 10poligen Stecker bestücken kann ?

Und beim USB-Connector der Pin „VBUS“, ist das ein Typo und sollte eigentlich „VUSB“ heissen oder heisst der tatsächlich so ?

Achja, und bezügl. „multiple headers for SPI output?“, das wär vielleicht ganz gut wegen SD-Card Anschluss.

Gruss, Oliver

Hey Oli,
Bat_Sens ist die Spannungsüberwachung, ja, aber U2 ist die Logikspannungsversorgung, ein 3.3V LDO Spannungsregler. Hierzu noch auf der TODO-List: Einen 3.3V LDO mit niedrigem idle current und low drop <0.3V suchen, der bezahlbar ist.

ISP-Header ist 6polig, weil ich das effizienter finde: Man braucht nur 6 pole und bei 10 sind 4 überflüssig. Das ist schon eine Menge Platz der zusätzlich draufgehen würde. zusätzlich zum 6pol einen 10pol geht nur mit airwires oder vias (also auch doof).

VBUS ist correct, USB = Universal Serial BUS :slight_smile:

SPI header kommen noch dabei, muss mir aber mal überlegen, wie und welche Pins ich als CSN (chip select not) rausführe, damit man die clients ansprechen kann.

Shure

Ok, is auch nicht so wichtig. Hab grad im Blog gelesen dass Du die Vias auf ein Minimum beschränken willst.

SPI header kommen noch dabei, muss mir aber mal überlegen, wie und welche Pins ich als CSN (chip select not) rausführe, damit man die clients ansprechen kann.

Welche Clients benötigen denn noch SPI-Kommunikation ? OK, der NRF24L01 könnt ich mir vorstellen. Sonst noch welche ?

Bzw. was wird denn jetzt noch alles an Peripherie benötigt ?

Soweit ich das jetzt überblicke steht da noch an

  • ein 2.4Ghz Modul
  • SD-Card
  • Messung des Stroms vom Generator
  • Messung der Spannung vom Generator (mehrere Phasen ?)
  • RGB-LED Modul
  • Ladekontrolle für Batterie ?
  • Messung dessen was vor dem Generator ankommt ? (ich sags mal mit meinen laienhaften Worten)

Bin schon gespannt darauf, leider gehts da in einen Bereich rein, wo ich absolut kein Plan von hab., von wegen OpAmps on board oder outgesourced, gemultiplexte Phasenspannung, usw. Wieso müssen die denn analog gemultiplexed werden, ich mein, wenn die Spannung und der Strom einmal gemessen sind und der Wert digital vorliegt dann hat man doch die Info (sorry, wenn ich so naiv frage, aber hab wie gesagt keine Ahnung v.d. Materie). Da Du das Core-Modul ja möglichst schmal ausgelegt hats machts glaub ich Sinn, alles weitere auf Peripherie-Module auszulagern, weil dann Wilssen-Core ev. auch noch für andere Projekte eingesetzt werden kann.

Bin gespannt wie die Strommessung aussehen wird. Willst Du dafür sowas wie einen ACS712 einsetzen (ist das überhaupt Gleichstrom bzw. brauchen wir da noch irgendwie nen Gleichrichter ? :wink: ) ?

Ich sprudel hier einfach mal unqualifiziert so vor mich hin :wink: Versuche mir nur eine Vorstellung von der Sache zu machen und hoffe das das nicht allzu schräg klingt. Ich versuche mir das bildhaft als Schema vorzustellen, vielleicht sollten wir das irgendwann mal skizzieren.

Gruss, Oliver

Der acs712 misst Gleichstrom wie Wechselstro , und zwar potentialunabhängig :slight_smile: ist nur leider teuer bei vielen Phasen…

Genau, wilssen core ist schlank und hat links und rechts die Peripherie fest auf dem pcb, aber die Peripherie ist optional und der core ohne jene natürlich auch für andere Projekte nutzbar.

Multiplexes muss man nur, wenn nicht genug adc Kanäle zur Verfügung stehen. Zb 3 Phasen Strom, 3phasen Spannung, Spannung nach Gleichrichter, Batteriespannung… Die das sind ja schon 8 Kanäle.

Kannst gerne fragen so viel du willst :wink:

Integrated three optional constant current sources / hp LED drivers for the RGB LED.
Leon Rische will be writing the code for the LED functions.

PS: Git updates are posted to IRC at every commit (channel #OSEG on freenode)

Great! Alex, can you recommend online/offline clients for IRC in the Wiki http://wiki.opensourceecology.de/wiki/IRC?
Thanks!

Update zum PCB:

  • ein 2.4Ghz Modul
  • SD-Card
  • Messung des Stroms vom Generator
  • Messung der Spannung vom Generator (mehrere Phasen ?)
  • RGB-LED Modul
  • Ladekontrolle für Batterie ?
  • Messung dessen was vor dem Generator ankommt ? (ich sags mal mit meinen laienhaften Worten)

unvollständige Featurelist:

  • ICSP via SPI
  • NRF24 via SPI
  • sdcard via SPI
  • Strom und Spannung vom Generator analog an den ADC
  • RGB-LED driver analog an drei PWM ausgängen oder z.B. via WS2801 (two-wire digital, SPI). Momentan ist das analog an drei portpins.
  • Spannungüberwachung nach Gleichrichter
  • Spannungüberwachung nach Spannungswandler (DC-DC Stepdown)
  • Referenzspannungsquelle für den ADC
  • Spannungsüberwachtung der Batterie für die Logikversorgung
  • RGB LED driver fertig,
  • Referenzspannungsquelle fertig,
  • NRF24 hat einen eigenen header bekommen (ziemliches Labyrinth)
  • Spannungsüberwachtung der Batterie für die Logikversorgung fertig,
  • SDcard ist auf dem Board, aber muss ich noch routen. Wird kniffelig und gibt wohl ein paar Brücken/Vias.
  • ICSP habe ich ausgelagert grad auf ein Peripherieboard, weil ich unten nicht mehr genug Platz hatte. Vielleicht passt das später noch oben hin. Ohne Vias oder Brücken aber nicht machbar. Schade.
  • ICSP ist jetzt grad 10polig, weil an der Stelle eh genug Platz war. 10pol hat aber redundante Pins, das ist überflüssig…
  • ICSP header bekommt VCC nicht konnektiert, weil das Board und die Peripherie auf 3.3V läuft, am ICSP aber 5V anliegen. Vielleicht mit drei Dioden in Serie später, mal schauen.

Offen: Alle Signalaufbereitungen für Spannung und Strom Inputs. (Ausser Batterie der Logikversorgung)

Hi Alex,

cool :wink:

Ist glaubich nicht so tragisch wenn der extern ist, weil man den ja eigentlich eh nur einmal am Anfang braucht um den Bootloader draufzubrennen. Und wenn man mehrere Wilssens herstellen will wärs sogar rationeller/schlanker wenn man dafür nur ein Peripherieboard braucht (natürlich vorausgesetzt da ist nichts anderes mit drauf) insofern wärs also ein Feature :wink:.

  • ICSP ist jetzt grad 10polig, weil an der Stelle eh genug Platz war. 10pol hat aber redundante Pins, das ist überflüssig…

Ich hatte das anfangs mal vorgeschlagen, weil man ein 10-poliges Kabel oft regulär da und zur Hand hat, z.B. vom PC her, ein 6-poliges aber nicht unbedingt.
Siehe auch
http://www.mikrocontroller.net/articles/AVR_In_System_Programmer#ISP

  • ICSP header bekommt VCC nicht konnektiert, weil das Board und die Peripherie auf 3.3V läuft, am ICSP aber 5V anliegen. Vielleicht mit drei Dioden in Serie später, mal schauen.

Klingt interessant.

Gruss, Oliver

Überlegung zur Wilssen Hardware


Der Wilssen ist ja gerade „heftig“ in der Diskussion. Wenn ich allerdings Arduino und FFT im gleichen Atemzug lese, bekomme ich das softwaretechnische Grausen! :slight_smile:

Lasst uns doch einmal zusammenfassen, was der Controller alles Können muss:

  • Strom- und Spannungsmessung
  • Dreiphasenüberwachung
  • Kommunikation mit Hostcomputer und anderen Nodes
  • Akkuladungen durchführen
  • Sich bis zu einem gewissen Grad autark mit Energie zu versorgen
  • Als Frequenzumrichter / Wechselrichter fungieren
  • Als Stromsenke bei Überspannung dienen
  • Phasenschiebung zur Blindlastkompensation vornehmen
  • Logging von Spannungen, Strömen, Konfigurationszuständen, etc
  • Galvanische Trennung von dem Powerteil

Das sind alles Dinge, die man mit einer einzelnen Platine nicht wirklich bewerkstelligt bekommt. Einen Arduino als Prozessor zu nutzen finde ich ein wenig fehl am Platze. Das hat ijon allerdings schon angemerkt (Siehe hier: https://discourse.test.opensourceecology.de/t/krtik-von-ijon-an-dem-controller/133/1 ), wenn auch in etwas drastischeren Tönen.

Mein Vorschlag wäre daher, ein modulares System zu entwickeln, um Interoperabilität mit anderen Devices zu erreichen. Das gesamte Konzept lässt sich dann zweimal aufbauen: Einmal für größere Maschinen in einem 19 Zoll, 4 Höheneinheiten Rackträger und einmal in PC104 Größe mit kleinen Steckern oder Aufsteckplatinen um die ganze Sache in kleineren Dingen zu verbauen.

Die Hauptplatine erhält einen relativ großen Prozessor und relativ wenig Peripherie. Um die Hauptplatine zu betreiben muss diese dann auf ein Powersupply gesteckt werden. Damit ist sichergestellt, das jede Platine für sich gekapselt entwickelt werden kann und keine Überschneidungen mit anderen Projekten entstehen können. Auch kann man so sicherstellen, das Spannungen genau da hin kommen, wo sie hingehören: Man nutzt einfach ein Steckersystem, welches 50 oder mehr Pins hat. Damit ist dann aufgeschlossen, dass – gleiches Auflagemaß vorausgesetzt – ein Modul 12V statt 5V bekommt und somit durchbrennt.

Das ganze macht es auch leichter, einen gemeinsamen Formfaktor für solche Dinge zu finden. Ich würde hier 10*10 Zentimeter vorschlagen. Das ist ein gutes Maß, um eine Menge an Bauteilen unterzubringen und eine relativ große Kühlfläche für Bauteile, die heiß werden, auf die Platine zu bringen. Von der Höhe halte ich 3,5cm von der Platinenoberfläche zur nächsten ausreichend. Damit könnte man – falls es denn jemals Erweiterungsbedarf geben sollte – kleine Module, ähnlich den DDR2 RAM Riegeln, in die Platinen zu stecken und ihnen somit extra Features, wie einen leistungsfähigen Coprozessor zur Verfügung zu stellen.

An sich sollte jedes Modul mit einem ISP / JTAG Header ausgerüstet werden, mit dem die Software entwickelt werden kann oder aber bei Problemen mit einem Bootloader das Board einzeln geflasht werden.

Das würde auf jedem Board mit µC einen kleinen „Coprozessor“ nötig machen, der den eigentlichen Controller im RESET Zustand hält und dafür sorgt, dass das Programm auch auf den Chip kommt und nicht irgendwo im Nirvana landet. Oft sind die Signalleitungen nämlich durch andere Platinen gegen Masse gelegt und können somit den Download auf den Flash stören. Das kostet pro Platine etwa ein bis zwei Euro mehr, benötigt ein wenig Zeit, um programmiert zu werden, doch damit hätte man dann die Möglichkeit geschaffen, dass sich jede Platine durchs Anhängen an das „Mainboard“ oder eine CPU Karte sich selbst und ihre Softwareversion preisgibt. Zusätzlich dazu kann man im EEPROM der kleinen Management CPU auch Dinge verstecken, wie zum Beispiel ein kleines Loggingsystem oder ob die Software auf dem Hauptprozessor des Boards noch intakt ist.

Wie man allerdings am Arduino sieht, benötigt man oft nicht mehrere Boards mit je einer CPU in einem Stack. Daher kann das auch gerne ein Hirngespinst bleiben. Was auf jeden Fall Sinn macht, ist eine Trennung der Komponenten.

Eigentlich hatte ich einen längeren Post geplant, allerdings läuft mir gerade die Zeit davon. Daher von mir nur mal so viel und nicht mehr :slight_smile:

einball :slight_smile:

Hey Jan,

So viele Anforderungen haben wir ja gar nicht. Ich denke eher so:

  • Strom- und Spannungsmessung
  • Kommunikation mit Hostcomputer, optional mit anderen Nodes
  • Akkuladungen durchführen (Für die Logikversorgung macht das ein eigener Laderegler, nicht der AVR)
  • Sich bis zu einem gewissen Grad autark mit Energie zu versorgen (Akku)
  • Als Stromsenke bei Überspannung dienen (Ich weiss noch nicht ob die Crowbar-protection rein analog wird… sollte aber kein Problem sein für den AVR)
  • Logging von Spannungen, Strömen, Konfigurationszuständen, etc

Btw, TiVA ist einphasig.
Galvanische Trennung vom Generator gibt’s nicht, aber Wilssen ist nicht niederohmig damit gekoppelt. Eine von den Anforderungen an TiVA ist ja SELV bzw. „safe to the touch“.
Wofür möchtest du die Frequenzumrichtung und aktive PFC? Aber das würde dann eh nicht der AVR machen.

Hi shure,

Naja, TiVa ist ja nur der erste Schritt in Richtung des großen Bildes. Wer nachhaltig sein will, der muss sich auch für die Zukunft wappnen. TiVa wird nicht die erste und nicht die letzte Windturbine sein. Wenn man dann entscheidet, das ganze ein wenig größer zu bauen, zb mit einer Asynchronmaschine, die 2-3 kW an Leistung bringt, dann wird der AVR schon ein wenig knapp bei der Berechnung und Korrektur der ganzen Phasengeschichte.

Ich würde keine Crowbar reinbauen, sondern bei der erstmal kleinen Leistung einen MOSFET, der die überschüssige Leistung dann über die Terminals verheizt. Das ist eine durch OpAmps leicht einstellbare Geschichte und vor allem ziemlich zuverlässig.

Ja da stimme ich dir zu, eine größere Anlage mit mehr Leistung ist komplizierter. Der Controller wird aber in einem solchen System nie den Wechselrichter spielen, dafür ist dann eben der Wechselrichter (an einem geschützten Ort) zuständig.

TiVA hat nicht das Ziel netzsynchron zu sein, Drehstrom oder Lichtstrom zu erzeugen, das ist eine „Forschungsplattform“. Ich habe da auch zu wenig Erfahrung, um mit solchen Leistungen zu experimentieren, finde es ausserdem gefährlich als DIY-Bausatz für den Laien.
Ich würde meinen selbstgebauten Windgenerator nicht mit einem Wechselrichter (teuer und gefährlich im Selbstbau) ausstatten, sondern ein Gleichstromnetz versorgen, was man selber warten kann und/oder Akkus laden, die dann bei Bedarf auch einen ‚einfachen‘ Wechselrichter speisen können.

Eine Anlage ohne Abnahme und Genehmigung ist laut dem Wikieintrag ja nur bis 2m² möglich (hätte da gerne noch eine Quelle zu wikipedia zeigefinger) - das sind weniger als 1kW.

bei der erstmal kleinen Leistung einen MOSFET, der die überschüssige Leistung dann über die Terminals verheizt. Das ist eine durch OpAmps leicht einstellbare Geschichte und vor allem ziemlich zuverlässig.

Gute Idee, daran habe ich auch gedacht. MOSFET mit einer ohmschen Last… Wenn das bei ganz viel Wind aber zu viel Leistung ist überlastet man eventuell den Generator. Der Fall muss also auch berücksichtigt sein. Dann sollte man vielleicht kurzschließen und den Rotor so bremsen und ganz langsam halten, da er dann nicht die entsprechende Reynoldszahl erreicht. Eine bessere Idee hab’ ich noch nicht, eine mechanische Bremse gefällt mir jedenfalls bei TiVA gar nicht.

Den MOSFET ohne zusätzliche ohmsche Last. Der FET stellt ja so oder schon eine Last dar, man muss ihn ja nicht ganz auffahren. Wieso sollte man den Generator überlasten? Wenn du ihn kurzschließt, dann fließt der Kurzschlussstrom und er wird erst recht überlastet. Nein: Der MOSFET soll lediglich aktiv Spannungsspitzen durch Böen abdämpfen und bei einer zu hohen Spannung an den Klemmen die überschüssige Leistung verbraten, damit nichts zu Bruch geht.

Eine mechanische Bremse oder zumindest eine mechanische Verankerung der Rotoren macht schon Sinn, da auch - abhängig vom Aufstellungsort - hin und wieder mal ein größerer Wind wehen kann. Ich weiß nicht, wo genau die maximale Windlast liegt, aber gesund ist es sicher nicht für den Rotor.

Aufbauen darfst du alles, was unterhalb der 10m Grenze liegt und 6m² Windangriffsfläche nicht überschreitet. Ab der Höhe/Fläche benötigst du eine Baugenehmigung. Das zieht allerdings auch eine Überprüfung des TÜV’s hinter sich her und was nicht alles zu dem Rattenschwanz gehört. Für BaWü siehe hier! Alle anderen Vorschriften müssen natürlich beachtet werden. Meiner Meinung nach bürokratischer Bullshit. Wo kein Kläger …

Wenn TiVA nicht netzsynchron werden soll, reicht der Arduino völlig. Die Frage bleibt dennoch, ob der Arduino eine FFT durchführen kann, oder ob man dafür lieber den Rechner nutzt.

Was hälst du von der Idee, das ganze für spätere Vorhaben mit den 10x10 cm modular mit je 2 oder 4 Steckern pro Platine auszulegen?

Gefährlich sind theoretisch auch die Ziegelpresse und am Holzvergaser kann man sich auch verbrennen. Hätte das daher nicht per se als DIY Methode ausgeschlossen. Wer zu dumm ist, etwas zu bauen und sich der Gefahren dessen nicht bewusst ist, ist selber schuld. Ich meine, es wird auch niemand in einen laufenden Häcksler reinlangen wollen :slight_smile:

Netzsynchronität ist bis jetzt noch garnicht in Planung gewesen? Immerhin funktionieren so ziemlich alle Geräte mit 230V/50Hz. Einen Wechselrichter zu bauen ist keine Kunst (Nur lange Simulationsarbeit). Interessant wird es erst bei einigen kW an Leistung, die er bringen muss. Hier hatte ich dann auch die PFC angedacht. Aber gut, ist kein Thema bei Wilssen → abgehakt.

Mit einem DC Netz hat man leider das Problem des Kabelwiderstandes. Wenig Spannung, viel Strom, viel Leistung übers Kabel verheizt. Wenn ich mir den Wikieintag zu DiVER angucke, da scheint mir eine DC/DC Wandlung auf 48V (PoE Standard) aus den ?? Volt, die die Windturbine erzeugt, sinnvoll. Je höher die Spannung, desto einfacher wirds nachher. Alles unter 60 Volt- unterliegt hier in Deutschland ja noch der Schutzkleinspannung.

Alles unter 60 Volt- unterliegt hier in Deutschland ja noch der Schutzkleinspannung.

Ja genau da möchte ich hin. Für den Benutzer und für die Legalität :wink:

Was hälst du von der Idee, das ganze für spätere Vorhaben mit den 10x10 cm modular mit je 2 oder 4 Steckern pro Platine auszulegen?

Ja, finde ich gut. Das soll ja modular sein. Schau’ dir doch mal das PCB Layout an. Um Kosten und Platz zu sparen sind das drei Teile und alles recht eng, aber DIY-freundlich fast einseitig und recht große SMD Bauteile. Also unter 10x10cm, aber Stecker bzw Header gerne. Rechts ist noch Platz frei, wo dann ein paar Header für Erweiterungen platziert werden können. Bis jetzt ist jeder einzelne portpin vom MCU auf zwei Headern ausgebracht und zusätzlich noch ICSP und SPI… ICSP wird aber wegrationalisiert für den NRF24 Header denke ich, denn über die portpins hat man schließlich auch ICSP…
Auf den rechten Teil kommt auch noch die Analogelektronik mit den OpAmps. Würde mich auch freuen wenn du die OpAmp-Schaltung weitermachst, bisher steht da noch nichts. Schau dir einfach die Issues an bei github… Für die Strommessung soll es mehrere Optionen geben: Entweder über #1 shunt onboard machen (für kleine Modelle wie TiVA) oder über #2 Hallsensor wie Allegro ACS712 an den ADC (vorher noch durch eine gainstage? Kann man den OpAmp von der Shunt-on-board Version vielleicht einfach dafür verwenden, wenn das gut ausgelegt ist?) oder via #3 Stromwandler (für die ganz großen Ströme…). In RC1 nur via Shuntwiderstand, schön wäre mit ‚klassischem‘ OpAmp anstatt Shuntverstärker-IC, damit man #2 und #3 auch an dem OpAmp nutzen kann. Welche rail-to-rail Typen sind erschwinglich bei 3.3V und niedrigem Stromverbrauch? Alles so Fragen die noch offen stehen. Magst du da dran arbeiten?

Ich habe festgestellt, das du eine neuere Version von Eagle nutzt. Kann ich das dann trotzdem editieren und pushen, ohne das da was verloren geht? Wie dem auch sei: Hier erstmal die Simulationen:

Die OpAmp Schaltung ist ja im Prinzip nichts anderes als ein nichtinvertierender Verstärker … Datenblatt: http://cds.linear.com/docs/en/datasheet/20545fc.pdf

Ja, ich habe hier einen Präzisionsverstärker genommen, weil das eine Messaufgabe ist. Da sollte schon ohne Drift und halbwegs akkurat vestärkt werden. Bei 100k ADC Impedanz braucht der OpAmp etwa 250µA, also nicht der Rede wert.

Mit einem SEPIC Wandler kann man sich die Umschaltung von LiPo auf 3,3V (Hier noch 5V … Alles eine Sache der Widerstandswahl :wink:) sparen - Der regelt 2 bis 12 Volt spielend aus:

Datenblatt zum Wandler: http://cds.linear.com/docs/en/datasheet/1613fs.pdf
Leider nicht so sparsam wie der Chip - Wenigstens regelt er halbwegs effizient :slight_smile:

Der Allegro Chip den du genannt hast, macht eigentlich nichts anderes als eine Hallspannung von 0 bis 5 Volt auszugeben, die direkt proportional zum Strom, der fließt, ist. Wozu bräuchte man da noch eine Gainstage?

Ja das sollte gehen. Ich habe das mit der neusten freien (beta?) Version gemacht, das Board ist klein genug für die Freeware.

Braucht der 5V zum Betrieb? Das wäre schade :frowning: sollte mit 3.3V alles laufen.
Gainstage wäre halt cool wenn man die von der Shuntversion nutzen könnte anstatt das Signal raw, um die Auflösung zu verbessern: Wenn der Hallsensor ±50A kann, dann gibts an dem ADC nur eine Auflösung von 100A / 1024 = ~0.1A, wenn der ADC ideal arbeitet und wirklich 10bit liefert. TiVA liefert vielleicht mal selten 1A… Selbst mit einer ±20A Version (ich glaube davon habe ich ICs) wird das nicht viel besser. Bei 50V Generatorspannung hätte man bei der Auswertung 0W, 5W, 10W,… :unamused: Das ist ja zu grob.

Der LTC1613 hat echt schlechte idle-werte: Quiescent Current 3…4.5mA (soviel braucht der AVR vielleicht) und unter 25mA load nur 50…80% efficiency. Dazu noch teurer mit vielen externen parts… lass uns lieber linear bleiben mit einem LDO, dann kann man auch onboard einfach über USB laden.

Prima! Das wollte ich hören! Dann gucke ich, das ich morgen den OpAmp (siehe Simulation) auf das Board verpflanze. Wie viel Ampere soll er Fullscale messen können? In der Simulation habe ich 0-10A genutzt. Deiner Aussage nach suche ich einen Shunt für 0-2A.


Gainstage wäre halt cool wenn man die von der Shuntversion nutzen könnte anstatt das Signal raw, um die Auflösung zu verbessern: Wenn der Hallsensor ±50A kann, dann gibts an dem ADC nur eine Auflösung von 100A / 1024 = ~0.1A, wenn der ADC ideal arbeitet und wirklich 10bit liefert. TiVA liefert vielleicht mal selten 1A… Selbst mit einer ±20A Version (ich glaube davon habe ich ICs) wird das nicht viel besser. Bei 50V Generatorspannung hätte man bei der Auswertung 0W, 5W, 10W,… > :unamused: > Das ist ja zu grob.

Wenn du den OpAmp zwischen Hallsensor und Shunt umschalten willst, brauchst du ein anderes Widerstandsverhältnis und damit eigentlich schon einen CMOS Schalter. Das wird aufwändig und definitiv nicht zielführend. Mit Jumpern macht das für mich auch irgendwie wenig Sinn. Der Strom fließt nur in eine Richtung (Generator → Last), so das man die oben simulierte Lösung super nutzen kann, um gute Ergebnisse zu erzielen. Der Allegro Chip hätte in beide Richtungen funktioniert (Ohne Strom liefert er 2,5V am Ausgang) und damit hätte man nur einen Bereich von 2,5 bis 5 Volt für den Vollausschlag des Sensors gehabt. Damit reduziert sich die 10 bit Genauigkeit des ADC wieder auf 9bit.

Braucht der 5V zum Betrieb? Das wäre schade > :frowning: > sollte mit 3.3V alles laufen.

So wie ich das aus dem Datenblatt rausgelesen habe, ja.

Der LTC1613 hat echt schlechte idle-werte: Quiescent Current 3…4.5mA (soviel braucht der AVR vielleicht) und unter 25mA load nur 50…80% efficiency. Dazu noch teurer mit vielen externen parts… lass uns lieber linear bleiben mit einem LDO, dann kann man auch onboard einfach über USB laden.

Klar hat er die! Immerhin schaltet er mit 1,4Mhz, damit die Spulen und Kondensatoren klein bleiben können und ist selbst im SOT23 Package untergebracht. Das war mein Hauptaugenmerk als ich mich bei Linear durchgeklickt habe. Wenn wir beim LDO bleiben wollen, dann guck dir mal den TPS73133 an. Bei Farnell 94ct als Einzelstück und hat nur 30mV Dropout. Und täusch dich mal bei den AVRs nicht: Ich hatte schon AtMega32er die bei 16 Mhz ganze 23mA aus der Leitung gelutscht haben. Zum AVR kommt noch eine nicht unerhebliche Menge an SD Kartenstrom dazu,


Schätze ich bin mir immernoch nicht ganz bewusst, wo das ganze hingehen sollte. Ich denke wahrscheinlich zu groß, zu komplex und in industriellen Maßstäben. Bei mir muss alles ziemlich flexibel sein. Ich dachte an eine Versorgung direkt vom Generator mit Umschaltung auf den LiPo on the fly, wenns denn sein muss. Ach, da schwirrt mir noch viel mehr im Kopf rum :slight_smile: