

-----------------------------------

Sorin Sfartz

18 Oct 2018 23:13


Adaptor pentru SkySafari

-----------------------------------

Cei care doresc sa foloseasca pentru controlul monturii programul SkySafari, instalat pe telefon/tableta,  sunt obligati sa isi cumpere un adaptor wifi sau bluetooth care de regula sunt destul de scumpe.

M-am gandit la cateva variante mai ieftine si nu foarte dificil de realizat. Toate variantele au fost testate pe montura CGEM si au functionat ok. In principiu ar trebui sa functioneze si la alte monturi. Conexiunea la montura sa face via portul serial RS232 care este disponibil la montura CGEM la capatul telecomenzii. Multe monturi "goto" dispun de un astfel de port.  Pentru conexiunea la acest port este necesar un adaptor TTL/RS232 care se gaseste la pretul de 3-4eur (poate si mai ieftin prin China). Eu am folosit adaptoare bazate pe chipul MAX3232 si au functionat foarte bine. CGEM are si un port auxiliar care este identic cu cel in care se introduce telecomanda, insa acest gen de port este un port serial TTL prin care se comunica cu un alt tip de protocol, decat acelea folosite de programele de planetariu. Folosirea unui astfel de port ar elimina nevoia adaptorului RS232, insa in acest caz ar trebui scris un software care sa replice exact ceea ce face telecomanda.

Adaptoarele RS232/TTL pe care le-am folosit aveau toate port serial cu 9 pini tip mama. Cablul de la montura are si el tot o mufa db9 mama deoarece este gandit sa fie conectat la un port serial de la pc, care de obicei este tata. Eu nu am gasit adaptor rs232/ttl tata, astfel ca in teste am pus niste fire de conexiune intre mufe. Conexiunea se poate face mai elegant cu 2 mufe db9 de tip tata cu firele conectate corect. Pinul 5 (Gnd) al adaptorului  trebuie conectat la pinul 5 al monturii. Pinul 2 al adaptorului trebuie conectat la pinul 3 al monturii si pinul 3 al adaptorului  la pinul 2 al monturii. 
In partea TTL,  adaptorul se conecteaza la un microcontroler care la randul sau este conectat la un adaptor wireless (bluetooth sau wifi).

In prima varianta am folosit o placuta arduino nano (o clona chinezeasca care costa pe aliexpress cca 2usd). Aceasta are conectati pinii 8 si 9 la pinii Tx si respective Rx ai modulului Bluetooth HC-05. Modulul bluetooth HC-05 costa pe la noi cca 30 lei insa pe aliexpress se gasesc cu 2.5-3usd.
Placa arduino nano are de asemenea pinii 10 si 11 conectati la pinii Tx si Rx ai modulului RS232. Uneori aceste module RS232 au logica inversata astfel ca in acest caz se conecteaza Rx la Rx si Tx la Tx. Pinii Rx, Tx ai modulului HC-05 functioneaza la 3.3V, astfel ca pinul Rx al lui HC-05 trebuie protejat, deoarece pinul Tx al lui arduino nano are 1logic = 5V. Pt aceasta am pus 2 rezistente intr-un divizor rezistiv, pt ca la iesirea arduino sa avem 3.3V. Pinul Rx al lui nano interpreteaza fara probleme 3.3V de la HC-05 ca 1 logic. In fine problema finala e alimentarea. O varianta simpla ar fi conectarea placii nano direct la pinul Vin cu +12V si folosirea iesirii de 5V pt a alimenta atat modulul HC-05 cat si adaptorul RS232. O placa autentica ar putea merge asa, insa clonele nano testate de mine au un regulator de tensiune foarte prost care se arde foarte repede. Astfel ca am adaugat un regulator LM7805 care alimenteaza toate placile cu 5V. Aceste regulatoare costa de regula maxim 1euro. 

Am atasat o poza cu conexiunile si o poza cu montajul de test. Realizarea acestuia mi-a luat vreo 15 minute si m-a costat: adaptor RS232 3 euro + modul HC-05 30 lei (in china se gasesc mult mai ieftin) + clona arduino nano 1.5euro + LM7805 0.5 euro = cca 12 euro.
Cea mai laborioasa parte a fost scrierea softului care functioneaza ca un bridge intre HC-05 si adaptorul RS232.


-----------------------------------

Sorin Sfartz

18 Oct 2018 23:35



-----------------------------------

Am folosit portul hardware serial pentru debug si 2 biblioteci software serial diferite, deorece software serial clasic din arduino nu functioneaza cu 2 porturi simultan. Pentru incarcarea programului in arduino nano trebuie instalat mai intai arduino IDE de pe pagina oficiala:

https://www.arduino.cc/en/Main/Software

Apoi trebuie adaugata bibiloteca aditionala altsoftserial scrisa de Paul Stoffregen :

https://github.com/PaulStoffregen/AltSoftSerial

Se face download in format zip, se extrage folderul care e denumit AltSoftSerial-master si care trebuie redenumit AltSoftSerial. Folderul redenumit trebuie pus in folderol Arduino/libraries care de regula e instalat in folderul Documents. Dupa aceasta programul poate fi incarcat in arduino ide. Pt cei care nu au mai folosit arduino ide: odata cu conectarea placii nano la pc, un nou port COM apare disponibil si trebuie selectat in meniul Tools/Port. Apoi trebuie selectata placa in meniul Tools/Boards - Arduino Nano. La unele versiuni ide trebuie selectat si daca este un chip de tip vechi sau nou. 

Dupa toate aceste preliminarii simple se apasa butonul Upload si daca totul merge bine apare intr-o bara mai jos mesajul Done Uploading. Apoi placa este gata de functionare.

In dispozitivul mobil se face conexiunea cu HC-05 care odata alimentat devine vizibil in lista de dispozitive bt. In SkySafari se configureaza la conexiune - BlueTooth. Conectarea dureaza putin mai mult la inceput deorece modulul HC-05 trimite la inceput cateva caractere de initializare care trebuie ignorate. Insa dupa 1-2 secunde, SkySafari se conecteaza si functioneaza bine chiar si la o rata maxima (10 cereri de coordonate/sec). 

Am atasat programul instalat in placa arduino nano. Este in format pdf pt ca forumul nu permite atasarea altor soiuri de fisiere. In arduino ide se deschide un nou sketch si se goleste de continut. Apoi se copiaza in el continutul din fisierul pdf (fara prima linie de titlu) se salveaza si apoi se face "upload".


-----------------------------------

Sorin Sfartz

19 Oct 2018 00:23



-----------------------------------

Varianta nr.2

Cea mai ieftina varianta testata, implica renuntarea la un microcontroler si folosirea unui modul wifi ieftin de tip ESP8266. Aceste module au inclus un microcontroler mult mai rapid decat arduino, care cu ceva efort poate fi programat pentru a face el conexiunea intre modulul wifi si portul serial. 

Exista module ESP8266 configurate ca placi de dezvoltare cu o multime de intrari/iesiri, etc. Insa eu am folosit cel mai ieftin modul care are doar 8 pini : Rx, Tx, Vcc, Gnd, Reset, Enable,GPIO0,GPIO2. Placuta poate fi programata cu un adaptor USB-TTL sau daca aveti o placa arduino uno,aceasta poate fi folosita ca un adaptor USB-TTL  conectand pinul reset la Gnd. In acest caz se conecteaza pinul Tx al lui 8266 la pinul Tx al lui Uno si respectiv Rx la Rx. Daca folosim un adaptor USB-TTL conectam Rx  la Tx si Tx la Rx. Majoritatea documentatiilor avertizeaza ca ESP8266 functioneaza doar la 3.3V. Placuta trebuie alimentata la 3.3V, dar cel putin doar pentru partea de upload a programului se poate folosi iesirea Tx de 5V a lui Uno fara probleme. Daca folosim un adaptor usb-ttl, acesta trebuie setat din jumperi sa aiba 3.3V la iesiri (majoritatea adaptoarelor permit aceasta). In arduino ide trebuie selectata placa generic ESP8266 module, upload speed 115200 si portul COM. Pentru progamarea lui ESP8266, in plus fata de conectarea adecvata a pinilor seriali Rx si Tx, trebuie conectat GPIO0 la Gnd, INAINTE de alimentarea placii. Astfel placuta cu pinul GPIO0 conectat la Gnd va intra la alimentare in modul de programare.  

Dupa incarcarea programului in modul, acesta se conecteaza direct la adaptorul RS232. Am atasat poze cu schema si cu montajul de test. Programul configureaza un server care va comunica prin protocolul TCP cu clientul (skysafari).  In skysafari se introduce adresa ip a serverului (192.168.4.22)si portul 80. Acestea,cat si numele retelei create de 8266 pot fi schimbate in program. 

Placuta este foarte rapida, astfel ca la citirea datelor ce vin de la montura CGEM, trebuie intarziat putin procesul de citire pentru ca toate datele sa ajunga in bufferul serial. Am mentionat aceasta, pt ca pentru alte monturi aceste valori ar putea fi nevoie sa fie adaptate. Pt CGEM e nevoie de un delay de 2ms dupa fiecare byte citit. Acelasi lucru e valabil si la citirea datelor din modulul bluetooth din montajul precedent. 

Costul acestei variante este de cca 5euro. 
Avantajul acestei variante este ca are nevoie doar de 2 componente si este ieftina. Dezavantajul este ca programarea lui ESP8266 e putin mai complicata. In plus acest modul se mai blocheaza uneori si are nevoie de un reset.  Poate e o problema doar cu modulul pe care l-am folosit eu.


-----------------------------------

Sorin Sfartz

19 Oct 2018 00:26



-----------------------------------

Iata si un filmulet care arata cum functioneaza varianta 2 - cu ESP-8266

https://www.youtube.com/watch?v=etEBoD1yIrg&feature=youtu.be


-----------------------------------

Sorin Sfartz

19 Oct 2018 00:41



-----------------------------------

In final am testat o varianta similara cu varianta 2, insa in loc de ESP8266, am folosit un modul ESP32, care s-a nimerit sa fie prin sertar. S-ar putea folosi o placa de dezvoltare bazata tot pe ESP8266 cu acelasi program de conectare prin wifi. In testul facut de mine am facut conexiunea prin bluetooth (modulul ESP are si wifi si bluetooth). Aceste placi sunt mai usor de programat avand port usb. Placa testata de mine nu era ieftina - era un model Huzzah esp32 de la Adafruit, insa exista in china astfel de placute la cca -5-6 euro. O sa incerc sa comand o clona chineza si sa o testez.


-----------------------------------

nobody

19 Oct 2018 01:48



-----------------------------------

Ce rol are firstChar=='$' ?


-----------------------------------

Sorin Sfartz

19 Oct 2018 08:12



-----------------------------------

Pai e o conditie care verifica daca comanda primita de la SkySafari incepe cu ´$´. Modulul bluetooth trimite la initializare un sir de genul $$$, care perturba comunicatia cu montura. Din cauza lui nu se conecta SkySafari. Daca sirul inStrWifi (care ipotetic contine comanda trimisa de skysafari), incepe cu $, se citesc in continuare caractere din sir pana se termina toate caracterele ´$´. Orice insiruire de 2 sau mai multi dolari e ignorata. Apoi in eventualitatea in care in buffer s-au acumulat dupa sirul de caractere $$$ si alte caractere utile, dupa ce se termina toti dolarii sunt acumulate (eventualele caractere utile) in alt sir (realString) care este trimis la montura ca si comanda. 

Nu sunt sigur ca asta e abordarea cea mai buna. Daca or exista protocoale care sa inceapa cu $$ sau cu $$$ sau $$$$ etc, programul asta va ignora astfel de secvente. Prima data am exclus complet orice $ din comenzile primite, dar chestia asta nu merge pentru ca protocolul celestron trimite si caractere $ in comenzile de slew de exemplu. In fapt protocolul asta celestron e cel mai idiot protocol pe care l-am vazut: trimite zeci de caractere netiparibile - daca nu te uiti la byte-ul efectiv receptionat, nici nu stii ce e acolo.  In plus cel mai agasant e faptul ca nu foloseste terminatori. ioptron termina orice comanda cu #. Skywatcher incepe orice comanda cu : si o termina  cu CR. Ideea e ca daca apar erori la transferul de date, in protocoalele normale stii sa izolezi datele utile, stii daca pachetul de date e corupt etc. La celestron nu stii nimic. Iar daca trimiti ceva eronat la montura, aceasta incepe sa raspunda haotic si trimite sute de caractere complet aiurea. Cel putin CGEM-ul meu asa face.


-----------------------------------

Sorin Sfartz

19 Oct 2018 09:04



-----------------------------------

M-am uitat abia acum pe fisierele cu codul sursa pe care le-am atasat si am vazut ca multe linii de comentariu au fost sparte, astfel ca ele incep pe un rand si continua pe urmatorul rand. Daca o sa puneti codul in IDE va trebui sa stergeti enter-ul care rupe linia de comentariu, sau sa stergeti comentariul cu totul, altfel vor aparea erori la compilare. La fel stau lucrurile si cu numarul de pagina din fisierul pdf si cu prima linie de titlu, care au fost adaugate la crearea pdf-ului. Trebuie sters orice nu e instructiune valida.

Imi pare rau, dar nu am gasit alta metoda sa atasez programele. Forumul nu permite atasarea fisierelor text sau .ino sau .C etc


-----------------------------------

nobody

19 Oct 2018 16:44



-----------------------------------

Se pare ca secventa aia de "$$$" o trimite chiar SkySafari.
E "escape sequence" pentru modulul Wifly (similar cu "+++" la modemuri).

Protocolul de la Celestron (NexStar) este folosit si de Skywatcher.
Ala cu ":..#" cred ca e LX200 de la Meade.
Protocolul NexStar contine si date in format binar, nu doar ASCII.
Comenzile au o lungime predeterminata. Raspunsurile de la HC se termina cu "#".

Este o problema cu felul cum ai folosit acel buffer. Un mesaj binar nu e bine sa-l stochezi intr-un string pentru ca daca iti apare un caracter 0x00 (NULL), acesta are o semnificatie speciala, inseamna sfarsitul stringului. Cand se citeste stringul respectiv, citirea se va opri la NULL. Practic vei ramane cu un mesaj trunchiat.

Am testat pe Skywatcher sa-i trimit dolari, ii ignora complet. Cre' ca accepta numa' Euro.  :lol:


-----------------------------------

Sorin Sfartz

19 Oct 2018 18:02



-----------------------------------

Secventa aceea apare la conexiunea bluetooth, nu la wifi. Daca secventa $$$ o trimite SkySafari e o prostie din partea dumnealui, pentru ca nici o montura nu asteapta asa ceva. Poate ca Skywatcherul ignora caracterele acelea, insa CGEM-ul meu o ia complet razna daca ii trimiti ce nu vrea el. Sau poate ca e o secventa special gandita pentru SkyBT-ul ala al lor si in cazul asta secventa nici nu ar trebui sa ajunga la portul serial.

Asa este, m-am grabit, protocolul telecomenzii skywatcher e la fel cu nexstar. Acela de care am spus eu e protocolul intern al lui skywatcher, adica cum discuta telecomanda cu placa lui interna.

Comenzile in protocolul nexstar nu au o lungime predefinita. De exemplu V#-versiune, e-solicitarea pozitiei, iar comenzile de slew au chiar si 8 caractere.Insa intr-adevar, ceea ce vine de la montura se termina cu #. Si intr-adevar sunt o multime de caractere speciale cum deja am spus, ceea ce poate fi neplacut. De exemplu intr-o prima abordare in care am cautat sa evit programarea modulului esp8266 am incercat sa folosesc comenzi AT, dar din cauza caracterelor non standard ASCII nu a functionat. 

De asta la primele teste am folosit un array de bytes. Intr-adevar daca vreo-un protocol ar folosi ´/0´ asta ar da peste cap totul. Dar sper ca nici un creator de protocoale nu va fi atat de ... ma rog.  In primele 2 programe nu am folosit array´s. Doar in ultimul (care de  fapt o fost primul test) le-am uitat. O sa le schimb si pe acelea ca la primele 2.


-----------------------------------

nobody

19 Oct 2018 20:18



-----------------------------------

Cand am zis lungime predefinita, m-am referit ca fiecare mesaj are o lungime cunoscuta, nu ca toate mesajele au aceeasi lungime fixa. De ex. comanda "V" are lungimea 1, tot timpul. Comenzile de slew au tot timpul lungimea de 8 caractere, din care ultimele doua sunt ... chr(0) & chr(0).

Daca vrei sa setezi sau sa citesti ora ... iar dai de 0x00, uite chiar acum o captura de pe portul serial (sunt si valorile in hexa):
Comanda:
h
68

Raspuns:
 Q  :  * <1><1><n> V <0> #
51 3A 2A 01 01 0A 56 00 23


Explicatia:
The format of the time commands is: QRSTUVWX, where:
Q is the hour (24 hour clock). 0 for Standard Time.
For example, to set the time to 3:26:00PM on April 6, 2005 in the Eastern time zone (-5 UTC: 256-5 = 251) you would send:
&#8220;H&#8221; & chr(15) & chr(26) & chr(0) & chr(4) & chr(6) & chr(5) & chr(251) & chr(1)

Vezi documentatia de la protocol, e plin de NULL sau valori care pot fi NULL (zero binar):


-----------------------------------

Sorin Sfartz

19 Oct 2018 22:51



-----------------------------------

Da, am citit si eu protocolul ala. Si nu imi place deloc. E complet neintuitiv. Parerea mea. Ce om normal ar raspunde la comanda V# (adica versiunea monturii) cu chr(major) & chr(minor) & &#8220;#&#8221;? Nemaivorbind ca pana sa verific ce trimite CGEM, eu nu mi-am dat seama ce sunt minor si major acelea.
Sau de ce trebuie o banala comanda de slew sa fie asa: &#8220;P&#8221; & chr(2) & chr(16) & chr(36) & chr(rate) & chr(0) & chr(0) & chr(0)? Poate e doar o chestiune de gusturi.

In fine chiar daca se trimit o gramada de NULL - uri in protocolul ala, nu e nici o problema din mai multe motive:

1. Bufferul este un array de bytes. Asignarea valorii zero in orice pozitie din array nu are nici o importanta. 
De altfel o buna dovada pentru lucrul asta, este ca programul merge perfect. Am testat toate slew-urile si functioneaza perfect. Daca un singur caracter in comanda aia tampita ar fi gresit, sau ar lipsi, CGEM-ul meu ar lua-o complet razna. Stiu asta pt ca am verificat. CGEM-ul in primul rand intra in asteptare mult timp, astfel ca skysafari se deconecteaza, iar apoi incepe sa verse pe portul serial sute de caractere aiurea. 

2. Chiar daca bufferul ar fi un string C, adica un array de caractere, asignarea unui NULL intr-o pozitie oarecare, iarasi nu influenteaza cu nimic datele, caci imediat s-ar scrie un nou caracter in pozitia urmatoare, deci nu ar conta ca scrierea unui zero sterge tot ce urmeaza dupa el.

3. Am mari dubii ca scrierea unui NULL in momentul rularii programului are vreo influenta. Banuiesc ca trebuie sa declari explicit in program buffer[10]='\0'; pentru ca compilatorul sa anuleze tot ce ar fi dupa indexul 10. Daca array-ul este definit de la inceput de o anumita marime fixa, de unde sa stie compilatorul ce o sa puna ulterior portul serial intr-o pozitie oarecare in array? Eu cred ca array-ul va ramane cu valorile scrise din portul serial asa cum au venit. Ar putea fi intr-adevar o problema daca s-ar apela functii pentru stringuri care cauta caracterul null. 

4. Nici in varianta declararii unui string cu "String sir=..." nu are importanta daca concatenam la momentul rularii programului un NULL. Sa presupunem ca sirul este: a, b, NULL, c, d. Dupa concatenare el va arata astfel: ab cd. 

Eu am pus array-ul acela de bytes din varianta 3 chiar in primele teste, din dorinta de a nu exista ambiguitati vizavi de cum e interpretat un caracter sau altul. Apoi am vazut ca merge si cu stringuri declarate cu String si codul e mai simplu. Insa acum daca ma gandesc mai bine, cea mai de incredere varianta e tot aceea cu array-ul de bytes. Nu e nici un dubiu vizavi de o valoare a unui numar intreg intre 0 si 255.


-----------------------------------

topacid

19 Oct 2018 23:56



-----------------------------------

Foarte mi&#537;to :D


-----------------------------------

nobody

20 Oct 2018 02:45



-----------------------------------

Vorbeam de prima varianta cu bluetooth unde incerci sa speli dolarii.

La acelasi String poti adauga NULL, dar cand incepi sa folosesti functii de manipulare, acel string devine impredictibil dupa primul NULL.


  char mightynull = 0 ;
 
  String string_1 = "$$$String_1_";
  string_1 += mightynull ;
  string_1 += "LOSTINVAIN";
  Serial.println(string_1);
  Serial.println(string_1.length());

  String string_2 = "WTF_";
  string_2 += string_1;
  Serial.println(string_2);
  Serial.println(string_2.length());
  
  String string_3 = "HMMMMM";
  string_3 = string_1.substring(3, 23); 
  Serial.println(string_3);
  Serial.println(string_3.length());



Rezultat:

$  $  $  S  t  r  i  n  g  _  1  _ <0> L  O  S  T  I  N  V  A  I  N
24 24 24 53 74 72 69 6E 67 5F 31 5F 00 4C 4F 53 54 49 4E 56 41 49 4E
Lungime: 23, s-a pastrat si ce-i dupa NULL

W  T  F  _  $  $  $  S  t  r  i  n  g  _  1  _  <0>_ <0> I  N <0><n><0><0><0> r
57 54 46 5F 24 24 24 53 74 72 69 6E 67 5F 31 5F 00 5F 00 49 4E 00 0A 00 00 00 72
Lungime: 27 OK, dar s-a alterat continutul dupa NULL

S  t  r  i  n  g  _  1  _
53 74 72 69 6E 67 5F 31 5F
Lungime:9, trebuia sa fie 20, dar e trunchiat de la NULL



In C, unde apare primul '\0' intr-un string, acolo se considera terminat. Asta n-are treaba cu compilatorul, ci cu conventiile din bibliotecile standard. 

In fine, fa cum vrei.


-----------------------------------

Sorin Sfartz

20 Oct 2018 14:33



-----------------------------------

Ah. Nu imi dadusem seama despre ce parte vorbeai. Ok. O sa schimb stringul ala intr-un array de bytes precum in var.3. E mai sigur asa intr-adevar. Dar asta inseamna ca trebuie sa retestez totul.

"In C, unde apare primul '\0' intr-un string, acolo se considera terminat. Asta n-are treaba cu compilatorul, ci cu conventiile din bibliotecile standard. "

Stiu asta. Este elementar. Totusi are treaba si cu compilatorul. In exemplele tale compilatorul "stie" ca in primul sir este un null, pentru ca tu ai initializat sirurile in felul ala. Pe masura ce concatenezi sirurile se vor altera tot mai mult pentru ca compilatorul "stie" de acel null si nu aloca resurse pentru ce e dupa el. Insa daca compilatorul e instruit doar sa primeasca caractere pe portul serial, nu va sti si nu ii va pasa de ceea ce vine pe acolo. Poti acumula ce vine in orice fel de string si sirul nu va fi corupt pt ca compilatorul aloca corect spatiu pentru insiruirea de caractere ce vine de la serial. De asta primele 2 variante functioneaza totusi ok, chiar si cu protocolul acela aiurit.
Un astfel de sir primit pe portul serial va fi considerat "terminat" la null, doar de functiile de manipulare a stringurilor care cauta astfel de caractere. Insa in programele mele nu exista astfel de functii, pt ca programul este doar un banal bridge de transfer de date.


-----------------------------------

Sorin Sfartz

24 Oct 2018 21:16



-----------------------------------

La sugestia lui nobody am schimbat putin programele pentru versiunile 1 si 2 astfel incat sa nu mai foloseasca stringuri. Am atasat fisierele HC-05.pdf pentru varianta 1 si ESP8266.pdf pentru varianta 2. Le-am testat si merg ok.


-----------------------------------

StarChild

21 Noi 2019 13:57



-----------------------------------

tot ptr SkySafari (si/sau DSO Planner) am facut folosit un adaptor exter de la serial la BT, ulterior am "construit" un adaptor intern in SynScan (de fapt am 2 , unul pe AZEQ5 si unul pe EQ8, amandoua merg impecabil), descriere aici:  http://astronomy.ro/forum/viewtopic.php?t=12034&postdays=0&postorder=asc&start=15   
Nu a trebuit programat nimic, singura "hakereala" a fost sa configurez modulul HC-05 prin aplicatia Hyperterminal, in rest componentele au fost doar lipite/conectate intre ele, nu a necesitat nici o linie de cod.


-----------------------------------

Sorin Sfartz

26 Noi 2019 14:17



-----------------------------------

Fain!

Insa e destul de greu de urmarit topicul acela. Poate ar fi o idee buna sa faci la sfarsitul topicului o sinteza in care sa pui totul intr-un singur loc: cum conectezi hc-05 ca sa-l configurezi, ce comenzi de configurare sunt necesare si schema de conexiune cu montura.


-----------------------------------

StarChild

26 Noi 2019 16:12



-----------------------------------

candva acuma in vacanta de iarna o sa fac un tutorial

