Sari la conținut
ELFORUM - Forumul electronistilor

mai multe transmitatoare pe 433 hmz


script22

Postări Recomandate

  • Răspunsuri 26
  • Creat
  • Ultimul Răspuns

Top autori în acest subiect

  • script22

    9

  • sebip

    4

  • simplex

    3

  • godFather89

    3

Top autori în acest subiect

  • 1 lună mai târziu...

Nu credeti ca se face risipa de energie transmitind de mai multe ori cite un mesaj fata de varianta care are si un receptor? Daca e alimentat pe baterii sau acumulatori cred ca ar putea fi o problema. La cum este descrisa problema ma duce cu gindul la sistemele de transmisie a datelor wireless de la contoarele de apa sau curent, care sint alimentate cu baterii (cele de la contoarele apa) si care transmit din cind in cind datele citite. Un receptor care sta in stand-by poate consuma foarte putin (daca e ales unul adecvat) si sa raspunda doar cind este "chestionat" si nu sa transmita periodic (poate de mai multe ori datorita suprapunerii semnalelor de la mai multe emitatoare).In functie de factorii de mediu unde va functiona se poate alege si frecventa de lucru (433MHz, 800MHz, 2,4GHz), frecventa care (daca este cazul) sa fie cel mai putin atenuata de mediul inconjurator (de exemplu la contoarele de apa care pot sta in camine inundate).Acuma scuze de "reinvierea" topicului ... ca vad ca nu s-a mai postat demult aici :-).

Link spre comentariu

Eu am nevoie sa trimit putine informatii si nu periodic o singura cand se schimba ceva in mediu inconjurator de acea aveam nevoie de o solutie simpla care nu implica si un receptor pentru 9 biti nu cred ca e consum prea mare trimisi de 10 ori de ex.daca stam sa ne gandim ca o telecomanda auto face cam acelasi lucru si totusi bateria functioneaza destul de mult timp solutia lui simplex e destul de buna cum nu am timp si nici bani sa fac ceva ce am de gand sper ca imformatiile postate aici sa fie folositoare si altora.

Link spre comentariu

Nu credeti ca se face risipa de energie transmitind de mai multe ori cite un mesaj fata de varianta care are si un receptor? Daca e alimentat pe baterii sau acumulatori cred ca ar putea fi o problema. La cum este descrisa problema ma duce cu gindul la sistemele de transmisie a datelor wireless de la contoarele de apa sau curent, care sint alimentate cu baterii (cele de la contoarele apa) si care transmit din cind in cind datele citite. Un receptor care sta in stand-by poate consuma foarte putin (daca e ales unul adecvat) si sa raspunda doar cind este "chestionat" si nu sa transmita periodic (poate de mai multe ori datorita suprapunerii semnalelor de la mai multe emitatoare).In functie de factorii de mediu unde va functiona se poate alege si frecventa de lucru (433MHz, 800MHz, 2,4GHz), frecventa care (daca este cazul) sa fie cel mai putin atenuata de mediul inconjurator (de exemplu la contoarele de apa care pot sta in camine inundate).Acuma scuze de "reinvierea" topicului ... ca vad ca nu s-a mai postat demult aici :-).

are o putere de transmisie 10 mw viteza maxima 4 kbs / deci o secunda e mai mult decat suficient pentru toate 10 transmisiisi o distanta de 20 -200 metrii in functie de antena deci asa cu o aproximatie nu stdiu daca e corect cine stie sa ma corecteze 20ma consum.60 sec (MIN) X 60 (min) = 3600 transmisii pt 20 ma . mai punem un 0 pt 200 ma si avem 36000 impartim la doi adunam cu 3600 mai punem 100 ma si avem 54000 transmisii .sa revenim 2400 baud rate la 1 mhz are 0.2 error rate , deci cred ca e ok iarasi cine stie mai bine sa ma corecteze nu am lucrat niciodata cu uart da e timp si pt asta.attiny 2313 consuma 20uA la 1 mhz 200 ua pt 10 ore 2ma pt 100 ore 20 ma pt 1000 * 2 40 ma pt 2000 ore / 24 ore = 83 zile cu 40 ma cred ca sunt suficienti.ce facem ca avem 54000 transmisii sa punem 40 pe zi asta asa ca un abuz ca sunt prea multe si tot avem 1350 zile adica vre-o 3 ani si 9 luni .ne mai trebuie ceva sa comutatam emitatoru asa ca un bc847 smd cu o putere de 100 ma ar fi suficinti pt transmitatoru nostru are un consum de doar 5 ua deci la asta nu mai facem calcul (nu stiu sigur daca sunt in idle sau in full power ori cum nu il luam in calcul ca e prea putin vom aproxima valorile ori cum nu am tinut cont de consumul atmega iar dupa sa calculam cate transmisii vom avea din restul de putere a bateriei dar soarta e cu noi )asa acm sa revenim cu o baterie de 300 avem vre-o 3 ani si 9 luni cu 40 transmisii pe zi , 40 ma avem 83 zile 2 luni si peste jumatate la 40 ma hai sa rotunjim putin si inmultim cu 2 si avem 80 ma 166 ziledaca ne uitam mai sus vedem ca avem transmisii pt 200 ma mai exact 36000 transmisii impartite iar la 40 pe zi vom avea 900 zile doi ani si peste jumatate 5 luni pt 80 ma consum procesor facem rapid un calcul 200 ma + 80 280 ma mai raman 20 aia ii dam la pierderi si putem spune ca cu o baterie de 300 ma la 9 volti avem 5 luni tensiune pt procesor daca impartim anii la 2 din 2 ani si peste jumate ramanem cu 1 an si vre-o 3 luni la 40 transmisii pe si total 18000 transmisii am castigat 100 ma care ii dam procesorului deci mai tine 6 luni cu 100 ma + 5 luni din inainte aprox 1 an. transmitatoru nostru a ramas cu 18000 transmisii 40 pe zi 100 ma. vom avea 1 an si 3 luni transmisii + 1 an microprocesoriar repet daca am gresit pe undeva cineva sa ma corecteze dar pot spune cu certitudine ca 1 an este mai mult decat suficient pentru o baterie de 9 volti .
Link spre comentariu

Daca se specifica faptul ca se transmite doar cind se intimpla "ceva" (la intervale mai mari de timp ...zeci de minute, ore) atunci e OK doar cu tranmitator, daca se transmite mai des ...de exemplu un termostat ... si transmiti sa zicem o data pe minut ...inseamna 1440 de transmisii zilnic ...si daca fiecare se repeta de 10 ori pentru siguranta transmiterii insemna 14 400 transmisii zilnic (din cele 54 000 din calculele anterioare ale colegului script22... rezulta 3-4 zile ! ).Prin urmare totul depinde de specificatii ... care in acest caz au fost destul de vagi la inceput si se mai clarifica din mers :-).Problema se pune cind sint mai multi senzori, respectiv emitatori, unde e mai serioasa problema suprapunerii transmisiilor. Solutia cu numere prime e foarte ingenioasa, cred ca singura problema acolo e sincronizarea timpului la fiecare emitator.

Link spre comentariu

Solutia cu numere prime e foarte ingenioasa, cred ca singura problema acolo e sincronizarea timpului la fiecare emitator.

Tocmai ca nu trebuie sincronizat timpul emitatoarelor. Aici apare avantajul.Daca ai doua emitatoare A si B, A emitind la momente aleatoare doua mesaje identice distantate la 3 ms si B, tot asa, emitind la momente intimplatoare (nesincronizate cu A in nici un fel) doua mesaje identice distantate la 5 ms, atunci in situatia cind se nimereste intimplator ca A si B sa emita simultan prima lor copie a mesajului, copiile numarul doi de la cele doua emitatoare nu vor mai intra in coliziune deoarece A mai emite la 3 ms de la coliziune iar B la 5 ms. Se presupune ca lungimea mesajului este mai mica decit 1 ms.
Link spre comentariu

Asa este ...in cazul a doua transmitatoare. Daca numarul acestora creste deja se complica , e nevoie de mai multe transmisii ca sa fie sigur ca se va prinde o fereastra de timp libera. Practic, depinde de marimea "retelei" de senzori. La un numar mai mare de senzori nesincronizati ... o singura retransmitere se poate suprapune (chiar si partial) cu o alta transmisie (cel putin la nivel teoretic). In 433Mhz e suficient sa mai ai citiva vecini cu statii meteo (cu senzori wireless), alarme sau alte device-uri si deja se aglomereaza destul de binisor si exista posibilitatea sa se mai piarda cite o transmisie. Acuma depinde si cit de grava e aceasta pierdere, daca e nesemnificativa atunci chiar nu conteaza metoda de implementare.

Link spre comentariu
  • 4 săptămâni mai târziu...

Am o intrebare , cati octeti sunt in informatia transmisa ? si de ce nu punem cate un string de identificare si sa-i lasam in plata Domnului de moduli TX la transmisie ? iar la receptie sa comparam stringurile si sa identificam care e si ce contine ? la 2400bd intr-o ora teoretic ai 1 milion de caractere(8biti) .Chiar nu-i loc de 10 stringuri ? daca urcam la 9600bd .. e si mai mult loc .Am luat de pe ebay cu 6RON perechea de RX TX la 433Mhz, ce-i drept , merge la 2400bd fata de un Hope care merge linistit la 31250bd dar costa de 5 ori mai mult perechea de TX-RX ...jos palaria pentru solutiile de mai sus, eu doar am dat cu presupusul ca in intervale de timp convenabile as putea decoda bitii.

Link spre comentariu
  • 2 săptămâni mai târziu...

Am o intrebare , cati octeti sunt in informatia transmisa ? si de ce nu punem cate un string de identificare si sa-i lasam in plata Domnului de moduli TX la transmisie ? iar la receptie sa comparam stringurile si sa identificam care e si ce contine ?

Stringul de identificare este adaugat de fiecare TX pentru ca altfel nu stii de la care statie ai primit mesajul, chiar in conditiile cind se presupune ca nu exista coliziune.Daca doua emitatoare emit mesaje ce se suprapun in timp, vei avea ceva de genul:1011...101 TX1 + 1101...011 TX2------------------2112...112 TX1+TX2 (asta se obtine la receptie, prin coliziune)Ce faci cu stringurile de identificare 101 si 011 emise de TX1 si TX2? La receptie ai un 112.Varianta ta nu rezolva problema.
Link spre comentariu
  • 2 luni mai târziu...

e clar ca la momentul x se vor suprapune bitii , dar , emisia la intervale fixe de timp (adica ecart de ordin al minutelor macar) si cu un mic soft de eliminare al erorilor cred ca pot gasi o modalitate de utilizare timp de cativa ani. Adica receptia fiecarui string . Momentan am doua perechi txrx in banda de 434MHz , abia astept sa incerc ceva de genul asta. S-ar putea calcula timpul pana la interferenta din cauza deviatiilor de ceas . E ca axa numerelor reale, nimeni n-a ajuns sa termine de numarat pana la 1, daramite pana la infinit !

Link spre comentariu

Creează un cont sau autentifică-te pentru a adăuga comentariu

Trebuie să fi un membru pentru a putea lăsa un comentariu.

Creează un cont

Înregistrează-te pentru un nou cont în comunitatea nostră. Este simplu!

Înregistrează un nou cont

Autentificare

Ai deja un cont? Autentifică-te aici.

Autentifică-te acum



×
×
  • Creează nouă...

Informații Importante

Am plasat cookie-uri pe dispozitivul tău pentru a îmbunătății navigarea pe acest site. Poți modifica setările cookie, altfel considerăm că ești de acord să continui.Termeni de Utilizare si Ghidări