Dupa ce am observat ca informatiile meteo nu sunt preluate de fiecare data de la serverul openweathermap, am modifcat programul ceasului anterior sa imi arate si ora ultimei actualizari.
Schema este aceeasi,
Programul NTPclock_8x32_v2_16.ino are mai multe modificari fata de versiunea anterioara: inlocuirea bibliotecii ESP8266WiFi cu WiFi (pentru ESP32), revenirea la biblioteca SolarCalculator pentru determinarea orelor de rasarit si apus de soare, neafisarea informatiilor meteo prea vechi, afisarea orei de preluare a datelor meteo, adaugarea unei culori pentru ledul de indicare stare informatii meteo (mov, daca nu s-au preluat de prea mult timp), o resetare pe timpul noptii, etc.
Am realizat 2 filmuletele, in care se vede mai bine ce am realizat:
Am depistat o eroare in programul NTPclock_8x32_v2_16.ino.. in subrutina de calcul a orelor de rasarit si apus de soare.. variabila zi (care este ziua din saptamana)
Dupa ce am testat ceasul NTP simplu cu Raspberry Pico W ce prezenta infrmatiile pe ecranul de monitorizare seriala, am adaugat placii, pe care e Raspberry Pi Pico, afisajul cu 8x32 leduri adresabile si comutotorul de ora vara/iarna,
doar ca am scos parte de configurare usoara a retelei WiFi, deoarece nu e compatibila cu Raspberry Pi Pico W si am schimbat pinii, asa ca l-am salvat separat, NTPclock_8x32_v2_9.ino.
In functie de pozitia comutatorului, avem ora de iarna (pinul de selectie la GND) sau de vara (pinul de lectie la +3,3V).
Am modificat programul, schimband si pinii, pentru a fi sigur ca nu sunt ei de vina, obtinand versiunea NTPclock_8x32_v2_12.ino care este combinata cu schema
Dupa ce am observat ca ceasul functioneaza dupa 48 ore, fara blocare,
Pentru a gasi motivul care care determina blocarea sau, mai bine zis, acum, activarea sistemului de repornire, am pus in stanga sus sa am un led ce e aprins in culoare verde cand ceasul este conectat la reteaua wifi si preia si ora de la serverul NTP, in culoarea albastra daca sistemul este ori deconectat de la retea ori nu preia ora de la serverul NTP, in culoarea rosie daca sistemul de transmisie/receptie wifi este deconectat/oprit. In partea dreapta, am un led care este verde daca s-au trimis si s-au preluat datele meteo de la serverul openweathermap, in culoarea albastra, daca s-au trimis datete catre server, dar nu s-au primit date si in rosu, daca nu s-au pututt trimite date, cel mai probabil sistem wifi oprit.
Schema de conectare la placa RP2040-Zero este simpla si deriva din cea a cu ESP8266 (Wemos D1 Mini):
- modulul de ceas RTC se alimenteaza cu +5V si GND, conectanduse SDA la GP4, iar SCL la GP5,
- modulul cu senzor DS18B20 se alimenteaza la +5V si GND, iar pinul de date la GP14,
- afisajul cu 8x32 leduri adresabile e alimenteaza la +5V si GND, iar pinul de date la GP15.
Dupa cum cred ca stiti, modulul de temperatura are senzorul DS18B20 si rezistenta de pull-up de 4,7kΩ dintre pinul de date si +5V, uneori si un led inseriat cu o rezistenta.
Ceasul este in teste de circa 3 saptamani si nu a apaut nici-un blocaj sau eroare, comparativ cu proiectul de ceas NTP cu placa Raspberry Pi Pico W, pe care o sa-l prezint in curand.
Dupa ce a sosit si o placa Raspberry Pi Pico W, am zis sa fac un prim test cu placa (care nu avea pini lipiti), asa ca am adaptat un program de ceas NTP, care arata informatia pe ecranul de monitorizare seriala a programului Arduino IDE.
In urma unor teste cu o placa Raspberry Pi Pico W pentru un ceas NTP, am observat ca uneori sistemul se blocheaza (ingheata), asa ca, dupa ce am cautat pe net, si nu am gasit solutie multumitoare, m-am gandit sa aplic o solutie extrema, un sistem care se reseteze placa Raspberry Pi (sau chiar Arduino) cand placa nu mai trimite impulsuri pe un anumit pin.
De fapt, am folosit 2 pini, dupa cum se vede in schema si simularea, realizata cu programul Micro-Cap
prinul numit INIT (D7) are 5V imediat ce porneste placa Arduino (sau Raspberry Pi Pico), ulterior pe pinul D5 numit in schema PIVIEM se trimite semnal dreptunghiular cu frecventa de cca. 1000Hz (semnal PWM 50%), apoi pinul INIT se aduce in 0V, apoi dupa un timp si semnalul PIVIEM cade in zero.
Dupa cum se vede din filmulete si imagini, dupa circa 12ms de la pierderea semnalului, pinul RESET din 5V cade in 0V pentru circa 7ms.
Primele 2 filmulete au fost multumitoare, urmarind semnalul cu un osciloscop didactic, sa-i zic asa. model DSO-TC3:
apoi am mai conectat in osciloscop-tableta, model ADS1013D, cu 2 canale, de la care avem pretentii cam mari, pentru timpii descrisi mai sus, reprezentarea este multumitoare
Am modificat putin timpii de reactie, la cateva sute de ms dupa disparitia semnalului dreptunghiular si cateva sute de ms de reset,
Am gasit, intai, in articolul How to Add a Raspberry Pi Pico Reset Button ca placilor Raspberry Pi Pico (fara sau cu W) li se poate adauga un buton de reset, conectant un buton fara retinere intre pinul 30 (RUN) si GND
asa ca am schimbat si placa, de data asta conectand Raspberry Pi Pico W, pinul INIT este GP21, iar pinul PIVIEM este GP20, semnalul RESET se duce in RUN, montajul se va alimenta din 3V3 (OUT), respectiv GND:
Osciloscopul-tableta a fost greu de controlat pe modul de captarea a unei imagini statice, unde pot masura timpii, dar nu am insistat, deoarece rezultatele vizuale au fost multumitoare, dupa cum se vede in filmuletele:
Dupa ce am testat cateva luni ceasul NTP pe afisaj 8x32 leduri adresabile, am zis sa adaug si ceasul binar-zecimal testat de curand (vezi articolul), programul rezultat find NTPclock_8x32_v2_8.ino, schema este aceeasi
In perioada asta am transferat proiectul pe o placa de test, de pe breadboard: