Go Down

Topic: [OT ITA] Lo spamm bar (Read 2236219 times) previous topic - next topic

zoomx

Io sono interessato alla configurazione "molti trasmettitori, un solo ricevitore" eventualmente con qualcuni che fa da ponte.

Gli NRF24 hanno un protocollo un po' astruso e dei limiti sui dispositivi connessi fra loro, 6 mi pare sia il massimo.
All'aperto vanno bene per via della banda 2.4GHz, al chiuso un  meno, i 433MHz vanno meglio e, di solito, consumano meno.

La sigla HC-11 mi aveva ingannato, pensavo fosse roba della serie Bluetooth.

Standardoil

Fare da ponte non ho mai provato
Mi tenta
Molti tx e un solo rx è esattamente il termoremoto
Anche se rx e tx è solo una convenzione
Sono bidirezionali
Io chiamo tx quella che ha "l'iniziativa" della comunicazione
Prima legge di Nelson (che sono io): Non scambiare il fine con il mezzo: ricorda "cosa" devi fare, non "come" devi farlo

Non bado a studenti, che copino altrove

Tu hai problema-Io ti domando-Tu non mi rispondi: vuol dire che non ti serve più

maubarzi

I limiti derivano dalle configurazioni automatiche, usano bande diverse e gestiscono comunicazioni parallele.
Io sto lavorando ad un ricevitore, che per me è un master, che interroga periodicamente i trasmettitori e nel pacchetto viene passato un indirizzo che identifica il singolo trasmettitore.
Nessun parallelismo nella comunicazione e quindi nessun vincolo a priori.
Alla fine, nella mia configurazione, il mercato non serve, le comunicazioni sono sempre pilotate dal master in modo sequenziale.

Al momento ho un software che fa questo:
Sul master che chiamo M ho impostato un'array di indirizzi, al momento per provare sono solo 5 ma potrebbero essere 256 perchè nella comunicazione ho riservato 1Byte.
Ho riservato 1Byte anche per il comando, che indica il tipo di comunicazione, richiesta dati, acknowledge, invio dati, ecc.
Il resto è il pacchetto dati opzionale.

Gli slave hanno un indirizzo, si spera univoco, che forse gestirò con dip switch oppure mi invento un modo per renderlo dinamico tipo DHCP, non so ancora.
Potrei generare un codice casuale e identificare con quello, alla prima connessione il master da l'indirizzo effettivo e si salva questo UUID per riconoscere il device anche in futuro.
Il vantaggio sarebbe che posso generarlo lungo evitando duplicazioni ma poi nella comunicazione usare 1 solo Byte di indirizzo dinamicamente assegnato.

Le comunicazioni, quelle fisiche ovviamente sono in broadcast, le onde radio non sono direzionabili, però ogni client tratta solo quelle indirizzate a lui e in base al comando arrivato come secondo byte sa cosa deve fare.

In questo momento ho 3 messaggi:
Master: richiesta dati (con timeout di attesa della risposta)
Slave: invio dati (con timeout di attesa dell'acknowledge)
Master: acknowledge (a perder)

Se il master non riceve i dati rifà la richiesta in seguito.
Se lo slave non riceve l'acknowledge si salva il dato per un invio futuro.

I pacchetti, pensavo di identificarli in base a data/ora presi da un RTC, così se si perde l'acknowledge il master può riconoscere un doppio invio dello slave che pensa di dover ritrasmettere.

Fino a qui è stato facile.
Ho perso più tempo a cercare di far rilevare allo Slave la carica della sua batteria per avvisare il Master quando è scarica per richiedere un cambio batterie.
Stavo usando un TL431 come voltage reference ma mi sono reso conto che non è molto affidabile, quantomeno se montato su breadboard, per cui ho rivisto i partitori resistivi per usare il riferimento interno da 1,1V. Il TL431, che dovrebbe essere da 2,5V con la configurazione a Vref, mi dava valori tra 2,7 e 2,8 misurati con un tester in vari momenti, quindi non proprio una tensione stabilissima come riferimento.
Con il reference internal sono arrivato a valori vicini tra tester e arduino e poco oscillanti.

E' acqua calda, lo so, ma mi ci sto cimentando e divertendo ;)
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

maubarzi

#24708
Jun 20, 2019, 12:10 pm Last Edit: Jun 20, 2019, 12:13 pm by maubarzi
Anche se rx e tx è solo una convenzione
Sono bidirezionali
Io chiamo tx quella che ha "l'iniziativa" della comunicazione
Si, pure io, ma con convenzione invertita, TX è quello che ha dati da trasmettere, RX è il Master che li riceve.
Ma solo perchè inizialmente pensavo a una comunicazione tipo UDP unidirezionale da molti a 1 ma poi ho cambiato idea e i 2 software li avevo già chiamati TX e RX e non ho più cambiato i nomi.

Al ponte ci penserò in seguito, magari pensando ad un algoritmo di routing tipo quello di internet, dove ogni device contatta tutti i vicini per vedere qual'è il giro minore per raggiungere il master.
Mi stuzzica la cosa per mettermi alla prova anche su questo aspetto che dovrebbe riadattarsi dinamicamente se si cambia qualche disposizione e se va offline qualcosa.
E poi funzionerebbe anche in caso di guerra termonucleare ;) che non è poco... :P
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

zoomx

La mia intenzione sarebbe quella di realizzare sensori a batteria che passeranno la maggior parte del tempo dormendo. Si svegliano mandano il dato e quindi nanna daccapo, compresa la readio. Si potrebbe comunicare con loro solo durante il periodo di trasmissione. Forse si potrebbe pensare anche ad una variante con trasmittente/ricevente accesa che sveglia il micro se arriva qualcosa giusto per lui.
Possibilmente vorrei battere i trasmettitori di umidità e temperatura cinesi, che campano parecchio con una pila ministilo o stilo, semplicemente trasmettendo più dati di vario tipo.

Chi riceve i dati, ed eventualmente ne approfitta per comandare qualcosa, sta sempre acceso e non va a batteria.

Però alla fine ci vuole una macchina sempre accesa per registrare tutti i dati che possibilmente non sia rumorosa. Il candidato è il solito Raspberry ma ogni tanto leggo che si piantano per corruzione della microSD.

gpb01

Search is Your friend ... or I am Your enemy !

maubarzi

#24711
Jun 20, 2019, 02:51 pm Last Edit: Jun 20, 2019, 03:31 pm by maubarzi
Si, anche il mio progetto meteo iniziale era identico al tuo come filosofia.
Quello attuale è una sperimentazione che comunque mette le basi per l'80% delle funzionalità richieste.
Quello attuale nasce da un progetto uscito qualche settimana fa di un gioco per addestrare i riflessi, dove N centraline venivano comandate da un master che dava l'impulso di accendersi e poi loro dovevano dare il feedback di "tocco".
Siccome mi sono arrivati assieme gli HC-11 e gli AM2302 sto sperimentando così, anche perchè non ho ancora deciso cosa usare per rilevare il "tocco", se IR, ultrasuoni o altro.

Non so te, ma il mio scoglio più grosso, quando provo cose nuove, è arrivare a far funzionare l'"HELLO WORLD", poi la strada diventa tutta in discesa.
Quindi, fatta la prima comunicazione, non ho più potenziali show stopper ma è solo questione di fantasia e di tempo per ottenere quello che mi serve.

Comunque, si, il mio progetto meteo finale lavorerà come il tuo, ma al momento sperimento l'inverso.
Mi interessa anche sperimentare il monitoraggio della carica della batteria.
E qualche altro dettagliuccio.

Tu che tempi ti sei dato? io laschi, lo faccio quando ho tempo e mi arrivano i pezzi dalla Cina con le carovane di Marco Polo.
Se vuoi ci apriamo un thread e affrontiamo il progetto assieme, anche se un po' a tempo perso, confrontando gli approcci e i risultati.
O se di scarso interesse per il resto del mondo anche in PM.
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

Standardoil

Niente di quello che fa il mio socio con arduino è di scarso interesse
Prima legge di Nelson (che sono io): Non scambiare il fine con il mezzo: ricorda "cosa" devi fare, non "come" devi farlo

Non bado a studenti, che copino altrove

Tu hai problema-Io ti domando-Tu non mi rispondi: vuol dire che non ti serve più

maubarzi

denghio socio, altra birra da aggiungere nel conto, la volta che ci vediamo ci scappa il coma etilico mi sa ;)
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

zoomx

La batteria va monitorata sempre.

maubarzi

Si, infatti, a prescindere da come poi si comunicherà.

E al momento mi torna comodo che resti sempre acceso e magari gli do anche da fare qualcosa di pesante in modo da scaricare la batteria abbastanza velocemente, per vedere se riesco a intercettare e interpretare bene la curva di scarica.
Alla fine, alcune comunicazioni mi sa che le farò comunque in polling, altre arriveranno in push, per cui metto tutto assieme e poi vedo di configurare al volo il tutto.
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

speedyant

A Torino piove!
Comunque interessante il discorso sugli HC-11, link dove "raccattare" informazioni?

maubarzi

Documento 1
Documento 2
Documento 3

Poi ci sono anche gli HC-12, non ho ancora approfondito le differenze, mi sono fidato del socio che elogiava alcune caratteristiche dell'11 che mi tornavano comode.
A tempo debito provvederò ad informarmi meglio anche sugli HC-12
Per gli HC-12 al momento mi sono salvato solo questo

Hanno varie cosettine interessanti.
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

zoomx

#24718
Jun 21, 2019, 08:43 am Last Edit: Jun 21, 2019, 08:43 am by zoomx
Tu che tempi ti sei dato? io laschi, lo faccio quando ho tempo e mi arrivano i pezzi dalla Cina con le carovane di Marco Polo.
Se vuoi ci apriamo un thread e affrontiamo il progetto assieme, anche se un po' a tempo perso, confrontando gli approcci e i risultati.
O se di scarso interesse per il resto del mondo anche in PM.
Noto solo ora questa parte,
Se ti stavi rivolgendo a me, si, possiamo aprire un thread, anch'io vado a tempo perso, sono mesi che vorrei decodificare i sensori della stazione meteo Lidl che, costruttivamente, sono buoni ma la centralina non registra nulla. A me serve per valutare se chiudere le tende o sapere se a casa mia piove mentre ancora in ufficio no (capitato!).

Vado a prender eun caffé...

maubarzi

#24719
Jun 21, 2019, 01:09 pm Last Edit: Jun 21, 2019, 02:20 pm by maubarzi
Cercando di rilevare la tensione della batteria, ho rilevato letture molto ballerine.
Ho indagato un po' e mi sono fatto una sorta di oscilloscopio con il serial plotter.
Ho notato che ad intervalli di poco meno di 20mS c'erano dei brevi picchi.
La frequenza è vicina ai 50Hz, pensavo fossero dell'alimentazione, che durante le prove era USB.
Invece no, l'USB del mio PC è molto stabile.
Alla fine ho scoperto di cosa si trattava.
HC-11!!!
Di sua iniziativa fa operazioni a circa 50Hz che provocano picchi anomali di ritorno sull'alimentazione.
Ho risolto mettendo un condensatore da 470uF tra Vcc e Massa dei pin dell'HC-11 e tutto è tornato stabile.
Il valore l'ho deciso a caso in base a quello che avevo in casa.

Nella mia ignoranza pensavo sempre che questi condensatori fossero per livellare la tensione in ingresso al dispositivo, non proteggere il resto dai casini di ritorno del dispositivo.

EDIT:
Sospetto che l'HC-11 faccia operazioni anche di sua iniziativa e queste richiedano parecchia corrente per cui se l'alimentazione non ci sta dietro la tensione cala.
Il condensatore mitiga fornendo la corrente necessaria.
Mi sono ingannato, perchè facendo tutto con lo stesso Arduino, il picco abbassava l'alimentazione e questo influiva sul riferimento di tensione rilevando una variazione inversa, infatti inizialmente i picchi li rilevavo in aumento, mentre monitorando con un Arduino esterno i picchi sono in diminuzione della tensione di alimentazione.
Strano però che il riferimento interno a 1,1V sia influenzato in questo modo, lo pensavo più stabile.

Comunque, questo mi ha stimolato a farmi un oscilloscopio da puareti con un Arduino Nano, 2 resistenze e il plotter seriale ;)
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

Go Up