Adrian Florescu YO3HJV

De ce?

Acesta este "fundul putului" (de la "din lac in put") pentru ca am pornit initial de la un controller pentru repetoare, caruia am dorit sa ii adaug detectia si generarea de CTCSS/DCS/DTMF; dupa ce am facut detectorul (bazat pe DSP pe platforma dual-core de la ESP32) am constatat ca nu am niciun mijloc la indemana sa verific acuratetea detectiei.

Standardul industriei cere precizie de sub 1% (0,5% tipic) astfel ca aveam nevoie de instrumentul de laborator cu care sa validez rezultatele decodorului.

Asa ca, dupa o sesiune de brain-storming cu mine insumi, solutia a iesit singura din fum si bere, anume un oscilator disciplinat cu GPS. Acum 20 de ani era dificil de realizat, necesitand mult, mult prea mult efort pe partea de hardware si la un cost prohibitiv.

Hei, dar acum avem placi de dezvoltare foarte capabile, pe masa avand chiar placa pe care dezvoltam repetorul. Aceeasi pe care dezvoltam si decodorul...

Pai, mi-am zis eu, de ce nu si un generator disciplinat cu semnal PPS GNSS?

Generarea semnalului, sinusoidal (ma rog, aproximativ), urma sa pice in sarcina unuia din cele doua DAC-uri disponibile pe platforma ESP32.

M-am consultat cu ChatGPT pentru a verifica daca performantele ESP32 permit implementarea unui astfel de generator si daca este posibila utilizarea unei interfete WEB pentru control (GUI) ca sa scap de accesoriile HW de tip encodere, butoane, afisaj samd...

“Dezbaterile” au fost interesante si m-au ajutat sa cristalizez directia de dezvoltare a proiectului. Chiar e bine sa ai “meciuri” cu artificiala asta, te poate ajuta sa iti pui ordine in ganduri cand o iei pe aratura!

La lucru!

Am mutat insa dificultatile dinspre hardware spre software. Pentru ca, in dezvoltare m-am lovit de un fenomen similar cu cel al dualitatii unda-particula, anume, "observarea" oscilatorului software din ESP32 introducea erori complet aleatorii si imposibil de compensat.

Pentru cei preocupati de latura aceasta, solutia a fost una aparent simpla dar care mi-a cam stors energia vreo doua zile (de vara, pana-n seara).

In loc de o masurare bazata pe diferente de timpi, timerele au fost bazate pe numararea de cicluri si acesteau fost folosite ca referinte.

Inchid paranteza prea tehnica. La fel, nu intru in detalii plictisitoare despre disciplinarea DDS-ului software pe baza impulsului primit de la receptorul GPS dar cateva aspecte tot o sa le prezint, ca deh, ma laud si eu cu ele!

Majoritatea receptoarelor furnizeaza un semnal de tip impuls cu durata de cca 100 msec, la fiecare secunda, cu precizia impusa de semnalul GNSS care, la randul sau, este furnizat de surse de ceas atomice.

Algoritmul de “disciplinare” functioneaza cam asa: timerul care sta la baza generarii de semnale furnizeaza cate un impuls la fiecare ciclu; la fiecare puls primit de la receptorul GNSS, valoarea calculata teoretic este comparata cu valoarea practica. Din diferenta este calculat un factor de corectie care este apoi aplicat.

Pare simplu dar in acest algoritm exista o serie de functii autoadaptive care asigura ca schimbarile sa fie progresive, aplicate la treceri prin zero si alte astfel de trucuri interesante, descoperite prin lovituri repetate de cate un zid in realizarea proiectului...

Cuiul din talpa

Un numar zdravan de ore am consumat intr-o serie de probleme a caror cauza nu reuseam sa o identific si care au tinut procesul pe loc.

Paradoxul: compilarea se derula fara nicio problema insa functionaltatea codului era inexistenta in anumite procese absolut necesare!

O INTrerupere refuza sa se declanseze... Uite-asa, incapatanata ca Domnul Goe! Doua zile am stat sa incerc sa inteleg ce se intampla si chiar ma gandeam ca ma apropii de cea de-a treia (in care daca problema nu se rezolva singura, proiectele trebuie abandonate)!

Ba chiar imi puneam problema daca e cazul sa ma apuc sa invat Assembly...

Pana la urma, dupa un proces intensiv de debugging hardware, concluzia a fost ca problema e intr-o librarie si o “discutie” pe aceasta tema cu ChatGPT a scos la lumina fix asta! Problema era intr-o librarie esentiala, “actualizata” chiar dar care, in acest proces de “imbunatatire” a pierdut functii utile si absolut necesare pentru proiectul meu...

Dupa revenirea la o versiune “invechita”, am depasit primul mare hop.

Verificarea

Nu a fost chiar asa simplu pe cat pare dar la un moment dat, semnalele au inceput sa fie vizibile pe osciloscop si o alta intrebare a iesit din ceata si bere: Cum naiba verific, obiectiv, ce iese pe DAC-uri?

Solutia, iarasi eleganta (zic eu), compararea unei referinte derivate (brutal de dreptunghiulare) din semnalul GPS dar cu frecventa inalta (5KHz) cu semnalele generate de DAC si cu semnalul din GPS cu ajutorul osciloscopului multicanal.

Iar rezultatul... mmmm, rezultatul a fost exceptional si incurajator, abaterile fiind dincolo de limita de observare, in limitele zgomotului semnalului! Caldura m-a tinut departe de drumul pana la laboratorul unde am si echipamente mai sofisticate dar, pentru ceva facut “pe masa”, sunt mai mult decat multumit.

Semnal DCS:

Semnal SINUS:

Interfata Web

Ochiul trebuie si el multumit cumva iar aici am implicat masiv Inteligenta Artificiala pentru ca, pe de-o parte nu stapanesc domeniul si, pe de alta parte, complexitatea interfetei grafice (GUI) si a Front-endului (partea de cod executata in browser, ce comunica cu Back-endul – programul propriu zis din ESP32) necesita interventii coordonate in multe parti de cod. Fix la ce e buna IA! Doar ca uneori are halucinatii!

Pe bune, IA, am descoperit si eu, halucineaza, motiv pentru care a facut praf deseori ceea ce, cu truda, construisem. Prilej pentru ea sa invete niste injuraturi neaose, romanesti, din alea de le zicea Pacala de-I sareau ochii din cap Dracului!

Pana la urma, din confruntare am iesit nitel mai cunoscator in aceste aspecte si macar pot sa ii dau LLM-ului (Large Language Model – IA adica) instructiuni foarte precise, care il tin treaz si in urma carora pot obtine ce doresc!

Am incercat sa fac interfata cat mai simplu de utilizat, ca un aparat de laborator – ceea ce, de fapt, si este acest proiect – dar si facil de utilizat de cine doreste sa isi transforme un ESP32 in sursa de semnal CTCSS/DCS/DTMF pentru diverse proiecte.

Utilizarea este intuitiva si este posibil sa mai fie unele bug-uri; “ochiul stapanului ingrasa vita” asa ca imi e greu tot mie sa le descopar, ramane ca utilizatorii sa strige ce nu e OK pe ici pe colo.

In principiu, interfata cu utilizatorul reflecta arhitectura interna:

Este impartita in sectiuni logic organizate ce ofera control si feedback... ce sa va povestesc eu mai mult?

Are si o interfata pentru incarcarea fisierelor necesare pentru interfata grafica, cine doreste isi poate face propria interfata!

Habar nu aveti cat m-am chinuit sa fac sa mearga incarcarea batch a fisierelor! A fost crima sa le tot incarc unul cate unul!

Cateva cuvinte despre performante:

-Acuratete in generarea de semnal CTCSS si DCS, mai buna de 1% (as zice mai buna ca 0.5%) dar nu vreau sa ma falesc prea tare! I-am atasat si un generator de ton cu frecventa intre 40 Hz si 1.2 KHz insa peste 900 Hz semnalul incepe sa se degradeze datorita limitarilor convertorului digital-analog.

-Nivel de semnal DAC1 si DAC 2:
• max 2.35 Vpp.
• med: 1.6 Vpp.
• min: 850 mVpp.

-Iesiri de semnal logic 0-3V pentru diverse semnale, disciplinate si ele cu GNSS.

Integrarea in laborator

Pentru ca proiectul sa devina un echipament de laborator, este utila conectarea unui modul GNSS care sa aiba vizibilitate spre cer. Codul nu foloseste nicio alta informatie transmisa de acest modul ci doar PPS, astfel ca un conector cu 3 fire poate sa isi faca bine mersi treaba.

Chiar si in absenta receptorului GNSS, precizia este una destul de mare, demonstrata de observarea factorului de corectie aplicat in urma semnalului de 1PPS.

In ceea ce priveste semnalul din domeniul analogic, adica iesirile, o minima filtrare pe fiecare dintre cele doua iesire ar putea imbunatati calitatea semnalului reducand posibilele artefacte produse de generarea digitala. Desi pe fiecare dintre cele doua DAC-uri exista un “volum” digital, ar fi util sa existe si potentiometri pentru reglajul fin al nivelului catre DUT (echipamentul care beneficiaza de semnal).

Un filtru trece-jos pentru frecvente mai mici de 1 KHz pentru DAC 1 si unul cu limita la 2 KHz pentru DAC 2 ar fi bine venite; in absenta lor, macar o retea de 1 Kohm si un condensator de cca 1 nF la masa ar putea sa mai reduca din artefacte cu pretul unei pierderi din semnalul util.

Generatorul poate fi integrat in reteaua WiFi existenta sau poate sa genereze propriul Access Point.

Vedeti? Asa e ca ati uitat de la ce s-a pornit?

Da, si eu am uitat; aveam nevoie de ceva care sa genereze foarte precis un ton CTCSS...

Va las link spre pagina de GitHub a proiectului unde il gasiti gata compilat, sa n va mai bateti capul cu librariile necesare: https://github.com/yo3hjv/CCTCSS_DCS_DTMF_Generator/tree/main

73 de Adrian, YO3HJV

Adrian Florescu YO3HJV

Articol aparut la 29-7-2025

1706