RX-TX ''read base time''

[T.Sorin]

Ziua buna tuturor.

          Deschid in randurile urmatoare o postare pe care sper sa o gasiti ca fiind interesanta si sa vedem daca este si posibil de realizat urmatorul proiect pe care-l voi detalia.

Cunoasteti probabil modulele radio pt placile de dezvoltare Arduino, in banda 433 mhz ... un transmitter si un receiver ... bun. La nivel de programare C++ ( am studiat si eu si realizat multe proiecte in sfera atmega328 ..insa acest detaliu de programare si implementare ma depaseste, recunosc )...  Intrebarea mea este : putem calcula printr-un program, cu ajutorul unei placi atmega328 sa zicem ..uno.. diferenta de timp Δt ..dintre un t0 ( care este momentul in care placa trimite prin intermediul transmitatorului un semnal - /ex. caracter oarecare- cifra litera)  si un t1 (momentul in care receptorul primeste acest semnal) ...evident ...vorbim de fractiuni de secunda... deci : Δ t = t1-t0 ... cred ca vorbim de cateva zeci de microsecunde... Asadar ... e posibil ori ba ?

 

Sunt curios de raspuns. Zi frumoasa de luni in continuare.

[informer]

Pai trebuie sa calculezi ca la 0.3Km per us, ca sa ai cateva zeci de us ar trebui sa ai niste km buni... iar perechea aia TX/RX este departe de a asigura o legatura la distanta aia.

Oricum asta cred ca ar fi cea mai mica problema considerand intarzierile in tot lantul, lipsa unei referinte atat de precise etc.

Asa ca, dupa mine, raspunsul este NU (hotarat).

 

 

[mihaicozac]

La modulele alea nu merge, că ai nevoie de canal de retur, receptorul ar trebui cumva să trimită informaţia de ACK, nu?

[T.Sorin]

11 minutes ago, mihaicozac said:

La modulele alea nu merge, că ai nevoie de canal de retur, receptorul ar trebui cumva să trimită informaţia de ACK, nu?

Haideti sa pun problema altfel ca sa am un startpoint ... sa facem abstractie de modulele de mai sus si de ideea de RF... am un DigitalRead(pin1) de un digital pin , ok ? si mai fac un DigitalRead(pin2) ...bun ... stiti daca se poate calcula ..nici nu intuiesc cum ... diferenta de timp dintre cele 2 read-uri ?

Editat Ianuarie 28, 2019 de T.Sorin

[informer]

Daca vrei diferenta de timp cat de cat precisa nu faci digitalRead()... aia-i o functie care dureaza doar ea destul de mult pt ca face mai multe decat sa se uite ce nivel are un pin.

Exista intreruperi la schimbarea nivelului unui pin, poti porni un timer ca si contor de impulsuri provenite din tact (divizat sau ba) iar la aparitia celuilalt event, vezi cate impulsuri ai numarat.

O sa ai si acolo "timpi morti" cat se executa una alta dar sunt calculabili daca citesti atent datasheet-u` procesorului.

Totusi, despre ce intervale de timp vorbim? Nu de altceva dar daca-s suficient de mari, exista metode mai comode....

Editat Ianuarie 28, 2019 de informer

[T.Sorin]

2 minutes ago, informer said:

Totusi, despre ce intervale de timp vorbim?

10-20uS

[informer]

Si am inteles bine, vrei sa masori intre momentul cand se modifica un pin si momentul cand se modifica celalalt?

[T.Sorin]

1 minute ago, informer said:

Si am inteles bine, vrei sa masori intre momentul cand se modifica un pin si momentul cand se modifica celalalt?

da, vreau sa-mi fac o idee despre cum functioneaza toata treaba asta cu read time intre 2 evenimente unul de sending data unul de receiving data in definitiv ..dar tu spune-mi te rog doar la read read ..apoi ma mai joc si eu ... in definitiv va fi vorba despre un sistem ,,forward collision-avoidance assist'' dar mai e cale lunga pana acolo ...

[mihaicozac]

Poţi folosi funcţia micros(), iniţializezi o variabilă la modificarea D1 şi îi citeşti valoarea când apare D2.

[informer]

Pai eu iti spun ce cred si cum as face eu.

In primul rand la treburi d-astea unde-i vorba de timpi scurti codul se scrie de obicei in asamblare.

Asta deoarece orice instructiune la uC-ul asta poate dura 1-3 (parca) impulsuri de tact ceea ce inseamna 1-3 x 1/16us.

(Sigur ca poti sa socotesti si pe codul generat de compilator dar nu cred ca vrei).

In rest asa as face: ori as porni un timer (ca si counter) la o intrerupere de schimbare de nivel ori efectiv m-as uita la pin (din asamblare asta ia putine cicluri, chiar 1 daca retin corect) si as face acelasi lucru.

Dupa care, la celalalt event, detectat in unu din cele 2 feluri, as opri contorul si as citi rezultatul.

Metoda asta ar permite precizii bune, pe undeva pe la cateva 1/16us daca socotesti corect cat dureaza fiecare instructiune si aduni la numarul contorizat.

Sigur ca daca nu-i nevoie de precizie deosebita, poti folosi cum spune colegul Mihai, functia C. 

 

 

[nico_2010]

Subiectul se muta la sectiunea "Idei si sfaturi"

Editat Ianuarie 28, 2019 de nico_2010

[puriu]

Un MC ordinar programat in .asm asigura precizia timpilor la nivel de microsecunda, unul rapid mai putin. Am indoieli privind promptitudinea modulelor radio. O idee ar fi folosirea unui emitator si a doua receptoare identice, unul plasat aproape de emitator si unul acolo unde este nevoie. La cel de langa emitator nivelul semnalului la intrare trebuie sa fie redus corespunzator celuilalt. Trebuie tinut cont si de lungimea cablurilor pana la cele doua receptoare. Viteza semnalului intr-un cablu este mai mica decat c. Daca lungimea celor doua cabluri este aceeasi, nu mai conteaza.

[one]

In principiu poti masura cu ATmega328  intervale mici de timp dar depinde si ce precizie si rezolutie vrei. Mai ai de luat in consideratie si timpii de propagare prin circuite, odata cu cresterea preciziei.

Pentru a masura 20-30us cu o rezolutie de 0.1us sa zicem, as face un oscilator extern de 10MHz si as folosi semnalul meu de masurat pentru a deschide/inchide porti care sa creeze fereastra de numarare spre microcontroller. As folosi un counter cu clock pe un pin extern si in practica voi numara numarul de oscilatii ca intra. Acest clock va incrementa in mod asincron timer/counterul si nu va depinde de clock-ul microcontrollerului si nici de timpul de raspuns la intreruperi sau alte evenimente.

 

Altfel timpul de raspuns pentru activarea/dezactivarea capturii cred ca este de minim 4 cicli, 0.25us la 16MHz, daca vrei sa masori utilizand clock-ul intrern al atmega.

 

Ar trebui sa folosesti module "transparente", care nu au buffere sau alte microcontrollere. 

Pentru a functiona pe cativa km totusi aceste module nu sunt bune.

 

[one]

Daca vrei sa masori o distanta oarecare mai degraba poti imagina ceva bazat pe GPS.

[one]

4 hours ago, one said:

Altfel timpul de raspuns pentru activarea/dezactivarea capturii cred ca este de minim 4 cicli, 0.25us la 16MHz, daca vrei sa masori utilizand clock-ul intrern al atmega.

 

Temporizarea pentru aceasta activare/dezactivare ar trebui implementata ca o rutina a carei timp de executie sa fie cunoscut, altfel daca se foloseste un alt timer se adauga alte latente de minim 4 cicli pentru intrerupere, apoi executia a cel putin unei intructiuni si efectul acesteia in ciclul urmator, etc etc.

Editat Februarie 14, 2019 de one