Více takových článků!
Pracuji aktuálně na modulu pro dálkové ovládání, akorát místo 433 Mhz jsem použil bluetooth modul, abych mohl zařízení ovládat telefonní aplikací nebo čímkoliv chytřejším.
Co se týče akumulátoru, pravděpodobně je nejlepší v bastlýřkém duchu recyklovat nějaké z mobilů, které budou mít požadovanou kvalitu a obsahují i ochranou elektroniku. Navíc mají docela příjemné rozměry, tvar a je jich všude plno zadarmo. :-)
Zatím rovněž nabíjím stejný modulem a mám ještě step-up modul pro "vybíjení". Ale hodlám využít následující modul, který obstará obojí a je bez konektorů. Pro nabíjení použiji programovací miniUSB co mám na desce s MCU.
http://www.dx.com/p/diy-5v-boost-pcb-module-for-mobile-power-blue-224682
Jo, pájení káblíků to je vždy něco. Někdy se káblík chytne na první pokus bez problému a u jiný baterky zase nedrží ani za nic.
Některý baterie lze použít jak jak jsou, zatímco u některých je lepší je rozebrat a napájet kablíky přímo někam na vnitřní desku s ochranou eletronikou, nebo využít jen samotný článek.
Mam otazku, niekede ( http://timgiles.free.fr/forumpics/ProMini-cut.jpg ) odporucaju prerezat cesticku k stabilizatoru, ze vraj to zmensuje odber, tu v clanku citam len o odstraneni cervenej ledky.Neskusal to niekdo? Este som nenasiel odvahu ten stabilizator takto odstavit.
pokud je cilem co nejnizsi spotreba, neni plnohodnotne arduino vhodna volba, lepsi je to na nem jen odladit a pak si poskladat cpu+periferie presne na miru:
http://nathan.chantrell.net/tinytx-wireless-sensor/
http://gammon.com.au/power
https://github.com/petervojtek/diy/wiki/Arduino-with-Very-Low-Power-Consumption
Proc jsou nazvy promennych a commenty v cestine? Vlastne jo to mix anglictiny a cestiny. Naposledy jsem takovy pristup videl na pocatku 90tek, kdy typicky progros neumel cesky a byl to derovany inzenyr.
Nevim jak ted na VS, ale takovy projekt bych neprebral pokud by si to autor neprepsal. Alespon v kodu nema cestina co delat :( Buuuu
Ve firmách možná (i když ani to není úplně ideální, komplikuje to případnou práci programátorů z jiných zemí.). U Open Source je to ovšem dost blbý zlozvyk. Zrovna nedávno po mě chtěl kamarád z Francie pomoct s chybou ve zdrojáku, luštit jména objektů, metod a proměnných bylo peklo.
Záleží na konkrétním projektu, jaké konvence si stanoví. Například víš, že existují poměrně velké knihovny (jedna je součástí Javy :), které mají komentáře německy? Důvod je jednoduchý - ten projek vznikl za přispění nějakého grantu a tam (se domnívám) požadovali docku v rodném jazyce.
Jinak používal jsem i zdrojáky s finskými komentáři, to bylo blaho, ale pořád platí - díky za ně, však on to někdo opraví, když bude zájem (já to jen převzal bez úprav :)
Mám to stejně, tak nějak jsem si zvykl na to, že zdroják je kompletně v angličtině. Včetně identifikátorů, komentářů,...
Vždycky je potřeba počítat s tím, že se zdroják dostane ven a bude s ním pracovat někdo další. I když je to domácí bastl, vždycky se může stát, že to přetáhnu do jinýho projetu, s tím se to dostane ven. A podstatný je v tomto ohledu, že neznám embeďáka, který by neuměl anglicky. Bez toho si ani nepřečte datasheet, erratu nebo aplikační poznámku...
Bylo na mašli, když jsem posledně opravoval jeden modul, ve francouzským dialektu C a dokumentace jenom v žabožroutštině. Dělalo to nějaký specifický zpracování digitálního signálu a byla to lahůdka. Autor v Québecu, přes několik časových pásem a měl dost svých starostí na to, aby hrál tři týdny e-mailový ping-pong...
Kluci, ten 8řádkový zdroják jsem úmyslně počešťoval (tj. přejmenovával proměnné z původně anglických na české samovysvětlující) v sobotu na LinuxDays, protože byl určený pro _české_ _začátečníky_ s Arduinem. Jestli se fakt z Roota teď dostane do Francie a tam s ním někdo bude mít problém, milerád mu ta tři slova přeložím, slibuju.
Dobrý den, taky se zapojím.
Myslím že tyto poblázněnosti vznikly s objevením a nepochopením bible nového
náboženství. Ta bible se jmenuje "Dokonalý kód".
Nepochopení spočívá v tom, že tato "bible" nemá tvořit dogmata a pevné hráze, ale dát generický návod na tvorbu čistě účelového a tím ve své nahotě dokonalého kódu.
Ovšem třeba jako obrázek je za tisíc slov, tak popisek nad neznámou funkcí je, s trochou nadsázky, za ušetřených tisíc sprostých slov. Čím větší projekt, tím to platí více a jestli je popisek česky nebo anglicky, je úplně mimo tématiku tvorby takového kódu, to souvisí spíše s Coding standarts a tam už je to na tom, jaké si to kdo udělá.
K výše zmíněnému důvodu, tedy aby to sedlo do přednášky na Linux Days napíšu jen jediné: "Účel světí prostředky".
uff, to jsou mi novinky!
komentare ve zdrojacich bezne vidam: frncouzsky, nemecky, ... a jeste par jazyku, ktere identifikovat neumim (ani neminim)
z toho by si sis asi hodil :)
pro mne bylo vzdy podstatne, ze zdojak samotny je citelny a dodrzuje zabehnuty CCC (CompanyCodeConvention) + jsou odkazy, linky, cisla tasku ci RQ, ze kterych vychazeji
souhlas
jj je a neni, i v dnesni dobe je dost programu co slitnou kdyz v ceste k souboru potkaji mezeru a nejsou to ani moc stare kousky a diakritika v nazvu umi take potrapit a nedavno jsem se potkal s programem co vse za prvni teckou bral jako priponu souboru, myslim ze tyhle nesvary s nami budou jeste dlouho
Obcas se i dnes stane, ze mi prijde nejaky 3x preposilany mail, aby ten puvodni text s diakritikou byl zmrsenej. A to si ho samozrejme preposilali jen cesi, u kterych se celkove spis ocekava ze maji SW co cestinu v ruznych kodovanich zvlada.
Vetsinou se (aspon v mailech) diakritice vyhybam, pokud teda nepisu na nejaky oficialni mista. Jinde je to priznavam tak podle nalady, spis ne, ale casto treba nediakriticky text obohatim diakritikou vyberove tam, kde by to mohlo menit vyznam.
To je dobrý nesmysl, běžně se mix používá. U zavedených pojmů (save, load) EN, u méně obvyklých CZ. Projekt, kde je vše v EN a obsahuje například entity popisující něco z oblastí práva, zdravotnictví apod., by byl pro většinu lidí nečitelný a ještě by se spousta lidí pohádala, jaký identifikátor tam vlastně má být (jak se překládá) a programátor by se naprosto vše musel prát nějakého neprogramátora, ale odborníka na dané téma a EN.
Nejlepší jsou hnidopiši typu Trident, kteří pro stromy nevidí les a nedokážou pochopit, v čem je přínos kreativních autorů typu Petra Stehlíka ... mimochodem, jeho články jsou skvělé ve všech ohledech ... Tridente, vyploď něco zajímavého a predhoď nám to ... rádi oceníme tvoji originalitu, invenci, preciznost, a především programátorský a dokumentační styl :-)
Pro příklady a články se čeština perfektně hodí, viz Proč psát programy česky? V produkčním kódu je to na zvážení, ale ani tam nemusí být vždy všechno anglicky.
Jediné, co bych doporučoval vždycky: udržet konzistenci (stejný jazyk) u kódu, komentářů a analýzy / základní dokumentace.
Ahoj Petře,
díky za podnětný článek, něco podobného se chystáme zbastlit taky, takže se zkušenosti hodí.
Pred casem jsem take zbastlil par domacich zarizeni (meteostanice, termostat, alarm, aj.)
komunikujici s embedded serverem (RPi) na 433MHz. Pro ev. zajemce:
http://www.pittnerovi.com/meteo
Dole na strance jsou odkazy na popis konstrukce, cele je to open hardware a open source.
Na přednášky Petra Stehlíka jsem se těšil. A to jsem ho ještě neznal. Překvapil. Vůbec nevadí, že něco nešlo, něco zapomněl, odnesl jsem si hodně. Nepovažuji se za začátečníka, pro mě nic nového, ale stálo i těch set km za to. Za mnou seděli dva kluci asi SŠ a byli taky nadšení.
Ano, je to hobby projekt v dobrém slova smyslu. Tohle je pro amatéry (amatér=nadšenec), pro ty kteří umí i vzít páječku do ruky. Vůbec mně nevadí čeština v programu, i když angličtině budu rozumět, české poznámky i názvy v rozumném smyslu, jsou mnohdy pro Čecha přehlednější.
Právě takovéto projekty dnes chybí. My, co si pamatujeme shánění UARTů, rozbory sériových komunikací, ale i třeba elektronky, těžko neseme, že jinde mají takových projektů hafo a u nás nic. A to jsme byli v bastlení velmoc. Tohle je dobrá cesta, jak lidi naučit přemýšlet, konstruovat, nejen sedět u bedny. Alespoň pracovat s moduly, když už neudělám plošák sám.
Děkuji mnohokrát za obě přednášky a tenhle článek.
P. S. Dnes přišel další dopis z Číny...
Zásadní věc, kterou jsem na LinuxDays nestihl, je říct lidem na přednášce, ať si mě najdou po přednášce na chodbě a pokecáme mocně o Arduinu a bastlení, protože to byl můj hlavní impuls, proč ty přednášky udělat - abych přilákal další nadšence a dali jsme se dohromady.
Zkusím reparát v Brně na OpenAlt, už za 11 dní. Kdo mě tam potká, oslovte mě a řekněte mi, co doma s Arduinem bastlíte!
Zdravim,
Par dni se snazim hacknout meteostanici Hyundai a nedari se, vsichni maji konstantni delku zpravy, jen ja dostavam delky v rozmezi 44 - 52 bitu. Je tedy velice slozite neco najit. Zkusim sve poznatky zverejnit a treba nekdo poradi (ale nedoufam v to), proto bych radsi koupil neco, co uz nekdo prolomil.
Dle fotky v clanku se jedna o Sencor SWS TS ci THS? Na Alze je maji oba za 200Kc a TS nema dobre komentare, asi tedy mate THS.
PC, moje cidlo je na chlup stejne, jen ma napis Hyundai a zelenou barvu a pak mam druhe nahradni sede a meri jen teplotu (blahove jsem doufal, ze to bude prochazka ruzovou zahradou).
Radius
Aha :) a jake elektro to bylo? Meri Vam i vlhkost?
V Datardu tohle vubec nevedou, maji meteostanice, ale nemaji samotna cidla, natoz vystavena.
Nasel jsem tahle:
SWS TS
http://www.sencor.cz/meteorologicka-stanice/sws-ts
Vnější teplota: -20°C až 70°C
Vlhkost NE
SWS THS
http://www.sencor.cz/meteorologicka-stanice/sws-ths
Vnější teplota: -20°C až 70°C
Vlhkost: 20% - 95% RV
Presnost asi nebude nejlepsi.
SWS TH65 - bohuzel jsem nenasel eshop, kde by ho meli, jen celou meteostanici
http://www.sencor.cz/cidlo-k-meteostanici/sws-th65
Venkovní teplota -20 - +60 °C +/- 1,5
Rozlišení teploty 0,1 °C
Rozsah měření vlhkosti 20° až 99% RV +/-5%
Rozlišení vlhkosti 1 % (asi si ma clovek vybrat jakou presnost chce)
Tento vypada nejlepe, a asi je hacknut (nebo ten THS)
https://docs.google.com/document/d/121ZH3omAZsdhFi3GSB-YdnasMjIQSGIcaS7QW6KsACA/edit
SWS 21 TS
http://www.sencor.cz/cidlo-k-meteostanici/sws-21-ts
Rozsah venkovní teploty: -20°C až +60°C
Přesnost měření: +1,5°C
Vlhkost NE
A ja mam:
HYUNDAI WSC 1925 G (darek, rekl bych ze z Lidlu, Tesca ci Kauflandu)
http://www.levneelektro.cz/p352478-zdravi-hyundai-wsc-1925-g
Vnitřní teplota 0°C až +50°C
Venkovní teplota -50°C až +70°C
Vlhkost NE
Libi se mi pouzitelny rozsah do -50, preci jen, drive nebyl problem mit -36 stupnu, posledni dobou ale i -20 na hrane staci.
Tak ted dobra rada nad zlato. Chtel bych cidlo i s vlhkosti.
Radius
Bylo to v místním maličkém elektro krámku http://www.elektroklesny.cz/
Vlhkost samozřejmě neměří, neboť je to náhradní čidlo k měření teploty bazénové vody, která má po celou dobu neměnnou 100% vlhkost.
Taky jako radius jsem myslel, že to bude jednodušší. Mám čidlo SENCOR SWS TS k meteostanici Hyundai a zdá se, že to vysílá jinak. To TS a THS bude rozdíl v humidity - H.
Strávil jsem u toho celou sobotu, čidlo vysílá OK, na osciloskopu OK, přerušení OK, ale asi jiné kódování, prostě to nejde (ani s originál knihovnami P. Stehlíka z Githubu - má tam časy 2000 a 4500 ms).
Zkuším to nahrávat z SDR do Audacitya dekódovat, ale nemohu se nemohu se zatím ničeho dopracovat....
Jinak samozřejmě perfektní článek. Děkuji.
Moje čidlo vypadá stejně, ale je zřejmě 36 bitové (http://forum.arduino.cc/index.php?topic=142871.60). Takže jsem použil program z odkazu. Taky nejde.
Problém proč to nejde, vidím ve vstupním signálu. Jedná se o AM, přijímač, nemá AVC a leze z něj velký šum. Abych to vysvětlil. Z příjímače jde impulz (0,4 ms, pak má následovat prodleva buď krátká (2,5 ms) pro log 0, nebo dlouhá (4,5 ms) pro log.1. Jenže v té "prodlevě" lezou do arduina krátké špičky - šum, které dosahují log. 1 TTL. Tím se znovu volá přerušovací rutina, jako by přicházel další impulz. A to je problém. Divím se, že to nikdo nezmiňuje. Mám dva přijímače (stejná série) a je to shodné.
Nemám log. analyzátor (už objednán), tak se na to mohu dívat jen Audacity a odhaduji.
Řešení bych viděl v eliminaci krátkých pulzů:
- Nastavení nějakých časových konstant, DPF u LM358 u RX nebo
- úprava přerušovací rutiny (ověření vícekrát) - nepočítal jsem, jak by to vyšlo časově.
Zdravím,
ten kód z odkazu mi se shodným čidlem Sencor SWS TS a i s THS funguje. Sice jsem se sním taky trápil ale nakonec se to rozjelo. Zkoušel jsem měnit nastavení a najednou to začalo přijímat. Jinak přijímač mam z Ebaye RXB6 a s tím to funguje dobře, jen nevím proč ale po pár hodinách to přestane přijímat, po resetu arduina jede zase dál. Taky hledám něco jiného ale bez výsledků. Dneska jsem narazil na tyhle stránky a přednášku tak to zkouším ale zase bez úspěchu:(
S tímhle nastavením mi to teď běhá
#define F_HAVE_DATA 0
#define F_GOOD_DATA 0
#define F_CARRY_BIT 3
#define F_STATE 1
const unsigned long sync_MIN = 4300;
const unsigned long sync_MAX = 4700;
const unsigned long bit1_MIN = 2300;
const unsigned long bit1_MAX = 2700;
const unsigned long bit0_MIN = 1330;
const unsigned long bit0_MAX = 1730;
const unsigned long glitch_Length = 300;
Ahoj, skusam len vysielat z Arduina a prijmat na SENCOR SWS 51S a nefunguje mi to. Niekde som videl, len neviem, ci k tymto sencor cidlam, ze vysielaju 3x za sebou. Tak mozno je to tym. Skusal som aj to, ale bezuspesne. Aj tak vsak neviem, aky je zaver spravy - po poslednom byte je este predpokladam glitch signal 300us a potom je tam aj koncova sync pausa a glitch signal, alebo uz nic? A pauzy medzi 3 vysielaniami su ake? (ak sa sekvencia 3x opakuje)
Pre zaujimavost, ked uz je tu digitalna stopa SENCOR SWS meteostanice, problem bol u mna v tom, ze Arduinu urcity cas trva, kym zbehne program a stanica uz to nevyhodnotila vzdy, ako spravna sekvencia impulzov. A s tymto casom pri 16MHz procesore som nepocital a mikrosekundove pauzy zistene odchytenim signalu original SWS TS senzoru bolo treba skratit. Konkretne mne dobre funguje vsetko o 10 microsec. kratsie. A na konci dat je este ina dlzka synchronizacnej pauzy - je dlhsia, ako na zaciatku. Takze casy u mna su:
int glitchLength = 500;// (a)
int sync = 3000; // (b)
int syncEnd = 4000; // (e)
int logic1 = 2000; // (c)
int logic0 = 1000; // (d)
int slowConst = 10;//skratenie vsetkeho o usec. (glitchLength = 490usec.)
_a_ b _a_ c _a_ d ___ _a_ e _a_
| | | | | | | | | | | |
___| |_________________| |__________| |______| | _ _ _ ____| |________________| |_______
Synchronising Logic 1 Logic 0 SynchronisingEnd
(Lutujem, ale s formatovanim v nahlade vs v zobrazeni sa mi nechce babrat. Lepsi je zaklad na http://forum.arduino.cc/index.php?topic=142871.msg1227950#msg1227950 )
Je pre mna zaujimave, ze aj tu a aj na odkazovanom fore su uplne ine casy.
V krásné přednášce s názvem „Arduino na 433 MHz“ na LinuxDays jste předvedl ovládnutí dálkově ovládaných elektrických zásuvek, kdy můžeme Arduinem jak poslouchat povely vysílané dálkovým ovladačem (takže vlastně máme šikovný osmitlačítkový dálkový ovladač čehokoliv s Arduinem), tak můžeme i sami vysílat povely spínající elektrické zásuvky. A jak výše uvádíte získáme tím jednoduchý, levný, elegantní a hlavně bezpečný způsob spínání i výkonově náruživých zařízení Arduinem – a ještě navíc fungující bezdrátově na dálku.
No prostě parádní náměty pro bastlení- děkuji.
Vzhledem k mým slabým programátorským schopnostem jsem se chtěl zeptat, zda někde nemáte uvedené zdrojáky - kde se načtená hodnota povelu z DO neukazuje na komunikačním portu, ale je využita k ovládání výstupů - kupř. Vaše praktická ukázka ovládání barevného LED pásku.
Doufám, že jsem to někde nepřehlédl, jen nějak potřebuji navést, jak se dá ta načtená hodnota co je vidět na komunikačním portu využít k ovládání.
Dobrý den
Jak dostanu příchozi správu teploty do proměnné serial mě ji vypíše ale jak to uložit abych stou teplotou mohl pracovat dále v podmínkach
void loop()
{
// vytvoření proměnných pro uložení
// přijaté zprávy a její délky,
// délka je maximálně 78 znaků
uint8_t zprava[VW_MAX_MESSAGE_LEN];
uint8_t delkaZpravy = VW_MAX_MESSAGE_LEN;
// v případě přijetí zprávy se vykoná tato if funkce
if (vw_get_message(zprava, &delkaZpravy)) {
// rozsvícení LED diody při příjmu (nepovinné)
digitalWrite(13, true);
// vytištění celé zprávy po znacích
// pomocí for cyklu
for (int i = 0; i < delkaZpravy; i++) {
Serial.print((char)zprava[i]);
}
// ukončení vypsaného řádku pomocí println
Serial.println("");
// zhasnutí LED diody při příjmu (nepovinné)
digitalWrite(13, false);
}
Skvělý článek a přednáška na Linux Days, díky!
Máte někdo zkušenosti s použitím 433MHz komunikace se zásuvkami EMOS P0065? Zkouším různé verze RemoteSwitch knihovny, ale nic mi to při stisku tlačítek nedetekuje. Jiná knihovna RC-switch mi při detekci vrací pro každý stisk jiný kód a v různém pořadí se pro každé tlačítko opakují 3 různé kódy. Asi mám něco špatně s časováním, ale nemůžu na to přijít. Odeslání nadetekovaných binárních kódu nemá žádný efekt. Díky.