Pomiary klimatu w domu i wokół.

[Belferek]

odległość + kabel = problem więc wydaje mi się, że to esp8266 jest lepszym wyborem. Tu także sprawdziłoby się RPi. Jest taka masa tutoriali na temat RPI + WiFi, RPi + LCD, że nie miałbyś z tym żadnego problemu, a stworzyłbyś sobie kolejne możliwości dzięki bardziej zaawansowanemu mikrokomputerowi.

[marek1707]

Ale może (niektóre) problemy są po to by je rozwiązywać? Zawsze to jakaś nauka, w sumie niewielkim kosztem. Skoro już XIXw można było przesyłać rozmowy przez Atlantyk a dzisiaj karta ethernetowa 1Gb/s kosztuje 30zł to może warto spróbować?

[Belferek]

Pewnie, że można. Kilka ładnych lat temu realizowałem projekt, który zakładał współpracę kilku mikrokontrolerów serii 8051 porozrzucanych w promieniu ok. 1500 metrów. Wtedy sieci LAN były na koncentryku, a o WiFi mozna było tylko pomarzyć. Rozwiązałem ten problem wykorzystując kable telefoniczne i własnej "produkcji" nadajniki i odbiorniki współpracujące z Rx i Tx procesorów - to działało. Tutaj Soyer nie chce łączyć mikrokontrolerów, lecz chce połączyć z Arduino oddalony o 15m wyświetlacz LCD więc jak dla mnie naturalnym wyborem jest dołożenie do tego wyświetlacza "inteligencji" w postaci mikrosterownika i połączenie tych dwóch układów np. za pomoca WiFi za ok. 30 zł (ESP) lub ok. 180 zł (RPi) - no ale może się mylę.

[marek1707]

Nie rozmawiajmy w kategoriach "mylę się", bo nie ma tu jednej prawdy objawionej. Zadałem tylko SOYERowi pytanie, czy jednak nie chciałby pobawić się w kabelek, skoro warunki pozwalają na jego położenie. Połączenie z niezbyt odległym wyświetlaczem można zrobić na wiele sposobów. Te radiowe wymagają jakiejś inteligencji po drugiej stronie choć dzisiaj, w dobie gotowych modułów procesorowo-radiowych nie jest to wielki koszt i trudność. Łącze kabelkowe, oprócz danych może nieść zasilanie co czasem bywa przewagą. Z uwagi na interfejs typowego LCD byłoby fajnie przesyłać do niego dane w jakiś skompresowany sposób, bo inaczej czeka nas 8-10 drutów. Z drugiej strony 8 linii to jakiś typowy kabel alarmowy lub skrętka. Można też postawić po drugiej stronie najtańsze Arduino nano i niech ono odbiera dane szeregowe (UART?) sterując nimi LCD. Wtedy wystarczą już tylko 3-4 druty. A po drodze są jeszcze jakieś pomysły pośrednie np. z SPI i rejestrem itp. Każde z tych rozwiązań wymaga troszkę pracy i wiedzy i to właśnie uważam w nich za najcenniejsze. Tak naprawdę to trzeba sobie odpowiedzieć na pytanie po co to robimy. Bo jeśli celem jest końcowy efekt, to trzeba za wszelką cenę iść na skróty i wybrać coś najłatwiejszego, prawie gotowego. Ale jeśli ktoś się wkręca i interesuje go co tam pod maską siedzi, transmisja cyfrowa na odległość kilkunastu metrów jest świetnym poligonem doświadczalnym. Niestety żeby zrobić to świadomie, trzeba mieć przynajmniej oscyloskop. W przeciwnym razie będzie to kopiowanie (w dobrej wierze) pewnych (i całkiem dobrych) standardów. Na pewno jednak dowiedzenie się czegoś o impedancjach, liniach długich, dopasowaniu, terminacjach i rodzajach nadajników/odbiorników linii oraz granicach pewnych technologii jest zyskiem wartym zainwestowania paru godzin czasu.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[SOYER]

LCD jest po I2C, oczywiście można go wylutować. Ilość przewodów to nie problem. Wolał bym dołożyć, jakieś nodeMCU za kilka złotych i przy okazji trochę się nauczyć. Tylko nie wiem, jak to wtedy oprogramować? Czy taki nodemcu, tylko odbiera dane i przesyła dalej do LCD, czy trzeba tak jakby osobne sketche dla node i arduino? Jakiś link?

Na razie LCD niby działa po I2C w tej odległości, tylko jest problem ze stabilnością, po jakimś czasie(1h, 2h, 3h) wiesza mi się arduino. Raczej na pewno jest to związane z LCD bo kiedy go odłączyłem to śmigało 24h bez problemu. Kiedy LCD był podłączony blisko to też śmigało tydzień bez problemu. Na razie zmieniłem mu rezystory podciągające z 4.7kOm, na 3kOm. Całkowicie bez podciągnięcia wcale nie działało na tą odległość.

Wiem, że po I2C na taką odległość się nie przesyła, ale na razie i tak nie mam tego jak inaczej podłączyć z braku potrzebnego sprzętu, to kombinuję po najmniejszej linii oporu...

[Belferek]

ESP8266 + NodeMCU to osobny mikrokontroler, który musisz oprogramować. Ten procesor to 80 MHz, stosunkowo duża ilość GPIO, UART, poziomy logiczne 3,3V (wbudowany stabilizator zasilania) no i WiFi .... porównaj z Arduino. Programować go możesz w Arduino IDE lub innym środowisku. Małe urządzenie, ale ciekawe. W sieci znajdziesz wiele poradników i przykładów np.:

http://www.jarzebski.pl/arduino/arduino-i-klony/nodemcu-v2-esp8266-lua.html

https://starter-kit.nettigo.pl/2016/04/esp8266-iot-praktyczny-przyklad-cz-4-arduino-ide/

http://henrysbench.capnfatz.com/henrys-bench/arduino-projects-tips-and-more/nodemcu-io-basics-pwm/

i wiele innych chociażby strona projektu http://www.nodemcu.com/index_cn.html

[ethanak]

Powiem tak: ja bym zastosował najtańszą płytkę arduino (pro mini lub nano) i na to bym zwalił obsługę wyświetlacza. Główny arduino.połączony z tym czymś poprzez serial - mamy tu do czynienia z transmisją tylko w jedną stronę, więc wystarczy para drutów. Nadający arduino może równie dobrze używać software serial. Jedyny problem to zastosowanie jakiegoś sensownego protokołu.

Można to ulepszyć stosując dwukierunkową transmisję (potwierdzenia) - wtedy masz albo trzy druty przy pełnym dupleksie, albo dalej dwa przy half-duplex (trochę się program komplikuje, ale się da).

Od strony programu - widziałby on tę maszynerię tak jak oryginalną bibliotekę liquidcrystal.

Może być?

[SOYER]

Mam pytanie, czujniki DS18b20, jako, że musiałem kombinować z wartościami rezystorów podciągających z powodu długości przewodów, zastanawiam się nad zastosowaniem potencjometru co da mi możliwość łatwego ustawienia wartości opornika. Oczywiście sam potencjometr to chyba za mało, trzeba bo go dobrać do pary ze zwykłym rezystorem żeby w miarę dopasować wartości.

Pytanie, czy stosuje się takie rozwiązania? W kursie elektroniki jest napisane, że tak, ale nie wiem czy w moim przypadku się nada...

[marek1707]

Pytasz tu o dwie rzeczy. Pierwsza to dobieranie wartości rezystancji do czegokolwiek a druga to stosowanie interfejsu 1-wire na większe odległości. No to tak:

1. W sytuacji gdy musisz z jakichś powodów precyzyjnie dobrać wartość rezystora to stosujesz albo potencjometr wieloobrotowy albo zwykły plus szeregowy rezystor "przenoszący" zakres regulacji w odpowiednią strefę wartości. Żaden z tych przypadków tu nie zachodzi. Precyzja jest potrzebna w układach pomiarowych, detekcyjnych itp, ale tutaj masz do czynienia ze zwykłym przekroczeniem zasad. Być może da się dobrać wartość rezystora podciągającego tak by układ działał, ale już sam fakt takiej konieczności powinien Cię zmusić do myślenia...

2. Bo interfejs 1-wire ma swoje naturalne ograniczenia wynikające z:

- czasów transmisji jednego bitu wyznaczonych przez standard a to oznacza, że nie możesz np. zwolnić pojedynczego bitu by wszystko działało pewniej przez kiepskie medium (kabel),
- ograniczonej wydajności prądowej wyjść współpracujących układów,
- naturalnych własności kabli transmisyjnych,
- asymetrii charakterystyk wyjściowych nadajników sygnałów wynikającej z przyjętej zasady: wyjście open collector robi zero, ale to opornik podciągający robi jedynkę,
- poziomów napięć wymaganych na wejściach w celu jednoznacznej detekcji stanów 0/1.

Wszystko to sprawia, że interfejs 1-wire działa dobrze na ograniczone odległości. Twoje eksperymenty podobne są do próby przejechania Maluchem Afryki. Tak, daje się i powstała nawet fantastyczna książka z tej wyprawy, ale na co dzień raczej tak ludzie tam nie podróżują. Wystarczy, ze z powodu kilku skał leżących na.. drodze(?) musisz objechać z drugiej strony jezioro, którego linia brzegowa ma długość granicy Polski i jesteś ugotowany. Tylko wytrawny podróżnik może się porwać na takie rzeczy, czujesz się takim w elektronice? Ludzie wybierają więc samolot lub porządnego land-rovera. Jeżeli musisz dobierać precyzyjnie jakieś elementy nie po to by wyżyłować konstrukcję (np. by osiągnąć 0.1% dokładności pomiarów), ale po to by w ogóle coś zaczęło działać, to po prostu poszedłeś złą ścieżką, przykro mi. W sytuacji gdybyś miał sprzęt pomiarowy, rozumiał jak przebiegają te transmisje i świadomie zbudował układ do przeniesienia sygnalizacji 1-wire przez długi kabel weryfikując to pomiarami, to OK. Jak rozumiem to nie jest ten przypadek więc co możemy Ci poradzić? Mogę tylko powiedzieć co ja bym zrobił:

Widząc kabel długości kilku metrów i konieczność zmierzenia czegoś na jego drugim końcu, od razu poszedłbym w zupełnie inne czujniki.

1. Jeśli to tylko temperatura, to pomyślałbym o taniutkich rezystancyjnych serii KTY

https://www.tme.eu/pl/details/kty81-120/przetworniki-temperatury/nxp/kty81120112/

Kosztują ok. 2zł, kabel nie wprowadza dużych rezystancji w stosunku do 1kΩ więc błąd z nim związany duży nie jest a pomiar oporności jest łatwy. To może być też złącze p-n zwykłej diody krzemowej (-2mV/K) lub droższy PT100, cokolwiek co oddaje analogową wielkość dającą się łatwo przekształcić na napięcie dla ADC. Taki sygnał jest praktycznie stały i przejdzie przez najgorszy i bardzo długi kabel jak przez masło. Dodatkowo, korzystając właśnie z bardzo niskiego pasma niesionej informacji, możesz dowolnie dobrze zabezpieczyć druty przed zakłóceniami, szumami i przepięciami.

2. Jeżeli wielkości byłoby więcej (np. wilgotność, temperatura, smog itp) wstawiłbym tam kawałek inteligencji (NanoPro za 10zł?) plus odpowiednie czujniki i wszystko wysłał przez UART. Można wtedy zrobić dowolnie wolną i dowolnie dobrze zabezpieczoną transmisję bo to Ty wtedy decydujesz o warstwie fizycznej łącza.

Tak więc jeśli Twoje pytanie dotyczy nie tyle sposobu dobierania opornika a raczej ogólnie przyjętej dobrej praktyki inżynierskiej w zakresie zdalnych pomiarów, to w tym przypadku radziłbym zmienić czujnik a wcześniej przejrzeć dostępne możliwości zamiast brnąć w złe rozwiązanie. Widzę też dobre strony tej sytuacji: próbowałeś, działa kiepsko, zapamiętasz do końca życia. A teraz zatrzymaj się i zawróć, popytaj, poczytaj i wybierz coś lepszego w tej konkretnej sytuacji. Rozpoznanie bojem jest może i efektowne, ale piekielnie kosztowne. I w sumie głupie.

[SOYER]

Ok, o długościach przewodów dla ds18 pisałem już kilkukrotnie i nikt się nie zająknął, że lepiej to zrobić na innych czujnikach. Dziękuję za informację. Nie przyszło mi to do głowy bo czujniki DS działają bez zarzutu, pokazują dokładnie i precyzyjnie. Ich wymiana to godzina roboty, więc gdybyś mógł napisać coś więcej o tych proponowanych. Np. dlaczego te , a nie analogowe używane w kursie LM35. Analogi też się nie nadają?

EDIT zauważyłem, że ten KTY81 jest od zera w górę... odpada 🙁

[marek1707]

No to teraz już wiesz jak to jest z Forum. Raz dostaniesz mądre rady a innym razem nic ciekawego. Nie jestem tutaj jakimś opiekunem merytorycznym i nie do każdego tematu muszę się wtrącać. Tutaj coś wrzucam, bo widzę Twoją desperację i dziwne pytania.

Dałem kilka przykładów prostych, pasywnych czujników analogowych. Widzę, że łapiesz bo dałeś przykład jakichś innych, dużo "mądrzejszych". Nie przerabiałem kursu (może pora zajrzeć..) więc nie wiem co tam było proponowane a możliwości jest naprawdę wiele. "Inteligentne" czujniki analogowe potrzebują zasilania więc to trzeci kabel obok masy i sygnału (chyba że dają sygnał prądowy, wtedy dwa wystarczą), ale za to dają wprost napięcie gotowe do zmierzenia. W przypadku "gołych" elementów pomiarowych typu KTY czy dioda czy PT100 dostajesz jakąś fizyczną wielkość (np. rezystancję) którą na sensowne napięcie musisz dopiero przerobić.

Jeśli Cię nie boli więcej kabli w LM35, kupuj i spróbuj. Pokaż jakiś schemat, powiem Ci co poprawić.

EDIT: "Zauważyłeś" w karcie katalogowej czy na stronie sprzedawcy? Jeszcze się nie nauczyłeś co jest źródłem a co tylko wodą po kisielu jakiegoś handlowca?

[SOYER]

Kabli nie ma więcej, do każdego Ds też trzeba trzy, ale wiem o co Ci chodzi. Nie jestem zdesperowany tylko ciekawy, niewiedza bywa ok kiedy wszystko działa. Ty mnie uświadamiasz, że jest źle i to mnie martwi 😅

W czym te analogowe LM35 będą lepsze w porównaniu do DS? Będą pewniejsze na tych 20m kabla? Czyli jak się coś zacznie sypać (albo w wolnej chwili)to wymienić ds na lm35?

[marek1707]

Lepsze? Spójrz na to szerzej. Tu nie chodzi o sam czujnik tylko o sposób przekazywania informacji. Pogoda to zjawiska bardzo wolnozmienne. Jak szybko może zmieniać się temperatura? Ile stopni na sekundę? A ciśnienie? Ponieważ to jest takie wolne, to do przesłania masz bardzo mało informacji i możesz to robić powoli. A jeśli powoli, to medium transmisyjne (kabel, "eter" radiowy, fale mechaniczne typu ultradźwięki) może być bardzo kiepskie, zaszumione itp. Napięcie o którym wiesz, że zmienia się bardzo powoli możesz przesłać przez dowolnie zły kabel bardzo daleko. O ile nie wejdą na niego zakłócenia o podobnym charakterze (np. jakiś wpływ Księżyca lub aktywność Słońca) to po odfiltrowaniu wszystkich szybkich śmieci na końcu masz czysty sygnał wejściowy.

Zupełnie inaczej jest z czujnikiem inteligentnym, typu 18B20, gdzie to producent określił jak wygląda przesyłanie zer i jedynek i na spełnienie jego wymagań jesteś skazany. To musi mieć taką długość [µs], a to śmaką. I z tego wynikają minimalne wymagania na medium. Oni projektowali ten scalak (i cały protokół 1-wire) z myślą, że będzie sterował krótkim kabelkiem podciągniętym do plusa przez spory opornik. Gdy kabel się wydłuża to nie dość że rośnie ilość zakłóceń przez niego łapanych to zwiększa się też jego pojemność. I musisz się bardziej starać by coś szybko po nim przesłać. Nie możesz zwolnić, bo 1-wire jest jaki jest i bity muszą biec szybko. Żeby "pokonać" gorsze warunki powinieneś mieć coraz mocniejszy nadajnik sygnału i coraz czulszy odbiornik. No ale przecież wyjście czujnika ma już jakiś maleńki tranzystorek, który nie jest w stanie ściągnąć do 0V linii podciągniętej np. przez 100Ω do +5V więc "moc" nadawania jest ograniczona. Po drugiej stronie (odbiorczej) stoi jakaś bramka cyfrowa, która "nie chce" widzieć dziwnych poziomów napięcia typu 1V czy 2.5V. Ona dobrze działa gdy widzi albo 0.1V albo 4.9V. Słabo nadany sygnał, zdegradowany przez długi kabel przestaje być zero-jedynkowy a zaczyna przypominać sinusoidę sieciową albo szum albo analogowy sygnał audio. Takie coś po przejściu przez bramkę odbiorczą daje sieczkę, tyle że cyfrową i żaden procesor z tego nie odtworzy poprawnej informacji.

To jest właśnie jest to niedopasowanie. Potrzebujesz zmierzyć temperaturę raz na 5 minut, ale musisz przesłać ją zgodnie z protokołem 1-wire w ciągu 1ms, przesyłając w tym czasie dziesiątki zer i jedynek i wymagając, by marna para nadajnik/odbiornik zrobiła to przez długi kabel.

Szybkie transmisje nie są darmowe więc jeśli masz np. UART nad którym panujesz, możesz ustalić prędkość na 115200 bitów/s i przesyłać coś na kilka metrów a możesz przestawić na 1200 i tą samą parą nadajnik/odbiornik i przez ten sam (tylko dłuższy) kabel przesłać na 2 km. A możesz też ustawić 300bit/s, zmodulować odpowiednio sygnał i przesłać przez radio lub przez kabel za ocean. Wszystko zależy od tego jak mocny sygnał w stosunku do zakłóceń widzi odbiornik. To nazywa się SNR (Signal-to-Noise Ratio) -zapamiętaj ten skrót, bo cała telekomunikacja na tym bazuje.

Przesyłając informację analogową (np. napięcie proporcjonalne do temperatury), na wejściu ADC możesz prawie dowolnie dobrze odfiltrować szumy i dostać czysty sygnał który nie może co prawda zmieniać się szybko, ale przecież nie musi.

Protokoły cyfrowe są fajne, ale musisz spełnić pewne wymagania żeby się nimi cieszyć. Dlatego zawsze zastanawiaj się co naprawdę chcesz przesłać: ile informacji i jak szybko. Jest cała gama takich warstw fizycznych łączy cyfrowych (i analogowych) i zawsze coś można dobrać (CAN, RS485, Ethernet, LIN, USB itd), ale małe scalaczki typu 18B20 w nich nie pracują - nie są do tego by przesyłać ich dane daleko. Są za to oszczędne jeśli chodzi o energię bo zauważ, że im szybciej i dalej chcesz coś przesłać tym kosztuje to więcej prądu. Taką mamy fizykę tych zjawisk.

[SOYER]

Dzięki bardzo, świetny i słuszny wykład 🙂

Powiedz mi jeszcze taką rzecz, odniosę się do telewizji. Kiedyś była analogowa, można było złapać "jakiś" sygnał i coś tam widzieć na ekranie albo dobrze dostroić odbiornik i antenę i mieć w miarę dobry obraz. Później przyszła cyfrówka i żeby dobrze ustawić antenę sat trzeba było się napocić... W cyfrowej albo obraz jest super albo nie ma go wcale, inaczej niż kiedyś analogowo.

Czy podobne jest np. z czujnikami temperatury? Jeśli z cyfrowego mamy dane to są one ok, a jak coś jest nie tak to po prostu nie ma odczytu?.

Jak jest w analogowych?

[marek1707]

Świat nie wie o tym, że przesyłasz sygnał "analogowy" lub "cyfrowy" i zakłóca oba dokładnie tak samo.

Patrząc np. na tę telewizję różnica jest taka, że.. w międzyczasie nauczyliśmy się robić lepszą elektronikę. Przykładowo w starej telewizji informacja była przenoszona tak:

- Jasność pewnego miejsca obrazu poprzez zwykłą amplitudę sygnału podstawowego,
- Kolor także poprzez amplitudę, ale sygnału "przesuniętego" w odbieranym widmie o tzw. podnośną koloru czyli 4.43MHz (bo to zostało dodane wiele lat później a musiało być kompatybilne ze standardem czarno-białym, który tego pasma po prostu "nie widział").

- Synchronizacja ramek i linii była zawarta także w amplitudzie sygnału podstawowego, ale poniżej tzw. poziomu czerni.

- Dźwięk był nadawany z modulacją częstotliwości (FM) na podnośnej dźwięku 6MHz.

Wszystko to były proste sygnały więc odbiornik mógł być skrajnie "głupi". Prosty tor odbiorczy z przestrajanym lokalnym generatorem, do tego mieszacz, wzmacniacz pośredniej częstotliwości żeby stłumić wszystko inne oprócz sygnału wybranej stacji, detektor AM/FM i proste filtrowanie: wszystko poniżej częstotliwości podnośnej koloru to jasność (a te najniższe partie jasności czarniejsze niż czerń to sygnały synchronizacji), wszystko co powyżej to kodowany kolor. Już nie wnikam jak, każdy może zobaczyć jak były tworzone sygnały różnicowe koloru w PALu. Żadna filozofia i dlatego takie odbiorniki dawało się robić nawet na lampach a tranzystory to już był luksus. Oczywiście później pojawiły się scalone tory odbiorcze, ale zasada wciąż byłą ta sama: prosty sygnał, prosta obróbka "na bieżąco" i układy nie rozumiejące tego co odbierają i co przenoszą dalej.

Jeżeli w antenie takiego telewizora SNR malał (czyli sygnału użytecznego było coraz mniej a szumu stosunkowo więcej) to przecież głupi odbiornik tego nie mógł wiedzieć. Szum był nieodróżnialny od sygnału z nadajnika i wchodził w tor jak w masło. Przede wszystkim losowo zaburzał amplitudę czyli jasność, więc ekran pokrywał się coraz gęstszym śniegiem. Gdy było go odpowiednio dużo, wchodził na obszar amplitud zarezerwowanych na sygnały synchronizacji i obraz zaczynał "zrywać" i "skakać".

Zobacz: teraz aby podjąć jakąś sensowną akcję po stronie odbiorczej, musimy coś o sygnale wiedzieć a priori. W starym sygnale TV taką wiedzą był np. timing sygnałów synchronizacji oraz obecność specjalnego impulsu tzw. identyfikacji koloru. Tylko te rzeczy były stałe, określone standardem i musiały się pojawić, by telewizor "wiedział", że w ogóle coś odbiera. Tak więc bardzo szybko zrobiono wyłączanie koloru gdy brakło lub pojawiał się nieregularnie identyfikator kodowania kolorowego. Czasem były też transmisje czarno-białe z definicji go pozbawione i dekoder koloru też wtedy się wyłączał. No i tzw. niebieskie ekrany lub wyciemnianie całego obrazu gdy odbiornik nie mógł doszukać się w sygnale miarowych impulsów synchronizacji. Cała reszta czyli dźwięk i treść obrazu były dowolne i telewizor nie mógł wiedzieć czy akurat nadajemy/oglądamy film o śniegu czy jest to szum z kosmosu.

W przypadku informacji kodowanej cyfrowo jest inaczej. Po pierwsze po jednej i po drugiej stronie operujemy liczbami. Obraz w nadajniku jest zamieniany na wielkie macierze liczb określających jasności i kolory poszczególnych punktów obrazu. To samo z dźwiękiem, choć jego udział w strumieniu danych to pewnie 1%. Te macierze są tak wielkie, że nie sposób ich przesłać w sensownej szerokości kanale transmisyjnym. Pamiętaj, ze im więcej informacji chcemy przesłać w jednostce czasu, tym szerszym medium musimy dysponować. A "eter" jest jeden i chcą w nim pracować i telefony komórkowe i WiFi i radary lotnicze i policja i BOR i komunikacja ze sztucznymi satelitami, okrętami podwodnymi, sondą New Horizons gdzieś za Plutonem i zwykłe radiostacje FM i modelarze i GPS i jeszcze mamy piloty do bram, samochodów, i alarmy itd.. Tłok jest tak duży (obejrzyj kiedyś tzw. bandplan czyli mapę przydziału częstotliwości radiowych a padniesz), że nie było szans na wciśnięcie gdzieś przesyłania gigantycznych ilości danych telewizji cyfrowej w jej "prostej" formie. Dlatego zaraz na początku zdecydowano, że będziemy przesyłać dane skompresowane. Nadajnik "upycha" wszystkie pixele obrazu w o wiele mniejsze macierze liczb. Ta kompresja jest oczywiście stratna bo bardzo szybko zauważono, że ludzi nie obchodzi kolor każdego punktu na ekranie osobno a raczej "wrażenie" z tego co widzą, oraz jasności/kolory dużych plam. Dzielimy więc obraz na mniejsze i większe kwadraty (bo tak łatwiej) i przesyłamy informację "kwadrat pixeli o boku B znajdujący się w miejscu X,Y ma kolor C". Takie proste zdanie zastępuje tysiąc liczb niosących kolor tysiąca pixeli. Poza tym okazało się, że przecież nie trzeba przesyłać każdej ramki obrazu od nowa skoro niewiele się w niej zmieniło od poprzedniej. Obrazy TV są w większości statyczne, czasem np. kamera jedzie za aktorem, który w tej sytuacji w obrazie prawie stoi a powoli porusza się tło. Koder w nadajniku wychwytuje takie rzeczy i przesyła informację "ten wielki kawałek obrazu przesunął się o 10 pixeli w górę i 3 w lewo". To pozwala zaoszczędzić kolejne mnóstwo niepotrzebnej informacji i dopiero takie zaawansowane analizy umożliwiły "upchnięcie" ogromu liczb w dostępne (także po starej telewizji, ale trochę po wojsku i trochę po starym GSM) pasma radiowe. Niestety kompresja po stronie nadawczej jest czystą matematyką a ta nie lubi błędów. Po drodze mamy jednak powietrze z całą masą zakłóceń i nasz sygnał, im będzie słabszy tym więcej bitów będzie przekłamanych - nie ma na to rady. Dlatego od razu postanowiono, że do wysyłanych liczb będą wprowadzane tzw. kody korekcyjne czyli specjalnie obliczane dodatki pozwalające po stronie odbiorczej na odtworzenie brakujących/uszkodzonych fragmentów danych. To troszkę zwiększyło sumaryczną ilość informacji do przesłania, ale bez nich nic by nie działało. Żadna ramka obrazu nie dochodziłaby prawidłowo. No i teraz te kody korekcyjne (tzw. ECC) mają swoje ograniczone możliwości. Tj. im zrobisz ten kod dłuższy, tym będzie lepszy i trzeba gdzieś znaleźć kompromis. Jeden kod może np. poprawiać maks. dwa błędy na 256 bitów a drugi - dłuższy może poprawiać aż trzy lub cztery dowolne błędy w tej samej paczce bitów. No i teraz, dopóki szum w tak "obudowanej" transmisji cyfrowej nie powoduje krytycznej liczby błędów, dopóty widzisz płynny obraz. Błędy są cały czas, w wielu miejscach przesyłanych informacji, ale kody korekcyjne usuwają je zanim informacja trafi do dekompresora, który odtwarza właściwy obraz. Jednak gdy zakłóceń robi się zbyt dużo, stopa błędów (tzw. BER czyli Bit Error Rate) przekracza możliwości przyjętego standardu kodowania i cała ramka obrazu/dźwięku lub jej fragment jest odrzucana. Czasem udaje się z niej coś odtworzyć i widzisz jakiś dziwny kolorowy kwadrat na ekranie, ale w większości przypadków obraz "zamiera' na chwilę aż do uzyskania kolejnej poprawnej ramki.

Podsumowując: przejście na "cyfrę" wymusiło kompresję danych. Dekompresja po drugiej stronie wymaga bezbłędnych liczb a to może zapewnić tylko kodowanie korekcyjne, mające swoją "pojemność" w sensie liczby poprawianych błędów.

Gdyby telewizyjne kanały radiowe były wystarczająco szerokie, kompresji by nie było, nadawalibyśmy mnóstwo niepotrzebnych liczb, obraz byłby bezsensownie szczegółowy, ale za to zakłócenia wyglądałyby wtedy prawie jak w telewizji analogowej. Zakłócona liczba wyglądałaby na ekranie jak pixel o dziwnej jasności. Nie byłoby wtedy telefonii komórkowej (ta też kompresuje dźwięk i to bardzo mocno), internetu przez LTE a wszystkie Służby działałyby na wspólnych pasmach z krótkofalowcami, modelarzami i kominiarzami.

Tak więc po prostu musieliśmy nauczyć się:

- kodowania informacji analogowej na liczby,

- kompresji tych liczb poprzez usuwanie informacji nadmiarowych,
- dodawania kodów kontrolnych i korekcyjnych,
- i wszystkiego tego samego tylko odwrotnie po stronie odbiorczej.

I to z powodu kodów korekcyjnych i ich skończonych możliwości naprawiania a nie skokowo zmieniającej się jakości transmisji widzisz "wszystko albo nic" w telewizorze DVB(T).

Gdyby Twój czujnik dodawał kody kontrolne (np. CRC) do tego co wysyła, miałbyś szansę odróżnienia ramek uszkodzonych od dobrych a gdyby jeszcze uzupełniał to o kody korekcyjne (ECC), mógłbyś także poprawiać niektóre z nich. Niektóre popsute za bardzo trafiałyby do kosza,ale te które byś dostawał byłby wyłącznie dobre. A wszystko dlatego, że wiedziałbyś z góry jak powinno wyglądać poprawne CRC z odebranych danych oraz jak i gdzie na podstawie ECC poprawić uszkodzone bity. Bez takiej technologii korzystając z czujnika cyfrowego jesteś wciąż w sytuacji starego telewizora, który musi łykać wszystko co przyjdzie i tylko po odczytach +95°C możesz domyślić się, że coś po drodze się wydarzyło.

BTW: Protokół 1-wire o ile pamiętam z definicji zawiera proste CRC więc biblioteka która gada z czujnikiem po prostu nie przekaże Ci danych gdy stwierdzi błąd CRC. Niektóre czujniki na I2C (np. wilgotności z serii SHT21) też generują CRC. W pewnych aplikacjach (np. samochody, samoloty) takie rzeczy to wręcz obowiązek określony normami. Wszystkie poważniejsze protokoły transmisyjne (Ethernet, USB) mają już na warstwie transportowej ramki z CRC.

BTW2: Dla "wtajemniczonych": zrobiłem tu dużo skrótów, ale starałem się tylko przekazać ideę a nie tłumaczyć PAL, MPEG-layer4, QAM, teorię przesyłania informacji czy ECC. Proszę o wyrozumiałość 🙂