Mam skaner Epson WorkForce DS-7500 z przystawką sieciową (Epson Network Interface Unit, B12B808451). Fajny sprzęt: szyba, ADF, duplex, a na panelu jest przycisk, po którym skaner sam wypycha skan na wybrany komputer. Wybierasz komputer z listy, wybierasz zadanie („Skanuj do PDF"), Start — i plik ląduje na dysku. Piękne.

No właśnie — „na wybrany komputer". Haczyk jest taki, że każdy komputer z tej listy musi mieć zainstalowany soft Epsona (Epson Scan 2 albo Document Capture Pro), czyli w praktyce: Windows albo macOS, zalogowany użytkownik i maszyna, która akurat jest włączona. A ja od dłuższego czasu wszystkie papiery wrzucam do paperless-ngx na domowym serwerze. Marzenie było proste: naciskam Start na skanerze, PDF pojawia się w katalogu consume, paperless robi resztę. Bez żadnego Windowsa po drodze.

Problem: żeby serwer pojawił się na panelu skanera, musi udawać komputer z softem Epsona. A jak Epson rozmawia ze skanerem — tego nie wiedział nikt. Serio, szukałem: zero dokumentacji, zero implementacji, nawet SANE zna tylko kawałek tej układanki. No to klasyka: Wireshark, stary laptop z Epson Scan 2 jako królik doświadczalny i 17 MB pcapa ze scenariusza „włącz skaner → wybierz komputer → zeskanuj dwie strony → zakończ".

Warstwa pierwsza: skąd skaner wie, że istnieję

Pierwsze zaskoczenie było miłe. Po włączeniu skaner nie robi nic — dosłownie, jeden ARP announcement i cisza. Dopiero kiedy na panelu wchodzi się w menu wyboru komputera, skaner strzela multicastem. I to nie żadnym własnościowym wynalazkiem, tylko SLPv2 — najnormalniejszym Service Location Protocol z RFC 2608. Tyle że na porcie 2968 zamiast standardowego 427, bo czemu nie ;-).

Skaner pyta (AttrRqst) o usługę service:NetScanMonitor-agent w scope PID 0145 — to, nawiasem mówiąc, USB Product ID tego modelu. Klient odpowiada (AttrRply) listą atrybutów:

(Ver=3.0),(ClientName=SERWER),(IPAddress=172.27.72.10),(EventPort=2968),(Group=0)

I tyle — ClientName to nazwa, która pojawia się na panelu. Oryginalny klient wysyła odpowiedź trzy razy pod rząd (UDP, retransmisja „na piechotę"), więc mój responder też tak robi.

Napisanie tego zajęło wieczór. Debugowanie, czemu skaner ignoruje moje odpowiedzi — drugi wieczór. Nagłówek SLP ma 3-bajtowe pole długości pakietu i policzyłem je o 3 za dużo (raz w nagłówku, raz doliczając nagłówek — double-count). Skaner nie zgłasza błędu, nie odrzuca pakietu, po prostu nazwa się nie pojawia i patrzysz w pustą listę jak sroka w gnat. Porównanie hex dump w hex dump z oryginałem znalazło winowajcę.

Warstwa druga: HTTP jak z 2004 roku

Po wybraniu komputera na panelu skaner otwiera połączenie TCP na port z EventPort i wysyła... SOAP po HTTP/1.0. Namespace http://schemas.epson.net/EpsonNet/Scan/2004/pushscan zdradza rocznik tego rozwiązania ;-).

Zdarzenia są trzy: JobList (wybrano nasz komputer), PushScan (naciśnięto Start; w body siedzi JobNumberIn — indeks wybranego zadania) i ScanEnd (koniec sesji na panelu). Na każde trzeba odpowiedzieć dwustoma z <StatusOut>OK</StatusOut>.

Przy odtwarzaniu odpowiedzi oryginalnego klienta wyszły dwa smaczki, które zostawiłem 1:1, bo z takim sprzętem nigdy nie wiadomo:

• nagłówki HTTP odpowiedzi mają spację przed dwukropkiem: Server : Epson Net Scan Monitor/2.0. HTTP/1.0 to toleruje, skaner — być może tego wymaga, nie sprawdzałem na odwrót;
• namespace w odpowiedzi to http://schema.epson.net/... — bez „s" w „schemas". Literówka sprzed dwudziestu lat, zabetonowana w firmware. Odtwarzam wiernie, razem z literówką ;-).

Niespodzianka: menu na panelu przychodzi... z komputera

To było moje ulubione odkrycie. Zawsze myślałem, że lista zadań („Skanuj do PDF" itd.) siedzi w skanerze. Otóż nie: po zdarzeniu JobList klient łączy się ze skanerem i wgrywa mu listę zadań komendą JOBW, której nie ma w żadnym publicznym kodzie. To, co widzisz w menu panelu, przed chwilą przyszło z komputera, którego dotyczy.

Dekodowanie payloadu JOBW to była osobna przygoda. Nazwy zadań są w UTF-16BE — big endian, choć wszystkie pola liczbowe obok są little endian. Zanim na to wpadłem, czytałem nazwy jako UTF-16LE i wszystko wyglądało na przesunięte o bajt; w notatkach miałem przez pewien czas wpis o „niewyjaśnionym off-by-one" ;-). Do tego każde zadanie niesie 10-bajtowy blob ustawień (źródło, dpi, rozmiar, format — panel wyświetla te parametry przy zadaniu).

A, i jeszcze jedno: jak wyślesz zepsuty JOBW, skaner nie zgłasza błędu, tylko... pyta na panelu o hasło. Żadnego hasła nigdzie nie ma. Straciłem na ten fałszywy trop pół sesji, kombinując, gdzie w NIU ustawia się hasła. Nigdzie. To po prostu uniwersalna reakcja na „coś mi się w tym payloadzie nie podoba".

Plan A umiera w trzy bajty

Na pobieranie samego obrazu miałem plan-minimum: warstwa transferu to ESC/I-2, który nominalnie implementuje backend epsonds w SANE. Miałem tylko odpowiadać na push i odpalać scanimage.

Guzik. Skaner za NIU wita się na porcie 1865 trzema bajtami, a epsonds (i epson2 też) uparcie czeka na pięć — i po timeoucie oznajmia, że skanera nie ma. Utrzymywanie forka SANE dla jednego read() wydało mi się smutniejsze niż napisanie własnego klienta. Zwłaszcza że SANE i tak nie zna JOBW ani całej strony push — więc poszedłem na całość: własny klient ESC/I-2, asyncio, zero zależności poza img2pdf.

ESC/I-2, czyli kolekcjonowanie INVD

Sesja skanowania to sekwencja komend w opakowaniu „IS" (12-bajtowy nagłówek framingu, ten akurat podpatrzony w źródłach SANE): INFO, CAPA, PARA (parametry), TRDT (start transferu), pętla IMG (strony jako JPEG), FIN. Brzmi prosto. W praktyce skaner na każde odstępstwo odpowiada lakonicznym INVD i domyślaj się człowieku, o co mu chodzi. Moja prywatna kolekcja:

• tokeny komend mają dokładnie 4 znaki: INFOx0000000 bez spacji, ale FIN x0000000 ze spacją, bo FIN ma trzy litery. Jedna spacja za dużo → token ma 13 bajtów → INVD;
• macierz korekcji kolorów to 9 bajtów danych, ale na drucie 12 — trzy bajty zerowego paddingu. Bez nich wszystkie kolejne pola się przesuwają → INVD;
• tablice gamma są trzy po 256 bajtów i wcale nie identyczne (RED == BLU, ale GRN jest inna — takie tam fabryczne kalibracje);
• PARA to dwa pakiety i dwie odpowiedzi: deklaracja długości (pusta odpowiedź!) i dopiero potem parametry (odpowiedź parOK). Nie odczytasz pierwszej odpowiedzi → strumień się rozjeżdża i debugujesz duchy.

Matryca, czyli 13 pcapów i dwa skrypty

Największy blob w PARA to parametry skanu: rozdzielczość, okno, kalibracja. Chciałem, żeby zadania na panelu mogły mieć różne dpi/rozmiary/tryby, więc musiałem zrozumieć, co się w tym blobie zmienia, a co jest stałe. Metoda siłowa: nagrałem oficjalnym klientem matrycę 13 capture'ów — po jednym na kombinację źródła, dpi, rozmiaru i trybu koloru — i napisałem dwa narzędzia.

Pierwsze wyciąga bloby PARA z pcapa (tshark składa strumień TCP, skrypt parsuje framing IS). Drugie, para_diff.py, parsuje blob na pola i drukuje tabelkę porównawczą. Gramatyka tokenów okazała się na tyle regularna, że parser mieści się w 30 linijkach:

def parse(blob: bytes) -> list[tuple[str, str]]:
    fields = []
    off = 0
    while off < len(blob):
        assert blob[off:off + 1] == b"#", f"expected '#' at {off}"
        tag = blob[off + 1:off + 4].decode("ascii")
        off += 4
        values = []
        while off < len(blob) and blob[off:off + 1] != b"#":
            c = blob[off:off + 1]
            if c == b"i":                      # 7-cyfrowy int
                values.append(str(int(blob[off + 1:off + 8])))
                off += 8
            elif c == b"d":                    # 3-cyfrowy int
                values.append("d" + blob[off + 1:off + 4].decode())
                off += 4
            elif c == b"h":                    # payload o podanej długości
                n = int(blob[off + 1:off + 4], 16)
                off += 4
                padded = (n + 3) // 4 * 4      # pad do 4 bajtów (patrz: CMX!)
                data = blob[off:off + padded]
                off += padded
                values.append(f"[{n}B {hashlib.sha1(data).hexdigest()[:8]}]")
            else:                              # gołe 4-znakowe słowo
                values.append(blob[off:off + 4].decode("ascii"))
                off += 4
        fields.append((tag, " ".join(values)))
    return fields

Trik z hashem zamiast zawartości robi całą robotę: 256-bajtowa tablica gamma to w tabelce [256B a1b2c3d4] i od razu widać, w których capture'ach jest taka sama, bez porównywania bajtów. Wyjście wygląda tak:

== #RSM
  fb_600_a4_kolor.para01.bin    600
  fb_300_a4_kolor.para01.bin    300
  adf_300_auto_kolor.para01.bin 300
== #GMT
  fb_600_a4_kolor.para01.bin    RED  [256B 07c3aa11]
  fb_300_a4_kolor.para01.bin    RED  [256B 07c3aa11]
  adf_300_auto_kolor.para01.bin RED  [256B e49b02f7]
== #ACQ
  fb_600_a4_kolor.para01.bin    0 0 4961 7016
  fb_300_a4_kolor.para01.bin    0 0 2480 3508
  adf_300_auto_kolor.para01.bin 0 0 2550 4200

I z takiej tabelki wnioski spadły same, w godzinę zamiast tygodnia: tablice gamma i macierz kolorów zależą wyłącznie od źródła (szyba ma swoją kalibrację, ADF swoją), nie od dpi ani rozmiaru. Okno skanowania #ACQ to po prostu rozmiar dokumentu razy dpi w pikselach. ADF centruje mniejsze dokumenty w poziomie, szyba kadruje od lewego górnego rogu. Czyli: mogę syntetyzować blob PARA dla dowolnej kombinacji parametrów, zamiast odtwarzać nagrane bajty. Builder w kodzie ma asserta, który przy każdym imporcie sprawdza, że dla referencyjnych parametrów produkuje blob bajt w bajt zgodny z nagranym — najlepsze 5 linijek w całym projekcie, złapały mi regresję dwa razy.

Wisienka: RE bez Wiresharka

Na koniec został drobiazg: kody rozmiarów dokumentu w blobie JOBW (żeby panel wyświetlał przy zadaniu „B5" czy „Legal"). Znałem trzy z capture'ów i szykowałem się na kolejne nagrywanie, aż zauważyłem, że bajty blobu to dosłowne kopie pól z plików konfiguracyjnych Document Capture Pro. A DCP ma eksport zadań do pliku .jxz — który okazał się zwykłym zipem z plikami INI.

Czyli: wyklikałem w DCP siedemnaście zadań różniących się tylko rozmiarem i typem pliku, wyeksportowałem, rozpakowałem i przeczytałem kody wprost z INI. Kompletna tabela kodów bez jednego pakietu w Wiresharku. Czasem najlepszy sniffer to unzip ;-).

Finał

Efekt nazywa się epson-pushscan i wisi na GitHubie (MIT, właśnie wyszło v0.9). Jeden kontener Docker, który udaje komputer z softem Epsona: odpowiada na discovery, wgrywa zadania na panel, odbiera zdarzenia i sam wyciąga obraz po ESC/I-2. Na panelu definiuję dowolne zadania — „Faktury" to ADF z duplexem w 300 dpi, „Zdjęcie" to szyba w A6 — a pliki lądują prosto w consume paperless-ngx, z właściwym uid/gid. Szyba, ADF z automatycznym podawaniem, duplex, sesje wielostronicowe, 200–600 dpi, formaty od PDF przez PNG po JPEG 2000 — wszystko przetestowane na żywym sprzęcie.

W repo leży też PROTOCOL.md — z tego co wiem, pierwszy publiczny opis tego protokołu, bajt po bajcie, razem ze wszystkimi pułapkami z tego wpisu. Jakby ktoś miał podobny sprzęt Epsona z NIU: częstujcie się. A jak wam zadziała na innym modelu — dajcie znać, chętnie poszerzę listę przetestowanych.

Skaner ma kilkanaście lat, protokół pamięta czasy SOAP-a, a mimo to całość okazała się do rozgryzienia w kilka wieczorów. Stary sprzęt ma tę zaletę, że nikt w nim jeszcze nie wymyślił szyfrowanego łączenia z chmurą ;-).

Trzy tygodnie temu, po 5 latach wymieniłem aparaty słuchowe - stare Phonaki Valeo 211 ustąpiły miejsca dwóm nowym modelom tego samego producenta z serii Versate M. Teraz czas na pierwsze małe podsumowanie.

Cała operacja wymiany rozpoczęła się niedawno, w okolicach połowy września kiedy to dowiedziałem się, że mogę się już ubiegać o dofinansowanie z NFZu do aparatów (przypominam - raz na 5 lat [ale do 26 roku życia] NFZ może przyznać do 3000zł - podana kwota dotyczy jednak osób uczących się).

Kompletując dokumenty, spostrzegłem, iż najnowszy audiogram miałem z 2005 roku - trochę stary ;-). Tak więc, w piątek 8.10.2010 w Olsztynie zrobiłem nowe badania i po raz kolejny wyszło, że mam niedosłuch na poziomie od -70dB dla 1kHz do -30dB dla 125Hz i 8kHz. Na szczęście wartości te nie pogorszyły się od ponad 16 lat. I tak oto, w poniedziałek 11.10.2010, komplet dokumentów wylądował w warmińsko-mazurskim NFZ.

Liczyłem na to, że w najlepszym wypadku odpowiedź uzyskam w okolicach grudnia/stycznia 2011. Możecie wyobrazić sobie moje zdziwienie, kiedy przysłali pocztą pismo o pozytywnym rozpatrzeniu wniosku o dofinansowanie już na początku listopada. Oczywiście nie obyło się bez utrudnień - otóż, wszystkie kwestie (np. wybór konkretnego modelu aparatu) musiałem załatwić do 23.11.2010.

W tym momencie był bodajże 3.11.2010 i rozpoczął się wyścig z czasem. Najpierw planowałem wszystko załatwić w Warszawie. Sądziłem, że nie będzie z tym większego problemu - ale szybko musiałem zweryfikować założenia. Najbardziej zaskoczyło mnie, jak trudno znaleźć punkt audioprotetyczny czynny w sobotę. Taka duża metropolia, a trafiłem jedynie na jeden punkt - na Pradze. Drugi szok przeżyłem gdy porównałem ceny konkretnych modeli w Warszawie z tymi z Olsztyna - przebicie min. 1000zł na sztuce. Trochę duża różnica.Tym samym, wróciłem do Olsztyna do zaprzyjaźnionego ośrodka, z którego usług korzystam od '94.

Kwestia miejsca zakupu została ustalona. Pytanie następne jaki typ aparatów i jakiego producenta wybrać. Do tej pory, moje trzy pary były modelami zausznymi. W związku z tym, zastanawiałem się nad modelami wewnątrzusznymi. Teoretycznie do korekcji mojego niedosłuchu można ich używać, ale dowiedziałem się od audioprotetyka, że będą one działały na granicy swoich maksymalnych możliwości. Cóż, wolę narzekać na nadmiar mocy niż na jej niedobór, więc po raz kolejny zdecydowałem się na "słuchawki zauszne" ;) OK, a na jakiego producenta? Dotychczas miałem do czynienia dwa razy z Siemensem i ostanie 5 lat z Phonakiem. Do wyboru - z uwagi na poziom niedosłuchu - miałem Siemensa, Phonaka, Oticona i Bernafona. Siemens odpadł z uwagi na to, że tak naprawdę to branduje czyjś sprzęt i aparaty słuchowe to tak naprawdę jeden z wielu różnych produktów tego producenta. Został Phonak - nie miałem z nim żadnych problemów ( w ciągu 5 lat uszkodzeniu uległ jedynie lewy rożek, który we własnym zakresie wymieniłem) więc i przy nim pozostałem - siła przyzwyczajenia ;-)

Producent i typ wybrany, audiogram zrobiony - na podstawie tych informacji komputer wylosował dla mnie model Phonak Versate M. Po wyjęciu z pudełka wygląd mnie zbytnio nie zachwycił. Wydają się większe od Valeo 211, ale to jedynie złudzenie potęgowane przez fakt, że Versate ma po prostu krótszy rożek a tym samym dłuższą "zabudowaną część". Poza tym, nie ma zwykłego potencjometru do regulowania wzmocnienia. Jest tylko przełącznik góra - dół z zakresem 10dB, skok +/- 3dB - tak więc precyzyjnie wzmocnienia tego nie ustawimy. I ostatnia rzecz - jest jeden przycisk na obudowie służący do zmiany programów i wyłączania aparatu. Nie ukrywam, że trochę mi to nie pasuje - aby zmienić np. z programu 2 na 1 mogę albo otworzyć komorę baterii i ją zamknąć (aparat się wyłącza i uruchamia z 1 programem), albo 3x naciskać guzik (pierwsze naciśnięcie - 3 program, drugie naciśnięcie - wyłączenie aparatów, trzecie naciśnięcie - ponowna aktywacja). Należy tutaj dodatkowo wspomnieć, że producent zaimplementował w tych urządzeniach opóźnienie podania sygnału na wkładkę (minimum 6 sekund, nie da się tego całkowicie wyłączyć). Na moje pytanie czemu to ma służyć dostałem informację, iż "normalni użytkownicy" włączają aparaty trzymając je w ręku, a następnie - już działające - wkładają do ucha. Tym samym narzekają że im „piszczy” Hm... ja tam zawsze byłem inny ;-)

15.11.2010 przyszedł czas na zaprogramowanie wzmocnień. Moim pierwszym zdaniem wypowiedzianym do audioprotetyka po "usłyszeniu na nowo" otoczenia było "To tak ma być?". Otóż, aparaty te w porównaniu ze starymi Valeo są bardzo ciche. Wszelkie szumy otoczenia są - po mistrzowsku wręcz - wytłumianie. Słyszysz tylko mowę i nic więcej. Hm... podobno kwestia przyzwyczajenia. Poprosiłem o ustawienie programu automatycznego jako domyślnego i wybrałem się na miasto. Pierwsze wrażenia nie były najlepsze - siedząc w samochodzie z przodu nie byłem w stanie prowadzić konwersacji z dwiema osobami na raz (tzn. z kierowcą i z pasażerem z tyłu). Aparaty chcąc "dbać o mój komfort" priorytetowały rozmówcę który był bliżej mnie, niemal kompletnie wyciszając drugiego. Wspominałem, że cały czas było było cicho?

Zanim dokonałem konkretnego zakupu, jednym z wymagań jakie miał spełnić nowy sprzęt była współpraca przystawką do transmisji dźwięku. Phonak tą "zabawkę" ochrzcił mianem Icom. Kiedyś użytkownicy aparatów mieli do wyboru tylko drogie systemy FM. Teraz natomiast, mamy małe „wisiorki” do powieszenia na szyję (patrz zdjęcie), które możemy np. sparować przez Bluetooth z naszą komórką. Jako, że wolę do ludzi dzwonić niż pisać SMSy, a w dodatku nigdy nie potrafiłem rozmawiać przez telefon korzystając z dedykowanego programu do rozmów telefonicznych, taka przystawka jest dla mnie wielkim udogodnieniem. BTW, oczywiście można do Icoma podłączyć dowolne zewnętrzne źródło dźwięku przez mini jacka 3,5mm - wtedy nasze aparaty robią za bezprzewodowe, stereofoniczne słuchawki (a w przypadku sygnału monofonicznego, dubluje go na obydwa aparaty - sprawdzone)

Wracając do głównego wątku, 15.11.2010, po powrocie do ośrodka poprosiłem o podbicie dźwięków dochodzących z tyłu i o zmniejszenie czułości programu automatycznego na zmianę warunków dźwiękowych otoczenia. Tego samego dnia, po południu wróciłem z kumplem do Warszawy. Moje wrażenia:

• słyszę dokładnie każdy szelest, każde pstryknięcie włącznikiem światła - tutaj ujawnia się dużo szersze pasmo przzenoszenia - brawa dla Phonaka.
• program automatyczny dla mnie to porażka. Podkreślam - dla mnie. Może gdyby aparatów używała osoba dla której to pierwsza para, byłaby tą opcją prawdopodobnie zachwycona, ale ja mam dokładnie sprecyzowane wymagania. Program ten – przykładowo - głupiał codziennie gdy myłem zęby. Gdy z kranu leciała woda, a ja szorowałem zęby szczoteczką, następowało totalne wytłumienie dźwięków otoczenia - nie słyszałem nawet własnego głosu! Czy oby na pewno to tak ma być? Oczywiście, zakręcałem wodę, odkładałem szczoteczkę i wszystko wracało do normy!
• piskliwe głosy dziewczyn zrobiły się jeszcze bardziej piskliwe.
• program "Rozmowa w hałasie" naprawdę daje radę - brałem udział w kilku ciut głośniejszych imprezach i o ile ja nie miałem większego problemu ze zrozumieniem ludzi, o tyle moi rozmówcy prosili bym głośniej mówił (!). Otóż odnosiłem wrażenie, że mówię odpowiednio do sytuacji – w końcu słyszę wszystko normalnie - aparaty muzykę wyciszały, głos podbijały - gdy w rezultacie okazało się, że to mnie ludzie nie słyszą, gdyż ja - nie chcąc słyszeć własnego krzyku - mówiłem za cicho!
• większość czasu korzystałem z programu "Spokojne Sytuacje", na który ręcznie musiałem przełączać aparaty po ich uruchomieniu (domyślnie uruchamiał się ten nieszczęsny program automatyczny)
• aparaty nie zapamiętują ostatnio aktywnego programu - po zakończeniu rozmowy via Icom wracają do pierwszego programu.
• byłem mile zaskoczony że zmieniając program w jednym aparacie automatycznie drugi aparat przechodzi na identyczny tryb.

Dodatkowo modele Versate mają funkcję automatycznego logowania wszelkich zmian dokonywanych przez użytkownika. Tym samym mój audioprotetyk po trzech tygodniach uzyskał całkiem sporo informacji odnośnie moich preferencji. Otóż - w ciągu 18 dni aparaty działały w sumie przez 291 godzin - to daje średnią na poziomie 16h na dobę. 70% czasu używałem programu "Spokojne Sytuacje", a 2% to transmisje przez iCom. W dodatku przez te 70% czasu miałem "podbicie" +3dB - fajna opcja, nie? :) Tak więc, poprosiłem o wywalenie programu automatycznego (odpalają się od razu „Spokojne Sytuacje”) i podbicie wzmocnienia o 3dB.

Swoją drogą w ciągu tych trzech tygodni miałem jedną "awarię" - przyznaję, z mojej winy. Wgrałem sobie oprogramowanie do programowania aparatów Phonak iPFG. Chciałem przejrzeć jakie opcje są dostępne przy tym modelu. Moją uwagę wróciło "Wybieranie głosowe" i "Ponowne wybieranie ostatniego numeru" i sekcji iCom. Ustawiłem, podłączyłem iComa do komputera, kliknąłem by zapisał dokonane zmiany i w tym momencie... Icom przestał transmitować dźwięk do aparatów. Ja sam mogę jedynie parować iComa z zewnętrznymi urządzeniami. POPRAWNE powiązanie Icom – aparaty, można zrobić jedynie przez iPFG i tylko wtedy gdy podłączone są jednocześnie aparaty (przez programator) i Icom (przez kabel). Jako że programatora nie miałem to Icom prawdopodobnie utracił powiązanie. Niestety nigdzie nie dało się wpisać ręcznie numeru seryjnego aparatów (była opcja sparowania z aktualnie podłączonymi do komputera), więc musiałem czekać do powrotu do Olsztyna (w tym czasie w Warszawie były straszne śnieżyce i nie uśmiechało mi się jeździć do serwisu). Aktualnie wszystko już działa ;-)

Co dalej? Czekam na nowe wkładki. I tym samym całą operację wymiany aparatów uznam za zakończoną. Ogólnie jestem zadowolony. Nowe modele spełniają swoją funkcje, a Icom jest tym czego potrzebowałem. Jeżeli będę miał trochę kasy na zbyciu, to poważnie muszę się zastanowić nad dokupieniem programatora we własnym zakresie - takie zboczenie zawodowe programisty ;-)

Od 14 lat noszę aparaty słuchowe. To jest sprzęt, który naprawdę intensywnie eksploatuję - regularnie po 14-16h na dobę. Jednak nic nie będzie działać bez odpowiedniego zasilania. Co jest tak wydajne że mimo ciągnięcia 0.8mA zapewnia działanie aparatów przez ~2 tygodnie?. Odpowiedź: Baterie cynkowo-powietrzne.

Jak jest zbudowana baterie?

Nie zgłębiając się w szczegóły i zapisy reakcji chemicznych powiem że anodę tworzy sproszkowanego cynk, a w roli katody występuje tlen. Funkcję elektrolitu pełni wodorotlenek potasu. Ogniwa cynkowo-powietrzne dostarczane są przez producenta w stanie nieaktywnym, tzn. proces chemiczny powodujący powstawanie energii elektrycznej nie jest rozpoczęty...

A czemu każda bateria ma naklejkę z jednej strony?

Pełni ona funkcję "ochroną" i wbrew pozorom jej rola nie nie ogranicza się do aspektów czysto estetycznych. Jej głównym przeznaczeniem jest zapobieganie utlenianiu się anody, a zatem zapobiega rozładowywaniu się ogniwa. W związku z tym nie powinno się jej zrywać jeżeli nie planujemy włożyć baterii do aparatu. Tak samo nie ma sensu ograniczać czas dziennego korzystania z aparatów do kilku godzin by oszczędzać ogniwa i przedłużyć żywotność baterii. Dostęp tlenu działa równie "destrukcyjnie" na baterię pod obciążeniem jak i bez niego. Więc za max. 4 - 5 tygodni i tak będziemy musieli wymienić baterie.

Dlaczego aparaty słuchowe wykorzystują baterie cynkowo - powietrzne?

Po rezygnacji - na etapie konstrukcyjnym - z tradycyjnej katody, gęstość energii na jednostkę masy jest bardzo wzrosła. Innymi słowy - mają wysoką wydajność w porównaniu do rozmiarów. Poza tym napięcie rozładowywania jest stałe i pod obciążeniem wynosi ok 1,1V.

Te naklejki są kolorowe. Dlaczego?

Baterie cynkowo-powietrzne produkowane występują w pięciu "wielkościach". I tak do ich identyfikacji możemy posłużyć sie kolorem naklejki jak również oznaczeniem liczbowym. Wyróżniamy:

• 8„10” / „230” - kolor żółty
• „312” - kolor brązowy
• „13” - kolor pomarańczowy
• „675” - kolor niebieski

I właśnie chcąc przywrócić jej prawidłowe napięcie (1.4V) należy po odklejeniu naklejki a przed włożeniem do aparatu odczekać 2 min. Takie są teoretyczne założenia, ale ja jakoś nigdy nie stosowałem się do tego zalecenia ;-)

Czytając ostatnio nowe notki w moim Google Readerze natrafiłem na wpis Tomasza Jędrzejewskiego pt. „Społecznosci programistyczne„, w której autor zarzuca brak należytej integracji polskim środowiskom developerskim. Skłoniła mnie ona do refleksji nad przyczyną tego stanu rzeczy.

Mam już za sobą kilka własnych przedsięwzięć jak również swój mniejszy czy większy wkład w tworzenie treści dla takich serwisów jak webhelp.pl, webcity.pl, pcmaniak.pl czy dawne scrypty.com, dlatego wiem, jak wygląda organizacja ludzi przy takich projektach. Cąłą treść można zawrzeć w takiej wymianie zdań:

• Weźmy, zróbmy to i to – OK, to się weźmy i zrób.

Tak zwykle wygląda konwersacja, póki nie znajdzie się osoba która, stanowczo narzuci jakiś harmonogram prac… ale wtedy nagle okazuje się, że nikt już nie chce brać udziału w projekcie!

Rozumiem, że ktoś nie chce uczestniczyć przedsięwzięciu non-profit, ale dlaczego w takim razie deklarował chęć pomocy? Aktualnie kończę kolejny, projekt (co, gdzie – już nie długo), którego pomysł zgłosił inny użytkownik na polskim forum Gentoo prawie półtora roku temu – przez ten czas kilkanaście osób deklarowało chęć pomocy – jak przyszło co do czego – cisza. Dlaczego tak wiele osób pomaga na różnych forach, a tak ciężko znaleźć kogoś do współpracy? Brak wiary we własne umiejętności? Inna złożoność problemów?

Niestety śledząc nieco rozwój różnych inicjatyw nasuwa się przykre pytanie – Czy Polacy to stado baranów? Nie chodzi mi tutaj o poziom inteligencji czy wiedzy! Raczej o sposób naszego działania i myślenia – ot, jeden krzyknie, wszyscy za nim. Przykłady?

• Ostatnie Mistrzostwa Świata w piłce nożnej – W którymś zagranicznym serwisie naszych rywali pojawiła się ankieta – Jakiego przeciwnika najbardziej się obawiasz? skierowana do obywateli tamtego kraju. Jak myślicie – kto wygrał? Polska. Wszystko za sprawą Wykopu i newsów w takich serwisach jak Onet. Po co ta nagonka?
• pojawiła się strona – http://www.gentoo-users.org/ z mapą użytkowników / developerów Gentoo z całego świata. Inicjatywa ciekawa. Na tą chwilę, najliczniejszą grupą na mapie są... Polacy.
• wspomniany przez Tomasza Jędrzejewskiego – grupowy – lament polskich użytkowników w sprawie braku dokumentacji w ojczystym języku do systemu szablonów OPT. Tak jak już ktoś wspomniał – programista bez umiejętności czytania angielskiej dokumentacji to jak kierowca bez prawa jazdy.

Nasuwają się wnioski – chcemy być pierwsi, chcemy być najlepsi, chcemy być najważniejsi… ale… tanim kosztem. Oczywiście można znaleźć też inne wytłumaczenie np. w pierwszym przypadku średnia wieku głosujących wynosiła zapewne 13 – 16 lat. Ale czym usprawiedliwić kolejne? Może nie dorośliśmy do wspólnego tworzenia projektów? Czy też gwałtowne obniżenie średniej wieku polskiego Internauty za sprawą popularyzacji Neostrady przyczyniło się do tego, że mamy do czynienia jedynie z 13-sto latkami rzucającymi słowa na wiatr?

Dlaczego nie potrafimy zachować umiaru? Czy to może dają znać o sobie zakorzenione kompleksy z czasów II Wojny Światowej i okresu PRL kiedy to – nie bójmy się użyć tego stwierdzenia – byliśmy piątym „kołem u wozu” dla ówczesnego ZSRR i III Rzeszy?

Trzeba przyznać, że w jednej rzeczy jesteśmy niekwestionowanymi mistrzami – w konspiracji. Szlifowaliśmy swój „warsztat” przez ~120 lat rozbiorów i dwie wojny światowe. Opanowaliśmy tą umiejętność do tego stopnia, że czasach PRL władza nie mogła znaleźć na nas haka ;-)

Kończąc już stawiam kilka pytań – Gdzie szukać przyczyny braku integracji? Jak z tym walczyć? Jak tego unikać? Hm… a może to ja obracam się w złym środowisku? Zapraszam do dyskusji

Dawno już minęły czasy kiedy do aktualizacji BIOSu używało się dyskietek. Niestety dalej w sieci można znaleźć archaiczne solucje, które opisują cały proces z użyciem nośnika 1,44MB oraz Windows 98. Dziś, dyskietki zniknęły, systemy się zmieniły, a odwieczny problem pozostał.

Opiszę tutaj procedurę zmiany BIOSu dla notebooka Compal JHL90. Na chwilę obecną najnowszą to 1.07 i na niej będę się opierał.

Wymagania:

• Pendrive ( ja użyłem PQI 1GB )
• HP USB Disk Storage Format Tool (np. stąd)
• paczka plików dla DOS
• nowy BIOS (JHXXX107)

To zaczynamy…

1. Ściągamy i instalujemy HP USB Disk Storage Format Tool.
2. Ściągamy paczkę plików DOS i rozpakowujemy do C:\USB
3. Wkładamy pendrive
4. Odpalamy HP USB Disk Storage Format Tool i ustawiamy wszystkie opcje tak jak na obrazku:

Klikamy start i czekamy do czasu zakończenia formatowania

Ściągamy nowy BIOS, rozpakowujemy archiwum, a następnie jego zawartość przenosimy na pendrive.

Odpalamy ponownie komputer boootując z USB a po pojawieniu się znaku zachęty wystarczy wpisać 107.BAT i potwierdzić ENTERem automatycznie rozpocznie się nadpisywanie zawartości BIOSu, po czym komputer się zrestartuje.

voilà!

W internecie są dostępne obrazy ISO z różnymi BIOSami. Teoretycznie wystarczy je wypalić na płycie i uruchomić z niej komputer. Niestety nigdy u mnie te płyty nie działały. Podejrzewam, że należy wyłączyć tryb AHCI dla CD-ROMu (jeżeli jest na złączu SATA), ale nigdy nie udało mi się tego na Compalu dokonać. Dlatego też opisałem proces z wykorzystaniem pendrivea – pozwala mi to zaoszczędzić płyty, nerwy i zabawy z AHCI ;-)

Kupiłem laptopa. Po niemal roku analizowania ofert i szukania wymarzonej konfiguracji sfinalizowałem zakup. A wszystko zaczęło się tak…

Był sierpień 2007 roku. Nieuchronnie zbliżało się rozpoczęcie najważniejszego roku szkolnego w mojej dotychczasowej edukacji – roku maturalnego.

Myśląc perspektywicznie, doszedłem do wniosku, że na studia przydałaby mi się jakaś mobilna jednostka centralna. Cały czas w moim pokoju stoi 3-letni wysłużony komputer stacjonarny ochrzczony mianem Pegaz ( Athlon 64 3000+, 2 x 512 MB RAM, GF 6600 GT), jednak wraz z wyjazdem na studia nie mogłem z domu zabrać jedynej, w miare wydajnej maszyny.

Na upartego mam jeszcze jakieś 3 komputery o wydajności zbliżonej do AMD K6 200Mhz ;-) ale na żadnym nie udało mi się uruchomić karty wifi Ralink 2400 PCI, z pomocą której łączę się w domu z internetem.

Tak więc jedynym rozsądnym rozwiązaniem był zakup drugiego komputera. W tamtym okresie wstępnie określiłem swoje wymagania:

• Procesor: dwurdzeniowy. Nasłuchałem się różnych opowieści, w których znajomi opowiadali jak nagrywali płytę i słuchali muzyki na komputerze w tym samym czasie. Ja bym nie zaryzykował, nawet teraz mając na pokładzie Core 2 Duo T9400. Dla mnie ważniejsze było to, że make -j3 kończy się (zwykle) szybciej niż make j2 ;)
• RAM: 4GB. Ceny kości spadły ostro w dół. I pomyśleć że 3 lata temu za 2 × 512 MB 400Mhz dałem 400 zł. W prawdzie zwykła Vista czy XP wykrywają 3,2 GB z powodu swojej 32 bitowej architektury, to jednak 4GB przydadzą się dla Gentoo na którym zamierzam pracować.
• Matryca: 15’‘. Doszedłem do wniosku, że 15’‘ to będzie dla mnie najlepszy wybór. Taki kompromis między mobilnością a wydajnością. Drugą ważną kwestią była natywna rodzielczość. Tutaj przyznaję miałem wątpliwośći. Pracując nadal na wysłużonym (hm… już chyba 8-mio letnim) 17’‘ monitorze CRT LG Flatron 795FT w proporcjach 4:3 każda inna rozdzielczość poza 1024×768 przyprawiała mnie o dreszcze. Jakim cudem mam zejść o 2’‘ i w dodatku zwiększyć obszar roboczy?! (chociażby do tych 1280×800).
• Napędy optyczne Dysk twardy 200 GiB. Nie chcę więcej dla własnego bezpieczeństwa, gdyż miejsza przestrzeń wymusza częstsze backupy i usuwanie niepotrzebnych rzeczy :-)

Przy okazji, obecnie posiadam 2 dyski WD2500KS (250GB, 7200rpm, 3,5’‘) zakupione w odstępie 1 roku. Jeden z nich (pierwszy, z rev. A) nie działa. Z powodu mojego pośpiechu uległo uszkodzeniu złącze SATA-DATA. Po naprawie wytrzymało 1,5 roku poczym spaleniu uległ jeden z układów „na zewnętrznej elektronice”. To się nazywa pech. Może ktoś tanio mógłby to naprawić? Nie chce mi się płacić aż 150 zł, więc dysk aktualnie czeka na spadek cen.

Oto wstępne założenia. Priorytetem była wydajność, jako że zamierzałem (i nadal zamierzam) korzystać z tego sprzętu przez cały okres studiów (inżynierskich póki co). Ponadto chciałem mieć na pokładzie jak najwięcej przyszłościowych zabawek ;-). Do takich zalicza się Bluetooth, Wifi z obsługą draftN i czytnik kart pamięci. Potem doszło do tego jeszcze HDMI (gdyż w grudniu ’07 wymieniliśmy w domu telewizor na taki ze w/w złączem. )

Na tym etapie poszukiwania zostały zawieszone z uwagi na niewystarczające fundusze i dużą ilość nauki ;) (ehm… oficjalna wersja ;) )

Cała idea odżyła w lutym 2008, kiedy to dzięki Google Reader natknąłem się na wpis Antoniego Jakubiaka pt.”Pojedynek Compal IFL 90 vs IBM T61p„. Wtedy też po raz pierwszy spotkałem się z terminem „kadłubek” w odniesienu do notebooków i marką Compal. Muszę przyznać że na początku odniosłem wrażenie, iż Compal to jakaś podróbką a’la Thomsonic. Dopiero wpis na angielskiej Wikipedii dotyczący tej firmy zmienił moje nastawienie do tej marki.

Dzięki informacjom w notce skierowałem się na witrynę sklepu eXelabs.pl, którego siedziba mieści się w Warszawie. Strona wywarła na mnie dobre wrażenie, a konfigurator, dobra lokalizacja oraz szybkie odpowiedzi na moje emaile przekonały mnie do tego by właście tam zakupić notebooka. Początkowo miał to był FL90 z T7700 & 4GB RAM. Już tylko czekałem na zakończenie roku szkolnego, i rozpoczęcie wakacji… aż tu nagle…

Pojawiły się nowe procesory mobilne Intela – Penryn T9x00. FL90 oficjalnie nie wspierał tej linii, ale Compal wypuścił nowy model FL92,który obsługę nowej serii już oficjalnie posiadał. „FL92? OK, reszta bez zmian” – powiedziałem. Nie na długo… w świecie rozeszły się wieści, jakoby Compal szykował coś ekstra w związku z premierą nowej platformy mobilnej Intela w połowie 2008 roku. Informację przeczytałem na forum Karen Notebook (link bezpośrednio do posta). GF M9600 GT? Super… tylko… kiedy dokładnie premiera?! Nie należę do ludzi wyjątkowo cierpliwych, więc rozpoczęłem poszukiwania alternatywy dla Compala. Konkurent miał spełniać dokładnie te same kryteria, oraz wsparać T9×00, HDMI etc.

Tutaj rozpoczyna się krótki epizod którego bohaterem jest markowy Dell i jego model M1530. W Polsce, prównywalna konfiguracja tej M’ki z FL92 kosztowałaby mnie jakieś 5 – 6 tyś zł netto. Atrakcyjne oferty znalazłem za granicą. Tak więc, jeżeli już koniecznie ktoś chce nabyć coś markowego to polecam laptopy określane jako „refurbished„. Jest to sprzęt który wrócił z jakiegoś powodu do producenta ten go naprawia i wystawia do ponownej sprzedaży. Takie egzemplarze są dużo tańsze, wady usunięte, gwarancja – nawet 3 letnia. Haczyk? Cóż w Polsce jest to mało znane. Handel tego typu sprzętem kwitnie na eBay’u, tak więc czeka nas zabawa ze sprowadzaniem sprzętu z UK / USA. Także polecam zajrzeć na brytyjskiego eBay’a. Sprzedawcy często akceptują PayPal’a więc nie będzie żadnej papierkowej roboty – jedyny koszt – to kwota przewalutowania (PLN -> GBP) + przesyłka. Za taką samą konfigurację jak FL92 (a nawet lepszą bo GF M8600 GT DDR3 – zysk ~20 – 30%) zapłaciłbym 3800-3900 zł wliczając w to wszystkie koszty.

Już chciałem kupować, już korespondowałem ze sprzedawcą, kiedy to Intel oficjalnie ogłosił premierę Monteviny na 15 lipca, a Karen Notebook potwierdził, że następca FL90 – JHL90 – pod szyldem California Access będzie do kupienia właśnie od połowy lipca… Określiłem końcową specyfikację Core 2 Duo T9400 1066Mhz, 4GB RAM 800Mhz, 200GiB 7200rpm, wifi, bluetooth, oraz matryca glare 1650×1080. Tak, ja, człowiek który bał się innej rozdzielczości niż 1024×768, wybrał największą z możliwych dostępnych dla Compali. Dlaczego? Zaryzykowałem na podstawie opinii innych osób. Na forum Notebookcheck.pl możemy znaleźć kilka tematów o wyborze rozdzielczości. Wiele osób twierdziło, że pracując na 1680×1050 za nic nie wrócą na 1280×800 ani tymbardziej na 1024×768, że to idealna rozdzielczość dla programistów, grafików etc. Zawsze narzekałem na brak miejsca na pulpicie czy też w obszarze roboczym 3Dsmax’a i muszę przyznać... że NIE ŻAŁUJĘ WYBORU. Sam teraz się dziwię jakim cudem wytrzymałem tyle lat na 1024×768.

I tak oto wróciłem do kadłubków, spokojnie czekałem na nadejście 15.07… (kiedy nie wiadomo skąd) pojawił się konkurent dla JHL90! Mowa tu o Acer 5930, który jak sie okazuje ma karte GF M9600 na DDR3. Jedyna wada dla mnie – matryca – 1200×800px? Niska rozdzielczość z przekreśliła ten model z mojej stawki.

Podsumowując, 25.07 nabyłem JHL90 aka California Access 162S w olsztyńskim oddziale Karen Notebook. Sprzęt obięty jest 24 miesiącami gwarancji i obym nie musiał sprawdzać jakości serwisu (którego siedziba notabene jest w Suwałkach).

Aktualnie mam na dysku dwa systemy:

Gentoo 2008 z GCC 4.3.1 & Glibc 2.8 oraz Xfce4.4

Microsoft Windows Vista Ultimate PL* do rozrywki ;-)

Można powiedzieć, że wszystko działa bez zarzutu. Na linuksie nie uruchomiłem jeszcze czytnika i skanera linii papilarnych gdyż ich nie potrzebuję. Zastanawia mnie tylko czy JHL90 ma jakiś czujnik podłączony do magistrali i2c, bo żadnego nie może wykryć.

*wyprzedzając ewentualne pytania dot. legalności Visty. Załapałem się na akcję gdzie za 30zł dostałem książkę „Poradnik administratora – Windows Server 2008” a z nią m.in. płytę z 32bitową Vistą Ulimate EN z licencją NFR na rok. Zanim ten rok minie mam nadzieję że uda mi się zdobyć licencję z programu MSDN AA ;-)