Fórum MyPower.CZ

mělo by to fungovat s tím uspáním tak, že procesor probudí buď watchdog timer (4s ?) ten změří několikrát napětí a potom rozhodne, jestli balancovat nebo ne. Naměřený hodnoty zůstanou v proměnnejch. Tím se zajistí, že balancer zapne minimálně na 4s, a nebude zapínat/vypínat jak zběsilej. Watchdog by měl zároveň zajistit reset při "zabloudění programu" (8s?) a další co probudí procesor je log0 na RX pinu.
Netuším, jak náročný je CRC na místo v RAM, snad to klapne.
Já zase vícenásobný předání zprávy považuju za bezpečnější a jednodušší než CRC, to napíšu na třech řádcích, vyhodnocení že třikrát přišlo stejný číslo a stejnej povel, tak zapiš do eeprom. Však to bude jenom pro nastavení základních hodnot, v zásadě by se v tom němělo vrtat. Ještě je otázka, jestli umožnit přepsání všech konstant Vref na zapojenejch balancerech, ale asi jo, jinak by ot bylo dost otravný třeba po přehrání firmware připojovat nb na každej modul a posílat tam příkaz pro nastavení Vref.
reference je nechaná jako nap. napětí, skutečný napětí je potom U=1024*Vref/ AnalogRead(A1);
odpor pro snímání proudu je momentálně 9miliohm, takže když se zadá Vref v milivoltech, a odpor v miliohmech, je výsůedek v ampérech:

I= (AnalogRead(A2)*Vref)/(AnalogRead(A1)*Rsense;
možná by bylo rozumější proud posílat v 0.1A, tj *10, jinak by byly hodnoty akorát 0,1,2.

samozřejmě tohle je nástřel, každá hodnota musí projít digitálním filtrem, aby to neshodilo nějaký rušení, a u A2 by klidně mohl být omezenej rozsah platnejch hodnot - ostatně u A1 taky.

Co posílat:
ve vyčítanejch datech: byte command+ napětí (2byte)+ proud(1byte nebo jenom 1/2byte?) teplota procesoru?(zatím se nepodařilo rozchodit) ještě něco?
nastavení balančního napětí pro všechny: byte command+2byte balanční napětí +1byte "cokoliv", pro zachování dýlky datagramu
nastavení napětí jednotlivě bude to stejný, akorát jinej command a data pro každej článek zvlášť.

ladicí a kontrolní blbiny:
zapsání Vref pro jednotlivý moduly: byte command+2byte napětí článku+1byte cokoliv - balancer si hodnotu Vref vypočte z naměřenýho napětí článku. max. ochrana proti přepsání omylem
zapsání VbalDefault do eeprom pro všechny: byte command +2byte napětí VbalDefalt + 1byte cokoliv , max. zabezpečení přepsání omylem.
načtení konstanty Vref: byte command+ 2byte + 1byte cokoliv
načtení konstanty VbalDefault: byte command+ 2byte + 1byte cokoliv
načtení konstanty VbalSet: byte command+ 2byte + 1byte cokoliv
sepnutí každýho balanceru na ty 4s: byte command +3byte cokoliv - stejně bych udělal vypnutí pro ověření funkce mosfetů (pozděj aktivního balanceru). Na deskách jsou signalizační LED

Už mě ani nic nenapadá, možná by se tohle mohlo proškrtat...
v zásadě by mělo po 99,99% času jet jenom vyčítání dat. Dvakrát z aden nastavení balančního napětí? -moje představa je, že třeba pro lifepo4 by při překročení nap. 3.4V na některým článku se nastaví bal. nap. na 3.4V, až 1-2 články překročí 3.45V, tak nastavit 3.45V pro všechny a když nap. překročí někde 3.5 (3.55V?) sepne nějakej výstup pro vytěžovač, ostatně první stupeň by mohl být aktivní už při 3.45V, a při překročení 3.6V napřed 10s zvukový varování a pak vypnutí nabíjení. podobně by mělo být řešenáý nízký napětí článku, řídící modul by měl měřit i proud, ale to je další level, zatím potřebujem vytvořit SW do modulů, aby jely spolehlivě a bez chyb.
párkrát za život procesoru by se mohlo změnit VbalDefault, stejně jako Vref. Tady bych na zápis do eeprom dal co nejsilnější možnou pojistku proti chbnýmu zapsání nesmyslů, mám z mládí otřesný zážitky ze zařízení, kde se do jedné eeprom zapisovaly provozní hodnoty a byly v ní i konstanty - nespolehlivější krám jsem neviděl...
Tohle by snad ani nemuselo být součástí řídící jednotky, podle mě by stačilo připojit přes převodník NB a z terminálu tam odeslat potřebnej datagram. Tím by bylo zároveň zaručený, že se to nějakou chybou řídící jednotky nepřepíše...

Pokud stačí přesnost napětí 10mV a rozsah bude vždycky mezi 2.5 - 5.0V tak se dá napětí přenášet na jednom bajtu (číslo by znamenalo počet 10mV nad 2.5V), zkrátí se celá přenášená zpráva, zkrátí se doba kdy tiny nespí a ušetří se trochu RAM za cenu o něco delšího kódu kvůli přepočtům.

Ako sa to bude kalibrovať ? Zmerám napatie na článku 0. a pošlem ho AT85 - s poradím 0.,
zmerám napatie 1. článku a pošlem AT85 s poradím 1. atď.... a AT85 si už dopočíta konštantu
a uloží do EEPROM ?
Ergo, ref [AT85_0] = napatie_článku[0]*hodnota_pinu_referencie[AT85_0]/1024.0 ?

Potom je vhodné si ju z AT85_0 vyžiadať a skontrolovať či je OK ?

Tak nějak bych si to představoval...

Jinak komunikace s vnějším světem je plánována jak? Bude v tom kruhu nějaký silnější procesor s rozhraním ven? Já bych loboval za megu s ethernetem a s celou baterií by se dalo mluvit po REST...

Zatiaľ do robím po svojom, kým mi prídu moduly od kodla.
Adresy AT85 sú: FFFF AT0, FFFD AT1 atď. rozsah FFFF až 8889 HEX, ergo cca. 15291 adries.
Vždy nepárne.

Príkazy globálne:
8888 = nastav rovnaké bal. napatie pre všetky
8080 = nastal calib. konštantu f_call, ak prišiel blud ignoruj a do eeprom zapíš 1.241

Odpoveď je:
FFFF 0 "sensorValue" 00000 4D9 = sensorValue je 140 HEX čo je 320 DEC a po prepočte:

1024 * f_call / 320 to dáva 3.96 V.

Takže ak príde nepárna adresa a 2. za sebou rovnaká hodnota napatia, tak to považujem za OK.
Do 70 znakového stringu sa vojde komunikácia s 4-ma modulmi.

Potom by sa adresovanie mohlo zmenit, ak tu bude fachcit, na iné, aby napr.
odpovedali len tie, čo začínajú na FFF, potom FF8 atď.

Ak to nebude fachčiť, tak to urobím podľa popisu tu vo vlákne, ak som tomu dobre
porozumel a budem to schopný nakodovať a v realnej prevádzke o testovať.

Dnes jsem zjistil, že první, co musím udělat, než osadím další moduly, je uklidit si na stole v dílně. Sice má 0.6x3.5m, ale už se na něj nějak nechtějí všechny předměty vlézt, a padají na krajích na zem. Takže sobota bude hlavně úklid, a pak možná chvilka laborování...

Zdravím ,

kodl69 píše:Dnes jsem zjistil, že první, co musím udělat, než osadím další moduly, je uklidit si na stole v dílně. Sice má 0.6x3.5m, ale už se na něj nějak nechtějí všechny předměty vlézt, a padají na krajích na zem. Takže sobota bude hlavně úklid, a pak možná chvilka laborování...

Víš jaký je rozdíl mezi vše shrábnout do popelnice a roztřídit do krabiček , šuplíků a škatulí ? Žádný po úklidu nic nenajdeš .

Elektronům zdar

Náhodou, hned po novým roce jsem roztřídil cca 10kg spojovacího materiálu, co jsem 25 let sypal do bedny. Byl jsem přesvědčenej, že doma nemám matičku M5, a po separaci jich bylo minimálně třicet. Je fakt, že hodně si na popelku zahrály děcka, toho staršího to bavilo podstatně víc než mě.
Spíš je to o otom, že dělám ledados, a pak je najednou na stole 1.5kg kladivo vedle mikrošroubováku, a pásky s 0603 SMD odporama, a to jaksi fakt nejde k sobě.

Takže kommand 8888 úspešne odskúšaný. Robil som to tak, že som najprv otestoval,
či je v poriadku komunikácia so všetkými modulmi a potom poslal kommand na nastavenie
balančného napatia pre všetky.

Ty specifický adresy do attiny nahráváš při programování?

Hej adresy su napevno pri prvom napaleni.
Len sa to strašne zle debuguje.

1. napaliť do Una Arduino as ISP
2. vybrať 0. AT85 a dať ho do shieldu
3. preklikať sa na obrazovke k oknu AT85_0
4. vybrať z menu dosku AT85
5. vybrať USB port
6. napaliť program
7. vybrať 0. AT85
8. dať tam 1. AT85
....

a. do Una napaliť riadiaci program
b. všetko znova pozapajať do kruhu
c. pripojiť napatie na všetky AT85
d. pripojiť napatie na UNO
e. spustit' seriovú konzolu

Vyskytla sa chyba a všetko odznova.

Nexistuje nejaký lepší sposob, ako to robiť a niečo na degugovanie priamo z AT85 ?

Nejako mi to nekomunikuje v smere UNO ==> do 0. AT85.
Pošlem príkaz na nastavenie bal. napatia za tým bal. napatie a ono to zahodí.

Ale keď dám vypísať buffer s natvrdo nastavenými napatiami, tak aj z 0. aj z 1. AT85
príde všetko OK.

Tak neviem či je to HW alebo SW problém.

Existuje, pro attiny je to debug-wire, prgramátor/dabudgger AVR-ICE, AVR Dragon, https://awtfy.com/2010/02/21/modify-an- ... debugwire/
ale za hromadu peněz. navíc to nefunguje s arduino ide, ale s atmel studiem, a s tím si teda nerozumím... Já komunikaci testuju tak, že mám připojenej k PC převodník USB/uart, a ten zapojím na optočleny balanceru. K tomu používám CuteCom terminál, a arduino používám jenom na to proǵramování attiny. Až bude hotovej program do attiny, budu řešit ten druhej konec... Ostatně když bude popsanej protokol, může si to kdokoliv přiohnout k obrazu svýmu...

dnes jsem otestoval komunikaci převodník uart ->optočlen->attiny->optočlen->optočlen->atiiny->optočlen->převodník uart.
i s jednoduchým prográmkem
projde 66 ascii znaků. Bez chyby. Zkoušel jsem to s napětím attiny od 1,8V!!! do 5V, i rozdílný napětí mezi nimi, bez chyby komunikace. Akorát po zapnutí to pošle nějakej blábol, ale to snad není taková chyba.
Jediný, co nemám otestovaný, je měření proudu balancerem, ale změření napětí na adc pinu asi nebude problém.
Takže jak bude chvilka, budu chystat testovací prototypy pro zájemce.
Jak je složitý udělat si účet na githubu? Že bych tam dal ty testovací sketche, a kdo něco stvoří, mohl by to dát přímo tam, k vyzkoušení ostatním.
Desky budou chtít nějaký doladění, ale o tom kdyžtak pozděj, prostě nic se nezdaří dokonale ani na druhej pokus...

github je v pohodě... Jdi do toho.
Podporuje pěkně spolupráci na projektu (děláš na své kopii a pak to umi spojit) a dokonce lze mít i skrytý kód - to je novinka.

Ta komunikace teda frčí přes 2 optický oddělené dráty? Docela bych zvážil zkusil dvě alternativy:
- lepší knihovnu pro softverovy sériový driver (aby se dalo současne posílat i přijímat),
- 1wire protokol a druhý drát na buzení.

No uvidíme.

Ja mám HW problém, nemožem cez TX Una a RX ATtiny85 dostať do ATtinny správnu
postupnosť znakov. Už na 3. znaku je tam skomolenina povodnej správy odoslanej z Una.

Tak konečne to funguje oboma smermi, problém bol odpor na prvom optočlene.

Najprv vráti Attiny85 hodnoty:
FFFD = adresa Attiny,
0148 = hodnota z nap. pinu HEX
0C33 = balančné napatie HEX = 3123 DEC mV
0F24 = kalibračné napatie HEX = 3876 DEC v mV

Po odoslaní príkazu 888A 101B sa nastaví
balančné napatie na 101B HEX čo je 4123 DEC

a ďalším prikazom sa nakalibruje hodnota f_call v Attiny, tým, že sa odošle aktuálne
namerané napatie článku 888B 0EC6 HEX,
čo je 3782 DEC v mV, hodnoty sa zapíšu do EEPROM.

Program v ATtiny má 4836 B a premenné majú 234 B.

Ešte je tam meranie teploty, ale neviem to správne prepočítať a nič som k tomu
zatiaľ na nete nenašiel.

na tohle jsi se díval? https://forum.arduino.cc/index.php?topic=26299.0
mělo by ot snad být u všech AVR stejný... přepočet by měl být: temp=(raw-336)/1.17
akorát potom uves ad převodník do původního stavu.

Teplota naměřená na vstupu ADC4 při použití interní reference 1.1V odpovídá -40C pro hodnotu 230, +25C pro hodnotu 300 a +85C pro hodnotu 370. To jsou typické hodnoty, ale je třeba to kalibrovat. Při kalibraci jednim bodem se dosahuje přesnost +-10C. Dvoubodova kalibrace dává lepší přesnost. Je to popsané v datasheetu na straně 133.

Pri pripojení na Lion sú tie hodnoty vyčítané z prevodníka stabilné, od 3.7 do 4.32 V
s chybou cca. 5 až 10 mV.
Skúsim to teraz nakalibrovať na LiFePO, ako sa to bude správať tam + pridám to meranie
teploty.

.
.
.
Tak na LiFePO to skáče viac ako na Lion, až o -10 až +10 mV.
https://www.youtube.com/watch?v=d-NeRHDPBso

Já jsem začal řešit "probouzení attiny" přes pcint a zároveň přes watchdog, ale je to na mě moc...
našel jsem tohle: https://github.com/SlashDevin/NeoSWSerial ale nějak nevím jak dál, aby přerušení fungovalo i pro RX data i pro probuzení procesoru. Nějakej nástřel kódu by mě dost pomohl...
Další problém je asi použití watchdog timeru pro probuzení attiny (třeba po 4s) a zároveň jako watchdog reset, třeba po 8s, je to vůbec u AVR možný takhle použít?