Tristar v křemíkovém nebi

[peater]

Tak, včera dorazil kurýr z Fedexu a držel v ruce podezřele velkou krabici. Na náhradní plošňák to nevypadalo. Rozbalím krabici a tam nový Tristar Tak toto jsem nečekal, ještě jednou klobouk dole to se teda jen tak nevidí.

[ixo]

Paráda! Mal si ho v záruke ešte, či už nie?

[peater]

Paráda! Mal si ho v záruke ešte, či už nie?

První jsem mysle že ne, tak jsem ho rozebral. Pak mě technik z Morningstaru řekl že v záruce ještě je. To rozebrání mu nějak nevadilo, jen chtěl udělat nějaké fotky poškozené části.

[dedo]

Skvelé prekvapenie! Neustále mám strach, čo robiť, ak sa môj 6-ročný TriStar zblázni...

[ixo]

Ahojte, ako vám fungujú Tristary? Mne už nonstop 6 rokov a 50 dní... Trochu mám obavy, keď raz odíde, komplet mi to odstaví elektráreň na dlhšiu dobu...

[MareC3k]

Aktualne mi bezi nonstop uz: 6y114d21h

[pkougl]

Ahoj,
jeden mam po reklamaci nový 3y102dní (původní taky funguje ale přijde mi že má někdy posunuvé Umppt, někdy na webovém rozhraní ukazuje mínusové hodnoty ale normálně jede, je jako záloha v krabici)
druhý mám původní 6y318dní a jedou samozřejmě nonstop
Pavel

[Antonio]

Môj tristar mppt 60A beží v kuse 71049h cca 8,1roka

[kodl69]

U kámoše bazarovej kus mppt 60A, co najel nevím kolik u prvního majitele, jede už třetí rok bez zaváhání s 2kWp polem na 24V systému...

[kybos]

Získaná energie

odpracovaná doba

Jeden z kousků, který u mne pracuje má za sebou 19MWh, které vyráběl přes 7 let.

[rimi]

A: 12MWh, 7y308d
B: 4MWh, 4y203d
oba prepanelovane
EDIT: sakra, co to je za nazev vlakna

[pezizka]

Já mám MPPT 45A, 5,7 roku, asi 2 roky hodně přepanelovaný, i tak bez zaváhání Vím o něm akorát když se chcu podívat na čísla

[ixo]

Pridám čerstvú, pomerne drsnú skúsenosť s Tristarom (prevádzka 7y94d), polovicou duše som sa s ním už dnes lúčil, ale nakoniec všetko dobre dopadlo. Čo sa stalo: predĺžil som dnes čas absorbcie, nastavenia uložil do regulátora a odvtedy sa na Tristar nedalo pripojiť cez TCP/IP.
Nezabrali tieto pokusy, ktoré v minulosti vždy zabrali:
- reštart controllera;
- reštart komunikačného servera;
- odpojenie od napájanie (aj na dlhšiu dobu).
Prúser. Okrem nemožnosti ho v budúcnosti konfigurovať som prišiel o dáta, ktoré z neho ťahám a reportujem a mám na ne napojenú unikátnu logiku mojej elektrárne.

TCP/IP konektivita bola mŕtva, avšak podľa diód aj stúpajúceho napätia na batériách bolo zjavné, že menič na pozadí naďalej fungoval. Prirovnal by som to ku kóme pacienta - vitálne funkcie zachované, avšak stav bezvedomia, bez interakcie.

Priame pripojenie LAN káblom (vygooglil som tento hint) prinieslo to, že Tristar sa v MSVIEW sa ukázal, ale nedalo sa naň pripojiť. MSVIEW pri každom pokuse spadol.

Zohnal som preto RS232 to USB kábel, čo je ďalšia možnosť napojenia sa na Tristar. S ním sa doň pripojiť cez MSVIEW po pár peripetiách dalo (sláva!) a dal sa dokonca aj konfigurovať, a na rozdiel od TCP/IP aj veľmi svižne. Skúsil som preto, aj keď s neúspechom:
- opäť reštarty všetkého možného;
- upgrade firwmaru na poslednú verziu (ide v skutočnosti o 2 FW balíky).

Napadlo mi zobrať aktuálne nastavenia a vrátiť hodnotu absorbcie na pôvodnú. A TCP/IP komunikácia sa rozbehla! Nedáva mi to stále zmysel. Nedalo mi to teda a opäť som zmenil dĺžku absorbcie na tú "problémovú". Komunikačný server sa opäť znefunkčnil tým istým spôsobom. Tak som tentokrát zmenil dĺžku absorbcie na inú, tretiu hodnotu, podobnú tej, ktorú som ráno zamýšľal a server opäť začal fungovať. Ďalej som neexperimentoval, zdá sa, že komunikačný server sa proste znefunkčnil pri dĺžke abosrbcie 3h 0m 0s. Vyzerá to ako bug, a pekne záhadný.

[solárník]

Jen pro úplnost - Otův Tristar se nakonec dostal ke mně, já na něj koukal a postupným měřením a IR kamerou jsem zjistil, že hlavní CPU je v pánu - proražený, má kraťas Vcc proti zemi asi 0,15 Ohmu. Takže konečná, s tím nejde nic dělat, protože neznáme/nemáme vnitřní program, i kdybych ho nakrásně vyměnil, bude to mrtvé.

@kodl69 - nemám s tím příliš zkušeností, ale v blokovém schématu driveru fetů IR2181S v Tristaru vidím logické hradlo mezi LIN a HIN, tedy podle toho, co vidím, je shoot-through poměrně nemožný. Ten driver nezapne dolní fety pokud je zapnutý signál na horní fety. Co na to tak koukám, tak by to dokonce mělo jít provozovat tak, že dolní signál do driveru by se nechal stabilně na HIGH a poslal by se PWM pouze do HIN, tedy vstupu horního driveru horního fetu. Ale třeba se pletu, koukal jsem na to jen zběžně. Ale to hradlo tam je v blokovém schématu.

@kybos / Jozef51 - všechny 3 cívky v Tristaru mají stejnou indukčnost cca 120 uH a poměrně velký DCR 10 miliOhm, tedy to není zrovna moc dobře udělaná cívka. I blbý laciný EPEver má cívku s polovičním DCR asi okolo 4,5 miliOhmu a dokonce s ještě o kousek vyšší indukčností (a i ta je udělaná stále blbě, hřeje jako prase). Tedy tím asi hypotéza kybose padá. Spíše to bude kvůli minimalizaci ripple tak, že Tristor to budí zpožděně o 120°ty jednotlivé drivery, takže výstupní proud je hodně konstantní, neripluje. Tomu odpovídá i velikost indukčnosti.

Je vidět, že je to dnes už předpotopní návrh, jak tu psal Jozef51, tlumivky jsou vinuty tlustým drátem, takže musí mít obrovské AC ztráty, protože už třeba při 40 kHz (nevím, na kolika jede Tristar, ale spíš ještě na víc) vodí měděný kabel pouze do hloubky 0,3 mm, což znamená, že jakýkoli vodič, který má víc jak 0,6 mm průměr, bude značně ztrátový a to o to víc, čím je jeho průměr vyšší než 0,6 mm. Dneska se to vine pomocí litz wire s izolovanými (!) vlákny právě max 0,6 mm průměr (pro 40 kHz, pro vyšší frekvence ještě slabšími), pak je šance, že ACR (AC rezistance při frekvenci PWM) bude skoro stejná jako DCR. A je to i důvod, když se podíváte do Tristar manuálu, že tam uvádějí v grafech, že čím větší rozdíl vstupního napětí od napětí baterie, tím je účinnost dramaticky nižší (virtuální frekvence na cívce je nepřímo úměrná hodnotě času PWM_ON (=duty), tedy napěťovému převodu střídače). Dnes už by to šlo minimalizovat, kdyby se tam daly lepší cívky.

@ Jozef51 Stabilizátory v Tristaru jsou nikoli 12 V, 5V a 3.3V, ale je tam hlavní 12 V, pak 3,3 V (CPU, PIC, EEPROM) a dále je tam 1,8 V - ten třetí je možná pro Vcore procesoru, nic jiného mě nenapadá. CPU mého měřeného Tristoru od Oty byl v pánu, takže se už nedalo nic zjistit. Z toho první stabilizátor musí zvládat vysoké vstupní napětí, to je ochrana všech MPPT měničů proti odpojení baterie za provozu. Aby to neodkráglovalo CPU a další logiku. Bez toho to při prvním odpojení baterie za provozu odejde do věčných lovišť (ono to většinou odejde stejně, pokud konstruktér nezajistí, aby se cívka někam rozumně mohla vybít, ale CPU zůstane živé, tedy pak stačí vyměnit silovou část. Primár cívky se posadí skrz diodu střídače (low side paralelně k low mosfetu) na zem, ale sekundár cívky řádně kopne a to se musí někam utopit. Na to CPU nestihne zareagovat ihned a odpojit vstupní mosfety (těch 8 malých stříbrných placiček na PCB Tristaru u Vin+), tak rychle CPU nepracuje. Dávají se tam TVS ochrany proti přepětí, ale při několika možných napětích baterie je to složité je správně naprojektovat.

Vskutku by mě zajímalo, jak se mohlo podařit to takhle celé propálit včetně CPU. Kdyby bouřka, tomu bych věřil. Ale jinak by se to nemělo stát, alespoň přes napájecí větev, co jsem tam tak koukal. Spíš tam mají v Tristaru nějaký problém s tím, že Vcc CPU je sice chráněné, ale vstupy nejsou (prostě se na to při návrhu vykašlali, což je škoda). A velmi pravděpodobně to tak bude. Že to CPU zabilo přepětí na vstupu, možná zrovna od toho IR budiče. Protože pokud dobře vidím, není tam mezi IR2181S a CPU piny vůbec nic, dokonce ani malý rezistor. Takže je to jasný.