Przeszukaj forum

Prezentowane urządzenie powstało na konkretne zamówienie: ma odczytywać raporty z maszyny sprzedającej słodycze. Jednej z wielu takich jakie można spotkać na stacjach benzynowych dworcach PKP, autobusowych itd... Głównym celem jest kontrola przepływu gotówki akwizycja i wysyłanie danych poprzez sieć GSM - na tym etapie przez SMSy. Pierwszą trudnością podczas przygotowania się do projektu było to, że ciężko znaleźć opisy protokołów używanych w tych maszynach, najgorzej było z MDB (Multidrop bus) w Polskiej części internetu niema nic interesującego w tym temacie, jak zwykle najwięcej opisów było na stronach anglojęzycznych, rosyjskich jak również sporo po hiszpańsku. W ramach badania magistrali MDB powstał optoizolowany podwójny port MDB - UART Później okazało się że nie potrzebuję MDB do odczytu danych, wszystko udostępnia mi standard EVA - DTS który jest dużo prostszy do obróbki. I tak powstało owo urządzenie tj jak narazie jego prototyp do testów 😉 Po co moduł WiFi? Faktem jest że wszelkie potrzebne dane spokojnie obsłużyłby jakiś mały AVR z kilka kB pamięci RAM. Miałem zamiar takiego małego stworka użyć w tym projekcie. Na szczęście ten "zamiar" trwał kilka chwil, do czasu aż zapytałem: w jaki sposób ma być przeprowadzona konfiguracja? Jakiś LCD z klawiaturą? Kablem z PC? hmmm a może aplikacja w telefonie? No i właśnie, tutaj konsternacja, ekipa klienta nie pomyślała nad tym heh. Postanowione zostało, że telefon obsługiwać to nawet maupa umi 🤪 więc moja w tym głowa aby każdy, nawet rzeczona maupa umiała poustawiać to i owo. W ten sposób, na pokładzie znalazł się ESP8266 który na czas konfiguracji staje się Access Point - em z uruchomionym serwerem www potrzebnym do aktualizacji oprogramowania - konkretnie https://github.com/ayushsharma82/ElegantOTA. Oraz z uruchomionym UDP za pomocą którego przeprowadzana jest konfiguracja urządzenia, poprzez aplikację Android (znów muszę tutaj wychwalić działalność Anywhere Software z ich pakietem b4x. Serio nawet taka maupa jak ja, dała radę po krótkim czasie nauki [heh] napisać aplikację która działa i nie wygląda jak g...o. Po czasie, nie wiem... w czerwcu zainstalowałem ten pakiet? coś około tego). Po konfiguracji/aktualizacji system przechodzi w tryb pracy nominalnej czyli wyłączona jest łączność wifi, a obsługiwany jest modem GSM lub prowadzony jest nasłuch raportów z DTS. O ile odczytywanie raportów z automatu nie sprawiło szczególnych trudności, z modemem GSM nie było tak kolorowo. Problemy z modemem - SIM800l: - brak bibliotek które potrafiłyby obsługiwać wiadomości w trybie PDU w jedną i drugą stronę - masakryczne ilości delayów w libsach już dostępnych - wykorzystane tylko kilka poleceń AT dla najprostszych funkcji - później przyszły problemy sprzętowe, zemściło się moje niedbalstwo: ścieżka zasilania modułu GSM była zdecydowanie zbyt długa co negatywnie wpływa na delikatnego ESP. Ale najwięcej szkoliło dziadowskie złącze szufladkowe! Dawało o sobie znać w najmniej spodziewanym momencie, kiedy już zdawało się że poprawiłem błąd w sofcie, nagle reset. Dobrze że to wszystko działo się na biurku, w pewnym momencie chciałem już odpuścić... Ale że "nie ze mną te numery Bruner", po kilku dniach odpoczynku skapłem się co jest źle. No, stąd ten kondensator dolutowany do modułu GSM, te moduły potrzebują sporo energii, na szczęście impulsowo, trzeba o tym pamiętać i zadbać o prawidłowe zasilanie, powiedziałbym że to 90% sukcesu przy pracy z nimi. Jeszcze w kwestii bibliotek. Co prawda nie napisałem takowej w całości, tak aby obsługiwała wszystkie możliwości modemu, ale zrobiłem potrzebne mi funkcje które np: po takim prostym poleceniu "AT" nie czekają _delay_ms(1000); a za to aktywnie nasłuchują kiedy przyleci ten "OK" z timeoutem 1000mS a to już dużo lepiej i szybciej działa. Prototyp działa, jednak pcb musi być zaprojektowana od podstaw, przede wszystkim bez modułu node mcu, za to esp07. Cały układ zasilania, zamiast stabilizatora liniowego przetwornica, zastanawiam się jeszcze nad tym sim800l, zostawić jako dev moduł czy sam układ? Niestety nie mogę podzielić się ani kodami źródłowymi ani schematami, tak wiem że w dziale DIY powinno się takie rzeczy umieszczać no ale nic nie poradzę.

Większość osób myśląc o cyfrowej telekomunikacji, myśli o współczesne mikroelektronice: smartfonach, komputerach i Internecie. Nie każdy zdaje sobie sprawę z tego, że idea przesylania informacji zakodowanej w ciągach zer i jedynek jest dużo, dużo starsza. Pierwszym urządzeniem tego rodzaju był telegraf skonstruowany przez Emille'a Baudot w latach siedemdziesiątych XIX wieku. Urządzenie po stronie nadajnika posiadało klawiaturę złożoną z pięciu przycisków, które operator musiał wciskać w różnych kombinacjach. Urządzenie wysyłało na linię ciąg impulsów, odpowiadających wciśniętej kombinacji. Odbiornik interpretował ten sygnał drukując na papierowej taśmie odpowiednią literę lub cyfrę, w jej naturalnej formie. Na początku XX wieku idea to została udoskonalona. Nadajnik został wyposażony w klawiaturę podobną do tych stosowanych w maszynach do pisania. Tak narodził się dalekopis. Transmisja danych pomiędzy tymi urządzeniami przypominała standardowy interfejs szeregowy. Z tą różnicą, że z przeciwieństwie do TTL UART-a czy RS323 poszczególne stany logiczne nie były kodowane przez wartości napięć, ale przez fakt przepływu (bądź nie) prądu w obwodzie. Normalnie przez linię płynął prąd o ustalonej wartości (zazwyczaj 60, 40 lub 20 mA). To był stan domyślny. Rozpoczęcie nadawania kolejnego znaku wymagało nadania bitu startu, czyli chwilowego przerwania obwodu. Potem nadajnik oczekiwał na pięć bitów z kodem znaku w alfabecie Baudot (zwanym także międzynarodowym alfabetem telegraficznym). Na końcu pojawiały się bity stopu w trakcie których odebrany znak był drukowany na papierze. Ktoś zapewne zauważył już, że używając pięciu bitów można było zakodować maksymalnie 32 znaki - zdecydowanie za mało, aby pomieścić wszystkie litery alfabetu, cyfry i znaki interpunkcyjne. To prawda. Stosowano pewną sztuczkę - dwie kombinacje bitów były zarezerwowane do przełączania pomiędzy dwoma rejestrami zawierającymi litery oraz cyfry i inne znaki. Ne stosowano także rozróżnienia na male i duże litery. Dalekopis chociaż w pełni cyfrowy, był urządzeniem elektromechanicznym, radzącym sobie bez pojedynczego tranzystora (chociaż oczywiście w latach osiemdziesiątych i dziewięćdziesiątych produkowano nowoczesne, elektroniczne wersje). Dalekopisy były powszechnie używane do przesyłania wiadomości przez wojsko i państwowe służby. Poczta wykorzystywała je do transmisji telegramów. Stosowano je także w roli terminali komputerowych, przed pojawieniem się monitorów CRT. Ślad tej zaszłości historycznej zachował się w nomenklaturze stosowanej w systemach uniksowych, gdzie terminal jest oznaczany skrótem TTY - od angielskiego słowa "teletype", czyli właśnie dalekopis. Przepraszam za ten przydługi wstęp, nie byłem jednak pewien, czy wszyscy będą jeszcze kojarzyć o jakie urządzenie chodzi... Przechodząc do sedna sprawy. Na co dzień pracuję w krakowskim Muzeum Inżynierii Miejskiej. Jakiś czas temu został nam przekazany dalekopis T100, wyprodukowany w latach siedemdziesiątych w Czechoslowacji, na licencji Siemensa. Ponieważ posiadaliśmy już taki eksponat, zostałem poproszony o sprawdzenie możliwości uruchomienia go i wykorzystywania w roli interaktywnej instalacji, zamiast "martwego" eksponatu ukrytego w muzealnej gablocie. Tak rozpoczęły się moje eksperymenty. Najpierw skonstruowałem prosty interfejs USB, oparty na starym mikrokontrolerze AT89C2051 i układzie FTDI. Do generowania pętli prądowej 40 mA używałem zestawu kilku baterii 9V oraz rezystorów o dużej mocy. Komunikacja z dalekopisem ruszyła bez problemu - pojawiła się jednak inna trudność. Okazało się, że uszkodzony jest moduł wzywaka - urządzenia odpowiedzialnego m.in. za zdalne włączanie silnika dalekopisu przy połączeniu przychodzącym, sygnalizowanym odwróceniem kierunku przepływu prądu w linii. Naprawa tego modułu okazała się bardziej skomplikowana niż początkowo sądziłem, ostatecznie postanowiłem więc wymontować wadliwą część i sterować silnikiem za pomocą przekaźnika, zamontowanego w moim interfejsie. Finalna wersja interfejsu zawiera mikrokontroler PIC32MX270F256B oraz moduł GSM SIM800L. Wykorzystałem także 2MB pamięć SPI flash, do wykonywania elektronicznej kopii przychodzących wiadomości. W osobnej obudowie znajduje się generator pętli prądowej, złożony z zasilacza transformatorowego oraz zestawu kondensatorów. Całość można obecnie oglądać na wystawie "Uwaga! Nieprzyjaciel podsłuchuje." w Muzeum Inżynierii Miejskiej w Krakowie. Po wysłaniu SMS-a na podany numer można oglądać dalekopis podczas pracy.

W moim poprzednim projekcie niektórzy przeczytali zapewne wzmiankę o tym , że powstała jego oddzielna wersja z modułem GSM , który całkiem nieźle sobie radził. Pomyślałem więc , że czemu by go tutaj nie opisać w końcu sam projekt został ukończony. tutaj początki czyli zlutowany moduł neoway a w tle genuine arduino uno , które w początkowej fazie zostało wykorzystane do przetestowania coś na zasadzie "czy to będzie działać". Okazało się , że tak aczkolwiek trzeba było dokonać zmiany baud rate na 9600 bit/s. Pod arduino jest bateria ze smartfona z , której zasilany jest moduł. Natomiast na arduino nakładka , która dała łatwiejszy dostęp (powielony) do pinów zasilania i masy. Na płytce stykowej widać konwerter poziomów logicznych przez który odbywa się komunikacja (SoftwareSerial). Piny IO modułu neoway pracują z napięciem 2,85V ale tolerują napięcie do 3,3V. Dobrze jest sprawdzić napięcie na pinie 3,3V przed podaniem go na konverter (w orginalnym uno nie będzie raczej problemu ale jeśli to będzie klon to możecie się zaskoczyć). Po kilku testach postanowiłem całość nieco zmniejszyć. to w zasadzie dalej jest to samo tyle , że model arduino uno zastąpiłem nano jeszcze z ATMega 168. Tact switch nad modemem to przycisk on/off , który uruchamia modem po dłuższym przytrzymaniu. tutaj już prawie wszystko było gotowe. Nad modemem przetwornica step-up regulowana. Wyjście z przetwornicy ustawione na 4,89V. Pewnie zastanawiacie się czemu na nie na 5V a to dlatego, że w tym modelu na pinie 3,3V jest 3,4V to wolałem nie ryzykować i lekko obniżyłem napięcie zasilania co dało pożądany rezultat w postaci spadku napięcia na pinie 3,3V nawet lekko poniżej 3,3V. ogniwo 18650 które widzicie pojawiło się tylko tymczasowo jako źródło zasilania aczkolwiek gdyby obudowa była większa to pewnie bym je zostawił. Na płytce znajdują się 4 DIP switch'e i tak pierwszy od góry włącza/wyłącza przetwornicę i tym samym doprowadza napięcie do wszystkich modułów poza modemem gsm (modem jest zasilany bezpośrednio z ogniwa). Następnie dwa DIP switch'e obok siebie wlączają/wyłączają piny TX i RX arduino od bluetooth. Ostatni DIP switch odcina napięcie do arduino. W ten sposób można wgrywać skecze do arduino po usb bez rozłączania kabli. Po prawej stronie mamy czujnik ruchu a po lewej to ten "stary telefon" w , którym nie działa dotyk ale można do niego podłączyć mysz. tutaj widać kolejno, start modemu, sprawdzenie rejestracji do sieci , siłę i jakość sygnału, a na koniec napięcie ogniwa. void skalaAku() { int aku2 = analogRead(A6); if ((aku2 == 860) && (charging == 0)) { digitalWrite(4, HIGH); //wyłączamy przekaźnik zasilania tp4056 Serial.println("Ogniwo max"); skala = 0; charging++; } else if ((aku2 == 790) && (skala == 0)) { m590.write("AT+CMGS=\"111222333\"\r"); // podajemy nr telefonu delay(300); getm590(); m590.write("Ogniwo 3,9V"); //podajemy treśc wiadomości m590.write(26); // Kod 26 = CTRL+Z delay(2000); // czekamy na wysłanie getm590(); // sprawdzamy czy poszło czy error skala++; } else if ((aku2 == 720) && (skala == 1)) { //740 OK m590.write("AT+CMGS=\"111222333\"\r"); // podajemy nr telefonu delay(300); getm590(); m590.write("Ogniwo 3,5V"); //podajemy treśc wiadomości m590.write(26); // Kod 26 = CTRL+Z delay(2000); // czekamy na wysłanie getm590(); // sprawdzamy czy poszło czy error digitalWrite(4, LOW); //włączamy przekaźnik zasilania tp4046 charging = 0; skala++; delay(300); } else if ((aku2 == 705) && (skala == 2)) { m590.write("AT+CPWROFF\r"); } } Tutaj mamy funkcję, która była wykonywana przez około tydzień czasu no i raz nie dostałem sms'a. Czas pracy na jednym cyklu ładowania to było jakieś 17h jak dobrze pamiętam więc wychodziło 2 smsy na dobę. Jeżeli ktoś chciał by z tej funkcji skorzystać to trzeba... void getm590() { if (m590.available() > 0) { Serial.print(m590.readString()); } } najpierw wpisać tą funkcję albo przynajmniej wcześniej zadeklarować , że funkcja getm590() wystąpi oraz zadeklarować dwie zmienne typu int , które występują w funkcji skalaAku() a to "świeże zdjęcie" dzisiaj zrobione na potrzeby opisu ale sam projekt tak wyglądał już w lipcu 2018 i tak jak wyżej pisałem bateria ze smartfona wróciła pod płytkę a zaoszczędzone miejsce zostało przeznaczone na moduł z dwoma przekaźnikami i od góry ładowarka tp 4056. Jeden przekaźnik może trochę dziwnie wykorzystany ale chciałem żeby ładowarka była wyłączana przed przekroczeniem napięcia 4,2V na baterii co widać w kodzie. tak to wyglądało po zamknięciu i jedynym problemem było to , że PIR sam się wzbudzał co kilka godzin pracy nawet po próbie przeniesienia go poza obudowę. Przyczyn dalszych nie szukałem bo tak jak napisałem na początku projekt powstał aby przetestować sam modem a ten nawet całkiem dobrze radził sobie z raportowaniem stanu naładowania baterii.