Solarflieger

maccl

User
Hallo Maccl, wenn es der 16MHz ProMini ist (5V 328p), dann rennt dieser Code dadrauf, und der kann auch mit dem Sunrise 11A.
http://www.rc-network.de/forum/showthread.php/505097-Solarflieger?p=4446530&viewfull=1#post4446530
Funzt auch mit der Arduino-IDE

Telemetrie habe ich kmpl. deaktiviert, da mir das zuviel Leistung frisst, funkt ja ständig vom Empfänger zum Sender.

Super, Perfekt!
"Arduino-IDE" iehgitt! ;)

Meinst Du Rechenleistung vom µC?
Oder meinst Du Strom-Verbrauch beim Empfänger?

Telemetrie wär ganz nett, aber im grunde reicht ja ein einfacher Spannungsensor. Oder man steckt noch einen unisens-e oder unilog dazwischen.
Der kann auch Strom in beide Richtungen messen.
Und wäre für evtl. "Rückspeisungen mit Pufferakku" auch intressant.
oder für Alarme... MAX-Spannung, damit man weiß "wo es steigt" ;)

Wär schon irgendwie verlockend die Messwerte direkt vom BLheli-Regler zu bekommen.
Ich hoffe da tut sich SW-seitig noch was.
Aber vermutlich wird das beim KISS-Protokoll bleiben. Und wenn blheli32 nur closed-source bleibt ist das auch schade.

gruß Maccl
 

maccl

User
sorry hätte mal hier weiterlesen sollen
http://www.rc-network.de/forum/showthread.php/505097-Solarflieger?p=4450864&viewfull=1#post4450864

Aber soll das heißen, dass das aktivieren von Telemetrie bei HOTT 0,22 Watt ausmacht (0,31Watt-0,09Watt)?

Oder nur wenn ein Sensor am Empfänger hängt?

Außerdem würde ich gerne wissen ob man bei HOTT die Telemetrie überhaupt abschalten kann.
Soweit ich weis geht das nicht.
Und Telemetrie wird ja eh immer übertragen (zumindest die Empfänger-Daten wie Reichweite und RX-Spannung....)

Gruß Maccl
 
Wo kann man den am besten die Solarzellen beziehen?

Wir haben letzten Winter im Verein einen großen Solarflieger gebaut. Dafür haben wir direkt bei SunPower 150 Zellen bestellt. Diese liefern aber leider nicht an privat und die Zellen des Vereins sind aufgebraucht.

Jetzt möchte ich mir gerne noch einen eigenen Solar Flieger bauen, aber die solar Zellen fehlen mir leider noch.

Wo bestellt ihr?
 
Hallo Maccl
Der Stromverbrauch bei Telemetrie kommt davon das der Empfänger zum Sender wird, und Daten zum Sender sendet. Bei Hott ist es recht einfach die zu deaktievieren, den Empfänger im Modell ganz normal binden, danach nen zweiten Empfänger auf das Modell binden, der zuletzt gebunden wurde, ist immer der Telemetrieempfänger. Aber der Sender macht dann Daueralarm, weil er keinen Empfänger findet. Im Winter will ich ne kleine Wetterstation für das Fotostativ basteln, die sendet dann vom Zweitempfänger zum Sender, dann ist Ruhe, und man hat nen Log vom Wetter. (Spielerei).

Wenn doch Telemetrie: (ja ca. ein 1/4Watt, das ist bei 5Watt unter ner Wolke richtig viel)
Der Arduino kennt berreits die Spannung und die PWM, um den UART Interrupt zu nutzen, damit nichts durch die Telemetrie blockiert, besser auf den 3,3V Arduino ausweichen, 1K2 zwischen RX und TX, T-Port am RX. Dann evtl ,den 328p Code an 8MHz anpassen PWM Timer muss dann doppelt schnell, und beim auslesen vom RC was weg, ist fix gemacht, hätte ich irgendwie auch mal Bock drauf.

Hier wäre gleich der passende Hott Telemetrie Code dafür, sicher nicht perfekt (ich übe noch), aber funzend, das mit dem _delay_ms(5); beim senden sollte man dann aber in den Timer0 mit reinschieben, wenn der auch MPP machen soll.
Können wir gerne auch zusammen zusammenbauen ;)

Code:
#define F_CPU 8000000
#include <util/delay.h>
#include <avr/io.h>
#include <stdio.h>
#include <avr/interrupt.h>
#include <stdlib.h>

volatile uint8_t i,TX,ESC[45]; 

int main(void){
TCCR0A  = 0b00000000; 
TCCR0B  = 0b00000011;       //prescale 1/8, OVF alle 2mS
TIMSK0  = 0b00000001;       //INT OVF aktiv
UCSR1B  = 0b10011000;       //INT RX aktiv
UBRR1L  = 0b00011001;       //19200baud                                         
sei();
    ESC[0] = 0x7C;        //immer 7C
    ESC[1] = 0x8D;        //ändern in: 8A=GPS 8C=ESC 8D=GAM 8E=EAM 89=VARIO 
    ESC[3] = ESC[1]<<4;   //ID wird berrechnet


while(1){   
    ESC[28]++;      //ein bissl Bewegung auf dem Display (Ampere) 
}}


ISR(USART1_RX_vect){
if ( UDR1 == ESC[1] && TX == 0){   
  TX=1; 
  _delay_ms(5);
  ESC[44]=0; 
  TCNT0=1; 
  i=0;
}}

ISR(TIMER0_OVF_vect){ 
if(i>44){i=45; TX = 0;}
else {while (!(UCSR1A & (1<<UDRE1))){}                             
      UDR1 = ESC[i];                                                       
      ESC[44] = ESC[44] + ESC[i]; i++; 
}}
[/QUOTE]



@Daniel
Aktuell bei LinkSolar, ich hätte zwar noch ein 150er org verpacktes Paket, das sind aber die S***teuren werksselektierten E60, wenn es dir was nützt.
 

maccl

User
Hi Holger

also Telemetrie würd ich schon gern einsetzen.
Da packe ich lieber ein paar Zellen mehr auf den Flügel. oder ich flieg nur bei Sonne ;)
Daueralarm am Sender kann ich nicht brauchen.

Den Trick mit den 2 Empfängern werde ich mal testen.
Ebenso würde mich interessieren ob der Stromverbrauch bei allen Empfängern gleich ist.
Ein GR-12 hat soweit ich weis nen andern Prozessor als der GR-12L ....
Mit welchen RX hast du das gemessen?

Sensoren hab ich schon ein paar gebastelt.
zu deinem Code: der ist schön einfach gehalten. Das finde ich gut.
Aber wenn ich das richtig sehe fehlt das End-Byte. Sicher nicht schlimm aber es gab schon Fälle, da haben sich Empfänger "aufgehängt" wenn die Antwort-Bytes merkwürdige Werte enthalten haben oder ein falsches Alarm-Byte gesendet wurde.

Wenn Du die Daten weniger so schnell sendest, geht dann die Stromaufnahme runter?
Man kann auch mittlerweiler bei den Anlagen einstellen ob die Telemetriie langsamer laufen soll (RX-Data).
Evtl. spart man sich damit was wenn der Empfänger dann nicht mehr so schnell sendet.
Werde ich demnächst mal testen.

Beim 328 würd ich die Brownout-Detection (BODLEVEL Fuses) sowieso deaktivieren (falls noch nicht deaktiviert), dann läuft er noch mit 2V.

hier gäbst ein paar Infos zum KISS-Protokoll und ein Beispiel-code (ungetestet)
https://fpv-community.de/threads/kiss-24a-raceedition.71001/post-903590

schreit ja förmlich nach einen Github-Projekt ;)

Gruß Maccl
 
Hi Maccl
Das Endbyte wird ganz hiermit "gebaut" : ESC[44] = ESC[44] + ESC; i++; , und schiest dann als 45stes Byte zum Sender.
Der Sender fragt mit 5Hz ab, auch den Empfänger, denke wenn, dann auch volle Pulle.

Telemetrie kann man ja nun im BLHeli erzwingen, vorher ging es ja nur per DShot über das gesetzte Telemetrie-Bit, so hustet er nun alle 13mS einmal das Kiss Protokoll auf die Serielle :) Stromshunt haben aber leider nur die etwas grösseren BLHeili-Regler.
Einen BLHeli-Hott Übersetzer mit attiny841 habe ich im Flieger, das funzt gut, finde nur grad nicht die Dateien im Wust.

Aber da kommt dann der 328p so langsam an die Grenze, weil der hat nur ein UART, der Attiny841 wäre auch da ne Idee? Oder besser gleich nen STM32F3/4 - bzw ein Flightcontroller, der kann dann auch Dshot, hat volle Sensorik, gibt es auch schon unter 2g. ........ Dann kann man auch gleich mit Hott Textmenü bauen, um MPP Einstellungen vom Sender her zu machen..man könnt soviel ;) ..,
nen halbes fliegendes Rechenzentrum, ich bin da ganz puristisch und hab nichtmal Telemetrie :rolleyes:



Alternativ wäre Arduino Softserial, aber dann müsste da irgendwie die Blockierung raus.

Code:
#include "SoftwareSerial.h"
SoftwareSerial HOTT(8,8);
uint8_t ESC[45] = {0x7c,0x8c,0x00,0xc0};

void setup() {HOTT.begin (19200);}

void loop() {
pinMode(8, INPUT_PULLUP);
if (HOTT.available() >= 2){ 
if((HOTT.read() + HOTT.read()) == 0x10C){
pinMode(8, OUTPUT); ESC[44] = 0; delay(5);
for(int i = 0; i < 45; i++) {HOTT.write(ESC[i]); ESC[44]=ESC[44]+ESC[i]; delay(2);}
}}}

Mein Arduino MInimal-Hott-Testcode:
biggrin.gif

Code:
uint8_t ESC[45] = {0x7c,0x8c,0x00,0xc0};

void setup() {Serial.begin(19200);}

void loop() {
if (Serial.available() >= 2){ 
if((Serial.read() + Serial.read()) == 0x10C){
ESC[44] = 0; delay(5);
for(int i = 0; i < 45; i++) {Serial.write(ESC[i]); ESC[44]=ESC[44]+ESC[i]; delay(2);}
}}}
 

maccl

User
Das Endbyte wird ganz hiermit "gebaut" : ESC[44] = ESC[44] + ESC; i++; , und schiest dann als 45stes Byte zum Sender.

ich meinte das Endbyte nicht die checksum (siehe byte 44 = 0x7D)

Dann kann man auch gleich mit Hott Textmenü bauen, um MPP Einstellungen vom Sender her zu machen..man könnt soviel ;)

stimmt schon.
Ich muss auch erstmal was bauen und Erfahrungen sammeln.
Werd auch erst ohne Telemetrie starten.
Und wie schon gesagt: ein unisens oder einen andern Sensor kann man ja auch noch mit einbauen.
Das geht super einfach, genau und die paar Gramm tun sicher nicht weh.

Wär halt nur schön gewesen wenn man mit einfachen mitteln einen MPP mit Telemetrie basteln könnte.
ich muss nur schauen wie zeitlich alles klappt. im Moment geht die Arbeit vor.
Aber darum meinte ich ja wäre ein Github-Projekt ganz gut, dan könnten dann evtl mehrer Leute entwickeln

Muss auch nochmal schauen was ich so an test-Sketches habe.
ich meine aber das ich einen MSP-Hott-Adapter (multiwii) mal gemacht hab der prima lief mit softserial.

Gruß Maccl
 
Moin

Der Nachteil beim dynamik-MPP, der die Leistung ja fiktiv an der ausgehenden PWM zum Motor festgemacht, sind Fehlinterpretationen in massiven Auf und Abwärtsfiguren, und das bei Propwechsel alles neu abgestimmt werden muss. Nachdem der Regelbereich eingeschränkt wurde (Idee vom Rolf, z.B. bei 12Zellen zwischen 6 und 6,4V) läuft er aber an sich recht gut.
Weil er von der Abstimmung sehr tricky ist, ist es eigentlich nix zum weitergeben.


Problem der "echten" MPP Regelungen sind ja das sie zu träge sind, es wird "ein vorher" mit "ein nachher" verglichen, da sich aber das Modell ständig hin und her bewegt, funzt das so nicht (zu träge). Das ist für die Solarbrunnenpumpe optimal, da hier das Panel ruhig steht. Ist aber das was dem Solarflug noch am nächsten kommt, da wir auch die Motorleistung zum MPP regeln. Im Gegensatz zu 99% der kaufbaren MPP-Regler, die laden einen Akku, und können keinen Motor regeln.


Ist mir heute morgen beim Frühstück eingefallen, wie man das machen könnte um weniger "Abstimmungsabhängig" zu sein, und zugleich den Temp-Drift der Solarzellen zu kompensieren.

(a) Wie beim Dynamik-MPP Regelgrenzen einhalten, Regelung wie immer mit mehreren KHz in der loop, aber die MPP-Berrechnung "langsam" in der 50Hz Interuptschleife zum Empfängerlesen verlagern. So hätte wir alle 20mS ein vorher nachher Vergleich (war schon in Versuchung den Watchdog Timer dafür zu missbrauchen :D). Ein "Fehltritt" des MPP hätte so kaum Auswirkung, da er "nur" für 20mS einen kleinen Schritt in die falsche Richtung macht, und das dann hoffentlich wieder "vernünftig" wird, die Fehlinterpretation bei fixen Flugfiguren wird man halt nie los werden, könnten so aber geringer ausfallen.

(b) das Kabel in der Tragfläche als Stromshunt missbrauchen, z.B. ein 0,3mm Kupferkabel daneben liegt (Schnapsidee), uns interessieren ja nur Vergleichs und keine Absolutwerte, dafür sollte das reichen.


Mal eben fix zusammen geschmiert, ohne Test, für den At44, geht sicher noch besser, evtl hat ja jemand noch Ideen dazu:

Code:
// ungetestet MPP by Holle 
// unkalibriert, angenommen wird für ADC 1Bit = 1mV


#define F_CPU 8000000UL
#include <util/delay.h>
#include <avr/io.h>
#include <avr/interrupt.h> 

//-------------  eigene Parameter -------------
int z          =   1;                //Regelgrösse (speed) für den Ummp Anpassung;
int MPP_max = 640;               //Regelbereich max 640mV Solarcell
int MPP_min = 600;                //Regelbereich min 600mV Solarcell

//-------------  statische Parameter-------------
int MPP    = 1024;                 //Motor OFF
int Pneu;
int Palt;
int Umpp;

int main(void){    
//-------------  Read ADC -------------
    ADMUX   = 0b10000001;       //     Read ADC6     
    ADCSRA  = 0b11000110;         //     Prescale 1/64  125 KHz 104uS FastMode
//--------------- Read RC -------------------    
    PORTB   = 0b00000001;          //     is RC Input    
    GIMSK   = 0b00100000;         //    PCINT1 activ
    PCMSK1  = 0b00000001;         //    PCINT1 is
    TCCR0A  = 0b00000000;         //    Timer ON
    TCCR0B  = 0b00000100;         //    Prescale 
//-------------  Write PWM -------------
    DDRA    = 0b00100000;       //    Write ESC is PA                  
    TCCR1A  = 0b00100010;       //    PWM  Mode 14 Channel-B        
    TCCR1B  = 0b00011010;           //    Prescale 1/8 500Hz //für ONESHOT 1/1 
    ICR1     = 2000;
    OCR1B      = 1000;                //     Write PWM
    _delay_ms(1500);            //    INIT ESC
    sei(); 
    
//-------------  endless loop ca. 8KHz -------------
while(1){
    ADMUX   = 0b10000001;                          //auf U-ADC schalten 
    ADCSRA |= (1<<ADSC);                         //start ADC
    while(ADCSRA &(1<<ADSC));                      //wait ADC
    Umpp = ADC;   
    if (MPP > Umpp) {if (OCR1B > 1100) {OCR1B--;}}
    else               {if (OCR1B < 1900) {OCR1B++;}}  
}}    
    
//-------------  RC-Interupt 50Hz -------------    
ISR(PCINT1_vect) {                                //RC-Interupt, 50Hz
if (PINB &(1<<PB0)) {TCNT0 = 0; }                 //rising edge, reset Timer
else          {if (TCNT0 < 46) {MPP = 1024;}        //falling edge RC OFF    
    else{                                        //falling edge RC ON    
        ADMUX   = 0b10000011;                      //auf I-ADC schalten 
        ADCSRA |= (1<<ADSC);                      //start ADC
        while(ADCSRA &(1<<ADSC));                //wait ADC
        Pneu = ADC * Umpp;                        //Pneu berrechnen
        if (Pneu < Palt) {z = z * -1;}            //wenn schlechter, Regelrichtung verdrehen
        MPP = MPP + z;                            //uuund regeln
        
//-----folgender Block könnte auch während des ADC ausgeführt werden------
        Palt = Pneu;                             //Pneu bekommt graue Haare
        if (MPP > MPP_max) {MPP = MPP_max;}     //die Grenzen einhalten
        if (MPP < MPP_min) {MPP = MPP_min;}        //die Grenzen einhalten                                            
    }
}}



EDIT
@Maccl, Unisens finde ich auch toll. Ein Vorschlag, nach neuem Update können alle Hott Empfänger (bis auf der 12L) mit einem Spannungsteiler direkt die Spannung auf Kanal5 messen. Wenn die Werte fluktuieren (das passiert teilweise wenn man den Empfänger direkt an die Spannung hängt), noch ein bissl Tiefpass mit drann.

Hast recht das Byte44 habe ich übersehen, dann müsste da noch ein ESC[43] = 0x7D; mit eingemogelt werden
 

maccl

User
@Maccl, Unisens finde ich auch toll. Ein Vorschlag, nach neuem Update können alle Hott Empfänger (bis auf der 12L) mit einem Spannungsteiler direkt die Spannung auf Kanal5 messen. Wenn die Werte fluktuieren (das passiert teilweise wenn man den Empfänger direkt an die Spannung hängt), noch ein bissl Tiefpass mit drann.

stimmt, das wär keine schlechte idee. Aber verbauchte Kapazität oder Strom lässt sich halt damit leider nicht messen.

ich hab mal den GR-12 mit dem GR-12L verglichen.
der "L" hat soweit ich weis ein andere Prozessor drin.

dann hab ich im Sender mit den Werten RX-Data im Telemetrie-Menü gespielt und siehe da es macht einiges aus.
getestet mit MC20 2.018. gemessen mit unitest2 an 5V.
(RX-Daten ist dafür gedacht die Telemetrie zu verlangsamen.... für Schleppflug etc... )

GR-12
RX-Data EIN 40mA
RX-Data "1" 25mA
RX-Data "10" 15mA

GR-12L
RX-Data EIN 38mA
RX-Data "1" 21mA
RX-Data "10" 7mA

mit externen Sensor erhöht sich der Stromverbrauch nat. etwas (unisens etwa 30mA)

erstaunlich finde ich das der "L" mit RX-Data "10" ca 7mA braucht.
bei 10 ist die Telemetrie recht träge aber man könnte ja noch etwas mit dem Wert spielen.
Aber d.h. für mich, dass man es nicht so umständlich mit dem Binden machen machen muss.
Und das DauerAlarm-Problem wäre damit auch erledigt.
 
Hi
Ja das sind mal Werte :)
7mA, dafür kann man das echt anlassen, das war mir neu mit dem "Schleppflug-Mode" :)
Wie ist es wenn man die Entfernung erhöht, erhöht dann der Empfänger die Sendeleistung, oder ist der Verbrauch "statisch" ?
 

maccl

User
Hi
Ja das sind mal Werte :)
7mA, dafür kann man das echt anlassen, das war mir neu mit dem "Schleppflug-Mode" :)
Wie ist es wenn man die Entfernung erhöht, erhöht dann der Empfänger die Sendeleistung, oder ist der Verbrauch "statisch" ?

Weis nur noch nicht ob man das bei den MZ-Anlagen auch umstellen kann.

Entfernung:Stromverbrauch hab ich nicht getestet.

Aber evtl. spielt es eine Rolle wenn die Luft "Besser leitet" (zb bei Regen)
;)

wär intressant was andre Epfänger für Werte haben.
zb Falcon, GR-16, GR-8.... (hab abe leider keine griffparat)
der GR-8 wär evtl auch was. da kannst nen Temp-Sensor und Spannungssensor direkt an die T-Buchse hängen.
aber ich hab den noch nie in der hand gehabt
 
@Daniel
Aktuell bei LinkSolar, ich hätte zwar noch ein 150er org verpacktes Paket, das sind aber die S***teuren werksselektierten E60, wenn es dir was nützt.[/QUOTE]

Hi Holger,

danke für die schnelle Antwort. Nimmst du flexiblen Solarzellen von LinkSolar?
Wenn ja, dann sind die j schon vorkonfiguriert. Bekommt man die wieder von dem Trägermaterial runter? Oder kann man die Zellen auch einzeln bestellen?

Ich weis ja nicht wie teuer die deine E60 Zellen sind, aber 150 Stück sind mir glaub für mein erstes eigenes Projekt zuviel.

Gruß Daniel
 
Moin Freunde der Sonne

Hab mal ein bissl gebastelt, um besser MPP Kurven analysieren zu können.

Zuerst ein Arduino mit ein paar Widerstände und nen FET auf eine Lochraster geklopft, was gar so rummflog.

IMG-20180909-WA0004.jpeg

Dann ein Raspi und nen Display aus einer defekten FPV-Brille vom Vereinskollegen, Software per Processing gebastelt, damit ist fix eine Visualisierung als XY Graph erstellt.

IMG-20180916-WA0002.jpg

Da ein Rapi eigentlich zu fett und zu lahm ist (wart---boooooot), mal ein bissl mit Apps gebastelt, weil das Phone hat man eh immer dabei. Zuerst per Processing, funzt auch super einfach, etwas hakelig war die Bluetooth Anbindung, aber dann lief mir die App "Bluetooth Electronic" über die Füße, an sich für den Zweck quasi gebrauchsfertig.:cool: (auf dem Steckbrett der Bluetooth-Adapter).

IMG-20180919-WA0001.jpg


Das ganze bei den ersten Tests bewegtem Bild:



Also Tespanel in die Sonne, und testmessen,

IMG-20180920-WA0005.jpg

Nun das erste Problem, Smartphone und Sonnenlicht, aber im Schatten konnte ich die Messung per Bluetooth auslösen, evtl. kommt ein epaper Display drann.

Das ist dann der Log der Solarfläche, alles noch unkalbriert.
IMG-20180920-WA0003.jpg

Auf dem Tablet siehts dann per Screenshot nun so aus, die gelben Knöppe starten die Prozesse, links MPP-Kurve messen. rechts Arduino-MPP-Tracking. Optik ist erstmal egal.
Screenshot_2018-09-21-17-53-53.png
 
Guten Tag miteinander :)

Ich möchte für eine Projektarbeit in der Schule einen Elektrosegelflieger mit Solarantrieb bauen.
Deshalb bin ich auf dieses Forum hier gestossen und habe gesehen, dass dies ein sehr umfangreiches und Spannendes Thema ist. Bei welchem Ihr sicherlich mehr Erfahrungen habt als ich.

Ich habe Grundlegende Kenntnisse im RC Flugzeugbau bzw. habe ich auch schon Bausätze flugfähig gemacht :P

Ich denke da an einen Elektrosegler mit ca. 2.2m Spannweite und ca 800g Gewicht eher etwas mehr Gewicht vermutlich.

Ich möchte mit einem Pufferakku arbeiten und nun kommt Ihr ins Spiel. Ihr seit hier die Profis was schlagt ihr für einen Akkutyp vor? Kommt man heutzutage überhaupt an einem Lipo vorbei ? Was das Leistungsgewicht angeht? Und was wird der von den vielen kurzeitigen Ladungen halten?

Überhaupt habe ich etwas Respekt von dem Laden bzw. beziehen vom Strom aus dem Akku für den Antrieb.

Wie habe ihr dies gelöst? Grundsätzlich braucht es ja wie für eine Normale Photovoltaik-Anlage einen MPPT also einen Laderegler welcher entweder in die Batterie einspeist oder eben direkt dem Verbraucher den Strom liefert.

Gibt es da Bauteile die man direkt ab Stange kaufen kann?


Ich freue mich auf eine gute lehrreiche Diskussion mit euch.

Falls ihr das Gefühl habt, dass es zu diesen Thema einen neuen Thread braucht erstelle ich gerne einen.


Beste Grüsse

Robert
 
Halo Robert

Vorschlag, baut etwas kleiner mit 14Zellen, das macht vieles einfacher.

Lipo war früher (Vintage;)), sind nur noch dann zeitgemäss, braucht man eigentlich nur noch, wenn es um sehr kurze Leistungsspitzen geht, ansonsten stehen sie in allen Belangen den aktuellen LiIon weit nach. Benutze ich nur noch in Hotlinern/Pylons.

Für das Projekt z.B. 2s LiIon, NCR3500mAh gut fürs gemütliche fliegen, wenn es auch performant sein soll 2s vtc6 oder q30.

Laderegler im einfachstem Fall: einfach nur eine Ideale-Diode Fet bassierend, und zusätzlich bei erreichen der Ladeschlussspannung mit einer einfachen Elektronik abschalten (da reicht ein Op-Amp, oder Arduino, Attiny....).
Evtl kann man die Ideale-Diode und Schalter auch in einem FET basteln.

Das ist zwar nicht die effizieriente Methode, aber es funktioniert. 14Zellen haben einen Umpp von etwa 7,4V, die Aldeschlussspannung 8,4V erreichen sie, aber da geht der Strom dann schon runter, darüber hinaus muss abgeschaltet werden.

Ansonsten finden sich MPP Laderegler, meist Arduino-bassierens tonnenweise als Pläne im Inet, die kaufbaren dürfte zu schwer sein.
 
Guten Tag Holger

Danke für deine Antwort :)

Beim Laderegler habe ich immer noch so meine Probleme, dass musst du mir noch einmal etwas genauer erklären.

Ich brauche ja eine Ladespannungsbegrenzung von 8.4V für einen 2S. Mit einer Z-Diode könnte man dies erreichen.

Mit dem Op-Amp wird dann bei einem bestimmten Stromwert abgeschaltet verstehe ich dies richtig? Da durch die ansteigende Spannung im Akku der Ladestrom immer kleiner wird.


Wie schliesse ich danach den Akku an den Motorregler an? Wird dieser einefach parallel angeschlossen?


Du siehst meine Elektrotechnischen Kenntnisse sind eher bescheiden.
Aber ich bin gewillt es zu verstehen :)
 

derjuwi

User
Moin Freunde der Sonne

Hab mal ein bissl gebastelt, um besser MPP Kurven analysieren zu können.

Zuerst ein Arduino mit ein paar Widerstände und nen FET auf eine Lochraster geklopft, was gar so rummflog.
[...]

@Holger: Was moechtest du mit deiner Elektronik erreichen? Sieht ja cool aus :)
Hab sowas aehnliches auch kuerzlich gebaut, auch mit einem Raspberry Pi. Muss mal suchen ob ich spaeter Bilder finde :)

Gruesse Julian
 
Moin Julian
Etwas "erreichen" eher weniger, ist Spielerei, um mal dies und das gemacht zu haben, wie böse Tiefpässe an der harten PWM an der reinen ohmschen Last sein können, besonders diese "Bluetooth Electronic" App macht richtig Spaß, man könnte all das mit einem Logger und Excel genauso erstellen. Diese "Spielereien" in der Testumgebung (umgebautes Netzteil das ein hochohmiges Solarpanel simuliert) bringen einem auf Ideen, und diese sind dann damit auch schnell zum testen umgesetzt.



@All
Was mich derzeit etwas beschäftigt ist das Flachdach der MPP Kurve, ein paar "gestreute" Logs des Testpanel unter verschiedenen Bedingungen, nah an den MPP herangezoomt:
streupunkte1.png
streupunkte2.png

Der erste Gedanke: Spannung scheint ja noch egaler zu sein, als ich dachte, oder wer misst misst MIsst. ...


Gestern habe ich dann dem MPP-Messer mitgeteilt, nur mal die oberen 3% der Leistungsspitze im Grafen anzuzeigen (was den Flash des Nanos zum stöhnen gebracht hat, alle Messwerte im Array:D) Das sah dann garnicht viel anders aus (links MPP-Kurve, rechts die Streuner) .

Screenshot_2018-09-24-14-10-55.png
Pi x Daumen, mutgemasst, liegt man bis zu 0,5V daneben, dürfte der maximale Verlust etwa 3% betragen.

Die Verluste eines guten MPP-Trackers sind ja auch nicht Null, er misst ja indem er bewust daneben tappt, und dann kommt dann wieder zurück, dann war da noch ein Shunt u.s.w.

Hier ein schickes Gif wie dasetwa abläuft:

AiWBx.gif


Quelle (empfehlenswert) https://electronics.stackexchange.com/questions/266863/help-on-mppt-algorithm


Die Crux ist nun, ändert man die Spannung etwas, um dann nachzumessen, hat sich in der Leistung fast nichts geändert, die Auswertung ist in kleinen Schritten sehr schwierig, und braucht gutes Messbrimborium. Ich habe bei einem Bekannten an einem kommerziellen MPP am Campinganel mal mitgeloggt, der MPPT war gewaltig am Pumpen, auch sieht man das oben im Screenshot vom Tablett im MPP-Tracking, der war nach dem üblichem Algo geproggt (wie der auf der Seite von der Bildquelle).

Der nächste Versuch ist nun: Die Spannung mal nicht stufenlos sondern Messwerte-sei-Dank schrittweise zu ändern, z.B. für das 12Zellenpanel bei 6,7V anfangen, erst per fixrd-Voltage Regelung einpendeln lassen, bevor gemessen wird, und dann 0,1V runter, und wieder von vorn Ende so bei 5,7V. schaunmermal.

Nachher kommt noch ein Beitrag mit gesammelten/gemessene (hoffentlich) interessanten Grafiken...
 

derjuwi

User
Da:

https://github.com/juwis/mppt-bldc/tree/rpm_mppt_tracker/src/autompptbldc/autompptbldc

findest du einen Ansatz wie ich das bei meinem Tracker im Messgeraet geloest habe. Der braucht allerdings (Original im Messgeraet, nicht der im Regler aus dem github Link) eine 3stellige Sekundenzahl um sich einzupegeln. Danach ist er aber reproduzierbar auf 0,01% genau. Das brauchen wir nicht, weshalb ich die obige Adaption gebaut habe die Geschwindigkeit fuer Praezision opfert.

Der im Regler (github Link) arbeitet auf einer Range und ist zumindest den ersten Versuchen nach schnell genug (~200Hz) um scheinbar zu funktionieren.

Im Prinzip ist es eine aus der Computergraphic verwendete Kantenerkennung die ich als Tiefpass/Steigungsfilter verwende.
Falls interesse an der Mathe besteht kann ich das gerne spaeter elaborieren ;)

Gruesse Julian
 
Hallo Julian
Ich wollte da mal die neuen Inas 240/253 ausprobieren, warte aber noch drauf, die haben eine "Enhanced PWM Rejection", k.A. obs was taugt.

Edit, den Code hab ich mir kurz angeschaut, im Prinzip so wie den Code den ich letzte Woche eingestellt habe, statt P dann rpm, vergleichen, und ggf. Differenzwert *-1, ist ja auch die allg. übliche Vorgehensweise.

Die Problematik ist nur, der Propeller dreht ja auch höher wenn man das Modell ansticht, und nicht nur wenn die Leistung steigt.

Für das Tracking im Testgerät habe ich es etwa so gebastelt, funzt dafür recht ordentlich:
Quelle mit Codes: http://coder-tronics.com/tag/perturb-observe/
C2000-Solar-MPPT-Perturb-and-Observe-Algorithm-Flow-Chart.png



@All


Im folgenden meine unausgegorenen Gedanken um den MPP.

zuerst mal eine kombinierte MPP Kurve mit unterschiedlichen Temperaturen und Lichtstärke:
pv-curves_2.png

Quelle: https://myelectrical.com/notes/entryid/257/photovoltaic-pv-panel-performance-modelling


Oder in "gröber"
solar-cell_i-v_curve_sfw.gif

Quelle: https://atmelcorporation.wordpress.com/2013/10/24/current-sensing-for-smart-meters-and-solar-panels/

Die Kurven sagen uns, und das nichtmal geringfügig:
-Je geringer die Temperatur, je höher der Umpp
-Je mehr Licht, je höher der Umpp (Licht ist Tage/Jahreszeitabhängig, Lage des Modell zu Sonne, Luftfeuchte, Wolken u.s.w.)

Nun ist es so, das es nachts nicht nur kälter ist als drausen, sondern ist es nachts auch kälter als Tags, und im Winter ist es kälter als im Sommer. Licht macht es genau umgekehrt, da es ja letztlich für die Temperaturen sorgt, tags ist es heller als nachts, und im Sommer ist es heller als im Winter.
ergibt, also wenn wärmer, dann auch heller, kombiniert:
Winter; geringe Temperatur = höherer Umpp + weniger Licht =geringerer Umpp
Sommer, hohe Temperatur = geringerer Umpp + viel Licht = höherer Umpp
Es gleicht sich als etwas an, leider reagieren die Zellen stärker auf die Temperatur als auf Lichtstärke.

Das mal Gra-Fisch:
Bestrahlungsstärke für mein Wohngebiet, SommerWinterzeit ausgeglichen (noch;)):
steinhudermeerlicht.png
Und der typische Oberflächen-Temperaturverlauf(blau) kombiniert mit der typsichen Bestrahungsstärke (rot), einmal Jahr, und ein schön knackiger Sommertag
MPP_wetter1.png





---
Also mal aufräumen. Die folgendende Grafik ist nach dem Datenblatt Sunpower erstellt:

Oben, Verlauf nach Lichtstärke und Temperatur für den Umpp. Realistische Lufttempatur zum Solarfliegen (von Ausnahmen abgesehen) sind wohl so (10)15-30°C, darunter erfriert die Sonne, darüber schmilzt der Pilot.
Die Oberflächentemperatur habe ich dieses Jahr eine Messreihe gemacht, nach der Landung direkt gemessen beträgt sie meist um die 10Grad über der Lufttemperatur, ich habe eine rauhe (Kühlrippen;)) sehr dünne Beschichtung auf den Zellen, mit einer dicken Harzbeschichtung darf man nochmal rund 10GRad oben drauf legen. Ich denke mit 25-55°C sollte alles abgedeckt sein.

Unten. Nun ist es so, wenn es drausen kaum mehr als 10°C hat, dann ist nicht Hochsommer, sondern sowas wie Winter, da steht die Sonne nicht so hoch, und wir haben eine geringere Betrahlungsstärke. Umgekehrt, wenn einem drausen die Sonne mit 30°C auf dem Pelz brennt ist kein Winter, wir haben also viel Licht, aber ein Solarpanel auf dem wir Eier braten könnten. Es wird nicht vorkommen das wir 1000W/m² und 13°C haben, auch fliegen wir nicht mehr unter 200-400W/m² (jeh nachdem...) so können wir den Randbereich um einen realsitsichem Bereich beschneiden.

MPP_wetter2.png

Wir sehen, die Auswirkung auf unser Solarmodell sind bei weitem nicht so gravierend wie bei einer Hausdachsolaranlage, die Sommer wie Winter unter allen Randbedingungen noch Strom produzieren soll, auch wenn längst schon kein Flugwetter mehr ist.

Fixed Voltage reicht aus wenn man mit 2-3% Verluste im Randbereich leben kann. Auch die beste Regelung wird keine 98/99% schaffen, da gibt es wahrlich effektivere Baustellen (Flächenbau, Leitwerk, Modellgewicht u.s.w.). Zielführender wäre wenn überhaupt, vermutlich eher ein Tempsensor unter den Solarzellen, der arbeitet auch im Flug und kann den U_soll aktuell halten.
 
Ansicht hell / dunkel umschalten
Oben Unten