Přesun na Google Apps

Tak jsem včera po měsících odkládání konečně slil svůj původní Google účet se systémem, který mi běží v rámci Google Apps na doméně. Bylo to věru potřeba, protože v tom byl už šílený nepořádek. Nicméně se to neobešlo bez zádrhelů, služba Bloggeru nešla přesunout přímo... vzal jsem to podle návodu v helpu a nějak jsem ignoroval poznámku, že po smazání původního uživatele přijdu o všechny obrázky, která na blog nahrál... a ejhle, ona to byla pravda. Takže jsem právě strávil příjemné dvě hodinky procházením všech příspěvků a ručním prolinkováváním na obrázky z Picasy. Doufám, že už to bude fungovat a vydrží navěky, nebýt mé averze k mazání čehokoliv, co už se na netu jednou objevilo, asi bych se na to vykašlal.

Na pravidelnější psaní příspěvků jsem definitivně rezignoval, prostě až bude zase potřeba něco vypustit do světa, tak to udělám. Dřív to bylo lepší... ono je to asi tím doktorandským, jak má člověk povinnost psát vědecké články, chuť dělit se se světem o zajímavosti ze svého oboru nějak opadne. Navíc to souvisí s přechodem od koníčku k práci, o mnoha komerčních projektech se zkrátka povídat nemůže.

No a když už jsem se po takové době dostal k napsání příspěvku, tak si neodpustím aspoň nějakou tu aktuální fotečku: důkaz mé pořádkumilovnosti (fotka je staršího data, nyní už přibyla další vrstva či dvě elektroniky důkladně promíchané s papíry), měření RFID tagů v EMC komoře (viz popis čtečky EXIN-1 v časopisu Elektrorevue) a konečně můj router Asus WL-520gU (ze kterého jsem volně podle návodu udělal bezva internetové rádio).

Co nového, skoro po roce?

Jee, to bylo řečí, jak jednoduchý blog pomůže pravidelnějšímu psaní. Kdepak, klasika, když není čas, tak prostě na tyhle blbinky dojde jako první. Tak jak jsem se flákal v uplynulém třičtvrtěroce? Zase ta elektronika, akorát že tentokrát už to byly spíše komerčnější projekty a věci hodně specializované. Systémy do elektrolodí a různé příslušenství, jako jsou budíky a nabíječky. A z úplně jiného soudku, ovšem mnohem blíže tématu mé disertace, firmware pro UHF RFID čtečku.

Prcek (aneb moje Eee 901) po již dříve popisovaném odbahnění ještě trochu zazlobil, jednoho krásného dne jsem zmáčkl vypínač a nic se nestalo, mrtvo. Už už jsem se těšil, že si konečně nadělím nový noťásek (stařeček, tj. Asus M6Va, už taky těžce dosluhuje, ale ne a ne umřít), jenže jsem se v tom zase začal vrtat... odešla 5V stand-by větev stabilizátoru RT8203, pokusně jsem ho přemostil 78L05 ze šuplíku a ono to začalo fungovat, takže už to tak zůstalo. No a pak ještě chcípnula baterka, přestala se úplně nabíjet. Tady domlouvání nepomohlo, koupil jsem nějaký čínský klon za $40, s kterým prcek vypadá spokojeně.

Už jsem naznačil, že moje studium by se mělo zabývat RFID systému v pásmu UHF, konkrétně metodami prostorové lokalizace tagů. Téma velice zajímavé, uvidíme, jak se bude dál dařit. Prozatím se pěkně projevuje moje zaměření praktické, nikoliv teoretické - místo simulování a modelování v MATLABu a přehrabování se v rovnicích jsem se vrhl do tvorby prototypu RFID čtečky EXIN-1, která bude sloužit k experimentování. Je tvořená modulově na čtyřvrstvých DPS... zatím asi nejrozsáhlejší věc, co jsem navrhoval a stavěl. Oživování mě teprve čeká, dosud jsem měl šanci testnout jen některé dílčí moduly.

MapGen v2.4 - teď už bez instalace

Zadařilo se mi vytrhnout z pracovního vytížení a konečně jsem dal dohromady žádanou aktualizovanou verzi MapGenu. A co je tedy nového?

Především jsem z balíku CygWin "vykousal" potřebné programy a knihovny a přibalil je přímo k archivu MapGenu, takže nyní už není potřeba nic instalovat, stačí stáhnout archiv, rozbalit a jedem. Druhá zásadní změna je, že jsem zlikvidoval konzolovou aplikaci MapGenu a veškeré funkce převedl do GUI. No a nakonec jsem opravil dva bugy, na které jsem byl upozorňován - chybějící nové úrovně 17, 18 a chybu díky změně formáty odkazu na mapy.cz (@ -> #).

Ke stažení je tedy nový MapGen v2.4 (2735 kB) (již neaktuální - viz zde). Instalace veškerá žádná, rozbalit kamkoliv a spustit. Ač změny nevypadají zvenku nějak zásadně, uvnitř softwaru téměř nezůstal kámen na kameni, takže odhaduji, že budou nějaké problémy. Prosím tedy případné testery o komentáře, příp. maily, co nefunguje tentokrát.

Jinak já poslední dobou opravdu nevím kam dřív skočit (vlastně už od začátku "prázdnin"), zlepšit by se to snad mohlo někdy kolem prosince, až skončí dva rozsáhlejší projekty. Z novinek snad jen tolik, že už jsem Ing., jako doktorand jsem se zabydlel na URELu a že brzo budu doma QRV na KV, protože transceiver už je na cestě.

---

Edit 31.7.2011: Před pár měsíci se změnil formát URL na serveru mapy.cz, s novým tvarem neumí současná verze MapGenu pracovat (viz komentáře). Prozatím funguje stará varianta, stačí rohy vyhledat na mapě old.mapy.cz a ty předat MapGenu. Otázka je, kdy mapy.cz starý systém odstřihnou, snad pak najdu čas k větší aktualizaci.

---

Edit 26.12.2011: Stará varianta na old.mapy.cz je bohužel asi definitivně pryč, takže MapGen v současnosti nedokáže určit rohy. Stahování samotné funguje, formát dat se nezměnil. Takže je potřeba WGS84 souřadnice, které mapy.cz momentálně ukazují v URL, přepočítat na UTM. Z UTM souřadnic už se dají snadno dostat souřadnice interně používané systémem mapy.cz (přepočet mapy.cz souřadnic na UTM: hodnota čísel se vydělí 32, od X se odečte 3700000, k Y se přičte 1300000). Teď to jenom implementovat a důkladně otestovat, já následující dva měsíce asi čas mít nebudu, ale zdrojáky MapGenu jsou tady ke stažení, takže kreativitě návštěvníků se meze nekladou :-)

Eee 901: vylovení, vysušení, odbahnění

Jsem šikula, to je o mně všeobecně známo. Ale tentokrát se opravdu dařilo.

V pondělí jsme byli na Vranovské přehradě odlaďovat firmware regulátoru BLDC motoru, který je namontován v loďce. Už při minulém výletu na Vranov to stálo za to, kdesi uprostřed vody, bez náhradního regulátoru a bez vesel, jsem přeprogramoval firmware, abych následně zjistil, že už se loďka nerozjede. Tehdy jsem si užil pár minut extrémního programování, než se zadařilo motor opět oživit.

Tentokrát jsem byl mnohem šikovnější. Se vším se docela dařilo, už jsme chtěli udělat jen finální zátěžový test. No a ono se potvůrka molo houpe, k němu sotva přivázaná loďka, která se houpe ještě víc... já plné ruce krámů, jeden krok... a už jsem letěl. Jednou nohou po koleno ve vodě a elegantním obloukem do vody odhozený můj miláček, servisní a cestovní noťásek Eee 901.

Žbluňklo to krásně, scéna jak z Neváhej a toč. Kolegové se naštěstí rychle vytasili s hráběmi, pod molem mohla být hloubka tak metr a půl a po možná pěti minutách hrabání dna se podařilo noťas zachytit a vytáhnout. No vypadal jak vodník, takže jsem vyndal baterku a pomalu se s ním loučil definitivně.

Odpoledne jsem se samozřejmě rozhodl, že zkusím štěstí, důkladně ho vysuším a otestuji, jestli nežije. Vrhl jsem se na něj se šroubovákem a rozkuchal na padrť, viz první dva obrázky. Vše pořádně vysušit a nechat vyschnout na sluníčku. A pak začaly ty pravé nervy s oživováním.

Nejdřív - nic. Po chvilce ukecávání najel na pár sekund s několika chybovými hláškami (logicky CMOS checksum error, pak USB overcurrent a další). Nakonec jsem se dostal až k BIOSu, to jsem začínal doufat, protože nic nebylo evidentně špatné kriticky. Akorát v displeji zůstala část Vranovské přehrady, jak je vidět na třetím obrázku. Po připojení napájení se ozvalo děsivé syčení a pískání, nicméně po minutce se vytratilo... nějaká tlumivka zřejmě vyschla.

Následoval totální rozklad displeje. Ten se skládá ze samotného LCD panelu (naštěstí nepoškozeného), pod kterým je cca 6 vrstev různých difúzních materiálů na rozvedení LED osvětlení v horní strany. Vše důkladně slepené vodou. Po vysušení a znovusložení - a připájení při té příležitosti utrženého kablíku podsvětlení - začal displej vypadat k světu! Trošku šmouhy na pozadí zůstaly, ale co.

Základní desku jsem pořádně vykoupal v isopropylalkoholu, dvousložkovým lepidlem přilepil jeden sloupek, který jsem zřejmě při rozebírání noťasu urval, a pustil se do skládání. No nebudu vás dlouho napínat, Eeečko funguje! Tedy - ťuk ťuk ťuk - uvidíme, na jak dlouho, na některých místech byly patrné stopy koroze. Kapacita baterky to trošku schytala, ale nic hrozného, dnes jsem to zkoušel a vydržela 4,5hod při přehrávání DivXů.

Ještě štěstí, že používám na práci Subversion a všechny repozitáře i tak paranoidně zálohuji, o jednu starost jsem měl tentokrát míň, nemusel jsem lovit data. Ale copak asi se mi zadaří provést příště?

MapGen v2.3 - změny uvnitř a GUI

Po dlouhé době jsem si našel den volna a dal dohromady novou verzi MapGenu. Obsahuje dvě zásadní změny: přechod z knihovny NetPbm distribuované v rámci GnuWin32 na distribuci v rámci CygWin a konečně vytvoření alespoň jednoduchého klikacího grafického rozhraní.

Knihovna NetPbm distribuovaná v rámci projektu CygWin je aktuální a řeší řadu problémů, s kterými jsem se potýkal (zejm. nefunkční pnmcolormap a chyba s dialogovým oknem u jpegtopnm). Na druhou stranu instalace CygWinu je mnohem větší kolos.

Takže kompletní postup instalace MapGenu verze 2.3:

• stáhnout a spustit setup.exe knihovny CygWin (vyžaduje připojení k internetu)
  
• proklikat k výběru balíčků (doporučuji ponechat i instalační cestu c:\cygwin\)
• vybrat Graphics/netpbm a Web/wget (automaticky se vyberou i závislé balíčky), dokončit instalaci
• stáhnout a rozbalit MapGen v2.3b (288 kB) (již neaktuální - pokračuj zde)
  

Samotný MapGen nedoznal interně nijak zásadních změn, bylo odstraněno omezení na 100x100 čtverců a přidána možnost spuštění s názvem INI souboru jako parametrem. Důležité změny jsou však v testování ErrorLevelu konverzí (nyní by měl být program funkční pro všechny možné varianty okrajů map) a ve finální konverzi na PNG nebo JPEG. Aktuální verze již nepoužívá paměťově náročnou metodu s IrfanViewem, nýbrž implementuje snížení barevné hloubky (u PNG/GIF, turistických map) na úrovní PBM a taktéž poslední konverze je zajištěna balíkem NetPbm. Výběr výstupního formátu mapy a případného snížení barevné hloubky je prováděn automaticky.

Nové je grafické rozhraní (GUI) pro MapGen. Je doufám relativně intuitivní, takže jen několik slov. Hranice mapy je možno zadat odkazy na rohy, tradičně souřadnicemi a nově též odkazem na střed a velikostí výsledné mapy, a to buď ve čtvercích 256px nebo v kilometrech dle aktuálního měřítka. Všechny výpočty souřadnic jsou zaokrouhlované, takže výsledek je plus mínus pár čtverců. Výběr aktivních vrstev zůstává, pomocí parametrů Wgetu lze specifikovat speciality jako Proxy server na místní síti. Tlačítkem Uložit INI soubor se vytvoří INI pro Mapgen, tlačítkem Spustit MapGen dojde k vygenerování INI a přímo k zavolání skriptu mapgen_start.cmd v aktuálním adresáři. U názvu mapy se nesmí použít diakritika a mezery.

Snad jen pro úplnost doplním dva časté dotazy. Odkazem na mapu je míněna adresa zobrazovaná při prohlížení na www.mapy.cz. A vygenerovaná kalibrace pro OziExplorer neobsahuje Moving Map parametry, nezbytné mj. pro správné zobrazení oblasti mapy v náhledovém okně. Proto je po vytvoření mapy nutné ji otevřít v OziExploreru, odklepnout varování a MAP soubor znovu uložit - tím se MM parametry dopočítají.

Veškeré připomínky piště prosím do diskuze, zejména GUI je první betaverze a bude nejspíš obsahovat nějaké chybičky, které opravím co nejdříve poté, kdy je testeři najdou :-). GUI prozatím neumí jednu poměrně zásadní a žádanou věc, a to dělení velké mapy na díly s přesahem. K tomu se dostanu snad zase někdy příště.

---

Edit 18.5.2009: A máme tu opravy prvních drobností. Verzi 2.3 nahrazuje verze 2.3b, jsou přidány nové vrstvy map (base-n, relief-h), funguje generování správné přípony fotomap pro Oziho (musí být jpg, ne jpeg) a přibylo zaškrtávátko Resamplovat PNG na 256 barev - to bylo doteď vždy automatické, nyní je to volitelné. Resamplováním vznikne podstatně menší obrázek, takže se lépe nahrává a lépe se s ním manipuluje. Na druhou stranu při proložení reliéfů to už dopadne s barvami docela zle, takže teď je možnost volby.

---

Edit 20.7.2009: Na mapy.cz trošku přeházeli obsah řádku se souřadnicemi, jako první rychlé řešení nefunkčnosti detekce souřadnic v odkazech v GUI je možné ve zkopírované adrese nahradit @x= za #x= (zavináč před x za křížek). V příští verzi GUI to opravím.

Hladinový spínač s tlakovým senzorem

Mým příspěvkem do letošní soutěže Freescale Technology Application byla experimentální potvůrka, nazvaná Hladinový spínač s tlakovým senzorem. Článek popisuje realizaci hladinového spínače, využitelného např. pro malou domácí vodárnu. Jako senzor úrovně vodní hladiny v nádrži je využit tlakový senzor z řady Freescale MPXV5004G.

Můj kompletní článek si můžete přečíst na HW serveru. Jsou tam i Eagle desky a zdrojáky pro AVRko. Konečně jsem si navykl psát nastavení pojistek do zdrojáku, je to pohodlí, když se po pár měsících vrátíte k projektu a bez přemýšlení můžete napálit ELF v AVR Studiu do procesoru se vším všudy.

ALVA-1: Nestíháme!

Ač dělám co můžu, nestíhám poslední dobou snad už vůbec nic z aktivit "navíc". MapGen čeká na opravu chybičky a rozšíření, hromada zajímavých projektů je rozpracovaná a já nevím, kam dřív skočit.

S rádiem je to podobné, ale děláme co můžeme. Na fotce můžete vidět prototypovou prkenní konstrukci přijímače. Vlevo nahoře jsou vstupní filtry, pod nimi první směšovač a post-mix zesilovač, následuje ovládací panel. Vpravo pak filtry pro SSB a CW (na sobě), mezifrekvence s BFO a reproduktor. Uprostřed nahoře je pokusná nízkofrekvence a mezi reprákem a panelem je blok DDS. Základní systémy a software jsou tedy hotové, na důkladnější otestování a vychytání much zařízení zatím ještě čeká. Vašek pracuje na vysílací části, kompresor, směšovače a nově též výkonový zesilovač jsou již také navrženy a převážně otestovány.

Hotová konstrukce na diplomku určitě už nebude, ale rádi bychom oživili všechny potřebné bloky. A v létě pokračování. Následující fotky jsou ochutnávkou možností ovládacího softwaru s grafickým displejem - rádio se mimo jiné bude umět samo oměřit a zobrazit charakteristiky jednotlivých filtrů, takže pro konstrukci nebude třeba na dolaďování prakticky žádného VF měřicího vybavení.

ALVA-1: V půlce vývoje?

Tak práce na KV transceiveru ALVA-1 pomalu pokračují. Jeden dva poslední moduly a budeme schopni konečně otestovat finální verzi příjmu. Prozatím mám oživené a otestované moduly kmitočtové syntézy a mezifrekvenčního zesilovače s demodulátorem (na obrázcích), spínaného směšovače, pokusný bastl řídicího panelu (prototyp se bude vyrábět v horizontu týdne až dvou) a nějaké smetí okolo. Vašek OK2VAS má navržené a naladěné vstupní pásmové propusti a především krystalové mezifrekvenční filtry včetně impedančních přizpůsobení, dále pak část vysílací cesty. Po dokončení post-mix zesilovače a nového řídicího panelu by měla být RX cesta hotová.

Řízení bude realizováno procesorem ATmega128, první náhled obsahu grafického displeje ukazuje obrázek. Stále ještě zůstává moc a moc práce, ale zatím věříme, že kompletní prototyp (bez mechaniky) stihneme do státnic, tj. někdy do června.

Filtry v Ansoft Designeru

Při vývoji našeho krátkovlnného rádia Alva jsem se rozhodl pro lokální oscilátor realizovaný formou DDS. Na výstup těchto obvodů je třeba navrhnout dolní propust, tzv. rekonstrukční filtr, který potlačí všechny složky nad požadovaným maximálním kmitočtem - především různé směšovací produkty mezi generovaným kmitočtem a kmitočtem hodin.

Po problémech se všemi možnými softwary jsem se nakonec uchýlil k systému Ansoft Designer SV, který jsme na fakultě používali pro VF obvody. Stručný postup: Project - Insert Filter Design, Lowpass, Ideal Lumped, dále např. Elliptic a vybrat parametry. Ansoft vygeneruje obvod, zpravidla verzi s více cívkami, takže zvolíme Filter - Circuit - Dual. Následně nezbývá než prohlédnout, zda jsou hodnoty reálné (známé "inženýrské oko", které dnes potřebují už i zatím ještě nedostudovaní inženýři ;-) ) a provést převedení do schématu pomocí Filter - Export - Electrical circuit. Ve schématu hodnoty upravíme na běžně dostupné součástky, provedeme analýzu pomocí Circuit - Analyze a Circuit - Create Report - Standard - S21. Dál nezbývá než měnit hodnoty součástek a vylepšovat k dokonalosti.

Výsledek setkání teorie s praxí je vidět na obrázcích dole. Simulace v Ansoftu odpovídá téměř perfektně, což je samozřejmě spíš náhoda. Použité jsou nejběžnější tlumivky 220nH z GME (á 6Kč) a SMD kondenzátory, celý obvod je na malé bastldestičce. Dolní a horní propusti jsou - narozdíl od pásmových propustí - celkem necitlivé na nepřesnosti, takže ke slušným výsledkům opravdu postačují tlumivky s nic-moc jakostí a vysokou tolerancí. Sweep do 1GHz mám také, ale protože už zdaleka nevypadá tak hezky, radši ho ukazovat nebudu :-) - to je samozřejmě způsobené především dlouhými přívody k tlumivkám (musím je ještě recyklovat...) a chybějícím stínicím krytem. Orientačně měl filtr -50dB @ 300MHz a -35dB @ 600MHz.

Radioamatérské UTC hodiny řízené GPS

Na jaře proběhla u nás na ústavu soutěž Freescale Technology Application (zkráceně FTA), zaměřená na využití součástek firmy Freescale. Protože se šéfovi ve skříni válel multiplexní displej pro hodiny s nedodělaným řízením, který zbyl po jakési ne právě dokonalé bakalářce, a času bylo málo, padla volba na realizaci řídicího systému na bázi procesoru MC9S08AW16CFG (Freescale si opravdu libuje v nezapamatovatelných značeních součástek).

Hodiny byly navrženy tak, aby zobrazovaly UTC čas, s výhodou bylo využito staršího GPS modulu od Leadteku, který i při slabém signálu nepostačujícím pro navigaci vracel spolehlivě údaj o přesném čase. Navíc přímo ve formátu UTC. Zkrátka ideální konstrukce do KV vysílacího koutku na radioklubu OK2KOJ.

Některé z prací byly / budou publikovány na serveru hw.cz, dostal se mezi ně i můj článeček. Kromě toho touto cestou => dávám článek na svůj web <= (pro blog už mi přijde moc rozsáhlý). Kromě procesorů už jsem měl možnost od Freescale okusit také tlaková čidla řady MPXV5004, ale o tom někdy příště.

Jinak letos se kromě soutěže FTA chystá také FRC aneb Freescale Race Challenge. Každý soutěžící totiž dostane své malé autíčko, na školách budou autodráhy a úkolem je vytvořit software, který se pomocí akcelerometrů a dalších snímačů naučí neznámou autodráhu a pak ji projede maximální rychlostí bez toho, aby autíčko vypadlo z koleje. No není to krásná myšlenka? :-)

FM přijímač pro pásmo VHF

Po dlouhé době jsem se vrátil k mrtvolce přijímače, původně pro pásmo 144 až 146 MHz podle OK2UGS. Jedná se o superhet s dvojím směšováním, osazený dnes již těžko sehnatelným obvodem MC3362. Naladění cílového kmitočtu je řešeno PLL syntézou s taktéž postarším obvodem SAA1057. Když říkám, že jsem se k této konstrukci vrátil po dlouhé době, tak to myslím vážně - pustil jsem se do ni někdy kolem roku 2002, plus mínus rok. Návod na konstrukci vyšel v příloze Electus v roce 1999, online na internetu lze nalézt stejnou konstrukci rozšířenou o popis možností příjmu meteosatelitů.

Původní účel přijímače už dávno nahradila profi ručka Kenwood TH-F7E, ale když jsem nedávno ve sklepě torzo tohoto rádia našel, rozhodl jsem se ho oživit. Aktuálním cílem se stalo využití jako jednoúčelový přijímač NFM jedné zajímavé místní služby v okolí kmitočtu 166 MHz. Před lety jsem pohořel na nedostatku znalostí a zkušeností z oblasti VF techniky a hlavně na naprosto nedostačujícím měřicím vybavení pro VF. Nicméně znalosti se zlepšily, na zkušenostech se pracuje a přístrojů je na fakultě dost, takže tentokrát jsem uspěl.

Prvním problémem bylo rozkmitat první lokální oscilátor na kmitočtu přesahujícím 150 MHz, nechtělo se mu. Nakonec jsem přidal další odpor k zvýšení proudu do LC tanku na pinu 21, cívka L5 je realizována jako vzduchová se čtyřmi závity, paralelně k C33 jsem přidal dalších 10p. Změnou napětí na varikapu šel oscilátor přelaďovat v širokém rozmezí až do cca 170 MHz. Druhým úkolem bylo rozjet PLL syntézu. Starý AT89C2051 se mi samozřejmě nechtělo programovat, takže jsem sáhl po ATtiny2313 a obslužný program pro nasypání obsahu registrů do SAA1057 jsem napsal v céčku. Kompletní zdroják je ke stažení zde. S tím souvisela úprava resetu, ATtiny má power-on reset integrovaný, takže jsem pouze osadil pull-up.

Dále bylo nutné naladit vstupní pásmovou propust na požadované pásmo. Cívky jsem žádné vhodné nevyhrabal, takže jsem použil opět vzduchové konstrukce, které jsem pomocí spektrálního analyzátoru s tracking generátorem dotáhnul na potřebné kmitočtové rozsahy. Tím se rádio dostalo do použitelné fáze, po postupném oživení se ozvalo první zašumění. Pravda, jakost vzduchových cívek je asi pěkně mizerná a sladění se mi nepodařilo zrovna ideální, takže jsem dosáhl citlivosti pro 12dB SINAD pouze cca 3 uV místo v návodu prezentovaných 0,6 uV. Navíc od určitých vyšších hodnot dochází k zahlcení vstupu a přijímač přestává fungovat. Naštěstí to nevadí pro požadovanou cílovou aplikaci, kdy je místní převaděč silný "tak akorát".

Další dvě drobnosti se projevily až sekundárně. Prvním problémem byla přítomnost tónu cca 1 kHz v demodulovaném signálu. Po delším experimentování jsem došel k závěru, že signál proniká přes vývod ladění varikapu (23). Jeho zablokování na několika místech kondenzátory 1 až 10 nF pomohlo, po přidání dalšího se pískot vrátil, takže jsem asi příčinu úplně nenašel, ale co, po odebrání tohoto jednoho nadbytečného kondíku je po pískotu :-) . Druhou drobností bylo nesnesitelné lupání v reproduktoru při otevírání a zavírání squelche. Původní konstrukce je řešená - stručně řečeno blbě, poměrně netypickým shutdownem zesilovače LM386. Takže dochází ke zmíněnému lupání a navíc k permanentnímu mírnému šumu z reproduktoru a také ke kmitání (resp. zesilování rušení) při plné hlasitosti.

Problémy jsem vyřešil tak, že jsem místo T5 osadil MOSFET (šuplíkové zásoby daly BS170), který při napětí na gate (tj. při uzavřeném squelchi) uzemňuje signálovou audio cestu - jeho source je připojený na zem, drain na běžec potenciometru hlasitosti. Tato metoda funguje výborně, mezi gate a source jsem navíc dal 100 nF kondík, aby se lupance ještě víc omezily. No a vůbec jsem na plošňák přidal ještě nějakou bižuterii, ale ta už by neměla být tak podstatná.

Takže tohle rádio hraje. Omlouvám se za nic moc fotky a hluboce se stydím za ten zoxidovaný plošňák, před lety jsem je ještě nelakoval a tohle už se fakt zachránít nedalo. Dneska už mé výsledky vypadají o pár řádů líp :-)

Jinak já poslední dobou nestíhám nic, několik projektů pracovně-školních, no a samozřejmě práce na krátkovlnném radioamatérském all-band transceiveru Alva, který bude společným dílem mě a Vaška OK2VAS. Když vše půjde dobře, tak během následujícího týdne až dvou budeme poprvé testovat příjem.

Napájení USB portu u Ferdy

Před časem jsem si pořídil přehrávač Ferguson D-880HX a hned se vrhl na "opravu" jeho USB portu, aby bezproblémově fungoval externí USB harddisk. Propojka místo diody pomohla, nicméně disk se po vypnutí přehrávače nezastavil, port byl napájený neustále.

Původně jsem chtěl použít elegantní řešení s P-MOSFETem, nicméně se ukázalo, že i na moderních typech s malým Rdson vzniká příliš velký úbytek a disk se odmítal rozběhnout. Proto jsem sáhnul k řešení zastaralému, ale zato 100% funkčnímu - do přehrávače jsem přilepil relátko. Detaily zapojení jsou zřejmé z fotografií. Relé je spínáno tranzistorem BC546 (univerzální NPN), jeho emitor jde na zem, báze před odpor 10k na signál ON, kolektor na cívku relé a ta pak na systémových +5V. To jsou na anodě vyjmuté diody, kontakty relé spínají anodu a katodu této bývalé diody. Relé je ke krytu přilepené tavicí pistolkou. Signál ON se nalézá např. na dolním (směrem k zadnímu panelu přehrávače) kontaktu neosazeného odporu, viz obrázek. Jedná se o stejný signál, ze kterého se napájí červená LED na předním panelu.

MapGen v2.2 - aktualizace

Díky připomínkám několika lidí jsem si konečně našel čas a opravil poměrně zásadní chybu v MapGenu - při stahování okrajových částí map se nevyrovnal s chybějícími daty (PNG obrázek "Pro toto přiblížení nemáme podklad k dispozici...") a při spojování souborů s nulovou délkou spadnul. Řešení je nakonec relativně snadné, všechny prázdné soubory nahradit bílým pozadím. Realizace už tak snadno nevypadá a zabrala hodně googlení, abych se vyhnul dalším programům a mohl použít jenom příkazový interpreter z Windows XP. Jen tak pro zajímavost, nahrazení nulových souborů je provedeno pomocí příkazu:

for /f %%A in ("img_baseimage.pnm") do if %%~zA equ 0 (pbmmake.exe -white 256 256 > img_baseimage.pnm)

No není to krása? ;-) Kromě odstranění této chyby jsem integroval do nové verze MapGenu kompletní funkci programu MapCoord. V INI souboru přibyly položky LinkBottomLeft a LinkTopRight, které mohou obsahovat link na levý dolní a pravý horní roh, zkopírovaný přes funkci Odkaz na tuto mapu ze serveru mapy.cz. Linky se MapGen pokusí rozparsovat a použít, bude-li libovolná ze specifikovaných souřadnic nulová. Kromě toho může být nulová hodnota také úrovně detailu (MapLevel), pak se použije detail specifikovaný v linku. Jinak má přednost prametr MapLevel z INI souboru. Program MapGen v2.2 je opět volně ke stažení zde.

Vinculum: ovládání USB zařízení

V rámci jednoho z fakultních projektů jsem byl postaven před řešení problému, jak ovládat signálový generátor Rohde&Schwarz SM300. Požadavkem bylo řízení z autonomního systému (tedy bez PC jako prostředníka). Jako USB Host byl vybrán poměrně rozšířený a známý obvod Vinculum VNC1L firmy FTDI. Zapojení tohoto obvodu a zprovoznění není nijak extra záludné, pěkná série článků vyšla i v češtině na Pandatronu. Problémy se začnou objevovat ve chvíli, kdy chceme připojit zařízení, které není standardně podporováno, tj. nespadá mezi různé flashdisky, HID, tiskárny apod. Takovým zařízením je samozřejmě i zmíněný vektorový generátor.

Dalším problémem pak může být nezveřejněný/utajený komunikační protokol mezi USB periferií a počítačem. V tomto příspěvku bych rád nastínil vhodný software a postupy pro odhalení komunikačního protokolu neznámého zařízení a jeho implementaci do mikroprocesoru řídicího Vinculum. Nepředpokládám, že by někdo řešil komunikace konkrétně se SM300, stejně tak se rozhodně nesnažím o podrobný návod - spíš se jedná o náznaky, jaké postupy při tvorbě ovladačů realizujících komunikaci přes Vinculum použít.

Co bude potřeba: vhodný počítač, ke kterému lze požadované USB zařízení připojit, s nainstalovanými ovladači a aplikací k řízení tohoto zařízení, dále s programem UsbSnoop; bastldesku s Vinculem, připojeným přes RS232 k počítači; samotné USB zařízení a nějakou tu kabeláž. Z dokumentace pak rozhodně datasheet k VNC1L a k firmwaru VDAP, dále specifikaci USB 2.0 (ano, je to bible, ale občas se to toho člověk musí nakouknout) a samozřejmě Google. Mně zpočátku třeba velice pomohl dokument Reverse engineering Windows USB device drivers for the purpose of creating compatible device drivers for Linux.

Vinculum definuje ve firmwaru VDAP pro práci s obecným USB zařízením sadu příkazů, z nichž o komunikaci se starají Send/Read Data (DSD, DRD) a Send Setup Data (SSU). V první fázi je tedy nutné zjistit, jakým způsobem zařízení komunikuje. To lze vyčíst z logu programu UsbSnoop, ten je však extrémně rozsáhlý a nepřehledný. Pro první nástřel je lepší využít omezené demo některé z komerčních aplikací, např. SysNucleus USBTrace. Po vyfiltrování mnoha nepodstatných paketů se dostaneme k paketům, které odpovídají příkazům zadávaným z počítače. Pro zmíněný generátor SM300 jsou to pakety typu URB_FUNCTION_VENDOR_DEVICE, což představuje Setup pakety (SSU) s Request identifikátorem, který není definovaný standardem, viz USB 2.0 specifikace kap. 9.3 a Vinculum firmware manuál kap. 6.6.6. Ostatní pakety nejsou pro přenos podstatné, což se ovšem liší přístroj od přístroje - např. v ukázce komunikace s klávesnicí na Pandatronu se využívá klasického datového přenosu (DRD). Setup pakety představují vlastně "příkaz" (identifikátor Value), který může obsahovat další data, resp. o ně žádat.

Komunikaci pro jednotlivé příkazy lze zachytit programem UsbSnoop. Pro SM300 pak dojdeme např. při nastavení frekvence 300MHz k záznamu:

[1920707 ms]  >>>  URB 1618 going down  >>>
-- URB_FUNCTION_VENDOR_DEVICE:
  TransferFlags          = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000008
  TransferBuffer       = 00000000
  TransferBufferMDL    = 85c951f0
    00000000: 00 00 00 00 a3 e1 b1 41
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000000
  Request                 = 00000035
  Value                   = 00002010
  Index                   = 00000000

[1920711 ms]  <<<  URB 1618 coming back  <<<
-- URB_FUNCTION_CONTROL_TRANSFER:
  PipeHandle           = 85e64748
  TransferFlags        = 0000000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000008
  TransferBuffer       = 00000000
  TransferBufferMDL    = 85c951f0
  UrbLink              = 00000000
  SetupPacket          =
    00000000: 40 35 10 20 00 00 08 00

Z paketu je patrné, že nastavení frekvence je identifikováno pomocí vendor request 0x0035, value 0x2010, následované daty 00 00 00 00 a3 e1 b1 41, což je double reprezentace hodnoty 300 ve tvaru LSB first. Položka SetupPacket pak obsahuje celý zaslaný paket bez dat, odpovídající požadavek k nastavení frekvence, posílaný po USB, tedy bude: 40 35 10 20 00 00 08 00 00 00 00 00 a3 e1 b1 41. Tohle je jen jeden příklad z mnoha, pro SM300 dále musí následovat příkaz pro provedení nastavení (value 0x37ff).

Poslední částí realizace je pak komunikace pomocí samotného Vincula. Po připojení VNC1L k počítači, napájení a USB zařízení ve vhodném terminálu zkontrolujeme uvítací hlášku Vincula (Ver něco On-Line) a pomocí příkazů IPH a SCS nastavíme binární zkrácený režim příkazů (viz kap. 6.6 manuálu k firmware Vincula). Dále přes 2c 0d (QP2 / Query Port 2) ověříme připojení "neznámého zařízení" na portu 2 a provedeme listing připojených zařízení přes 85 20 nn 0d (QD / Query Device), kde nn je index od 0 do 15. Vinculum vrací stavovou strukturu, obsahující VID a PID daného zařízení, při nalezení správného zařízení jej vybereme ke komunikaci pomocí 86 20 nn 0d (SC / Set Device). Vyhledání dle VID/PID je důležité zejména u komplexních zařízení, jako je zmíněný generátor SM300, které na USB sběrnici obsahují hub a více zařízení rozlišených podle PID.

Nyní již je možné komunikovat se samotným zařízením pomocí příkazů SSU, pro příklad zmíněný výše (nastavení frekvence) bude tedy příkaz vypadat: 9a 20 40 35 10 20 00 00 08 00 0d 00 00 00 00 a3 e1 b1 41. Červeně je značený příkaz Vinculu (SSU + CR), modře setup paket, zeleně zasílaná data. Při úspěšném provedení odpoví Vinculum promptem ('>' + CR), podobným tvarem lze také používat setup pakety na čtení z USB zařízení, potom před promptem vrátí Vinculum data přečtená z USB zařízení.

Jak bylo už řečeno na začátku, nejedná se o žádný návod ani konkrétní postup, vše je to o "hraní si" se zkoumaným zařízením, o jeho hackování v původním významu tohoto slova. Takže pokud budete tvořit vlastní ovladače do jednočipu, který přes Vinculum bude spolupracovat s USB zařízením, přeji hodně úspěchů!

Externí HDD a Ferguson D-880HX

Konečně máme po zkouškách, tak jsem se rozhodl, že si udělám radost a svůj postarší DVD/DivX přehrávač Yamada DVX-6700 vyměním za novější kousek železa. Volba padla na Ferguson D-880HX, zejména pro jeho podporu USB2.0, vynikající možnosti nastavení titulků a příznivou cenu. Recenzi tohoto přístroje si můžete přečíst třeba na serveru DIGIlidi, je to opravdu pěkná mašinka. Přehrávání z USB flashdisku fungovalo krásně, nicméně při připojení 2,5" 80GB HDD Hitachi v USB šuplíku, samozřejmě bez externího napájení, se ozvalo jen charakteristické cvakání. Inu nelenil jsem, rozloučil se se zárukou a pustil se do kuchání Ferdových vnitřností.

Cvakání disku je způsobeno poklesem napění na USB portu při vyšším proudovém odběru, vznikajícím při roztáčení disku. Pohledem na základní desku je patrné, že mezi +5V systému a USB jsou zařazeny dva prvky - dioda v propustném směru (D6) a vratná pojistka (F1). Na diodě vzniká právě onen vražedný úbytek napětí - neměřil jsem ji, ale předpokádám, že to bude obyčejná křemíková dioda, tj. s úbytkem 0,6-0,7V, což už je pro HDD moc. Tato dioda ovšem není nezbytná. Má zřejmě zabránit napájení elektroniky přehrávače z vnějšího zařízení, ovšem z principu se na tomto USB portu nikdy externí napájení neocitne, připojovaná zařízení (flash, čtečka, HDD) jsou pasivní. Proto není nic jednoduššího, než diodu D6 přemostit drátovou propojkou. A ejhle, disk bez problémů a odmlouvání najede.

Další drobností, která se mi nelíbí, je fakt, že USB port je napájen i při vypnutí přehrávače, tj. pokud je ve stand-by režimu. Tohle vyřeším hned, jak se mi pod ruku dostane nějaky P-MOSFET, kterým bude možné napájení spínat. Domácí zásoby zklamaly.