Pokračujeme v diskusi o výrobě osvětlení lehokola i další DYI elektronice. Předchozí díly:
6. díl: http://www.nakole.cz/diskuse/16414-vlastni...
5. díl: http://www.nakole.cz/diskuse/15798-vlastni...
4. díl: http://www.nakole.cz/diskuse/15570-vlastni...
3. díl: http://www.nakole.cz/diskuse/14034-vlastni...
2. díl: http://www.nakole.cz/diskuse/12599-vlastni...
1. díl: http://www.nakole.cz/diskuse/10771-vlastni...
A související témata:
PWM pro výkonné LED diody: http://www.nakole.cz/diskuse/12574-pwm-pro...
Napájení LED z dynama: http://www.nakole.cz/diskuse/4569-napajeni-led...
LED diody: http://www.nakole.cz/diskuse/251-led-diody.html
K tomuto příspěvku z předchozího dílu:
http://www.nakole.cz/diskuse/16414-vlastni...
Postup uspávání je popsaný v dokumentaci avr/sleep.h:
http://www.nongnu.org/avr-libc/user-manual...
sleep_cpu() se musí volat se zakázanými přerušeními. Pokud to není uvozeno podmínkou, je jednodušší volat sleep_mode().
Já mám v kódu zhruba toto, což až na ten BOD odpovídá tomu příkladu z dokumentace:
http://www.fi.muni.cz/~kas/git/?p=bike-lights...
cli();
if (TIMER1_IS_ON()) {
set_sleep_mode(SLEEP_MODE_IDLE);
} else if (adc_is_on) {
set_sleep_mode(SLEEP_MODE_ADC);
} else {
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
}
sleep_enable();
// keep BOD active, no sleep_bod_disable();
sei();
sleep_cpu();
sleep_disable();
Jsem asi trochu mimo.
Proč to set_sleep_mode() voláš před každým uspáním? Nestačí to zavolat jen když chceš ten spánkový režim změnit
sleep_mode()? Jak pokud není uvozeno podmínkou?
Já mám kód takhle:
void sleep(void) {
do {
cli();
interrupt = INT_OK;
sleep_enable();
sei();
sleep_cpu();
sleep_disable();
} while(interrupt != INT_OK);
}
Ještě před nedávnem tam nebylo to zakázaní přerušení. Přerušení od WDT a ADC do proměnné interrupt nic nezapisuje, USI ano.
Protože si nechci hlidat všechny místa, kde by se mohl změnit důvod pro spánkový režim. Tak to radši zkontroluju vždycky před usnutím, a příslušným způsobem nastavím. Ale jinak ano, tohle by šlo udělat i tak jak píšeš.
Podmínku myslím něco, co určuje,jestli usnout nebo ne. Třeba bys měl nějaké přerušení a v handleru bys nastavoval nějaký příznak, který by ti v hlavním programu řekl, že máš něco zpracovat, a ty bys to nezpracoval a usnul. Tak se udělá
cli();
if (mám_něco_zpracovat) {
sei();
goto out;
}
sleep_enable();
sei();
sleep_cpu();
sleep_disable();
out:
K tomu tvému: podle mě to je furt špatně - ta podmínka toho while cyklu by měla být taky se zakázaným přerušením. Jinak se ti stane, že otestuješ podmínku, vlezeš do další iterace, přijde přerušení, které změní proměnnou, a ty teprv pak zakážeš přerušení a přepišeš tu proměnnou interrupt (čili přijdeš o tu hodnotu kterou tam mohla ta obsluha přerušení dát.
Takže bys to řešil pomocí atomic bloku s nonatomik sekcí uvnitř? Předpokládám s parametry ATOMIC_FORCEON
a NONATOMIC_FORCEOFF.
Já myslím že stačí to udělat tak jak jsem psal, jen pomocí sei() a cli(). To celé co jsem psal zavři do while(1) a udělej z toho cyklus s ukončením uprostřed (to goto out). Podstatné je, aby ten test na hodnotu interrupt byl v nepřerušitelné sekci spolu s tím následným usnutím i s tím nastavením proměnné. Možná nějak takto:
while(1) {
cli();
if (interrupt == INT_OK) {
sei();
goto out;
}
interrupt = INT_OK;
sleep_enable();
sei();
sleep_cpu();
sleep disable();
}
out:
(je to z hlavy, možná tu podmínku mám naopak, ale takhle nějak).
Nějak to vyšpekuju. To goto nahradím brake. Ale až ráno, teď jsem úplně mrtvej.
Jo, jasně. Z cyklu break, ze složitější konstrukce goto.
Žádní goto! Nikdy.
Víš co, já programuju přes 20 let, a ještě kdysi na gymplu nás externě učil programovat jeden docent blahé paměti z MU, a ten říkal: "oni ti teoretici vám pak budou vysvětlovat jak je goto zlé, ale řeknu vám, jedno takové dobře umístěné goto dokáže krásně zpřehlednit kód". A měl pravdu.
Samozřejmě nesmíš používat goto místo cyklů nebo náhodně skákat po kódu sem a tam, ale třeba jako ošetření výjimky v C je goto skvělé, protože s sebou nemusíš do všech vnořených cyklů a podmínek tahat i test na ten chybový stav. Nebo pěkně je to vidět ovladačích v kernelu - tam často alokuješ různá přerušení, datové struktury a podobně, a musíš být připravený na to, že když to někde v půlce selže, musíš ty věci které jsi dosud naalokoval zase v obráceném pořadí odalokovat. Tak abys neměl nekonečně vnořené ify se dělá něco jako
init()
{
if (!(dev=allokuj_zarizeni))
goto err_dev;
if (!(irq =alokuj_preruseni))
goto err_irq;
if (!(data = alokuj_data))
goto err_data;
... vlastni inicializace ...
return OK;
err_data:
uvolni_preruseni(irq);
err_irq:
uvolni_zarizeni(dev);
err_dev:
return -ENODEV;
}
Treba tady:
http://git.kernel.org/cgit/linux/kernel/git...
To výše uvedené goto pro vyskočení z cyklu je samozřejmě špatně - vzniklo to tím že jsem přepisoval ten původní kód který v sobě neměl cyklus. A tam by záleželo na tom, jak vlastně to zpracování vypadá. Proto jsem tam dal obecné goto. Kldině tam mohl být třeba return z aktuální funkce nebo ten break z cyklu podle použití.
Jsem se zase rozkecal.
Udělal jsem to takhle. Pokud mi tam překladač nepřehodí pořadí instrukcí, mohlo by to fungovat.
void sleep(void) {
cli();
do {
interrupt = INT_OK;
sleep_enable();
sleep_bod_disable();
sei();
sleep_cpu();
sleep_disable();
cli();
} while (interrupt != INT_OK);
sei();
}
Jo, to by mělo fungovat. Když už se bavíme o čitelnosti kódu, přijde mi do ... while o dost méně čitelný než while(1) s opuštěním uprostřed. Navíc u toho opuštění uprostřed bys rovnou mohl mít return, když to celé je jedna funkce, která nic dalšího nedělá. Ale to je asi individuální.
Kompilátor ti nic nepřeskládá -- cli() i sei() jsou definované jako __asm__ __volatile__. To je myslím základní vlastnost zamykacích primitiv, aby byly definované tak, aby je kompilátor nemohl pokazit (i když si vzpomínám na problém na SGI Altixu, kde jsme museli opravovat driver SCSI řadiče, protože zamykací primitiva zamykaly proti přeskládání přístupů do paměti, ale už ne proti přeskládání toho co jde po PCI sběrnici - musela se tam doplnit I/O bariéra).
To sleep_bod_disable() ti na tiny 461 funguje? Mně to překladač nežere.
Já mám 861a, a funguje (používám jen při vypnutí světel, protože po zapnutí zas všechno nainicializuju znovu, takže brownout mi až tak nevadí. Kdyžtak se podívej do výše odkazovaného zdrojáku, jestli ti tam oproti mému nechybí nějaký #include.
Nějak furt nemůžu vyladit senzor osvětlení. Mám problém s příliš rychlým přepínáním režimů. Jak chci aby to fungovalo:
- 4 zóny: plné denní světlo, zamračeno/podvečer, večer/noc s veřejným osvětlením, úplná tma
- dostatečně rychlá reakce (například při vjezdu do tunelu nebo při opuštění vesnice s veřejným osvětlením)
- dostatečná "hystereze", abych třeba při jízdě alejí, kde se střídá světlo a stín, nepřepínal režimy 2x za vteřinu
Implementace:
- měřím ADC 16x za sekundu, vždy dvě měření po sobě a beru jejich součet
- z tohoto dělám running average (jak je to česky?) s posunem o 2 bity: value += adc_value
- (value >> 2); Což by mělo zajistit reakční dobu 1/4 sekundy.
- výše uvedené 4 zóny jsou definovány svou minimální a maximální hodnotou (kde minimum "jasnější" zóny je o kousek níž než maximum nejbližší "tmavější", právě kvůli té hysterezi. Ten překryv ale nemůžu už zvětšovat, jinak to nepřepínalo ani když už bych to přepnutí očekával (například v podvečer jedno povyjetí na slunko stačilo k zapnutí nejjasnější zóny, ale zpět už se to nepřepnulo, dokud jsem třeba nevjel do lesa).
- teď jsem ještě doimplementoval, že pokud přepnu zónu například dolů, tak nejbližší přepnutí zóny zpět nahoru může nastat nejdřív za 4 sekundy (a podobně opačným směrem).
Přesto to přepíná příliš často - teď jsem jel po městě, bylo zataženo, a v podstatě co 4 a kousek vteřiny to oscilovalo mezi nejjasnějšími dvěma zónami.
Jaké další triky byste použili, aby ten systém nepřepínal příliš často, ale přitom měl dostatečně rychlé reakce například na vyjetí z vesnice do tmy?
Že to oscilovalo mezi nejjasnějšími režimy, znamená, že to měnilo intenzitu předku, nebo ještě něco jiného?
Já má přepínání intenzity předku podle rychlosti udělané následovně. Venkovní procesor měří tiky mezi průletem magnetu, je tam running average (já bych tomu spíš říkal low pass filtr). Pravidelně se posílají zprávy tomu vnitřnímu MCU, rychlost se počítá při generování zprávy. Vnitřní MCU nezmění intenzitu okamžitě, ale celkem pomalu a plynule. Hodnota pwm pro daný proud se ukládá, ale pouze pro účely přepínání mezi dálkovnou/potkávačkou, kdy chci přepnout okamžitě. Úrovní mám, myslím, 12, jsou tak daleko od sebe, že se i s tolerancí nepřekrývají.
Za jízdy není běžně změna režimu vůbec vidět. Když prudce zabrzdím z velké rychlosti, tak je vidět plynulé klesání, trochu opožděné. To samé, když hodně zrychlím z nuly.
No, měním intenzitu všeho, přičemž standardní blikání mám 2x jasně, mezera, 2x slaběji. Takže dokonce dvě intenzity na každý režim a světlo (i zadní, na plném světle chci svítit víc). Režim úplná tma navíc přepíná na souvislé svícení místo blikání předku, a vzadu místo krátkých záblesků má souvislé svícení s krátkými zhasnutími, aby bylo z auta za mnou víc vidět, kde vlastně jsem.
Napojení na tachometr je zajímavý nápad, ale já asi chci ve městě intenzivně blikat, i když stojím nebo jedu pomalu. Myslím že upravovat to podle rychlosti by se hodilo hlavně v noci.
No ale hlavně já po změně zóny osvětlení restartuju blikání, takže když restartuju příliš často, není to takové to pravidelné blikání. Zóna osvětlení se mi zobrazuje i na LEDce osvětlení tachometru: dva světlejší režimy se ukazují počtem bliknutí, dva tmavší trvale svítí a ukazují se počtem krátkých zhasnutí. Takže pro účely ladění přesně vidím, kdy dochází k přepnutí režimu.
Na noc je ta regulace podle rychlosti skvělá, přijde mi, že to šetří baterku.
Jak chci vlastně svítit ve městě jsem se ještě nerozhodl, protože občas potřebuji stálé světlo, abych viděl, občas by stačilo i slabé blikání, když jsou lampy.
Já na tohle mám přepínání tlačítkem mezi režimy "chci svítit víc" a "chci svítit míň". V nočním režimu to mění jas, v denním to přepíná mezi "2x slabě, mezera, 2x silně, mezera" a "1x slabě, mezera". Mimo silnici ve dne nebo do kopce v noci zapínám ten slabší, jinak ten silnější. Ale zjistil jsem, že v noci v zásadě silné světlo nepotřebuju - když je úplná tma, oči si zvyknou jak na silnější, tak na slabší režim dost podobně.
Zajímavé. Já mám ten rozsah od cca 65 lm pod 10 km/h do cca 500 lm nad 55 km/h. A rozhodně si nemyslím, že bych na ten nejslabší režim byl ochotný jet třeba i 20 km/h
Tak zas v rámci objektivity musím přiznat, že vlastně pokud jsem teď párkrát jel v úplné tmě přes 50 km/h, bylo to vždycky po silnici, a tedy jsem měl ten silnější režim, což je 500 mA. Někdy si tam pokusně dám silnější, ať vidím jestli je to rozdíl.
Ale do kopce je fakt jedno, jestli jedu 250 mA nebo 500 mA (na XM-L U2).
Kdyz to tak ctu, jen si rikam, jak skvele mi funguje tlacitko na riditkach. Ten pohyb palcem prilis namahy nestoji, neprepina se to kdyz nechci a stejne akorat ja vim, jaky rezim chci zrovna pouzit.
Cim dele to takhle mam, tim vic jsem presvedcen, ze by to zautomatizovat byl problem. Copak zadni svetlo, tam je v dusledku skoro jedno, jak zrovna blika, ale spravne zhodnotit predni, to uz je orisek. Podle me by senzor rozhodne musel mirit dopredu, protoze kdyz vyjizdim z obce, tak na me jeste chvili zezadu sviti lampy a ja pritom koukam do tmy.
Vyhodnocovat rychlost je zajimava myslenka, jenze ja silny svetlo potrebuju nejenom, kdyz se nekam ritim vyssi rychlosti, ale predevsim v mistech, kde je silnice sama dira a ja tam jedu krokem.
Dalsi komplikaci by bylo misto (kudy jsem behem 24hod jel 48 krat), kde je na budove silne svetlo, ktere sice silnici neosvetli, ale v jednom miste dost oslnuje... takze ja jsem si potreboval prisvitit abych silnici vubec videl, zatimco cidlo by mozna dokonce zhaslo, protoze by na nej svitilo svetla dostatek. Navic ja jsem svetlo prepinal s predstihem, zatimco sebelepsi automatika by mela nejake zpozdeni.
Dalsi komplikace, co me napada je dest. Aspon ja na mokre silnici (s mokrym svetlem) potrebuju vetsi vykon, jak takovou situaci detekovat, netusim.
Takze nevim nevim, jestli je realne vychytat automatiku natolik, aby praci setrila a nepridelavala... :)
Já jsem vypozoroval, že v podstatě není šance, aby nějaké umělé osvětlení generovalo větší světlo než slunko ve dne. Takže nehrozí že by řídící jednotka považovala umělé osvětlení za den.
Mokrá silnice se řeší sama od sebe, aspoň v mém případě, kdy je senzor namířený dolů: mokrá silnice tolik neodráží světlo, takže se automaticky považuje za tmavší.
Ale jinak jo, mám tam ke každému režimu ještě tlačítkem ovládané dva stavy: svítí míň a svítí víc. Asi by nebyl problém to v nočních úrovních osvětlení upravit na tři stavy (v úplné tmě tři úrovně jasu, ve skoro tmě něco jako bliká málo, bliká hodně a svítí souvisle).
Ale jinak jo, je problém to vychytat, a nevidí to do budoucnosti. Ale zase furt lepší než standardní blikačky se sedmi nebo kolika režimy, jeden horší než druhý.
Tak dulezite je, zda ti to v dusledku praci setri nebo pridelava. Respektive zda ti to jako celek vyhovuje. Ja totiz nekdy mivam problem si priznat, ze vyvinute reseni moc pouzitelne neni a nechci se ho vzdat, kdyz uz me stalo tolik prace... tak aby to nebyl podobny pripad... ;)
Tak standardni blikacka, kdy clovek pokazde musi promackat vsechny rezimy, aby to mohl vypnout, je kazdopadne jiny level. Ja mam pro den 2 rezimy, pro noc 3 a pripada mi to akorat, i kdyz nejvetsi vyhodu proti beznym svetlum vidim v tom tlacitku na riditkach.
Ono kdyz obcas necham svitit vetsi vykon nez by v danem miste bylo nutne, tak se nic zleho nestane, ale kdyby se mi svetlo zacalo nesmyslne prepinat v okamziku, kdy proste potrebuju videt, to by vadilo...
Akorat bych mel casem jeste vyresit moznost volby nejakeho neagresivniho souvisle sviticiho zadniho svetla, abych za rok potreboval jen dve vyjimky misto tri... :)
Mokrý asfalt je dobrý argument, to jsem zatím nevyřešil a řešit asi ani nebudu. Další argument je oslňování protijedoucích a společníků přes zrcátka. To už jsem vyřešil. Přepínačem na řidítkách můžu zapnout slabý režim, cca 20 mA, který by oslňovat neměl.
Ta regulace podle rychlosti mi přijde skvělá. Nemusím vůbec myslet na přepínání režimů. Zároveň mi přijde, že to zvyšuje výdrž na baterku. Dřív jsem často zapomínal přepínat na slabší režim a nebo ten slabý byl zase moc slabý.
Je fakt, ze regulaci svetla podle rychlosti melo v dusledku kazdy svetlo na dynamo a prislo mi to docela dobre (samozrejme do okamziku, kdy clovek zastavil), takze na tom asi neco bude. Navic je dobry napad, ze intenzitu menis plynule, to odstranuje riziko, ze se svetlo bude z nejakyho duvodu prepinat mezi dvema urovnema sem a tam, coz by mi vadilo opravdu hodne.
Chvili jsem ted premyslel, co by mi snimac rychlosti prinesl, celkem smysluplne se treba jevi prepnuti na slabsi rezim, kdyz zastavim, ale uz jsem zase vymyslel situace, kdy muzu chtit rozsvitit na maximum i kdyz stojiim na miste, takze jedine vylepseni, o kterem budu v dohlednu premyslet, jsou brzdova svetla....
Rozsvícení na maximum při zastavení je asi potřeba hlavně u zadního světla, a to ve většině případů řeší ten brzdový senzor.
K ostatnímu, ať příliš nerozvětvuju diskusi:
Já samozřejmě mám možnost i manuálního nastavení režimu, ale chtěl bych to zkusit dotáhnout do stavu, kdy to bude "dostatečně dobré" i automaticky- Předvídat budoucnost to samozřejmě nebude umět. Moje auto to při vjezdu do tunelu taky neumí, ale ta krátká prodleva nevadí, a přínos v pohodlí, že nemusím myslet na zapnutá světla, je fakt velký.
Udělal jsem to teď tak, že měřím dva running average: jeden jak jsem psal výše, a druhý ještě 32x pomalejší (průměr za cca 8 vteřin). Pokud z toho rychlejšího vypočítám změnu o víc než jednu zónu, provedu přepnutí. Pokud bych měl ale přepnout zónu jen o jednu nahoru nebo dolů, zkontroluju ještě, jestli ten pomalejší running average ukazuje taky na novou zónu. Pokud ne, nechám současnou, a počkám až jestli do nové zóny dokonverguje i ten pomalý, anebo naopak jde jen o chvilkový výkyv typu alej, a ten pomalý zůstane tam kde je. Výsledkem je, že na velké změny reaguju hned, a na malé změny až pokud se fakt potvrdí v delším čase.
Že by mi světlo začalo blikat pokud bych chtěl svítit se mi fakt nestalo - v této oblasti je měření dost stabilní a funguje - rozdíly jsou fakt velké. Pro představu: fotoodpor mi vrací hodnoty od 0x0C5 do 0x33B (to při svícení přímo na něho; při namíření dolů jsem naměřil nejvíc 0x30C). Hranice jednotlivých zón jsou zhryba 0x250, 0x2E0 a 0x300 plus nějaká hystereze kolem. Takže v nejtmavší oblasti ty změny jsou fakt velké, a poznat spolehlivě kdy už je tma není problém. Co je trochu problém jsou ty dvě nejjasnější zóny, protože tam reálně ta úroveň osvětlení světlo/stín fakt osciluje.
Tuhle diskusi tady vedu spíš proto, že mě "z estetických důvodů" vadilo příliš rychlé přepínání mezi nejjasnějšími dvěma režimy ve dne (což ze sedadla ani nepoznám, pokud bych se nekoukal na stavovou LEDku :-)
Světlo na dynamo svítí podle rychlosti jenom při drápání se do kopce.
Co mám na Oceláči 3 LED v sérii, v podstatě přímo z dynama, tak asi od 15 km/h už to svítí prakticky stejně a to je tam potřeba aspoň 10 V. (Automat na Azubu od 15 km/h začne teprve přidávat.)
Regulaci podle rychlosti dynama jsem nechtěně vytvořil při realizaci "úsporného režimu" zapojením kondenzátoru 10 uF do série s dynamem. Kolem 30 km/h tam sice teče míň než polovina proudu a jde to lehčeji, ale nad 50 už je to i trochu víc než bez kondenzátoru, protože je to závislé na měnícím se kmitočtu a průběhu napětí. Účinnost je v celém rozsahu horší. Je to použitelné jakž takž ve dne, v noci jsem si už zvykl, že to svítí pořádně.
Tak jsem teď zjistil, že pokud chci ATMega8 uspat hlouběji než do IDLE a mít zapnutý timer 2, je potřeba externí krystal 32,768 kHz.
V jeho datasheetu se píše: handle the crystal carefully, it cannot stand heavy shock
Tak si říkám, že to není úplně vhodná součástka na kolo. Co si o tom myslíte vy?
Ono mi to totiž žere cca 5 mA, což se mi úplně nelíbí.
Tenhle krystal je v každých hodinkách (kromě natahovacích) a jinak skoro všude. Když se podělí 2^15, vyjde 1 Hz. Že by nesnesl otřesy, o tom jsem nevěděl. Snad kdyby se s ním mrsklo o něco tvrdého, tak by to mohlo vadit. Je fakt, že vadných jsem měnil spoustu, ale hlavně ve stolních přístrojích.
Dát ho do nějaké pěny asi není problém, ale i tak si říkám, že by dostával na kole celkem velké rány.
Cestou z práce jsem si vzpomněl, že mě to nenapadlo hned: Je úplně v každém cyklokompjůtru. A obvykle ten nejlevnější typ, s drátovými vývody. Aby se o něco neklepal, někdy se pouzdro přilepí k desce nebo za konec připájí. Ale to už prodražuje výrobu.
Co jsem pochopil, tak ten 32,768 kHz krystal se nedá vyrobit moc malý. Doopravdy se tam používá tenhle?
Myslim, ze zrovna tenhle krystal se pouziva na svete nejcasteji. Pokud ma neco merit cas, skoro vzdycky je to tahle frekvence.
V nejakem zapojeni uz jsem ho taky planoval pouzit pro casovac, aby mel procesor informaci o case a pritom skoro nic nezral, ale pak z toho seslo, takze prakticke zkusenosti zatim nejsou.
Navic by podle tohohle casovace slo dokalibrovavat interni oscilator.
Na novejsich ATmegach je jeste alternativa probouzet se prerusenim od Watchdogu, ale tam uz se o presnem case mluvit neda.
Na probouzení watchdogem jsem zvyklý. Zjištění, zě to u nejakého AVRka nejde bylo celkem nepříjemné. Boj s timerem 2 byl na celé odpoledne. On se totiž musí ten porovnávací registr musí nastavovat až po těch ostatních, což jsem nevěděl.
Na probouzení watchdogem jsem zvyklý. Zjištění, zě to u nejakého AVRka nejde bylo celkem nepříjemné. Boj s timerem 2 byl na celé odpoledne. On se totiž musí ten porovnávací registr musí nastavovat až po těch ostatních, což jsem nevěděl.
No protoze na to jdes opacne. Kdybys nejdriv poznal ATmega8 a teprve potom se seznamoval treba s 88PA, byl bys nadceny, co vsechno je tam navic.... ;)
Ja davam procesor zasadne do patice, takze upgrade na PINove kompatibilni procesor (nebo zmena velikosti) by nebyl problem. U SMD je to trochu pracnejsi...
Premyslim, jestli je neco, co by ti teoreticky branilo jeste pouzit treba 168PA, mela by umet vsechno a ledacos navic, akorat jsou tam kosmeticke zmeny v nazvech regitru, ale mam pocit, ze tam byl podstatny rozdil v interni referenci pro ADC, to by mohlo vyzadovat i nejakou zmenu v zapojeni. :-/
Mně v použití ATMega 168 brání jenom to, že ta mega 8 už je tam připájená, funguje to a nechce se mi vydávat další peníze na světlo na kolo. Ve venkovním MCU ADC vůbec nepoužívám. A spotřeba 0,8 mA mi přijde celkem akceptovatelná.
Nakonec je lepší, že mi časování běží na timeru 2, protože 16 ms je pro PWM stmívání ledek nepoužitelné. Mám kontrolky udělané intenzitou na den a na noc jedou na 1/2 SW PWM.
To jsem se nedávno také divil, že ta ATMega328P, co mám v SEEEDUINU, má jen 1,1 V referenci, já jsem zvyklej přemýšlet s 2,56 V a to mně při nákupu rezistorů teď celkem vypeklo.
Napadá mně takové otázka. Bude měření ADC s 20-ti násobným zesílením stejně přesné vůči referenci 1,1 V jako při 2,56 V? Ta tiny 461 má obě. Použití nižšího napětí reference by umožnilo nižší ztráty na měřících rezistorech.
FWIW, já používám na Tiny861a měření s 1.1V referencí. U předního světla přímo, u ostatních dvou s 20x předzesílením. Měřící odpor 0R033 je na to přední světlo příliš malý (na nejnižší proud 150 mA reguluju někam k hodnotě ADC 4 nebo 5, což už je fakt málo a není to moc stabilní, na vyšší proudy je to ale OK). Ale zato na 1.5 A protopím na tom odporu pouhých 0.074 W.
Tak jsem zjistil, kde byl zádrhel a proč to žralo víc, než se píše v datasheetu. Měl jsem tam 6 nohou volných bez nastavení. Tak jsem jim zapnul pull-up rezistory a ono to najednou žere o 3,5 mA míň. Takže s nějakými dalšími drobnými úpravami 0,8 mA, což už považuji za dobrou hodnotu a na krystal kašlu.
Jaké máte zkušenosti s tolerancemi různých vlastností součástek? Já jsem teď namontoval druhou řídící jednotku světel na manželčino kolo, a podle všeho ukazuje senzor osvětlení o dost jinak než na mém kole - co u mě ukazuje ADC jako 0x304, na tom druhém kole je cca 0x318. Je to stejná deska ze stejných součástek, většina ze součástek je dokonce kupovaná dohromady, čili by snad měly být i z té stejné série.
Ještě jsem neměřil úrovně napětí (nechce se mi to zas vymontovávat), ale podezírám rozdíly v interní napěťové referenci ATtiny.
Jakou máte zkušenost vy?
No az se podivas do datasheetu na presnost interniho Vref, tak zjistis, ze tvoje odchylka cca 2.5 % na celem obvodu je naprosto paradni vysledek. :-D
Aspon u ATtiny85 jsem nasel tohle:
1.1V = 1.0V .. 1.2V
2.56V = 2.3 .. 2.8
Coz je taky odpoved na otazka, ktera z referenci je presnejsi. Teoreticky 1.1, ale jen malinko, u obou je mozna odchylka az 10%.... :)
Doporucoval bych dat do firmware/eepromky nejakou kalibracni konstantu, to vyjde nejlevneji. Pokud mas Vref dostupny na PINu, tak ho muzes zmerit voltmetrem.
Jo, tolerance z datasheetu jsem četl. Akorát mě zajímalo, jestli opravdu reálně jsou takovéto odlišnosti i v rámci jedné série.
S tou EEPROMkou to musím nějak vymyslet. Pokud je fakt problém s tou interní referencí, pak bych asi podle toho měl přepočítávat všechno, co měřím přes ADC. Od proudů LEDkama pře senzor napětí baterek až po ten fotoodpor. U těch proudů to není až tak kritické, ale u těch baterek už možná ano - snažím se vyhodnocovat zbývající kapacitu podle vybíjecí křivky, a kolem toho inflexního bodu jsou úbytky napětí docela malé při docela velké výdrži.
S EEPROMkou bych potřeboval nějak vymyslet, jak v Makefile nepřepsat celou - jakože bych měl zvlášť příkaz pro přepsání té části EEPROM, kterou používám pro EEPROM proměnné závislé na konkrétním buildu, a zvlášť pro přepsání té "konfigurace". Abych jako při programování nemusel řešit "teď programuju desku číslo 1" a "teď programuju desku číslo 2", ale poznalo se to nějak samo a bylo to blbuvzdorné.
Jestli mas dve desky, bylo by nejjednodussi si do EEPROM jednorazove zapsat vyrobni/evidencni cislo a podle toho si vybrat konfiguraci v programu. :)
Pokud jich planujes vice, tak by v eeprom mely byt vsechny HW zavisle informace, ktere bys tam zapsal jednou a pak vzdy prehraval jen firmware (pojistka EESAVE nebo tak nejak, aby se eeprom pokazde nesmazala).
Jestli chces modifikovat obsah eeprom pri behu make, asi nejuniverzalensi by byl nejaky vlastni ceckovy programek, ktery by modifikoval bud vysledny eep soubor nebo treba generoval ceckovy soubor, ktery se pak teprve zkompiluje (to by pak slo i skriptem).
V datasheetu mas vyrobcem garantovane rozmezi parametru. Jake hodnoty se v praxi vyskytuji, je samozrejme otazka. Ono tady nepujde jen o odchylky jednotlivych kusu, ale treba zavislost na teplote, napajecim napeti, stari a nevim cem jeste...
A hlavne nemusi jit jen o rozdily v procesoru, ono treba i odchylky 1% odporu se muzou nesikovne poscitat...
Hmm. Koukám, že jestli se pustím do vylepšování měření proudu u světel, že budu muset udělat hned dvě vylepšení.
Nepřesnost při měření se zesílením odstraním externím zesilovačem a měřením v single ended modu a nepřesnost referenčního napětím odstraním externí přesnou referencí.
Samozřejmě si to dělej jak uznáš za vhodné, ale podle mého názoru tak jak to navrhuješ je to zbytečné. Ta jedna součástka sama o sobě nijak nepřesná není (aspoň jsem to nepozoroval), a pokud ti jde o jeden vyrobený kus, tak rozdíly mezi součástkama nemusíš řešit. Toto je podle mě přesně problém na řešení v softwaru, nikoliv v hardwaru.
Pokud takovou presnost opravdu potrebujes, urcite je to moznost. Nicmene z meho pohledu zrovna u svetla, pokud se nepohybujes vylozene na hranici povoleneho proudu, odchylku 10% ani nepoznas... ;)
Vzdycky to bude kompromis a vetsi presnost tak zaplatis slozitosti, casem vyvoje, cenou, rozmery a mozna i spolehlivosti.
Pojal jsem myšlenku postavit si čelovku na jednu lithiovou baterku (asi 18650). Předpokládám že by šlo o jeden step-down, chtěl bych to mít řízené procesorem. Jak byste to dělali?
Jedna možnost je P-MOSFET na high side a dioda pro low-side. Jaké jsou nevýhody diody ve step-down měniči? Je úbytek napětí na diodě významný pro účinnost celé věci?
Druhá možnost je dvojice N-MOSFETů, ale tam asi pořád potřebuju nábojovou pumpu na sepnutí high-side (je to tak, anebo stačí spínat napětím CPU?).
Potřebuje procesor stabilizované napětí? Lithiový článek dává řekněme od 4.2 do 3.5 V, to by možná šlo napájet přímo bez dalších součástek, snad kromě odrušovacího kondenzátoru.
Máte k tomu nějaké poznatky?
Varianta p-mosfetu jen tak je nereálná, k němu bys potřeboval nějakou napěťovou pumpu. Dioda na low-side IMHO zvyšuje minimální rozdíl napětí mezi vstupem a výstupem. Na diodě ztratíš nejméně 0,3V, spíš víc. Zas na druhou stranu přes ní proud poteče jen malou část cyklu. Nikdy jsem to přímo neměřil.
Dvojice n-mosfetů se také neobejde bez napěťové pumpy, potažmo řídícího čipu. Já na to používám celkem drahý specializovaný čip. Nakonec ty také, jestli se nepletu.
Procesor stabilizaci napětí nepotřebuje, do těch 3,5 V by to mělo fungovat v pohodě.
Já osobně bych to asi postavil na specializovaném čipu pro řízení ledek s externím řízením intenzity pomocí PWM nebo napěťové reference. Ono totiž moje osvědčené (ale drahé a velké) řešení s ATTiny 461, mosfet driverem a dvěma n-mosfety potřebuje 5 V pro ten mosfet driver.
No právě. MCP14628 má doporučené napětí od 4.5V. Tak jsem si říkal jak to obejít.
Podle mě ale na P-MOSFET nepotřebuju napěťovou pumpu, pokud on sám je spínán napětím blízkým napětím na zdroji (což CPU bez stabilizátoru je). Myslím že Jrr to takhle má - jen P-MOSFET a diodu, protože jeho napětí baterky je 4.8V.
Ztráta napětí na low-side diodě je ale jen drobný nedostatek z hlediska efektivity, není to na překážku maximálnímu napětí, které z toho step-downu může lézt, ne? Jakože pokud budu mít baterku okolo 3.7 V a na diodě budu chtít mít okolo 3 V, nezpůsobí to žádný problém.
No a ten specializovaný čip pro řízení LEDek je třeba jaký?
No vida, jeste se na me nezapomnelo... :D
Jojo, na step-down pouzivam IRF9Z34N a jeho gate je pripojeny primo na PIN ATmegy.
Pri napeti 4.8V uz mi program vystrazne blika, ze baterka brzy dojde, vetsinou je tam vic. Z hlavy uz nevim kolik vychazelo maximalni napeti, ale pri nabijeni koncim okolo 6.2V a vse funguje, spodni hranice je kvuli bateriim 4V.
U me je procesor za stabilizatorem (nevim uz presne typ, ale nejaky MCP s min ubytkem a klidovym proudem pod 2uA), protoze by pri nabijeni asi dost trpel, ale kdyz napeti klesne pod 5V, uz se o zadne stabilizaci mluvit neda a zadny problem jsem nepozoroval. Klicovy bude kondenzator hned procesoru, idealne i nejaky LC/RC filtr, aby mu pulzy z menice prilis necvicily s napajenim...
U step-down (buck) muzes tranzistor trvale otevrit a pak bude napeti na vystupu pri pozadovanem proudu limitovane akorat ubytkem na tranzistoru a civce, tedy jejich odporem. U nizkych napeti tudis pozor, aby se ti uz mosfet dostatecne otevrel.
Snilard ma asi pravdu, z hlediska efektivity to optimalni nebude, ale vzhledem k tomu, ze mi to svetlo roky dobre slouzi, tak ja jsem spokojen. :)
No a když máš 6.2 V na baterkách, tak to ještě zvládá ten MOSFET zapínat, když MCU má jen 5V, a z nožičky možná leze ještě o kus míň?
Já jsem chtěl něco malinkého v SMD podobě (přecejen čelovka je něco jiného než osvětlení kola), a zatím si myslím, že bych použil IRLML6402:
http://www.ges.cz/sheets/i/irlml6402.pdf
Každopádně pokud bych to udělal z ATtiny45V nebo něčeho takového, tak by mělo na celou tu legraci stačit docela málo součástek.
Ještě přemýšlím, jestli by šlo udělat dostatečně rychlé přepínání intenzity přes fotoodpor: na poslední šifrovačce měl jeden člově v týmu nějaký Fénix, a v podstatě se s tím nedalo za chůze krátce pohlédnout do mapy - jak to světlo bylo nastavené na velkou intenzitu aby bylo vidět do dálky, tak při sklopení do mapy to docela dost oslnilo a člověk dalších několik kroků neviděl nic. Možná by šlo detekovat osvětlení a při sklopení hlavy k mapě by se ta čelovka mohla sama ztlumit.
Předpokládám že bych koupil z DX nějakou čelovku na 1x 18650 s Cree XM-L, tím bych měl vyřešenou mechanickou část, a jen bych do toho dal svoji elektroniku. Mám vymyšlené třeba to, že po zapnutí by se čelovka měla pustit na minimální intenzitu a ne na maximální, aby si člověk při zapnutí v úplné tmě omylem nevypálil oči. Nebo zrušit blikací režim, který všechny takové čelovky z DX úplně zbytečně mají implementovaný.
Problem neni zapnout, to se Gate proste uzemni, problem je naopak se zhasnutim. Pri urcitem napeti, uz nevim kolik to u me bylo presne, ale tipuju cca 7V, uz tranzistoru nestaci 5V na gate, aby zustal zavreny a predni svetlo se mi samovolne rozsviti... tak jsem to prohlasil za vlastnost a nazval to ochranou pred prepetim... ;-)
Tedy ja mam jeste na te nozicce obrovsky pull-up odpor na Vbat, aby svetlo bylo zhasnute, kdyz se vynda procesor nebo je v resetu, diky cemuz na te nozicce bude pri logicke 1 neco malo pres 5V (napeti omezuje ochranna dioda v procesoru).
Aha, chybka se vloudila :)
Tak mně napadá, jestli by k tomu p-posfetu na high-side dát na low-side n-mosfet. Některé ATTiny mají nastavitelný dead-time generátor, jen by se to muselo vylatit, aby nebyl zbytečně dlouhý a zároveň aby nedocházelo k překryvu. Možná by se tam musel dát ještě nějaký invertor signálu či jak se to jmenuje.
To maximální výstupní napětí při použití shottky na low-side je IMHO nižší, než při použití mosfetu, to jsem psal. Změřené to nemám, ale z teorie by to tak mělo být. To snížení max. napětí vlivem použití diody bude hodně záviset na střídě, která bude u tebe dost blízká jedničce, takže to ta dioda IMHO moc nesníží.
Každopádně bych si myslel, že pokud na low-side bude dioda, bude skok napětí mezi max povolenou střídou a stavem stále zapnuto vyšší, než když tam bude mosfet.
Těch čipů je mraky, zeptej se strýčka googla, nebo pohledej na farnellu, mají tam na to speciální kategorii.
Jestli se chceš dostat na co nejmenší rozdíl vstupního a výstupního napětí, snaž se snížit všechny odpory po cestě, ale to víš dobře sám i beze mně :) Já to na svém driveru měřil pro různé proudy, ale už nemůžu najít, kam jsem zapsal výsledky. Rozdíl 0,7 V by měl jít IMHO udělat, pokud použiješ cívku normálních rozměrů a ne nějakou mikro SMD.
Ano, nad N-MOSFETem na low-side jsem taky uvažoval, akorát nevím jak stanovit ten dead time (ATtiny25/45/85 dead time generátor obsahuje). MCP14628 to podle datasheetu přímo nějak měří, kdy už může sepnout druhý výstup.
Navíc teda ten invertor, to už je podle mě zbytečně moc komplikované.
Pokles napětí na diodě bude mít vliv na rozvlnění napětí, resp. na napětí ve fázi, kdy je high-side vypnutý. V té zapnuté fázi bude limit i nadále blízký napětí zdroje, ne? Navíc část z toho poklesu by měl vykrýt kondenzátor.
Hloupé je, že Schottkyho diody s mezním proudem nad 2 A a s malým poklesem napětí (pod 0.5 V) v SMD podobě u nás v podstatě nejde sehnat. Našel jsem tak leda tohle, a to je SMB, což je docela zbytečně velké:
http://www.ges.cz/cz/sk54-GES04913423.html
Máte nějaké jiné zdroje?
Nebo teda - jak jsem psal - použít N-MOSFET i jako high-side. Přemýšlím nad tím, jestli to může fungovat, nebo jestli na sepnutí high side bude třeba větší napětí než je na pinu drain.
Ten dead time by se asi musel nastavit nějak experimentálně.
S tím p-fet na high-side a n-fet na low-side bych viděl problém v tom, že pro ně potřebuješ souhlasný signál, zatímco ten dvojitý PWM výstup s dead-time generátorem produkuje invertovaný signál, jestli se nemýlím.
Ano, invertor to dost komplikuje. Nebo to nasimulovat pres OC1A a OC1B s tim, ze dead time by se pridaval jen v jednom smeru (asi zavirat low side driv nez otevres high side, ale tezko rict - podle datasheetu je zavreni pomalejsi nez otevreni).
Momentalni plan je mit nejdriv mechaniku (koupi celeho svetla z DX), a pak do toho vyrobit alternativni elektroniku, asi teda jen s diodou.
Ohledně té diody - něco takového mám ve step-downu pro SSC-P7.
Mám tady pár SK24, ty mají při 2 A kolem 0,45 V a při 1 A asi 0,38 V. Dát několik slabších diod paralelně není ve spotřebce nic neobvyklého. Pak taky jestli stačí schottky na 20 V, tak ta má při stejném proudu menší úbytek.
U snadného zdroje součástek na pokusy už nepracuju a slušnější obchod je už taky daleko, takže je občas problém.
Poslední vývoj: koupil jsem za necelých 17 dolarů tohle:
http://dx.com/p/lzz-186-600lm-1-cree-xm-l-u2-3...
Uvnitř je skutečně XM-L U2, optika vypadá použitelně, je to uchycené v kovovém obalu, takže s chlazením snad nebude problém (oproti fotkám na DX není ta optika uložená v černé části, ale ve stříbrné kovové (kovové je vše od čočky dozadu, co má válcový tvar). Držák na baterku je kdovíproč oddělen konektorem, a vypadá taky docela vodotěsně.
Co není vodotěsné je obal na driver (taková ta plochá oválná část do které vede kabel od baterky) - ten je z plastu a víko není zatěsněno žádným o-kroužkem. Víko drží na dvou křížových šroubech, z nichž jeden už měl při dodání strženou drážku, takže vyšroubovat šel velmi těžko.
Při pokusu přeostřit jsem ukroutil kabel k LEDce :-(, takže pak už nebyl důvod nevlézt dovnitř. Je to jednovrstvá deska s dvěma součástkami v pouzdře SOT-23 (asi tranzistory), jednou SOT-23-6 (asi řídící čip), a pak už jen nějaké odpory (odhaduju 1206). Pokud jsem dobře viděl, žádná cívka, žádné kondenzátory. Jak to může fungovat?
Místa je uvnitř docela dost, takže nějaký jednoduchý driver vlastní výroby by se mohl vejít. Uvidíme.
Napadá mně PWM hnané přes nějaký malý rezistor.
Schválně to světlo zkus natočit kamerou (klidně v telefonu) při malé intenzitě, mělo by tam být vidět blikání.
A nebo pak lineární řízení proudu.
Tak jsem to teda rozdělal ještě jednou, a je tam i jeden kondenzátor. Celkově tam je toto:
- dva SOT-23 čipy s označením A1SHB, zřejmě P-MOSFETy. zapojené paralelně (propojené G-G, S-S a D-D), asi jen kvůli maximálnímu proudu.
- Drain zapojený na + baterky
- Source zapojený na + LEDky
- 10K odpor mezi G a D, asi pull-up pro implicitní zavření těch P-MOSFETů.
- pak je tam SOT23-6 čip popsaný snad 103A, možná 1Q3A nebo 193A:
- jeden pin tohoto čipu propojený na Gate obou P-MOSFETů
- jeden pin na tlačítko
- jeden pin připojený přes odpor (doufám že je to odpor) označený "430" ale na desce popsaný "470R" na + baterky
- nejspíš ten stejný pin je ještě propojený kondenzátorem popsaným na desce "C106" k zemi
- propojená zem: LED-, baterka-, jeden pól kondenzátoru, jeden pól tlačítka
Tohle všechno dohromady dělá slabé svícení, silné svícení a blikání na nějakých maximálně 2.8 A.
Našel jsem zajímavý dokument s popisem toho, co všechno zohlednit při návrhu plošného spoje pro buck konvertor. V datasheetu MCP14628 sice taky nějaká doporučení jsou, ale tady je to podrobnější a názornější. Snad to bude k užitku i někomu dalšímu:
http://rohmfs.rohm.com/en/products/databook...
Na srazu mě inspirovalo obrázkové světlo do špic, co si na kolo montoval Láďa Bláha.
Tak jsem si říkal, že bych si něco podobného, akorát mnohem jednoduššího chtěl také udělat.
Pohrávám si s myšlenkou napájet to pomocí elektromagnetické indukce. Prodávají se světla, kde se do špic dají magnety a světlo na rámu má v sobě cívku. Já bych to rád udělal obráceně. Na rám magnety a cívky na světlo do špic.
Jenže vůbec nevím, jaký by se k tomu hodily magnety, jaká cívka a tak. Když si tu doma smotám z nějakého měděného drátu v bužírce jen tak cívku a šmrdlám kolem ní nějakým obyč magnetem na lednici, tak z toho víc jak pár mV nedostanu. Nenasměroval byste mě někdo?
Na srazu jsem nebyl - to byl takový ten jednořádkový řetěz který zobrazuje obrázek když se kolem otáčí? Něco jako
http://mashable.com/2013/05/27/monkey-light-pro...
http://www.youtube.com/watch?v=qRlr784qKEo
Já jsem nad tím přemyšlel, a podle mě by šlo mít to i jen na statické části kola s tím, že obrázek by vznikal jen za jízdy. Nemusel bys řešit napájení a tak vůbec. Třeba kdybys to dal na přední vidlici? Z každé strany jeden strip?
Zkoušel jsi googlovat "propeller clock"? U těch se obvykle používá zdroj ze sítě na nerotující části a přenos na rotující část trafem. Když to trafo navineš se souosými vinutími, sekundár se točí uvnitř nebo vně primáru, je jedno, jak se točí, na funkci trafa to nemá vliv. Už jsem víckrát uvažoval přenášet takhle elektřinu bezdotykově a bez mechanických odporů na rotující kolo. Určitě by šlo udělat bazmek, který by se chytnul třeba ke šroubům brzdového kotouče a primár k ose náboje, podobně jak u nábojového dynama bys jen odpojil kablík když potřebuješ kolo sundat. Otázka je "jen" jak to navinout (parametry cívek) a napájet (jakou frekvenci, jestli stačí obdélník...). Tohle by mi připadlo jako elegantní řešení, které by mi nevadilo na kole mít.
Pak mně ještě zaujalo tohle dynamo-světlo založené na vířivých proudech.
http://www.magniclight.com/MagnicLight/index...
To je neuvěřitelné, co lidi vymyslí! Přiznám se, vůbec netuším, jak to asi může fungovat, ta transformace vířivých proudů na použitelnou elektřinu. Nikdo ale neřekne, jestli jde víc energie do LED nebo do zahřívání ráfku. Vypadá to tedy dokonale.
Já bych si myslel, že kolem toho permanentního magnetu musí být namotaná celkem velká cívka, která využívá změny magnetického pole z těch vířivých proudů.
Docela by mně zajímalo, jaké z toho můžou lézt výkony, jestli to budou prodávat někdy jenom jako dynamo a za rozumnou cenu, tak bych to rád vyzkoušel.
Z cívky ale nemůže jít stejnosměrné napětí. Pokud by mělo být střídavé, tak kde vznikne ta frekvence? Snad jedině širokopásmový šum.
Chtěl jsem ještě za světla posekat zahradu, ale tohle bylo silnější.
Mám tady neodymový magnet z repráčků, co jsem kdysi vozil na klasice, má i pólový nástavec a takovou misku, tak jsem do něj namotal pár závitů drátu a připojil osciloskop. Do 12V mikrovrtačky jsem dal hliníkový kotouček, určený k tomu samému pokusu tak před 50 lety z Merkura Elektro.
Přiblížením magnetu asi na 1 mm k roztočenému kotoučku blízko jeho obvodu se vrtačka zatížila přes 80 W a kotouček se pěkně zahříval. To se dalo víceméně čekat. Pokud by to nebrzdilo, něco by nebylo normální. No ale z cívky - nešlo vůbec nic.
Možná by se místo pokusů dalo o tom něco dohledat, ale není lepší nechat se fascinovat kouzelníky, než se vždycky snažit najít vysvětlení? Asi jo.
Podle mě řešení je skryté v tom, jak se to chová v nízkých otáčkách (LEDky střídavě a nepravidelně blikají) a vůbec že jsou tam ty LEDky dvě.
Podle mě uvnitř bude rotující část s něčím takovýmto:
http://www.youtube.com/watch?v=FVkFNtLXjV4
akorát to nebude zapojené na klasické dynamo, ale bude to zpřevodované na rychlé protočení permanentního magnetu uvnitř cívky, podobně jako měla ta světla, která využívala magnetu ve výpletu. Při malých otáčkách to jen občas udělá protočení toho magnetu, takže to krátce a intenzivně blikne. Při velkých už to bude stíhat točit furt.
A dvě LEDky zapojené antiparalelně, aby požraly výkyvy napětí oběma směry.
Jak by se choval ten tvůj magnet, pokud bys ho nechal volně viset vedle kotouče? Měl by tendenci se otáčet jako to dynamo na výše odkázaném videu?
A kouzlo je pryč. No vypadá to logicky. Otáčející se kotouček při pokusu strhává magnet s sebou, sice menší silou, než kdybych ho brzdil mechanicky, ale tahle síla může stačit k roztočení malého dynamka uvnitř. To se zdá najednou až moc primitivní. Že ledky střídavě blikají, to jsem si všiml, je to hlavně stroboskopickým jevem při snímámí, skutečná rychlost blikání bude vyšší.
OK, je čas na pokusy. Vypůjčil jsem si od dětí tyčinku z Geomagu a kolo :-), postavil kolo na řidítka, roztočil přední kolo a přiblížil k němu jeden pól tyčinky,kterou jsem držel v ruce. Stalo se to, že magnet mi v ruce periodicky "škubal" zřejmě směrem k ráfku nebo možná trochu ke středu kola. A to docela silně. Čím větší otáčky, tím větší frekvence škubání. Ventilek magnetický nemám.
Zřejmě ty vířivé proudy tečou nějak nerovnoměrně nebo nějak chvíli přetrvávají a nerovnoměrně se sčítají. To škubání by asi rovnou šlo nechat v cívce přeměňovat na napětí. Nebo možná rovnou sbírat z toho ráfku cívkou. Jak tam taková nerovnoměrnost může vznikat?
Tak jsem to taky vyzkoušel, celkem u šesti ráfků. U všech docházelo ke škubání přesně naproti ventilku, kde je ráfek spojený. V tom místě jako by byl vložený kus železa, magnet tam má sklon držet.
Velké překvapení - u ráfků pro véčka je magnetická celá brzdná plocha, ale v tom spoji víc.
Další překvapení - některé špice jsou magnetické, některé ne, i když jsou všechny nerezové. Na jednom zadním kole jsou magnetické všechny špice z jedné strany a z druhé ne a přitom se liší jenom délkou.
Myslím, že nic z toho nemá velký vliv na ten princip roztáčení magnetu uvnitř, který nejspíš používají. Ale každá taková nehomogenita může to pomoct magnetu utrhnout se z klidové polohy už při malých otáčkách.
Pokud tam máš takovou nehomogenitu, že to škube magnetem, tak podle mě nepotřebuješ ani žádné mechanické části - stačí vedle magnetu dát cívku a jen pomocí ní sbírat měnící se magnetické pole toho ráfku.
Pokud to pole není homogenní, jsme už tam kde jsme chtěli být i bez mechanických částí.
Zítra to plánuju zkusit - použít třeba svazek geomagových tyčinek a kolem nich omotaný drát jako cívku (nebo možná cívku mít vedle). Možná se silným magnetem a větší rychlostí budou nehomogenitu generovat i díry pro špice nebo tak něco.
Tak to docela ziram.
Nemuze byt finta v tom, ze rafek NENI homogenni hlinikovy kotoucek, ale jsou tam diry pro draty?
Vypadá to tak. Nebo dokonce ty dráty samotné možná můžou způsobit vznik indukčnosti, že se vířivý proud neuzavře na malém místě ráfku, ale proteče někudy i přes špice a udělá cívku.
... anebo to fakt souvisí s dírou pro ventilek. Přijde mi, že frekvence škubání magnetu docela odpovídá frekvenci otáčení kola. Zítra si zkusím ventilek nějak výrazně označit a provést pokusy na více kolech.
Tak, zrovna jsem si říkal, kolik energie se ztratí v zahřívání ráfku. Navíc tohle (asi) znamená mít magnety z obou stran ráfku, což třeba na zadní CrMo vidlici AZUBu nemá vhodné umístění.
To už mi přišlo lepší to řešení s magnetama ve výpletu a získáváním energie prudkým roztočením magnetu ve světle. Ale je třeba přiznat, že ty vířivé proudy mají svoji eleganci.
Funguje to i s magnetem na jedné straně.
Oproti řešení s magnety ve výpletu mi přijde, že to je schopné vyprodukovat mnohem víc energie. Oproti klasickým dynamům to má, zdá se mnohem lepší účinnost, takže to asi tolik v tom ráfku neprotopí.
Mně se líbí ta neskutečně malá hmotnost a možnost to snadno odmontovat.
No připisují tomu neuvěřitelné vlastnosti. Neumím dokázat, že je to blbost, dost možná není. Ale zdravý racionální skepticismus velí, že čím dalekosáhlejší důsledek mi někdo předkládá, tím lepší důkazy mám chtít. A tady mi někdo tvrdí, že jde udělat světlo s neuvěřitelnou účinností, v principu použitelné na každé kolo, lepší než cokoliv co kdy kdo vyráběl a prodával. A nenabízí vysvětlení jak to funguje, ani zdůvodnění kde je tedy ten háček, proč to není masově na trhu. Tak nevím, jsem z toho takový rozpačitý. Ale je to tak zajímavé, že jestli to fakt aspoň nějak funguje, chci to mít jednoho dne v ruce :-).
Na otázku, proč to není masově na trhu, si odpověz sám… Už jenom ten web mluví za své.
Je to celkem novinka nastartovaná Kickstarterem, celkem one man show…
Jak moc to ve skutečnosti brzdí by mně také zajímalo. Hlavně jak je to s účinnosti ve větších rychlostech.
Vířivé proudy jsou známe asi 160 let a používají se na hodně různých věcí, včetně brzd tryskových vozidel pro rekordní rychlosti, mechanických tachometrů a podobně. Ve většině aplikací pro přenos výkonu jsou problémem velké ztráty. A teď někdo přijde s tvrzením, že lze vířivé proudy zcela jednoduše použít ke generování proudu s velmi vysokou účinností, bez těch ztrát. Včem je ten háček, že to najednou jde až teď a dřív ne? Čekalo to třeba na objev neodymiových magnetů? Nebo tu byly dřívější pokusy a ekonomicky selhaly? Proč? Je to třeba z nějakého důvodu drahé v porovnání s jinými systémy? Systémů osvětlení kol už se vymýšlelo hodně, včetně některých hodně divokých, viděl jsem i generování proudu tlumičem přední vidle. A tohle nikdo nikdy nezkusil?
Tohle všechno by mě zajímalo a prezentace toho světla na netu působí dojmem, že zrovna tomuhle všemu se pečlivě vyhýbají. A kdykoliv jsem dřív viděl něco, co vypadalo skvěle na videu, ale vyhýbalo se vysvětlení, byl jsem později zklamaný, že to ve skutečnosti funguje mnohem hůř, než to vypadalo (a někdy i vůbec, ale tohle asi nebude ten případ). Tak proto jsem zvědavý na tyhle šťouravé otázky.
Dokonalé by bylo, kdyby se výrobci rozhodli demonstrovat tu účinnost. Půjčili si kolo s wattmetrem v zadním náboji, roztočili ho naprázdno a s generátorem u ráfku, pro srovnání výkonu, a potom ukázali wattmetr připojený na výstup toho generátoru, nebo napětí a proud ledkou. Pak by bylo jasně vidět, jak je to s tím výkonem světla a účinností. A možná by takovým jako jsem já padla čelist a začli slintat "to chcu". Ale možná by se taky zjistilo, že je to pětkrát horší než SON... Kdo ví.
Jo test s wattmetrem by mně také zajímal. Ten test, kdy roztočí přední kolo naprázdno mi přijde také celkem zavádějící, o odporu neříká vůbec nic.
Mně se na tom líbí, že se to dá ke kolu snadno přidat a zase odebrat, což s nábojovým dynamem nejde.
Někde psali, že do LEDky jsou schopni dodávat okolo 300 mA. A připustili že účinnost je menší než u nábojového dynama, nicméně jejich výhoda je, že nejtěžší komponentu celého systému - ráfek - už na kole máš i tak. A že nepotřebuješ žádné externí kabely, celá věc je malinká a zapouzdřená.
Zkoušel jsem hledat na netu, vypadá to, že skutečně používají rotor ze střídavě polarizovaných permanentních magnetů a kolem rotoru je cívka. Pokud by to někoho zajímalo, tady je jejich patent:
http://worldwide.espacenet.com...
(kliknout vpravo na Download). Je to německy, ale jsou tam obrázky. A tady je k tomu diskuse podobná té naší:
http://www.candlepowerforums.com/vb/showthread...
V té diskusi jsou probírány různé principy, jak by to mohlo fungovat. Zajímavé mi přišlo tohle, což využívá feromagnetického materiálu - špic v kole:
http://www.youtube.com/watch?v=-FooPy2OLXk&...
Díky za odkaz na patent, je super. Konečně je jasné, co a jak to dělá.
Hmotnost systému je určtě dobrá, v porovnání s nábojovým dynamem nebo baterií s opravdu dlouhou výdrží. Možnost vrátit kolo mechanicky do stavu bez toho prostě sundáním té věci z vidle je taky super, překonává nevýhodu nábojového dynama, které bude dělat odpor a váhu vždy.
300mA maximum by vypadalo konzistentně s tím, co bylo na videích vidět za světlo. S moderníma ledkama to na běžnou jízdu celkem stačí. A i při menší účinnosti než má nábojové dynamo to nemusí být tak strašné s tím mechanickým odporem, protože nábojovky dávají 500mA i do dvou ledek v sérii.
Začíná se mi to líbit, já snad ještě objednám nějaké neodymové magnety a dám se do pokusů. Jako nouzové světlo na kolo na kterém budu jezdit denně by to mohlo být fajn.
Předělal jsem osvětlení tachometru tak, abych to už neukopnul při sesedání. Zároveň jsem možná vyřešil problém se sháněním krabiček, pouzder a dalších udělátorů, které vždycky mají v nevyhovujících rozměrech nebo trochu jiné než bych potřeboval:
Postavil jsem si 3D tiskárnu a jako první nikoliv testovací výtisk jsem navrhl a vyrobil držák na dvě LEDky - stavovou a osvětlovací. Člověk se furt učí, příště bych zevnitř ty díry pro LEDky udělal kuželové, ať to tam jde lépe nasunout. Ale v zásadě dobré, bude následovat držák na zadní světlo.
Moc pěkné. Co máš za 3D tiskárnu?
Průša i3. Stavěl jsem ji v rámci www.reprapworkshop.cz.
Jeste mozna doplnim fotky ze stavby tiskarny, treba to nekoho zaujme:
http://www.fi.muni.cz/~kas/blog/index.cgi...
Troško jsem se pustil o víkendu do "vylepšování" světla. Dopadlo to neradostně, ale předělávat to po HW stránce nebudu. Všechno se bude muset vyřešit softwarově.
Chtěl jsem nalakovat všechny desky a přidat na vstup velký elyt. Oboje se povedlo. Ale při nandavání zpátky se mi podařilo protrhnout izolaci k potkávačkám, takže při dalším vyndavání ten kabel budu muset přestřihnout, ocínovaný by neprošel dírou. Také jsem zapomněl dát na desku v rámu vyndavací provázek, takže můžu jen doufat, že se neukroutí napájecí kabel.
Přidaný velký elyt má za následek, že světlo po vypnutí nechcípne hned, ale procesor stihne během pomalého poklesu napětí zaznamenat třeba i dvě chyby. Ale blikání předního světla vlivem zadního to nevyřešilo. Takže hloupé.
Zpětně už vím, že jsem měl nalakovat pouze vnější desku a na tu v rámu se vykašlat, do rámu se moc vody nedostane, deska byla úplně v pohodě. Chybami se člověk učí.
Podle mě blikání je způsobeno poklesem napětí baterky pod zátěží. Čili kompenzovat a brát to jako samostatné režimy, jak kdysi navrhoval Jrr. Mám to stejně a funguje to dobře kromě nejslabšího režimu - vlivem single-ended měření předního světla a relativně malého měřícího rezistoru (0R033) je na ADC příliš malé rozlišení, aby to rozumně stabilizovalo. Při vyšších proudech je to OK.
Já teď přemýšlím, jak moc chci vlastně svítit. Teď pouštím do XM-L U2 v nejsilnějším režimu 1.5 A, ale v noci při souvislém svícení jen asi 700 mA. Vidím s tím dobře, ale včera v noci mě předjel někdo, komu světlo svítilo výrazně víc. Což je k vzteku, protože jsem přes to světlo viděl hlavně svůj vlastní stín. Tak nevím jestli si noční režimy 300 a 700 mA nedoplnit ještě o jeden 1.5-2 A. Na kolik svítíte v noci vy?
Mám jedno ze svých nejstarších světel, které obsahuje 4 lampy Cree XR-E Q5 (nedávno jedna vyměněná za R2, ale to je jedno). Pouštím do nich cca 250mA ve slabším režimu a asi 800mA v silnějším, který ale skoro nikdy nepoužívám. Při cca 10°optice mi ty zhruba 3W stačí. Když za mě najede Bety na druhém Oceláči s novějším světlem podobného výkonu, taky vidím svůj stín, ale ne nějak extra výrazně. A v silnějším režimu jsem s tím jednou jel z kopce zatáčkovitou silnici, kterou jsem neznal, a při 60km/h jsem pořád ještě pohodlně stíhal vidět vše potřebné.
Je to možné, ale přijde mi, že tam bude ještě něco dalšího. Myslel jsem si, že se to přidání obrovské kapacity zlepší, ale nic. Ono se to děje jen při určité rychlosti v závislosti na nabití baterky a jenom při použití 2S baterky. Přijde mi to jako nestabilita při přechodu mezi nekontinuálním a kontinuálním režimem step-down měniče.
Já mám 2 teple bílé XP-G2 v sérii, buď ty nejsilnější nebo druhé nejsilnější. Ženu do toho od 100 mA při 10 km/h a méně až 900 mA při cca 55 km/h, myslím. Na normálním asfaltu v pohodě, na mokrém asfaltu je to trochu slabší. V lese přepínám na manuální režim.
Podle mého názoru velká kapacita to zhorší, protože zpozdí zpětnou vazbu.
Chtělo by to nějaký digitální osciloskop, abych dokázal změřit, co se tam přesně děje. Protože mi přijde, že ten pokles napětí musí být velmi krátký, ale výrazný. Jrr to napájí, pokud vím z NiMH baterek. Já to napájím vysokoproudými Li-Pol, kde je pokles napětí vlivem 200 mA fakt minimální.
Tak mně teď napadlo, že bych jako jednoduchý nízkofrekvenční osciloskop mohl použít Arduino a cpát to rovnou do počítače.
Moje hloupost a zbrklost je vskutku nekonečná. Teď jsem procházel seznam úkolů a mimo jiné tam stálo, že chci prohodit cívky v měničích světla, až budu vyndavat elektroniku z rámu, tak aby pro USBčko byla menší indukčnost a pro přední světlo ta větší. No samozřejmě, že jsem to neudělal a všechno to už je zpátky v rámu a nalakované :/
Na co dát pozor, když bych chtěl navrhnout mikrokontrolerem řízené zařízení, napájené ze zásuvky 230 V? Jakože bych chtěl, aby součástí toho zařízení byl zdroj.
Teď odhlížím od toho, že bych to možná ani podle norem neměl sám dělat, nevím.
Představuju si, že budu mít svorkovnici na tři dráty, PE přivedu na kostru a nechám ho o kus delší, aby se v případě problémů vytrhl jako poslední, N a fázi přes nějakou pojistku na nějaké malé trafo, třeba toto:
http://www.ges.cz/cz/ee20-10-5-106-GES07506818...
K tomu doplním lineární stabilizátor třeba na 5 V, a je vymalováno. Otázka je, jestli to trafo je správné řešení, jestli to nebude mít velký odběr i v klidu - pak by se musel dělat spíš nějaký spínaný zdroj.
Nebo pokud by šlo něco takového koupit hotové - aby to dávalo něco nad 5 V a okolo 100 mA, mohl bych to taky použít. Chci jen aby to nebylo velké a aby to byla komponenta pro vestavbu, ne třeba externí nabíječka.
Nabízí se varianta koupit nějakou značkovou USB nabíječku a tu rozkuchat. Ty levné čínské nedodržují základní bezpečnostní pravidla.
http://www.lygte-info.dk/info...
http://www.righto.com/2012/05/apple-iphone...
http://www.righto.com/2012/03/inside-cheap...
http://www.righto.com/2012/10/a-dozen-usb...
Ano, tím směrem asi půjdu. Dokonce mám jednu vhodnou USB nabíječku od mobilu Samsung, u které se rozpadl miniUSB konektor, tak si radši koupím novou než bych to spravoval.
Ale stejně by mě zajímalo, jak by se to dělalo "od základu".
Můžeš provést reverzní inženýrství. Jinak v tom článku, kde rozebírají starou iPhone nabíječku je dole předpokládané schéma zapojení.
Tam bylo vic informaci nez jsem chtel dostat :-). Mimo jine tam resili prechodove stavy pri spinani tranzistoru s indukcni zatezi (coz jsou treba boost prevodniky) tak, aby k sepnuti dochazelo, kdyz uz civkou netece skoro zadny proud. Ted mi to bude vrtat hlavou, jestli nemam svoje prevodniky v tomto smyslu upravit. Ale nejdriv bych musel tu asi padesatistrankovou prezentaci pochopit. Tak teda dik :-)
Pred par lety jsem stavel desticku, co mela spinat 230V a byt zavrena v instalacni krabici, takze externi zdroj nepripadal v uvahu, navic neslo o jeden kus...
Pojal jsem to klasicky - transformator, usmernovac, kondenzator, stabilizator 78L05, kondenzator, ATtiny. Relatko pak bylo napajeny primo za usmernovacem a spinany tranzistorem.
Pozitivni bylo, ze to nakonec spolehlive funguje a soucastky vysly docela levne, horsi to bude s ucinnosti.
Z toho 12V trafa lezlo na prazdno mnohem vic nez jsem cekal (spechalo to, takze jsem vse objednal v potrebnem poctu kusu, zatimco jsem kreslil plosak), takze jsem pak musel korigovat zapojeni s cilem vyuzit hotove desky a koupene soucastky. Misto Grece jsem usmernil jen jednocestne a navic pridal odpor a zenerku, aby se stabilizator neusmazil. Ve vysledku pokud neni rele sepnute, tak desticka citelne topi. Bylo mi jasne, ze to slo udelat lepe, ale na predelani uz nebyl cas. :-/
Dneska bych uz spis hledal nejaky hotovy napajeci modul. Ruzne nabijecky jsou idealni, protoze za tu cenu nic podobneho postavit nejde, navic uz to casto doma lezi.
Jo, takový nějaký problém řeším - časově spínané 230V přívody v co nejmenším rozměru. Jdou koupit spínací hodiny na jednu zásuvku, ale je to obludné, a když člověk potřebuje takové zásuvky tři, z toho dvě spínané současně, vede to na nechutný hrozen prodlužek a rozdvojek. Takže uvažuju, že bych to postavil sám.
Jeden kolega používá na spínání tuším topení toto:
http://www.ges.cz/cz/stavebnice-k-8056...
8 reléových výstupů, RS232C 2400bd ovládání. K tomu by z jedné strany šel připojít 12V zdroj a z druhé ATtiny (možná spíš ATmega s RTC) s 5V stabilizátorem a tím to řídit. Ale to už jsou tři samostatné věci, tak zkoumám jak to udělat menší.
Možná je teda cesta vzít desku z nabíječky a k tomu udělat desku s procesorem, záložní baterkou pro hodiny, a několika elektronickými relé, třeba takovými:
http://www.ges.cz/cz/elektronicke-soucastky...
Pokud by se to vešlo do rozměrů 45x45mm dvojmodulu, tak bych to mohl vestavět do standardní vaničky, k tomu bych dal několik 45x45mm kostek se zásuvkama, a bylo by.
Ještě teda: ta relé se rozlišují pro indukční zátěž a pro kapacitní/odporovou. Například zářivka je jaká zátěž? Indukční kvůli startéru?
Jednoduché trafo není problém, jediná výhoda spínaného zdroje je mírně menší velikost, ale u malých proudů už to nemusí být moc výrazné. Pokud použiješ správné trafo (nominální výstupní napětí je efektivní hodnota při nominální zátěži, takže na 5 V stabilizátor by mělo 5 nebo 6 V trafo v pohodě stačit), nepotřebuješ žádné zenerky (mmch, existuje i "vysokonapěťová" verze 78xx, která na vstupu snese hodně velké napětí) a samotný stabilizátor proud nežere, pokud zátěž nic nespotřebovává, takže naprázdno to fakt topit nebude.
Pokud by jsi chtěl jít po minimální velikosti, má smysl uvažovat o zdroji s kondenzátorem (hledej "Transformerless Power Supply"), ze kterého jde rozumně vytáhnout tak 10 mA, tedy pro AVR víc než dost. Ale relé bys musel mít s cívkou na 230 V a spínat ji třeba přes tyristor. (Případně najít SSR, co bude mít dost malé požadavky na proud LEDkou, tím asi vyhraješ i něco místa oproti mechanickému relé, ale bude asi dražší.)
Jo, ještě jedna poznámka k bezpečnosti. Je dobré se vzdát představy, že existuje nulák a fáze, ale brát to jako dva silové vodiče, na kterých obou může být potenciál vůči zemi (v případě věci zapojené do zásuvky mohou být zdířky "prohozené" zcela v souladu s předpisy, v případě zařízení zastavěného "do zdi" sice víš, co je nulák, ale při poruše rozvodů se na něm umí objevit potenciál). Jediný "zaručený" zemní potenciál je PE, ale ten nesmíš galvanicky spojit s N a nesmí po něm za normálních okolností téct žádný proud.
K té poznámce: ano, takhle si to představuju. N a F jsou v různých instalacích skutečně zapojeny různě. Nehledě na to, že dvoupólovou vidlici (europlug) jde dát do zásuvky oběma směry. Spojovat N s kostrou na spotřebiči by mě ani ve snu nenapadlo, a předpokládat že N má vůči PE vždy nulový potenciál taky ne.
Tak jsem si koupil toto SSR:
http://www.ges.cz/cz/s202s01-GES05700123.html
Melo by mit okamzite spinani (ne v nule), protoze nektere zarivky co nemaji elektronicky predradnik jsou v podstate indukcni zatez. Zkusil jsem to zapojit - mam 6x AA NiMH (cili neco mezi 6 a 7.2 V), na ridici stranu jsem dal 300R odpor a cervenou LEDku, na spinanou stranu jsem na totez napajeni dal 100R odpor a druhou cervenou LEDku. Chova se to tak, ze kdyz pripojim napajeni, sviti obe LEDky. Kdyz vypnu ridici stranu, tak spinana strana zustane svitit (zkousel jsem to uz asi pred hodinou a furt sviti). Kdyz pak vypnu i spinanou stranu a znovu ji zapnu, tak LEDka na ni nesviti, a rozsviti se zase az zapnu i tu ridici stranu.
Ma SSR mit nejakou hysterezi? Nebo proc se spinana strana nevypne po vypniuti ridici strany?
Ted nevim, zda ti rozumim spravne, ale ty tim zkousis spinat stejnosmerne napeti? Ja bych trochu cekal, ze to bude treba spinat jenom stridave...
To ze muzes spinat v libovolnym okamziku jeste podle me neznamena, ze se to pak nerozepne az pri pruchodu nulou. Nicmene studovat ten dataheet se mi prilis nechce.... :)
Ano, zkousim stejnosmerne, ve finalnim produktu bude stridave. No a myslel jsem, ze kdyz se od kazdeho typu SSR delaji dva modely "spina ihned" a "spina v nule", tak ze kdyz koupim ten prvni model, tak bude skutecne spinat ihned a ne az v nule, a tedy bude testovatelny i stejnosmernym proudem. No ale mozna si to predstavuju prilis jednoduse. S tyristory jsem zatim nikdy nic nedelal.
No a další dotaz: v datasheetu toho SSR na straně 9 mají vzorové zapojení:
http://www.gme.cz/img/cache/doc/523/158/s202s02...
Zjistil jsem k čemu je varistor (to by šlo použít i k omezení přechodových jevů a extrémních napětí u boost měniče, zajímavá součástka). Ale chápete někdo, k čemu je tam ta dioda mezi vstupními piny? Jako ochrana proti přepólování vstupu?
A pak ještě koukněte na fyzické rozměry na stranu 2: až pokud má být ta věc zanořena v plošném spoji, čili jak velkou díru pro piny navrhovat? Obrázek na straně 4 vpravo nahoře naznačuje, že i ta nejširší část by měla být uvnitř plošňáku. Rozumím tomu dobře?
Dioda je podle mě opravdu jen ochrana. LEDky obecně nemají rády moc velké závěrné napětí. (U tohohle SSR máš v DS 6 V jako absolute maximum.)
Letování: já bych obrázek na str 4 chápal také jako "absolute maximum", tedy nikde neletovat blíž. Do plošňáku bych nechal relé zasunuté jen normálně po rozšíření nožiček.
Problém s blikáním předního světla jsem vyřešil šalamounsky :) Prostě vzadu blikám takovou intenzitou, že to přední měnič ještě moc neovlivňuje :)
Mám však jiný zádrhel. Nedaří se mi vypnout PWM tak, abych mohl používat jeho piny jako normální výstupy.
Tímhle časovač zapínám:
power_timer1_enable();
PLLCSR |= (1
Aha. Ono to nefunguje :/
Tak ještě jednou. Kód je v tomhle gistu:
https://gist.github.com/snilard/7063307
Myslím si, že zádrhel je v tom zdrojáku, ale nevím kde. V HW by být problém neměl. Je to na ATTiny461A.
Tak nevím. Zprovoznit se mi to nepovedlo, tak jsem se na to vykašlal. Takovej základní zádrhel je malá flash toho MCU. Aktuálně jsem na 99,9%, takže kód navíc znamená škrty jinde.
Takže z toho mám dvě poučení. Nemá smysl škudlit a nekoupit nejlepší MCU z řady. Velká kapacita na vstupu nemusí zlepšit chování navzájem se ovlivňujících měničů a zároveň může přinést velké problémy při vypínání, pokud to člověk nemá do čeho vybít.
Doporučuju epizodu z minisérie Moon Machines věnovanou navigačnímu počítači. Komplet celý program měli nacpaný ve 72kB rope core memory, kterou nějaké v podstatě švadleny ručně ušily z drátu a ferritových prstýnků hezky jeden bit po druhém. Hodně dnešních programátorů by si z nich mělo vzít příklad s jak malou pamětí lze vyjít když se musí :-)
http://www.youtube.com/watch?v=vU5G9VsoER8
Tak zrovna v tehle malych brouckach se zase tolik pameti neplytva (v tomhle ma myslim 4KB flash), i kdyz samozrejme by se porad dalo citelne usetrit, kdyz by se misto Cecka programovalo primo v assembleru... to jina liga jsou stolni PC... :-D
Myslim, ze by se nasla spousta aplikaci, kdy se funkce od doby MS-DOSU prakticky nezmenila, ale v podstate jen kvuli barevnym okynkum to misto desitek KB potrebuje stovky MB...
Nikdy jsem ten jev moc nechapal, ale neco uz tusim od doby, kdy jsem videl kod v C# jednoho kolegy z prace. Strucne receno to, co bych v cecku vyresil bitovym soucinem a posunem (maskovani) z prijatych dat, on vyresil funkci, ktera mu kazdy byte vypsala jako retezec binarnich cislic, po jednotlivych znacich to nastrkal do nejakeho dynamickeho pole, zbudoval nad tim nejaky objekt a ten pak pouzival ke vsem dalsim operacim a zapis modifikovanych dat probihal zrejme analogicky. Jestli jsme to spocitali dobre, kazdy bit pak potreboval 4B (+ rezie tech struktur), to znamena 32x vetsi pametova narocnost a spousta nesmyslne ztraceneho casu procesoru... :)
Obavam se, ze spousta dnesnich programatoru vubec netusi, co konstrukce, ktere pisou (casto spis naklikaji) vlastne pro procesor a pamet znamenaji, takze ten vysledek podle toho vypada... :-/
Jo tak o tom něco vím. Mám pět let starý počítač. Tehdy mi to celkem v pohodě běhalo s 1 GB paměti. Teď tam mám 3 GB, víc nejde, a nestačí mi to. Zase musím říct, že ten systém toho umí víc a je použitelnější, tedy za podmínky, že to nezačne divoce swapovat. Takže by mi třeba i procesor ještě dneska stačil, ale chipset nesežere víc paměti.
Já bych postupoval tak, že bych zakomentoval vše až na poslední řádek. Měla by se rozsvítit LEDka. A pak bych postupně odkomentovával řádky odshora a odspodu, dokud to bude fungovat. Až nebude, zřejmě jsi nahoře něco nastavil co jsi dole nevrátil zpět.
Nebo to teda nebude fungovat ani se vším až na poslední řádek zakomentovaným, pak je problém ještě jinde (DDR registr?).
Něco takového jsem zkusil. Ale tedy ne řádek po řádku. Nepomohlo to. A už jsem se na to vykašlal. Až někdy později budu vyndavat desku z rámu, tak ten velkej kondík půjde pryč. Doufám, že to nebude za méně než několik let.
Zkouseli jste nekdo pajet takove ty QFN, BGA a podobne soucastky pomoci horkeho vzduchu a pajeci pasty s cinem? Premyslim, jestli svuj pristi projekt neudelat ciste z duvodu vyzkouseni technologie okolo procesoru ATtiny v pouzdre QFN. Podle videi z tytrubko se zda ze na tom nic moc neni. Boschuv fen s regulaci teploty mam, koupil jsem si na DX nejakou pastu co mela dobre recenze, tak snad to nebude moc problematicke.
Jake mate v tomto zkusenosti?
Prosim (vim ze je to OT) napada nekoho zdroj
ktery udela 12V/2A z 48V (DC)?
Idealne aby umel soucastne i 24V/0.5A
Nasel jsem PC zdroje napajene z 48V, ty by resily cast 12V, ovsem 24V uz ne.
Pokud mozno by se melo jednat o "nakupovanku"
me schopnosti konci u zapojeni LED...
Prip mne prosim navedte na klicova slova pro vyhledavani...
DC DC měnič je asi správné klíčové slovo. Možná něco z tohoto:
http://www.gme.cz/dcdc-menice
Když se rozklikne některá sekce, lze vyhledávat i podle parametrů (vstupní/výstupní napětí, výkon, ...)
Jak byste řešili reálný čas? Jakože potřebuju v pevný okamžik dne provést nějakou akci (sepnout zásuvku, viz výše).
Díval jsem se, že nějaké atmegy mají interní RTC, ale nevím jestli to není kanón na vrabce. Pak exsistují samostatné RTC čipy ovládané přes I2C. Anebo v AVR134 se píše o softwarové implementaci pomocí 32.768 kHz krystalu a Timer/Counter0.
Asi nejvíc se mi líbí to poslední, je to jen jedna součástka navíc. Ale nevím jestli to nemá nějaké další problémy. Jak drahý je krystal, jak je přesný, a jak je to oproti dedikovaným RTC čipům?
Další věc je, jak tohle zálohovat baterkou. Jak udělat, aby při výpadku napájení běžely aspoň hodiny, ale zároveň aby to bylo nějak oddělené, aby se ta baterka nevysosla jiným subsystémem? Plus dobíjení baterky. Líbí se mi řešení které popisoval Radek, že má na LEDkách 4.2 V, což zároveň může sloužit pro udržování napětí na lithiovém článku.
Dá se ještě využít 50 Hz ze sítě. Většinou bývá frekvence hodně přesná (tak od boku bych nadhodil desítky ppm, ale bez záruky), ale nejsem si jistý jak je to s integrovanou odchylkou. I když (IMO) 50 Hz používají některé verze spínačů na "noční proud", takže tam asi snaha o udržení malé dlouhodobé odchylky bude.
Krystal má takovou přesnost, jak se píše v datasheetu. Cena určitě není překážka. Většina integrovaných věcí bude používat taky nějaký krystal, takže principiálně podobné vlastnosti.
Ještě můžeš zkusit využít tohle: https://en.wikipedia.org/wiki/DCF77 pokud tě trápí dlouhodobá přesnost, ale zkušenosti s tím nemám žádné.
Pokud chce, aby mu hodiny bezely i pri vypadku napajeni, rekl bych, ze 50 Hz resenim nebude. Nicmene mohl by si treba podle 50 Hz prubezne dokalibrovavat interni oscilator, aby pri pripadnem vypadku byla odchylka co nejmensi. Kazdopadne krystal bude jistejsi.
Kdysi jsem problem s realnym casem vtipne obesel. Pro ladici a kontrolni ucely jsem potreboval mit v pameti prubeh teploty za poslednich nekolik dni a chtel jsem poznat aspon kdy byl den a kdy noc... misto hodin jsem si do "logu" ulozil nekolik bitu ze snimace osvetleni.
Tedy prakticky tam zadny snimac osvetleni nebyl, jen indikacni LED, ale kdyz zrovna nesvitila, tak jsem s ni zmeril to osvetleni... :-)
Samostatny RTC bude myslim vetsinou zbytecna komplikace.
Pokud ti procesor pobezi z krystalu, muzes si merit cas pomoci nektereho casovace, akoratze procesor pak nemuzes uplne uspat (jen Idle), takze budes muset zvazovat frekvenci jako kompromis mezi rychlosti a spotrebou, plus nekde by se mozna dalo trochu kouzlit s preddelickou.
Nektere ATmegy (treba ATmega48PA...328P) umi bezet z interniho oscilatoru a pritom pouzivat Timer2 s 32 kHz krystalem.
To mi na RTC pripada jako idealni, protoze muzes mit slusne presne hodiny a pritom procesor uspat tak, ze bude zrat jen par mikroamper.
Prakticky to vyzkousene nemam, ale jako reseni se mi to libi nejvic.
Ano, to druhe je to, o cem pise dokument AVR134. Nejspis to umi i ATTiny2313 (861a to neumi), ale asi koupim ATmegu168PA. Ted jeste vyresit to zalohovani baterkou. Idealni by bylo, pokud bych pri behu na baterku neztratil hodiny, vic bezet nemusi. A jeste rozhodnout, jestli staci mit primarni baterku treba 3V, anebo resit dobijeci a jeji dobijeni.
Jo, objevil jsem, ze na DX maji dvouradkovy displej rizeny HD44780 za o neco malo vic nez tri dolary, zatimco v GESu jsem nasel nejlevnejsi asi za 120 korun. Tak jsem jich hned par objednal - pokud pouziju ATmegu, budu mit dost pinu i na paralelni ovladani toho displeje.
Ještě k tomu zálohování baterkou: jakou baterku použít? Přijde mi zbytečné dávat tam velikou 18650. Jaké existují malé lithiové baterky? Našel jsem 15266, což by možná šlo:
http://dx.com/p/ultrafire-15266-3-6v-600mah...
Nebo pak nějakou mobilovou nebo vrtulníkovou, která je sice na objem větší, ale je zase placatá. Co byste použili?
Ohledně zapojení mám představu, že bych to napájel z +5V stabilizátoru a dal tam diodu s úbytkem něco pod 1V a nějaký omezující rezistor. Tím bych měl zajištěno, že se baterka nepřebije nad nějaké 4.1 V.
A druhou diodu od baterky k VCC procesoru. Procesor by pak v případě výpadku primárního napájení zaznamenal jen pokles napětí (o úbytek na těch diodách nebo na jedné z nich).
Pomocí pinu bych četl informaci jestli napájení funguje nebo ne a shodil všechny vstupy a výstupy kromě RTC krystalu.
Může to takto fungovat?
Já bych na to použil nějakou ze starších baterek, co mám doma vykuchané z notebooků. A kdybych žádné neměl, tak asi nějakou malou plochou.
Co se týče nabíjení, IMHO by mohl fungovat nějaký nastavitelný lineární stabilizátor nastavený na 3,8 V. A držet celý systém na tomhle napětí. Proud omezovat maximem toho stabilizátoru.
Jak byste dělali senzor vlhkosti? Podle zběžného průzkumu na Farnellu to vypadá, že existují analogové senzory, které ukazují vlhkost jako impedanci:
http://cz.farnell.com/multicomp/hcz-d5-a/sensor...
V datasheetu většinou uvádí, že se jedná o impedanci při 1 Vrms sinusovém signálu 1 kHz. Což znamená, že to asi potřebuje nějakou další elektroniku na to, abych do toho dostal nějaký signál. Předpokládám, že generovat sinusový signál pomocí MCU nebude úplně jednoduché. Jak byste tohle obsluhovali? Mám na mysli generování signálu a měření impedance.
Druhá možnost je vykašlat se na základní součástky, a koupit už něco hotového. Adafruit má senzor za $5, DX dokonce za $3.10 i s teploměrem (který bych taky využil):
http://dx.com/p/arduino-digital-temperature...
P.S: Pokud máte pocit že jsem už uhnul od tématu osvětlení a lehokol, máte pravdu. Pokud vám to vadí, ozvěte se a já se pokusím vypadnout s tím na jiné fórum. Konec hlášení :)
Ta střídavina je v tomhle typu senzorů jen proto, aby se senzor "nerozbil" (trvalý stejnosměrný proud by jej nějakým způsobem zničil, co tak tuším). Senzor dává skutečně ohmický odpor. Takže není třeba se trápit sinusovkou, (symetrický) obdélník bude fungovat stejně dobře a cokoliv jiného taky. Potřebuješ jen nulovou DC složku, což nejjednodušeji zajistíš kondenzátorem v sérii se senzorem.
Pak musíš jen vymyslet jak měřit ten odpor. Asi by úplně stačilo usměrněné napětí na senzoru a spočíst si, co udělá na kondenzátoru ten obdélník (jeho vyšší harmonické).
Mmch, vypadlo na mě z vyhledávače (nečetl jsem, ale na rychlý pohled je to ono): http://www.sensorsmag.com/sensors/humidity... , třetí sekce, "Resistive Humidity Sensors".
co nějaká inspirace tady ?
http://www.root.cz/clanky/arduino-merime-a...
je tam odkaz na https://www.sparkfun.com/datasheets/Sensors...
Tentokrát opět něco on-topic. Vyrobil jsem si lepší zadní světla.
Mám dvě místo jednoho, abych byl lépe vidět z většího rozsahu úhlů - původně mi při pohledu zezadu zprava (tak od 30 stupňů od osy jízdy dál) zakrývala světlo flaška.
Navíc jsem přidal ještě malou vysokosvítivou žlutou LEDku svítící doboku, zapojenou paralelně k té výkonové, a omezenou 100R odporem na rozumné proudy (se samostatnou regulací jsem se nezalamoval).
Držák má zadní stěnu otevřenou, aby větrala hliníková destička, kterou používám jako chladič. V držáku je zezadu takový bazmek, který pružně dotlačuje chladič k LEDce.
Obě světla jsou zapojena paralelně, což sice není optimální, ale zatím se zdá že svítí obě stejně. Osy světel svírají úhel 6 stupňů (každé je odkloněno 3 stupně od osy jízdy směrem ven), takže se rozsah největšího osvětlení směrem do šířky ještě zvýšil.
Optiky jsou Fraen FHS eliptické (10x22 stupňů pro LEDku s charakteristikou batwing), namontované širším úhlem vodorovně.
Asi největší vychytávka je to, co jde rozumně udělat jen 3D tiskem a ne obráběním: díry na šrouby mají z jedné strany šestiúhelníkové osazení, do kterého přímo zapadne matka M3. Takže šroubovat k držáku hlavové opěrky le možno jen jedním nástrojem - šroubovákem.
Parádní světlo, závidím tiskárnu, ale jen pro úplnost bych dodal, že zrovna tohle není jedna z věcí, co nejdou udělat obráběním. Umí to kdejaké cnc, jde to udělat obrážěčkou (angl. shaper) a dokonce se dá i vrtat čtvercová nebo šestiúhelníková díra, je to jen otázka chytrého přípravku :-). Příklad zde: http://www.youtube.com/watch?v=PMSbdhQM9GU
Co je skvělé na 3D tisku je možnost vyrobit "ježka v kleci", třeba matici navlečenou v tenkém místě něčeho, co je na obou koncích silnější. To už opravdu obráběhím nejde a musí se to dělat vícedílné.
Jo, pravda. Na obrazecku jsem zapomnel. Nicmene 3D tisk ma i dalsi vyhody - treba ze muzes regulovat "strukturu" materialu - ze v miste kde by lisovany vyrobek byl plny muze mit ten vytisk nejakou vnitrni strukturu. Treba takhle to muze delat vypln: "plna" cast ma dve nebo tri vrstvy shora a zdola uplne vyplnene, a co je mezi tim ma jen 2-3 perimetry (obvody) a mezi nimi je takova sestiuhelnikova vypln, kdy kazda vrstva ma o 120 stupnu jinak tazena vlakna, takze to cele je lehci nez plny objekt a pritom podobne pevne.
hranatou diru nevrtas ale vlastne frezujes ci spise obrazis slozenym pohybem. Musis mit ve vztahu prumer nastroje , vyoseni a rychlost otaceni vyoseneho drzaku.
Krasna matematika.
Delalo se to uz na vackovych automatech pred 50 lety :-)
3D tisk je sice krasna vec ale kolega ktery
dela konecne upravy (cti: brouseni, tmeleni, lakovani) vzdy rika ze po NC frezce se to dokoncuje lepe.NC dela jemnejsi schody a taky hmota po nataveni se hure dobrusuje.
Ale tak jasně, každé má svoje výhody. 3D tiskárna asi nejvíc to, že dohromady váží tak 10 kilo a vejde se do krychle o straně 40 cm, a pořídil jsem ji pod 20 tisíc. A mám zdrojáky od všech komponent od CADu přes výrobu G-kódu až po firmware, který na základě toho G-kódu řeší takové detaily, jako aby při skokové změně směru o 90 stupňů nechtěl po krokových motorech nekonečné zrychlení.
A tisknout můžu i o půlnoci v obýváku, aniž by na mě přilítli sousedi nebo se vzbudily děti.
Přesně tak,protože jezdim autem i na kole,tak vim co je potreba.Baterie musi byt funkcni a svetlo umistene tak,aby bylo videt uz z dalky a ne az to kolo srazim.Nejhorsi je soumrak,na to musi byt super svetlo s dobryma bateriema,v noci muze byt i slabsi,ale musim byt soudny a denne si zkontrolovat svitivost.Ja pouzivam dva zadni svetla,obe blikacky a kazde jine
Člověk musí být soudný oběma směry. Příliš velký výkon nebo příliš chaotické blikání zadního světla na bezpečnosti nepřidá. Jasně, lepší než nic nebo nějaká slabounká bludička, ale méně je někdy více. Od světla chcem tři věci: řidič musí uvidět, že tam něco je, a to včas, následně musí poznat co to je a potom správně poznat rychlost a směr pohybu. To první volá po velkém výkonu, to první a druhé se snadněji zařídí blikáním než trvalým světlem, ale to poslední by zas chtělo stálé světlo. Podle mě nejlepší kompromis je něco, co neoslňuje na víc jak pár metrů ale ne slabší a blikat by to mělo co nejvíc pravidelně, aby to nemátlo. Taková věc se moc neprodává, většinou jsou dost slabé na přímý pohled zblízka i za tmy, takže za šera nic moc. A často mají zbytečně složité blikání. U vlastní výroby proto obvykle volím 2x2 režimy: blikání a svícení, dva různé výkony pro den a tmu. Zatím se mi to hodně osvědčilo.
Kdyz uz tady planuju pokusy s ATmegou - zkouseli jste nekdo pouzit MCU s nejakym bootloaderem? Idealni by bylo, kdyby ta deska s ATmegou sla pripojit k pocitaci nejen pro cteni a zapis dat, ale i pro upgrade firmwaru. Vite o nejakem spolehlivem bootloaderu, ktery by pouzival USART v rezimu RS232? Predpokladam ze pak bych potreboval jen doplnit prevodnik TTL urovne na RS232.
Dival jsem se na dokumenty Atmelu, a k Atmega168PA maji jen popis DES a AES bootloaderu, coz je pro me zbytecne. Neco jednodussiho standardniho?
Druha moznost je USB: Arduino ma zvlast FTDI FT232 cip pro pripojeni pres USB. Akorat ten je tak 2-3x drazsi nez samotna Atmega168PA. Nebo koupit ATmegu s USB (asi 16U4), ale ta zase nema RTC rizene pres 32kHz krystal a neuvadi se tam klidova spotreba (asi je prilis velka).
Já používám Arduino. Konkrétně levné čínské seeeduino. To, jak píšeš, používá ten převodový čip. Novější originál Arduina používají na převod další ATMega, takže pak nejsou v počítači potřeba ovladače. Dávat jo do hotového výrobku bych asi nechtěl, ale na prototypování je super. Ten převodový chip se dá použít i na komunikaci s externím ATMega. Takže i pro nahrání bootloaderu a programu. Já Arduino občas požívám jako obyč programátor přes MISO/MOSI/SCK, s bootloaderej jsem si zatím nikdy nehrál.
Levne, jo? Ja jsem si na prototypovani objednal Nano z eBay za 6 dolaru:
http://www.ebay.com/itm/281145520990
(ale nerikejme hop, jeste jsem to nedostal).
A co znamena "nejsou potreba ovladace"? Pokud to zarizeni ma USB rozhrani, tak na druhe strane musi byt neco co s tim umi mluvit (ovladac). At uz se to tvari jako seriovy port (ten FTDI cip) nebo jinak. Co dela to nove Arduino jinak nebo jak se na USB tvari?
No bylo levnější než Arduino Uno. Kupovali jsme ho přes český obchod hwkitchen.com, bylo tehdy ve slevě. Kvalita zpracování je horší než u originál Arduin, ale má některé funkce, které jsem dost ocenil, navíc.
Když je použit v Arduinu ten FTDI čip, tak abys do něj mohl z toho IDE nahrávat program, tak musíš nainstalovat ovladače k tomu FDTI, tedy já jsem je na Macu musel nainstalovat. Na windows asi také bude potřeba instalace, na Linuxu nevím. Když máš moderní Arduino s přídavným ATMega nebo s MCU, co umí USB rovnou, tak to prostě připojíš k počítače a z Arduino IDE uploaduješ program rovnou (zase zkušenost z Macu). To samé asi i když to tam budeš cpát přes avrdude, to IDE ho, myslím, používá také.
Ten FTDI čip se, pokud vím, běžně používá v takových těch USB to RS232 převodnících, takže se to v počítači tváří asi rovnou jako sériák.
No a moje otazka je, jak jinak nez seriovy port se to muze tvarit (a hlavne jak se dosahne toho, ze to nepotrebuje samostatny driver).
FTDI FT232 je ten nejstandardnejsi ze standardnich USB-to-RS232 cipu, cili me docela prekvapuje, ze se nekde musi neco instalovat. Na Linuxu je to soucasti v podstate vsech distribucnich jader co jsem v posledni dobe videl. Zapojis a fungujes.
Tak mám zase jeden off-topic dotaz:
Co je potřeba k tomu, abych mohl řídit otáčky DC motoru (čili komutátorového) z nožičky MCU? Představuju si, že bych PWM výstup MCU připojil na gate N-MOSFETu, přidal pull-down rezistor k zemi, a motorek zapojil mezi kladný pól zdroje a drain MOSFETu. Source MOSFETu připojit na GND, samozřejmě.
Je v tom nějaká záludnost? Budu potřebovat nějaké vyhlazování těch pulzů nebo nějakou ochranu před přepětím? Jak rychlá musí být frekvence toho PWM, když motorek je třípólový a bez zátěže natočí něco pod 20000 RPM? Jaké napěťové špičky tam mohou vznikat, když zdroj má 19 V?
---
Pokud by snad někoho zajímalo co zas bastlím, tak je to jen takový nápad: odešla mi elektronika v jednom autíčku na digitální autodráze, a tak přemýšlím o postavení vlastní. No a když už bych byl u toho, mám nějaké volné 3-osé gyro a 3-osý akcelerometr s čipem 6050, tak přemýšlím o tom, že bych udělal autodráhové autíčko, které by se řídilo samo podle předchozích zkušeností. Udělal bych snímání otáček motoru, natočení sběrače v kolejnici, a to všechno bych používal k detekci rychlosti, zatáčení, smyku, atd. Mohl bych udělat vychytávky typu brždění přední nápravy, možná telemetrii a podobně.
Vhodnější bude řídit přes plnej most. Budeš moct dát zpětnej chod. MCU doporučuju použít ARM, budeš tam mít hodně výpočtů...
Na autodráze typicky není zpětný chod potřeba, ledaže bych implementoval nějaké brutální brždění. Ale k tomu podle mě stačí jen oba konce uzemnit, na což by měl stačit poloviční most.
No a který ARM? ARM je cokoli od nějakých malých věcí na kterých ani Linux neběží až po brutální multicore SoC z tabletů s integrovanou GPU. Jako jo, naučit se další platformu je dobrá výzva. Pro ty nižší ARMy se taky používá GCC? Jaký programátor je pro to potřeba a kde jsou nějaké úvodní informace?
STM32F1xx nebo STM32F4xx
Programátor/debugger - ST-LINK nebo J-LINK.
Prostředí podle libosti. KEIL, IAR, nebo jen make s GCC (gcc se používá skoro na všechno).
Informace:
http://forum.mcontrollers.com/
http://www.mcu.cz/forum/
No a další dotaz: jak byste detekovali z MCU signál o amplitudě větší než napájení toho MCU samotného? Jakože MCU třeba na +5V, signál high +19V, low 0V.
Třeba odporová dělička ze dvou velkých odporů v poměru 14:5, uprostřed bych připojil pin MCU, a možná ještě mezi ten pin a zem Zenerovu diodu na 4.7 V?
Zenerovu diodu jsem nikdy zatím nepoužil, na co si dát pozor? Představuju si že je to dioda, která se v závěrném směru otevře (prorazí) nějakým mezním napětím. Jak jsou na tom například s nějakými mezními proudy a s rychlostí otevírání/uzavírání?
Už si tady sice píšu jen sám se sebou, no ale aspoň pro budoucí generace uvedu, že jsem Zenerovu diodu úspěšně použil. Jediná netriviální věc byla dodržení minimálního proudu diodou v závěrném směru, aby se udržel průrazný stav.
http://www.fi.muni.cz/~kas/scxreader/
Další součástka k seznámení a vyzkoušení je ultrakondenzátor:
http://en.wikipedia.org/wiki/Supercap
Přemýšlím že by to šlo použít pro zálohování napájení místo baterky (jak se snažím použít výše). Že bych po detekci výpadku napájení vypnul v MCU všechno co jde, nechal běžet jen 32kHz krystal a jeho přerušovací rutinu, a na těch pár mikroampérech by to mohlo pár dní přežít.
Zkoušeli jste s tím někdo něco dělat? Jaké to má vlastnosti a na co dát pozor?
Mám vyzkoušený 1F 5,5V (http://www.gme.cz/cez-1f-5-5v-pan-196-dlc-21x7... ve dvou aplikacích dost jiných od tvojí: parelelně ke dvěma výkonovým ledkám napájeným z dynama. Nabíjí se maximálně pár desítkama ampér a vybíjí též, takže nevyhlazuje třeba blikání světel v malé rychlosti. Ale po zastavení klesne napětí na světlech na těch jeho 5,5V a svítí to jako jakási parkovačka ještě několik minut. Intenzita pomaličku klesá, ale v úplné tmě rozeznáš slabounkou záři ještě po několika hodinách.
Druhá aplikace je zálohování těcho hodin: http://www.postreh.com/phprs/view.php... kde kondík nenapájí 12 pozičních led, jen oscilátor a čítače hodin a tři ledky indikující vteřiny, minuty a hodiny. 10mA potřebných pro ty tři ledky to udrží asi 40 vteřin, pak se zastaví hodiny, protože napětí asi kleslo pod provozní napětí oscilátoru. Nicméně hodiny se neresetují, jen postupně slábne jas. Ještě několik minut se umí rozběhnout z tohohle místa bez resetu, pokud se obnoví hlavní napájení.
Obě aplikace mají své nevýhody nebo nedokonalosti či jak to říct, ale v obou jsem spokojený s tím, jakou službu součástka velikosti knoflíkové baterky poskytuje.
Pokud opravdu potřebuješ jen mikroampéry, neváhal bych věřit, že to bude trvat několik dnů než tomuhle kondíku klesne napětí pod přijatelnou úroveň.
Já jsem našel mezitím ještě nějaký whitepaper od Panasonicu, kde popisují jak se to chová. Docela dobré. Akorát jsem z toho nevyčetl, jak se to chová při nabíjení na napětí nižší než jmenovité - třeba mám 5.5V superkondenzátor, zdroj 5.0 V, a za ním ještě diodu s úbytkem třeba 0.4 V, abych při výpadku napájení z toho kondenzátoru napájel fakt jen to co nutně potřebuju. Takže reálně ten kondenzátor bude napájený třeba na 4.5 V. Jak se to projeví na vlastnostech?
Potřebuji zvolit nějaký malinký konektor pro in-system programování mých výtvorů. USBASP má 10pinový konektor 2x5 s rozestupem 2.54 mm a půlkou vodičů nevyužitých. Teď jsem ještě v nějakém dokumetu Atmelu viděl konektor 2x3, což už je lepší. Ale při použití jen SMD součástek ten konektor i tak zbytečně trčí do výšky.
Co jiného menšího byste použili?
V některých projektech používám tohle: http://www.ges.cz/cz/kabely-konektory/konektory...
Jo, ale Print konektory jsou furt to stejné - 2.54mm rozteč, a zabírá to o dost víc místa než jednořadý nebo dvouřadý header.
Myslel jsem spíš něco typu PCI slot, že by se tam ten programátor nasunoval zboku, a na desce byly jen kontakty. Kdesi jsem viděl něco podobného kde protikus byl kolíček na prádlo s kontakty připevněnými vevnitř :-)
pokud chceš nejmenší konektor co na daný počet pinů jde, tak se mrkni, jestli bys nedal dohromady něco s FPC (flexible printed circuit) nebo FFC (flexible flat cable). Konektory vypadají nějak takhle:
https://www.google.de/search?q=fpc+connector...
https://www.google.de/search?q=fpc+connector...
Ještě mě napadlo, že kdyby to nešlo rozumně koupit, a potřebuješ jen jeden, šlo by splašit nějakou vyhozenou elektroniku. Třeba v LCDčkách to určitě je, viděl jsem to i uvnitř mobilů a foťáků (tam už je to opravdu miniaturní). Mohl bys kuchnout konektor z desky i ten kablík co se do něj připojuje, pak je to jen otázka jak si poradit s připájením kablíku na programátor a konektoru na desku. možná by to vyžadovalo horkovzduch, nebo extra jemný hrot a klidnou ruku. Záleží jak miniaturní verzi vezmeš.
Když já bych chtěl něco čeho bych mohl mít víc stejných kusů. Čili ne vymontovat jeden konektor odněkud, ale mít možnost ho koupit.
Pájení kablíku by se nemuselo dělat - dal bych na druhou stranu stejný konektor, a připájel bych až ten.
Tak stačí chvíli googlovat, našel jsem firmu, co prodává kabel i konektory třeba zde:
Kabely: http://cz.rs-online.com/web/c/kabely/paskove-a...
Konektory: http://cz.rs-online.com/web/c/konektory...
Ceny vypadají velmi rozumně, jen jsem nezkoumal, jestli to třeba neprodávají v nějakém balení minimálně n kusů.
Zajímavé, díky za tip. Co jsem zkoumal tak mají konektory po 10 kusech, dopravné 175 Kč.
Ještě jsem vymyslel, že by vlastně ten konektor 2x3 mohl být rovnoběžně s deskou, každá řada z jedné strany desky, jako je to tady:
http://fabiobaltieri.files.wordpress.com/2011...
Směrem do šířky ještě nějaké místo mám, na rozdíl od směru do výšky. Akorát teda musím vymyslet, jak to zapodporovat v gEDA/PCB.
Prosím tě, mohl bys mi vysvětlit význam slova "zapodporovat"?
8-)
Zajímavá konstrukce. :) V PCB by to mělo jít v pohodě -- pady na obou stranách desky (u spodních flag onsolder) místo pinů, ne? (Ale nezkoušel jsem, jen mám za to, že by to mělo fungovat.)
Jo, právěže ten flag onsolder jsem neznal. Ale už je to vyřešeno:
http://www.delorie.com/archives/browse.cgi?p...
Kdo máte zkušenosti s recyklovanými součástkami ze staré elektroniky - podle čeho identifikujete typy a parametry těch součástek? Mám například starou řídící jednotku ze sušičky prádla a je tam spousty malých SMD zenerových diod (aspoň myslím že jsou to zenerky - takové prosklené červené válečky s černým pruhem na jedné straně. Jak se pozná závěrné napětí?
Nebo obecně - jak identifikujete ty součástky?
Začal jsme přemýšlet o drobet jiné konstrukci LED driveru, než teď používám. Pro každý okruh by byl jeden MCU, asi ATTiny25. Výstupní výkon by se řídil napětím přivedeným na AREF a MCU by řídilo PWM pomocí porovnání z analogového komparátoru místo z čísla z ADC. Aby nemusel být měřící rezistor moc velký, chtělo by to nějaké zesílení měřeného napětí. Na farnellu jsem na to nějaké specializované součástky našel (http://cz.farnell.com/diodes-inc/zxct1022e5ta... ale za 30 Kč mi přijdou celkem drahé. Tak bych se rád zeptal, jakou součástku mám hledat, aby to mělo zesílení napětí tak 10x, 20x?
Pak je tu druhá myšlenka. Když mám na jednom MCU víc měniču a přepínám ADC se zesílením mezi jednotlivými okruhy je potřeba měřit hodněkrát a počáteční měření zahodit, aby člověk dostal nějaká rozumná čísla. Kdybych ADC nepřepínal a nechal ho nastavené na stále stejnou nohu budou výsledky důvěryhodnější? Budou pak výsledky použitelné po každém měření? Že bych se rozhodoval o změně PWM po každém jednotlivém měření ADC.
Ještě pár otázek.
Jak můžou být malá napětí, která budu porovnávat na AC? Že bych nepoužíval zesílení, ale naopak porovnával vůči hodně malým napětím.
Kdybych použil napěťovou referenci, třeba http://cz.farnell.com/diodes-inc/ap431ag-13/ic... můžu ji připojit na výstup PWM a její výstup přes jednoduchý low pass filtr připojit na AREF uvažovaného MCU? Přemýšlím, jak z řídícího MCU generovat ta požadovaná napětí pro porovnání pomocí AC.
Pokud si dobře pamatuju, tak AC používá ten stejný předzesilovač jako ADC. Takže zhruba stejná přesnost. Spíš je otázka, jak bys chtěl takováto mikroskopická napětí spolehlivě vyrábět a spolehlivě vodit po rámu kola, aniž by to bylo někde rušené.
Já používám měřící rezistor 0R033, což dává při 3A proudu ztrátu 0.3 W (z 10 W příkonu, které sežere LEDka). při menších proudech je to ještě víc zanedbatelné. A toto zvládám regulovat v rozsahu řekněme 150-3000 mA při single-ended měření ADC (1.1 V maximum a 10 bitů rozlišení).
Tebou navržený přístup mi nepřijde smysluplný. Já na centralizované řídící jednotce vidím zásadní výhodu, že mám jedny baterky, jedno ovládání, jeden senzor osvětlení a k výkonové LEDce mi stačí dva dráty. Naopak tahat někam daleko napájení a pak z něho odebírat pulzní výkon znamená obrovské rušení a tak vůbec.
Já když už bych předělával step-down, tak bych to upravil na jeden lithiový článek a P-MOSFET+Schottky místo dvou N-MOSFETů a driveru s nábojovou pumpou. Něco takového si chci postavit pro čelovku.
Já to nechci tahat nikam daleko. Jde mi o to postavit driver, který bude rychle reagovat na vnější vlivy. Domnívám se, že komerční LED drivery by dokázali vyregulovat blikání předního světla způsobené silnými bliknutími zadního světla. Což jaksi teď nemám. Zkoušel jsem všechny možné SW cesty a jediná byla snížit intenzitu zadních záblesků.
O stavbě čelovky také uvažuju, ale spíš jako step-down z 2S či 3S lipolky.
Já ty měřící rezistory používám drobet větší 0R11 a reguluju do 900 mA oproti 2,56 V referenci v double-ended modu s 20x zesílením. Vážně používáš single-ended mode?
K otázce, jak vyrábět mikroskopická napětí, asi nějakou napěťovou děličkou.
Ano, u předního světla mám single-ended. U ostatních dvou diferenciální s jedním pinem zatlučeným do nuly.
Pokud to všechno řídíš z jednoho místa, tak není problém brát zvlášť stav "svítí přední a nesvítí zadní" a "svítí přední i zadní" a obě hodnoty pro přední světlo ukládat a používat zvlášť.
Jo tak takováhle korekce u mně prostě nefunguje. Je tam nějaký přechodový jev v řádu ms, který se projevuje jen se začátkem pulsu. A libovolná korekce při začátku bliknutí zadku to nedokáže zpravit.
Je pravda, že driver řízený z AC by to třeba také nezvládl vyrovnat, ale mne láká to zkusit.
Každopádně, jestli to budu ještě někdy rozebírat, tak tam narvu cívku s větší indukčností. Tak trojnásobně větší i za cenu, že bude mít větší odpor.
Když to necháš regulovat ve stavu "svítí jen přední" (třeba 10 vteřin nebo tak nějak), zapamatuješ si výslednou hodnotu PWM, pak to necháš regulovat dalších 10 vteřin ve stavu "svítí přední i zadní", zapamatuješ si výslednou hodnotu, a pak jen bez další regulace mezi těmito stavy a těmi dříve určenými hodnotami budeš třeba po půl vteřině přepínat, tak to přední světlo bude poblikávat?
Pokud ne, máš něco špatně v regulaci (třeba reguluješ moc rychle nebo moc brzo po zapnutí).
Takhle konkrétně jsem to nikdy nezkoušel. Ale domnívám se, že i tak by to poblikávalo, že se mi navzájem ovlivňují cívky a nějaké dráhy na desce.
Zkoušel jsem to pohasnutí změřit, to se jakž takž dá. Tak jsem udělal, že pokud to pohasne, s příštím bliknutím se posune PWM o 1. Takhle nějak to v principu bylo. No a driver se postupně posunul tak, že za propadem intensity následoval nárůst nad požadovanou intensitu.
Čím dál víc o tom přemýšlím, začínám docházet k závěru, že tohle by nemusel zvládnout ani rychlý driver. On ten problém bude asi v tom, že se tam ten step-down měnič nachází někde kolem přechodu mezi kontinuálním a nekontinuálním režimem. Že bych tam měl spíš dát větší cívku.
To "pohasne" jsi určoval okem nebo z ADC? Pokud z ADC, tak ještě může být špatně něco s tím ADC měřením.
Já jsem si kdysi napsal testovací verzi, kdy zadní LEDka blikala třeba 1x za 2 vteřiny (natvrdo nastavená šířka PWM pulsu), přední svítila trvale (taky natvrdo nastavené), a tlačítkem jsem mohl přidávat šířku pulsu po jedničce nahoru pro tu část cyklu, kdy svítí obě LEDky (PWM pro situaci "svítí jen přední" zůstávalo stejné jako na začátku). No a tímto jsem to ručně doklikal do situace kdy na přední LEDce nebylo okem nic poznat.
Z toho jsem zjistil že řešení existuje, a upravoval ty různé low-pass filtry a firmware a další věci okolo ADC tak dlouho, až to regulovalo dobře.
Pohasnutí vidím pouhým okem.
Takovéhle ladění můžu zkusit, ale bude to dost složité, protože k driverovému MCU přímo není připojené žádné tlačítko. Chápu to dobře, že jsi postupně zvyšoval střídu předního světla v režimu svítí obě?
Ještě je otázka, na co bys potřeboval takovouto superrychlou zpětnou vazbu, na kterou budeš pak muset velmi přesně vyladit low-pass filtr na vstupu ADC, a kterou ti na druhé straně bude kazit kondenzátor na výstupu měniče.
Tak když na to přijde, dá se měřit proud co teče cívkou, třeba tím odkazovaným zesilovačem, a kondenzátory zapojit paralelně jen k LEDce. Takže pak bude zpětnou vazbu zpomalovat pouze cívka a ne kondenzátory.
A ten zesilovač umí nějak posunovat úrovně napětí? Protože u step-downu je potenciálně na cívce víc než na napájení MCU.
Co jsem pochopil, tak to je dělané na měření na high-side a leze z toho zesílené napětí na měřícím rezistoru. Takže ano, podle datasheetu umí.
Tak koukám, že si tyhle high-side proudové snímače berou napětí přímo z plusové měřící nohy. Takže je otázka, jestli by to vůbec mohlo s step-down měničem fungovat. I když minimální napětí tam je 2,5V, což je více než propustné napětí většiny bílých diod.
Tak jsem našel součástky, kterou jsem hledal. To co potřebuju je "obyčejný" operační zesilovač. On ho asi v sobě má i ten ATTiny, ale asi až za multiplexerem. Takže pokud buduu stavět driver jen s jedním okruhem, není důvod nevyužilt vnitrní zesílení, ale u více-okruhovych driverů by mi ten operák dával smysl. Budu to muset nějak vyzkoušet.
Dává to takhle smysl?
Já tomu furt nerozumím - jaký je důvod nahradit měření v MCU něčím jiným, za cenu další docela velké součástky v obvodu? Podle mě přepínání kanálů ADC není problém:
ADC ATtiny je schopno udělat okolo 9k měření za sekundu při taktu 125 kHz. Kdybys měřil tři kanály, každý třikrát po sobě, první výsledek bys zahodil a další dva zprůměroval, dostaneš se někam těsně pod 1 kHz. A to by mělo bohatě stačit i pro velmi rychlou regulaci, pokud by ti ji vůbec výstupní kondenzátor dovolil spolehlivě provádět.
Jenže takhle to měřit mi ADC jaksi nedovoluje. Musím dělat nějakých, myslím, 16 měření naprázdno a pak dalších 16, které se průměrují, aby z toho lezla rozumná čísla. To mi rozhodně nedává frekvence kolem kHz.
Pokud používám to zesílení na ADC na driveru, kde je jen jeden okruh, pak je to v pohodě. Tedy aspoň si to myslím. Úplně podrobně jsme to nezkoumal.
Tobě stačí i v diferenciálním režimu udělat, jak píšeš, tři měření a lezou z toho rozumná čísla? Mně prostě přijde, že to zesílení tam dělá celkem bordel ve spojení s přepínáním vstupů.
Psal jsi, že používáš na jeden kanál single-ended režim, jak přesně to používáš? Bez toho zesílení ti z toho musí lézt hodně malé hodnoty, ne? A nebo tam musí být velký rezistor.
Dívám se do zdrojáků, a skutečně jedno měření zahazuju a pak dvě sčítám. Lezou z toho rozumná čísla kromě případu, kdy jedu na nejslabší noční režim - 150 mA na přední LEDce už v single-ended režimu dává hodnotu ADC myslím 4 nebo 5, takže to už se reguluje těžko, a je trošičku vidět, kdy zadní LEDka bliká.
Při single-ended měření, 1.1V interní referenci a 0R033 měřícím rezistoru odpovídá nejnižší bit ADC proudu asi 32 mA. Při diferenciálním měření s 20x zesílením je LSB zhruba 1.64 mA.
Takto to mám a takto to funguje bez blikání s výjimkou toho nejnižšího režimu přední LEDky. A pak teda ještě beru jako jeden stav že zadní LEDka svítí, i když může svítit různými proudy. Takže při změně intenzity zadní LEDky je vidět změna intenzity přední. Protože ale v nočních režimech používám druhou intenzitu jen na brzdové světlo, vidím velmi mírnou změnu jasu jen když zmáčknu nebo pustím brzdu. Dalo by se to obejít podobně, ale nechtělo se mi to ve firmwaru řešit.
Zajímavé. To by mě zajímalo, co dělám blbě, protože mně tak málo měření nestačí.
Teď to přeprogramovávat nebudu, to by zabralo zase moře času. Jestli se někdy dostanu k tomu, že vytáhnu elektroniku z rámu (to je vždy operace celkem na dlouho), tak tam vrazím cívku s větší indukčností. Je to pro mne poučení pro příště, nedávat malé cívky, když hrozí ovlivňování od ostatních okruhů.
Hele, ty tomu kontinuálnímu režimu připisuješ téměř magické vlastnosti. :) Měnič si bude v pohodě měničovat i v nekontinuálním. Pokud budeš hodně daleko, naroste ti ripple, ale to ti může být dost jedno, protože u menších proudů to neohrožuje maximální current peak LEDky a ve frekvencích měniče je to jinak úplně jedno (máš na vstupu ADC low pas, že jo? :-p ).
Smysl kontinuálního režimu je slušné chování pro účely regulace. Ale pokud reguluješ přes procesor, máš nesrovnatelně víc možností, jak to vyřešit.
Co mě tak napadá k tvé záhadě (a třeba i pro příště):
Když měříš diferenciálně, měříš skutečně napětí přímo na měřícím odporu? Tj. dva spoje od odporu k + a - pinu ADC, po kterých neteče žádný proud? Nebo měříš vůči jakési "zemi", na které ti lítají desítky mV podle toho, kudy se vrací proud z ostatních LEDek?
Nemáš regulační smyčku nestabilní (moc velké zesílení apod.), takže pokud ji zrychlíš kratším měřením, tak ti začne celá regulace kmitat?
Nemáš na vstupu ADC moc velkou impedanci (RC filtr s příliš velkým odporem)?
Máš obecně rozumně natahané silové cesty k jednotlivým měničům, nejlépe i s kondenzátory apod., aby ti proud do jednoho měniče neovlivňoval napětí na druhém apod? Indukované napětí od vysokoproudé cesty měniče? Odpory do gate spínacích MOSFETů? (tam si nejsem moc jistý, jestli by to mohlo škodit až takhle, ale rozhodně zákmity na řízení gate není nic, o co stát) Pokud má AVRko samostatný napájecí pin pro ADC, hodí se jej oddělit malým odporem nebo indukčkou/feritem (+ vhodný kondenzátor u něj) ... atd.
Díky za rady, o něčem jsem věděl, o něčem ne :)
Myslím, že kontinuální režim nepřeceňuju. Však ono mi to funguje i mimo něj. Jen to nemravné chování se děje na rozhraní. A když to rozhraní posunu do nízkých proudů, které mně nezajímají, tak by se to mělo chovat mravně. Zádrhel toho nemravného chování je, že se to děje moc rychle. Ano na vstupu ADC mám low pass :)
Napětí měřím skoro na měřícím odporu, přes ten kus země by nic lítat nemělo, nemá kam. Příště udělám lépe :)
Regulaci určitě nemám nestabilní, měřím jen každých 16 ms…
Jak velká odpor má ten low pass is nepamatuju
Obecně rozumně silové cesty natahané nemám, bojoval jsem s prostorem, takže to tam létá dost všude a to si moc dobře uvědomuju, že je špatně. Ale ono to měření nebylo moc přesné ani v předešlé iteraci, kde ty cesty byly výrazně lépe vedené. Odpory do gate MOSFETů nemám.
Ta ATTiny461 má AVCC a AGND, takže ano má napájení pro ADC. Jak přesně by měl vypadat ten filtr? Takhle: https://www.dropbox.com/s/laf8edgayxbe5qt... ?
Filtr: buďto místo cívky malý odpor ~10 ohm (to je "bezpečná" varianta), nebo pokud použiješ cívku, tak si spočti Q filtru pro konkrétní hodnoty L, C a odporů, abys tam nakonec nevyrobil naopak peak. Pro L, C, sériový odpor cívky Rs a zátěž (paralelní odpor ke kondenzátoru) Rl bys měl mít sqrt(1+Rs/Rl)/[sqrt(C/L)*Rs+sqrt(L/C)/Rl] menší než asi 0,5. (ještě tam může hrát roli i ESR kondenzátoru, ale to už si kdyžtak dopočti sám).
Ještě bych přidal ovlivňování civek navzájem svým polem.
Jinak ale některé věci z toho jsou "nice to have", ale ne úplně nutné: pro srovnání - já nemám žádný odpor do gate, a vlastně ani pull down - to zajišťuje ten driver přivedením třetího stavu na vstupní pin. AVCC mám propojené s VCC, akorát mám poblíž velký 10uF kondenzátor k zemi.
Co bych fakt příště udělal líp by bylo lepší oddělení vysokoproudých cest. Ale i tak mi zem u analogového vstupu lítá proti zemi baterky tak maximálně o několik málo mV - velmi blízko hranici přesnosti mého měřáku. Určitě ne desítky mV.
Naopak kmitání regulace pozoruju v tom režimu kdy přední LEDka svítí a zadní má blikat - na té zadní pak to bliknutí v délce cca 60 mS je viditelně rozvlněné. Ale u mě je rychlost regulace kompromisem, kde na druhou stranu získám to, že nemusím nejdřív odměřit hodnoty PWM pro očekávané proudy jednotlivých LEDek v jednotlivých kombinacích, ale prostě to nechám na tu hodnotu doregulovat. A to i v režimu "světelné houkačky", kde potřebuju dokonvergovat fakt rychle.
Ještě mě napadlo - já furt vidím jako zdroj problémů ty kondenzátory na výstupu - není to náhodou tak, že ten měnič na začátku bliknutí musí pracovat fakt hodně, aby nejdřív nabil ten výstupní kondenzátor a začalo to svítit, a až už to svítí, tak se očekává daleko menší výstupní energie? Takže když by se to regulovalo příliš rychle, tak by se mohl regulátor i snažit vykrývat tyto špičky s každým bliknutím, a tím pádem by nikdy nedosáhl dlouhodobé stability?
Já se to snažím obejít tak, že mám "pomalé" kanály ADC (napětí baterky, senzor osvětlení, ...) a "rychlé" kanály. Rychlé měřím furt dokola, pokud jsou příslušné výstupy zapnuté. A po každém tiku časovače případně změním stavy LEDek (bliknutí), změřím pomalé kanály, a až pak se vrátím k měření rychlých. Takže možná mi těch pár stovek mikrosekund od zapnutí měniče do prvního měření jeho zpětnovazebního odporu umožní vůbec tento přechodový jev nevidět.
Jasně, jsem prostě psal co mě napadlo, třeba ty gate odpory netvrdím, že jsou nutné, záleží na tranzistoru a charakteristice buzení atd. Jsou potřeba jen kdyby měl obvod dělat zákmity. Na druhou stranu rozumně malý odpor (podle frekvence a náboje gate) nemůže uškodit.
Ad vysokoproudé cesty: ty mV měříš normálním multimetrem? Na to je potřeba kouknut osciloskopem, jinak to není příliš vypovídající.
Kondenzátor: pokud reguluješ LEDku, není v principu kondenzátor vůbec potřeba -- pokud ti ripple proudu nepřesáhne povolený peak proud LEDky. Na LEDce uvidíš stejný ripple jako na cívce (LED sama o sobě dost dobře drží napětí bez ohledu na proud). Kondenzátor může o něco snížit rozkmit proudu na LEDce. Odezvu taky nějak ovlivní, ale alespoň u velkých proudů to podle mě nebude moc významné, protože budeš rád, když ti kapacita vystačí na frekvenci měniče. Regulační smyčku máš v AVRku o několik řádů pomalejší. Ale koneckonců zkus si to spočíst nebo nasimulovat, to by neměl být moc velký problém. Každopádně opět, pokud znáš charakteristiku řízeného obvodu, můžeš nastavit regulaci tak, že nebude kmitat a zároveň bude rozumně rychlá (v rámci přesnosti, se kterou tu charakteristiku znáš. V tom máš mnohem větší prostor k nastavování, když reguluješ procesorem.
No, měřím multimetrem. Nic jiného nevlastním.
Ale kdyb měl někdo tip na rozumný levný malý osciloskop (ideálně jen USB se zobrazováním na počítači, v mém případě komplikovaný o podmínku že to musí být 100% funkční pod Linuxem), nechal bych si říct :-)
K tomu kondenzátoru a frekvenci: já mám frekvenci 125 kHz a kondenzátor 68 uF na velkou LEDku (proudy od 150 do 3000 mA, napětí na LEDce tak od 2.8 do 3.3 V). Jak moc takový kondenzátor bude ovlivňovat výsledek (třeba zpožďovat regulaci)? Já se přiznám že jsem to nepočítal, našel jsem na webu "step-down calculator", zadal tam hodnoty, trochu je zkusil poměnit abych viděl jak moc a kterým směrem se to hýbe, a podle toho stanovil jak velký chci kondenzátor a cívku.
něco jako http://dx.com/p/bm102-bm102-50mhz-2-ch-usb... ?
No, něco takového. Akorát jsem nikde neobjevil, jestli to umí fungovat pod Linuxem. A na DX na to nejsou žádné recenze.
To už bych se spíš podíval na
http://dx.com/p/ds0201-2-8-lcd-pocket-mini...
což má sice o něco horší parametry (sample rate, délka sond, ...), ale zase je to autonomní a umí to ukládat waveformy na SD kartu.
Mozna radeji jeho modernejsiho kolegu
http://www.ebay.com/itm/SainSmart-ARM-DSO203...
Uvnitr je open source a existuji i aleternativni firrware. Musim ale varovat - ma to desne nepohodlne navrzenou ergonomi ovladani :-( Skoda
A zajimave vypada i tenhle
http://www.ebay.com/itm/Digital-Storage-QDSO-3...
Rozhodne ma nejvyssi vzorkovaci frekvenci akorat je jednokanal...
http://yveslebrac.blogspot.cz/2008/10/cheapest...
Tohle má příliš malou sample rate bych řekl - ADC v AVRku umí měřit do těch necelých 10kHz.
Ale zase je na tomto zajímavé, že připojil ATtiny45 na USB přímo, bez další HW podpory v procesoru.
osobně neznám ani jedno, jen jsem dal pro ukojení vlatní zvědavosti do gůglu a na dx.com "small usb oscilloscope"
a vypadlo třeba tohle
jsou to zajímavý hračky, jak moc je to skutečně použitelný ale neposoudím ...
ale třeba to vezmete jako inspiraci na vlastní tvorbu
Softwarove USB na AVRku neni zasadni problem pres projekt V-USB (drive zrejem avrusb) http://www.obdev.at/products/vusb
ale podobnych projektu je nekolik.
Omezenim je pouze USB LOW speed, krystal 12 MHz (16, 20 a mozna jeste nejaky) nebo 16.5 MHz z interniho PLL oscilatoru na ATtiny85.
Hlavne ma ale obsluha preruseni naprostou prednost pred vsim ostatnim, zakazat preruseni nesmis (tusim) na vic nez 2 us, zatimco preruseni od USB ti muze sebrat procesor radove na 100 us, takze programovani casove citlivych veci se stane obtizne, neco pak vubec nepripada v uvahu.
Kazdopadne to celkem funguje a je to elegantni zpusob, jak jednoduse vyrobit periferii k soucasnemu PC.
Snazit se takhle resit osciloskop mi jako dobry napad nepripada, vetsi limit nez sample rate (ozelis-li rozliseni a presnost muzes frekvenci zvysit) bych cekal v datove propustnosti takovehle USB komunikace.
Kalkulačky budou zřejmě počítat s odporovou zátěží, ne s LEDkou, takže velikosti výstupního kondenzátoru nebudou dávat moc smysl. Záleží i na konkrétní LEDce. Třeba 3A cree mají ve vysokých proudech diferenciální odpor pár desetin ohm. Což znamená, že kondenzátor bude pravděpodobně vcelku zbytečný.
Pokud vyjdu z 220 uH cívky, co máš na stránkách, tak při 10 V -> 3V to dává nějakých 70 mA ripple, tedy na LEDce se při zmíněném diferenciálním odporu změní napětí o nějaké desítky mV max. Při tomhle rozdílu napětí taháš z 68uF kondenzátoru něco jako 20 mV * 68 uF * 125 kHz ~ 200 mA. Teda ve velkých proudech zanedbatelné. V malých to něco udělá (navíc bude větší diferenciální odpor), ale mám pocit, že tam zas rozkmit proudu ničemu nevadí. (Snad to je správně, ale moc na to nespoléhej a klidně mě někdo opravte ...)
Víc se mi to teď počítat nechce, promiň. Ale ono to principiálně není moc těžké, IMO stačí kouknout třeba už jen na popis na Wiki, který by pro většinu věcí měl stačit. Nebo existují hromady pěkných AppNote, co na tebe vypadnou z vyhledávače ...
Doporučení na levný osciloskop bohužel nemám (i u drahých bych s doporučováním konkrétního docela váhal), ale pokud chceš něco, co má trochu smysl ...
Sample rate menší než pár desítek Ms/s nemá dneska prakticky vůbec význam. Nezapomeň, že teoreticky (!) maximální frekvence je půlka samplerate, prakticky míň, protože tam taky potřebuješ nějaký lowpass, abys nekoukal na blbosti. Dá se sice kouzlit s oversamplingem nebo jiným podobný zneužíváním nyquista, ale to bych nepovažoval za běžné použití scope a navíc to za potřebuje stabilní samplerate apod.
Druhá věc je, že u osciloskopů (obzvlášt digitálních) složených z "náhodných" součástek jen aby byly nějaké parametry dost hrozí, že si nikdy nebudeš moc být jistý tím, jaká je souvislost mezi obrázkem na obrazovce a realitou. Čím blíž uváděné maximální frekvenci, tím hůř.
Pokud se chceš vejít do ceny pár tisíc CZK, skoro bych ti doporučil kouknout po nějakém starším bazarovém, klidně i analogovém scope. (Jsem teď schválně kouknul na ebay a zdá se, že v cenové hladině kolem 100 EUR se jich pěkných pár nabízí ... dokonce i třeba (náhodný odkaz, nemám na to víc názor) http://www.ebay.com/itm/hitachi-oscilloscope-V... , kde už je dražší poštovné ...)
Problém s analogovým scopem je velikost. Nemám už moc kam svoje krámy dávat, a USB krabička je přecejen něco jiného než těžká analogová potvora s CRT obrazovkou.
Njn, to je pak těžký. :)
Mmch, co CRT obrazovka, ale taková zpožďovací linka (http://www.amplifier.cd/Test_Equipment/Hewlett... ) ... Ta na obrázku je ještě celkem drobek, měl jsme kdysi v ruce nějaký starý vysokofrekvenční scope, kde tohle tvořilo zhruba 2/3 objemu i hmotnosti celého osciloskopu. :)
Což o to, já jsem kdysi měl desku ze starého počítače, kde na principu zpožďovací linky bylo něco, čemu by se dnes přibližně řeklo "dynamická paměť".
dle vypraveni pana z Tesly Bratislava mely prvni kalkulacky pouzite tyto "pameti". pry to melo 7000
(sedum tisic) zavitu a tvar "nuly" takze tomu rikali "stadion"
jo to byly casy kdy lyze byly drevene, svetry vlnene.....
http://en.wikipedia.org/wiki/Core_rope_memory
A co tenhle projekt na kickstarteru: http://www.kickstarter.com/projects/751733865...
Vážně o tom uvažuju :)
Proč ne. Škoda, že neukázali, jak chtějí postavit analogovou část a co používají za ADC. Pokud se jim analogový vstup povede, mohlo by to být zajímavé. (50 MHz na 100 MS/s je spíš výpočet, než parametr vstupů, 20 mV/div, tj. ~ 0,5mV max rozlišení, pokud je to 8bit, není úplná špička, ale může stačit).
Docela škoda mi na podobném projektu přijde omezení na 2 kS paměti. To je pro spočítání spektra dost málo (i když pravda, spousta drahých scope je na tom podobně zoufale). Pro logický analyzátor to bolí ještě podstatně víc. Nevím jaký důvod měli nepřidat k tomu XILINXu externí RAM, ale přijde mi to dost podstatná nevýhoda.
Takhle z kickstarterových informací mi to po hardwarové stránce připadá dost neodhadnutelně, ale alespoň by to mohlo být zajímavé ze softwarové stránky.
Zkus jim napsat, třeba prozradí víc. Tomu, co píšeš rozumím, ale sám bych takovéhle odhady dohromady nedal. Mně na tom osobně dost vadí, že na to, aby to fungovalo s iOS zařízením, je potřeba jailbreak. Takováhle zařízení se dají provozovat určitě i bez jailbreaku. Snad to časem vylepší.
Už jsem na kickstarteru viděl nějaký podobný projekt, kde byl osciloskop jen jedním z programů dané desky, ale mnohem dražší. Zkusím to najít.
(pokud ti vadi nutnost jailbreaku, proc si kupujes Apple?)
Protože na všechny normální požadavky, které na telefon mám, jailbreak nepotřebuju.
Svůj první iPhone jsem musel jailbreakovat a odblokovávat, protože se tady prostě koupit nedal a já ho měl ze států (tedy blokovaný na AT&T). A byl to celkem opruz to s každou novou verzí systému dělat. Jo hračičky pěkný, ale teď mám telefon na používání ne na hraní si s ním. Ten současný jsem koupil normálně tady, takže jailbreak nepotřebuju. A ani nechci, je to čím dál tím složitější a nic by mi to nepřineslo. Krást programy nechci. Systém už za ta léta umí vše co od jen požaduju.
Tenhle projekt budiž důkazem toho, že to jde i bez jailbreaku: http://www.oscium.com/oscilloscopes
Jo, jasně - nic ve zlém. Jen mám jiná kritéria na výběr telefonu než ty - nepodporoval bych firmu, která je otevřeně nepřátelská vůči tomu, abych jejich produkt používal jak chci já, ne jak chtějí oni. Proto jsem si vybral tehdejší Samsung, protože oni měli natolik otevřené specifikace, že k tomu mobilu byly bez problémů a bez nějakého rootování dostupné firmwary třetích stran. Teď ještě pomalu pracuju na tom, abych se zbavil Velkého Bratra v podobě aplikací Google.
Já jsem si ji vybral, protože se mi její ekosystém dobře používá. Některé omezení to má. Ale ani konkurence není bez omezení. Pořiď si k Androidímu telefonu tepák… Nebo se něco změnilo a Android už má podporu Bluetooth smart? Hromada geniálních programů je jen pro Mac nebo iOS. Třeba TextMate. Když pustíš na Macu jiný systém než Mac OS X, bude výdrž na baterku vždy slabší, přestože budeš mít všechny potřebné drivery.
Kdysi jsem také prosazoval otevřenost za každou cenu, dnes mám jiné hodnoty. Třeba použitelnost a promyšlenost UI :) Myslím počítače obecně, ne jen telefony.
No na diskuzní stránce se k otázkám ohledně analogové části (jak jsme pochopil, tak dokonce od lidí, co jim už něco poslali) vyjadřovali dost málo, tak nevím jestli by to mělo smysl. Pokud by chtěli ukázat, co mají, tak to udělají. Já osobně si podobný scope stejně pořizovat nechci, jestli bych rozšiřoval svoje vybavení, tak spíš něčím alespoň o řád rychlejším (a taky alespoň o řád dražším, njn).
Tak jsem v otázkách na kickstarteru dočetl, že ADC mají 8-mi bitové.
Jo, koukám že zrovna začli odpovídat. :) 8bit není pro osciloskop nic špatného, to nemá být voltmetr. Větší rozlišení může mít někdy smysl pro spektra (kde má smysl koukat na napětí v log škále), ale to je stejně zabité malou pamětí.
50 MHz je tedy šířka pásma analogového zesilovače. Zřejmě tam není žádný další filtr(?). Tedy pokud nemají v záloze nějaké kouzlo, bude cokoliv na vstupu, co přeleze 50 MHz (tj. půlka samplovací freq.) zobrazeno do nižších frekvencí. Neumím si úplně přebrat jak moc to bude v praxi vadit, protože běžně mají osciloskopy samplovací frekvenci výrazně nad šířkou pásma vstupního filtru.
Z mého pohledu je i těch 20 MHz, které to bude nějak rozumně zobrazovat až až. V současné době ani nevím na co bych takovou frekvenci využil, protože to co bych případně chtěl vzorkovat bude mít max stovky kHz.
Jasně, však já neříkám, že to nestačí. Jen mě trochu překvapuje ten nepoměr mezi pásmem analogového zesilovače a ADC. Každopádně 50 MHz spolu se zesílením několik desítek zní pěkně, o tom žádná. :)
Jinak ono i na věci, co fungují na stovkách kHz je minimálně megahertzový scope nutnost. Protože pokud je to něco "digitálního", zajímá tě často jak skutečně vypadají hrany, pokud je to třeba analogový zesilovač, tak je taky vhodné vidět alespoň řád nad jeho maximální "provozní" frekvenci, abys měl nějaký odhad, jaké má skutečně vlastnosti atd.
Ještě pár blbých otázek.
MS/s = milion vzorků / s ?
Když to má 100 MS/S a paměť na 2048 vzorků, tak to navzorkuje jen 20 us časový interval? Znamená to, že by se tam nějak měla dát snížit vzorkovací frekvence, když se chci koukat na pomalejší děje?
Jo, megasample, přesně tak. Vzorkovací frekvence bude předpokládám nastavitelná, bylo by divné, kdyby ne, ale nedostaneš z toho prostě víc než tenhle počet vzorků v časově souvislé řadě. To znamená, že pokud chceš vidět třeba 1 ms průběhu, tak musíš samplovat s někde na 2 MS/s. Což znamená, že rozumně uvidíš frekvence ve stovkách kilohertz. (A pokud tam budou nějaké vysokofrekvenční (>1MHz) zákmity na hranách třeba, uvidíš je jako kmity na úplně jiné frekvenci -- z toho co píšou mi vychází, že žádný přeladitelný filtr na vstupu nemají). Pokud ti bude stačit ještě menší frekvence, dostaneš se k uváděnému 200 waveforms/s, které umějí přenést po USB. Pokud tam je někde dvojitý buffer, nebo něco podobného, mohlo by pak jít s vhodným softem mít ~ 400 kS/s jako kontinuální data.
... jo, pokud to umí hradlové pole, tak ADC může stále samplovat na 100 MS/s, následně XILINX na data aplikuje digitální lowpass a pak se teprv uloží s požadovaným časovým rozlišením. To je asi rozumnější přístup než laditelný analogový filtr a předpokládám, že to podobně dělají i jiné digitální osciloskopy.
Nějaké znalosti o vzorkování mám ze zpracování obrazu, takže Nyquistův limit i aliasing znám. :)
Někde jsem tam četl, že samplují, pak odesílají, ne oboje dohromady. Takže jednoduchý buffer, víc paměti to FPGA zřejmě nemá.
Procesor dáva možnosti regulace, ale už ne znalosti, jak ji dobře udělat :)
Tak ono stačí pro začátek vyjít z jednoduchého pravidla, že oscilátor se od zesilovače liší ve velikosti zesílení zpětné vazby ve chvíli, kdy se její fáze otočí o 180 stupňů. :) Aneb jako vstup máš frekvenční charakteristiku regulovaného obvodu (tj. zesílení a fázové zpoždění podle frekvence) a k tomu hledáš zesílení (charakteristiku) regulátoru (PID nebo cokoliv jiného) takovou, aby ti po složení nevznikl bod, který má fázové zpoždění 180 st. a zároveň zesílení větší nebo rovné jedné. Abys obvodu rozmluvil i tlumené oscilace, mělo by to být splněno s dostatečnou rezervou (pokud najdeš výraz "phase margin" je to jednoduše řečeno právě tohle).
Výhoda digitální regulace je třeba v tom, že pokud je charakteristika regulovaného obvodu hodně závislá na nějakých dalších parametrech (třeba napětí baterie, střední proud, atd.), které jsou regulátoru známy, dá se s tím kouzlit a měnit/přepínat parametry regulační smyčky.
Ty výstupí kondenzátory se určitě nenabíjí nějakým závratným proudem, máš tam cívku, která ten proud poměrně spolehlivě drží.
No ale dokud se nabíjí, tak PWM výstup kmitá, ale přes LEDku a měřící rezistor nejde nic, čili regulační smyčka bude mít tendenci hodnotu PWM zvyšovat, a až se nabije kondenzátor a zjistí že přestřelila, tak zase zpět snižovat.
Pokud ti tohle udělá zadní LEDka když zároveň očekáváš souvislé svícení od přední LEDky, tak ta přední bude na začátku toho pulzu poblikávat.
No já mám tu regulaci tak pomalou, že by na nějaký překmit neměla ani stihnout reagovat. Vlastně pokud tam vůbec nějaký překmit je, tak by ho ani neměla zaznamenat. Blikání dělám tak, že tam nejprve na 16 ms pustím střídy, kdy ještě neteče žádný proud, a pak natvrdo střídu pro požadovaný proud na které se to při předchozím bliknutí "ustálilo". Ono k tomu ustalování (růstu na daný prud) dochází až během několika desitek bliknutí.
To poblikávání se určitě neděje od zpětné vazby, ale vzájemným fyzikálním ovlivněním těch okruhů.
Takže těch 16 ms ti vlastně nabíjí kondenzátor, a tedy tam je odběr z baterky, který nemáš ve stavu toho druhého (trvale svítícího) světla podchycený. Jaký má vlastně těchto 16 ms důvod?
Já bych fakt zkusil natvrdo přepínat mezi dvěma stavy (pomalu, třeba jedno přepnutí za 2 vteřiny):
LED A svítí s PWM=a1, LED B nesvítí
LED A svítí s PWM=a2, LED B svítí s PWM=b
Nějak bych nastřelil čísla a1 a b aby to svítilo, a zkusil jestli jde ručně upravit hodnotu a2 tak, aby na LED A nebylo vidět blikání.
Pak bych teprv řešil, jestli to do tohoto stavu jde nejen ručně nastavit, ale i automaticky zregulovat.
Jenže ono se to nabíjení kondenzátorů děje i při blikání menší intenzitou, kdy to na předním světle vidět není.
16 ms je nejkratší čas watchdog timeru.
Tenhle test zkusím :) Jen hodnoty a1 a b budou muset být celkem přesné, aby se problém dostavil. Ale to není problém zapsat to do EEPROM.
EDIT: Nejen těch prvních 16 ms, ale i zbytek bliknutí nemám na předním světle nijak ošetřený.
Tohle téma jsem teda už dlouho neotevřel, ale něco sem přidám.
Po šesti letech jsem se rozhodl trochu rozebrat elektronické centrum ze starého treka. Vždycky jsem doufal, že to nikdy nebude potřeba a nebylo.
V šuplíku mám ale už moc dlouho jakési SSC 3W emitory, co jsem tam chtěl dávno dát místo původních Luxeonů. Je to přesná náhrada, i když z dnešního hlediska jsou taky zastaralé, i Cree svítí trochu víc.
Mezitím jsem na tom přestal jezdit. No nějakou kontrolu to konečně chce. Časem jsem zapomněl, jak to přesně vypadá a co to dalo práce složit, tak se do toho teď pouštím.
Plošák nevypadá zle, ale z druhé strany je to přesně podle vzoru japonské spotřební elektroniky 70. let. Stejně tak se musí při opravě postupovat.
Vypadá to, že kdysi intenzivní používání to přežilo beze změn, kromě kosmetických detailů. Jednu závadu jsem našel - vodotěsná membrána pod spodní mřížkou před repráčkem houkačky má praskliny.
Doufám, že to bude nakonec aspoň o trochu líp svítit. Zbavovat se toho je škoda.
Zkoušeli jste někdo provozovat ATtiny (konkrétně ATtiny 25) časované interním nízkofrekvenčním oscilátorem 128 kHz?
Já jsem zkoušel naopak zvýšit frekvenci na 8 MHz, a můj programátor s tím měl problémy. Naštěstí jsem měl před zvýšením frekvence sleep, takže bylo možné zresetovat MCU a do tří vteřin začít programovat na implicitní frekvenci 1 MHz. U low-freq oscilátoru ale změna vyžaduje změnu pojistkového registru (fuse), což je předpokládám operace, kterou MCU nemůže udělat samo.
Je problém z USBASP programovat MCU nastavený na low-freq oscilátor?
Předpokládám, že na vyhřívač bot nepotřebuju extra velké frekvence, tak bych třeba mohl pár mW ušetřit.
Matne si vzpominam, ze jsem kdysi ATtiny85 na 128 kHz prepnul a potom byl docela boj prepnout to zpatky, protoze jsem tou dobou pouzival primarne PonyProg, kteremu jsem neumel rict, ze ma vkladat delsi pauzy.
Predpokladam, ze avrdude by s tim problemy mit nemel, nicmene NEZKOUSEL JSEM TO, zatim se to na nic nehodilo. Pominu-li zdlouhave programovani, takhle nizka frekvence uz se casto nehodi, pro topeni by to asi stacilo, ale treba komunikace s teplomerem Ds18b20 by uz mohla predstavovat problem.
V aplikaci, kde se vetsinu casu vubec nic nedeje muzes byt v power-down (pokud to zapojeni umoznuje) a kdyz uz se procesor na chvilku probudi, tak 1 MHz nesezere o tolik vic s ohledem na fakt, ze procesor muze rychleji znovu usnout...
Já nemůžu být úplně v power down, pokud chci topení spínat přes Timer/Counter, který v power down neběží. Takže budu mít dva stavy - power down, a "topíme". No a odběr v tom druhém jsem chtěl minimalizovat. Ale asi to nemá cenu vzhledem ke spotřebě toho topení samotného. U světel může ušetřený miliwatt pomoct, u topení s výkonem v řádu řekněme půl wattu a víc nejspíš ne.
Samozřejmě můžu nastavit watchdog na nějaké to minimum 16 ms, a tohle brát jako krok regulace, ale to už bych pro rozumné rozlišení musel mít frekvenci PWM v řádu sekund, což už možná bude cítit jako nerovnoměrnost.
Zatím jsem předpokládal že frekvenci a TOP u T/C0 nastavím tak, aby se do TOP dopočítalo za nějaký velký zlomek sekundy (třeba čtvrt sekundy), dám si přerušení při compare match a při overflow, a v přerušení budu přes ADC měřit napětí na baterce ve stavu vypnuto a ve stavu zapnuto. A z toho bych odvozoval, kdy se vypnout kvůli ochraně před hlubokým vybitím.
Kvůli prostoru nemám low-pass na vstupu ADC pro napětí baterky, takže s tímto budu muset opatrně.
No ale dobře, nechám to na implicitních 1 MHz a kašlu na to. Možná obětuju jednu desku a jeden procesor na vyzkoušení (už jsem si upgradoval firmware v USBASP, takže snad teď už půjde nastavovat rychlost programování).
Asi bych se zamyslel, kolik procent energie z celku sezere ve kterem rezimu procesor, respektive kolik procent takhle muzes usetrit.
Pokud potrebujes relativne pomale PWM, urcite bude zrat mene Idle rezim na 128 kHz nez Idle na 1 MHz. Otazkou je, zda bude vubec meritelny rozdil ve vysledne dobe, po kterou budes mit topeni aktivni...
Vyhoda procesoru DIP je, ze se daji vyndat z patice. Jednu ATtiny mi uz zachranoval kolega z prace, kdyz se zrejme zapnula fuse pro debugwire... :-/
Na procesor v desce se "vysokonapetovy" programator aplikuje tezko...
Teď jsem to doprogramoval pro Murphyho.
Nakonec jsem k časování použil Timer 0 a PWM udělal softwarové. Už se mi s tím nechtělo řešit, spínací mosfet jsem dal na výstup timeru 1. Ony jsou tam po cestě takové ztráty v tenkých vodičích, že spotřeba MCU bude zanedbatelná.
Důvody, proč jsem nepoužil WDT byly dva. 128 kHz časovač toho tiny 25 je nějaký zpomalený, takže to házelo divně dlouhé časy a chtěl jsem udělat PWM i na stavovou diodu, což s 16 ms časovačem nejde.
Zkoušel jsem s tím WDT rozlišení PWM 6 bitů, což dávalo něco přes vteřinu. Na těch Murphyho vložkách z DX to PWM rozhodně cítit nebylo. Na mých vložkách, kde vede drát přímo po povrchu a jakási výkonová regulace tam má interval cca 4 vteřiny je při nabité baterce s tenčími ponožkami cítit, kdy to hřeje a kdy ne. Jinak řečeno, z mého pohledu 16 ms WDT a 6 bitů PWM je na vložky do bot v pohodě. A to i po stránce přesnosti požadovaného výkonu.
Tady jsou moje zdrojáky, bez komentářů:
https://gist.github.com/snilard/8677343#file...
Procedura measure_intensity() měří nastavení poťáku, kterým uživatel nastavuje intensitu. Nastavení je lineární ve výstupním průměrném výkonu. Minimum jako ekvivalent 3V, maximum kolem 7 V. Měření napětí se zátěží a bez zátěže tam je proto, že při vývoji jsem to napájel přes neskutečně tenký celkem dlouhý kabel na kterém byly ztráty 0,6V. Konečné řešení toho kabelu využívá pouze 10 cm, takže tam už takové ztráty nejsou, ale to už jsem neměřil.
Kód je docela srozumitelný, díky. Akorát mě pobavilo použití cli() a sei(), ale o kus dál přímo SREG.
Ještě je teda zajímavé, že pro stav baterky používáš jen napětí na nezatížené baterce, ale asi to v zásadě dává smysl.
Pochopil jsem dobře, že od připojení baterky rovnou začneš topit? Tohle bude znamenat, že nesmíš omylem nechat baterku v topítku, jinak by se ti časem hluboce vybila.
Přemýšlím jak to udělat, aby uživatel mohl rozlišit vybití baterky od "něco nefunguje". Možná bych varovně blikal jen omezenou dobu (třeba deset minut) a pak bych se vypnul úplně.
Jo a ještě - to měření ti funguje spolehlivě? Pokud si dobře pamatuju informaci z datasheetu, tak první hodnotu z ADC po probuzení by se mělo zahodit. Ty vypínáš ADC po každém měření, takže bych myslel, že ty výstupy budou hodně nespolehlivé. No ale třeba nejsou.
Hmm. S tím usínáním a ADC jsi mi tedy nasadil brouka do hlavy. Nevím, a teď už to nezjistím, Murphy si to už odnesl. Myslím, že z toho lezla celkem konzistentní čísla nakonec (trochu mě to měření zase potrápilo). Příště zveřejním zdroják dřív :) Nějak jsem se duševně přepnul na free runing mode ADC. Poučení pro příště :)
Hluboké vybití nehrozí, je tam kontrola na nabití baterky. Po startu to začne topit a s vybitou baterkou by to po jednom cyklu mělo skočit do stavu vybité baterky.
Stav něco nefunguje nedokážu detekovat. Co by tam mohlo nefungovat?
To použití cli() a sei() je způsobené vznikem metody Init_WDT — command + c :) Napětí zatížené baterky bylo během vývoje naprosto irelevantní, moc velký odpor po cestě k MCU. Finální verze by to asi nepotřebovala. To už jsem nakonec psal :) Každopádně ono i to napětí bez zátěže vybití bezpečně detekuje.
Hluboké vybití hrozí protože sice přestaneš topit, ale furt běžíš a svítíš kontrolní LEDkou. Teda jestli dobře chápu zdroják a výstup z hlavní smyčky. Já bych to třeba omezil že po vybití bych blikal třeba 10 minut, ale pak bych vypnul všechno a uspal se navždy.
"Něco nefunguje" mám na mysli stav kdy třeba nemá baterka kontakt nebo tak něco. Jakože je třeba rozlišit stavy "něco nefunguje na nízké úrovni, ani neběží procesor" a "procesor žije, ale systém je vypnutý nebo detekoval vybitou baterku". Ten druhý dát nějak najevo třeba aspoň krátkým bliknutím.
Asi budu v budoucnu dělat něco jako tachometr, tak bych si rád ujasnil možnosti přesného měření otáček.
Napadá mně několik možností.
Varianta pro vysokootáčkové děje by byla měřit počet tiků během určitého časového intervalu. A to buď pomocí SW čítače a přerušení a nebo, a tím si nejsem moc jistý, pomocí timeru/counteru. Tahle varianta je např. na kole dost nepoužitelná.
Pro nízkootáčkové děje už vlastně implementaci mám. A to, že měřím čas mezi jednotlivými tiky. Takhle to mám udělané na kole, ale tam je granularita 8 ms a přesnost malá, není tam žádný krystal, ale pro určení intensity světla to stačí.
Pro tenhle otáčkoměr bych asi použil krystal jako zdroj frekvence MCU a časovače nastavil na něco drobnějšího. Pravděpodobně to poběží ze zdi, takže mA nebude potřeba řešit. Jinak by do hry určitě přišel nějaký nízkofrekvenční krystal nebo real-time hodiny. Což by na druhou stranu mohla být zajímavý zkušenost :)
Mam pocit, ze na VS v jednom predmetu byla zrovna realizace tachometru kola jednou z oblibenych zkouskovych otazek. Pocitani pulsu za casovy interval byla typicky spatna odpoved, protoze pri beznych rychlostech tech otacek za vterinu prilis nebude a aktualizovat rychlost na displeji jednou za minutu by taky prakticke nebylo. Nicmene otacky neceho rychlejsiho, samozrejme takhle merit muzes.
Na kole tedy urcite spise merit cas mezi dvema pulsy, nabizi se bud pracovat s hodnotou nejakyho casovace v okamziku preruseni nebo zkusit vyuzit jednotku input capture. V praxi samozrejme potrebujes i nejak omezit nejdelsi cas mezi pulsy, po kterem povazujes rychlost za nulovou, abys nemeril nekonecne dlouho.
Jako varianta zpresneni me napada merit cas vetsiho poctu pulsu, pripadne na vysledky aplikovat nejakou formu prumerovani.
Pokud by ti slo jen o rychlost (pripadne vzdalenost), asi by to slo i bez krystalu, pro aktualni rychlost velkou presnost nepotrebujes. Pokud bys chtel merit cas nebo zobrazit prumernou rychlost, pak by to urcite nejaky krystal chtelo.
Chtěl bych aby to měření bylo konzistentní v čase, takže bych krystal použil. Jinak děkuji za potvrzení myšlenek. Na kole mám udělaný low-pass, myslím 3/4 minulé rychlosti + 1/4 aktuální rychlosti.
Spíš by mě zajímalo, jak plánuješ řešit displej - nějakým tím HD44780?
Asi nějak takhle: http://www.hwkitchen.com/products/lcd-display...
Co to má za ovládací čip, netuším.
Jo, to bude tenhle. Pro ty alfanumerické v podstatě nic jiného neexistuje.
Já mám 2x16 s modrým podsvícením asi za 3 eura z DX. Ale furt se mi to zdá velké na to, aby se to rozumně vešlo pod přesmykač.
Kde se dají koupit mikrospínače v nějakém širším sortimentu?
Navrhoval jsem si topítko do bot s tím, že bude mikrospínač 6x6 mm SMD s výškou těla tak 2.5 mm a výškou tlačítka asi 3 mm nad to (vymontoval jsem jich asi šest z nějaké staré elektroniky a navrhoval jsem to podle nich). No ale teď se dívám, že ani v GES, ani v GME takové nejspíš nemají. Nejbližší tomu jsou tyto:
http://www.ges.cz/cz/elektronicke-soucastky...
ale ty mají brutálně vysoké tělo (asi 4.5 mm) a o dost širší to tlačítko (asi 3.5 mm proti 2.5 v těch recyklovaných). Ty recyklované ještě navíc mají to tlačítko gumové místo plastového, což je o něco příjemnější na stisk. Ale to bych i oželel. Co vadí, jsou ty rozměry, zejména výška těla.
Nevíte, kde by měli širší sortiment?
Tohle by se nesneslo? http://www.gme.cz/p-b17310-p630-143
Kdyby se nad to do díry ve stěně krabičky dal štift, co by malinko trčel ven a uvnitř měl osazení, aby nevypadl, mohlo by to tam pasovat.