Trasmissione dati semplice a infrarossi

Pensavo... In attesa di decidere che trasmettitore dati usare, e in attesa di comprarlo e di avere i soldi , visto che vorrei finalmente cominciare a prendere in mano un pò di software e i cavi non mi piacciono, per fare qualche prova potrei trasmettere ad infrarossi accontentandomi di basse velocità, pensavo di usare semplicemente i soliti ricevitori integrati ad infrarosso quelli per le tv così dovrei trovarmi il segnale già pronto da mandare sulla porta, e per la trasmissione posso semplicemente amplificare con un transistor e inviare ad alcuni led infrarosso. Che ne dite?

Beh,Gyppe,per trasmettere i dati tramite i raggi infrarossi non puoi semplificare così tanto le cose.

Innanzi tutto i ricevitori da telecomando lavorano con segnali infrarossi modulati da una portante che può essere compresa nella banda 33-38KHz oppure a 56KHz a seconda del modello di ricevitore. Per le spiegazioni seguenti considererò il modello a 38KHz che è tendenzialmente il più diffuso.

Seconda cosa i ricevitore IR devono ricevere degli impulsi a 38KHz di breve durata, altrimenti si saturano e il led trasmittente non può essere "pompato" per ottenere una buona portata.

Terza cosa: i ricevitori a IR prevedono che tu usi dei treni di impulsi a 38KHz inframezzati da una pausa. lunga più della durata del treno stesso.
Tanto per intenderci se tu prendessi un segnale a 38KHz e lo mandassi a un led vedresti che il ricevitore IR inizialmente farebbe commutare la sua uscita da 1 a 0, per poi tornare entro breve a 1 a causa del controllo automatico del guadagno (CAG) presente al suo interno che riduce la sensibilità in caso di fascio di raggi IR continuo.
Se tu applichi brutalmente il segnale di una porta seriale al modulatore a raggi IR rischi di perderti dei bit in caso di più bit consecutivi uguali, infatti in questo caso il CAG, passando dal primo bit al bit numero n sempre uguale ridurrebbe la sensibilità.
Quarta cosa: il ricevitore IR inoltre altera in modo evidente il segnale, allungando il bit quando l'uscita va a 0, allungamento che altera la durata dei bit in modo anche significativo, rendendo critica la decodifica dei dati.

Non sto dicendo che non si possa fare nulla, ma ti sto solo mettendo in guardia da facili sottovalutazioni del problema.
Circa 12-13 anni fa realizzai una chiave elettronica montata dentro un frutto Living che riceveva il raggio emesso da 3 led non collimati (senza lente) da una distanza di 12-15 mt. con un consumo sul trasmettitore di soli 10mA.
Ovviamente per fare questo progettai sia il trasmettitore che il ricevitore in modo da rispettare tutti i limiti imposti dal ricevitore IR.

Caspita è vero c'è di mezzo anche il 38Khz della modulazione, grazie robo non sapevo di questa caratteristica dei ricevitori.
Ok, ho capito, troppi sbattimenti io pensavo ad una robetta da fare in 10 minuti, se ci devo perdere tempo tanto vale farsi un trasmettitore radio come si deve.
Grazie a tutti, progetto bocciato.
Comincio con i cavi e basta, così evito anche di comprare batterie e mi dedico solo alla gestione motori e i primi programmini.

Leggerei qui:

http://www.gedanken.demon.co.uk/infra-red-tx/

e qui:

http://fly.cc.fer.hr/~mozgic/UIR/

e mi farei un'idea della questione

mi pareva di aver letto che ci sono anche comodi sistemi di conversione bluetooth/seriale... magari puoi usare questo? con un pic o similari è comodissimo trasmettere sulla seriale no?

Aggiungo questo:

http://www.next.gr/inside-circuits/Simple-...tics-l4356.html

Dunque, puoi fare cosi'. Questo che ti ho postato ora e' un trasmettitore a 36 Khz ad un canale. Puoi tentare di pilotare il pulsante con un pic, in pratica, implementando pero' anche un controllo sugli errori. Non avrai una velocita' eccezionale ma puoi provare a trasmettere qualcosina ad esempio per pilotare un piccolo roboto o simili. Comunque qui la difficolta' e' la parte software del sistema di ricetrasmissione perche' devi essere sicuro che chi riceve legge tutti i dati. Se devi allora trasmettere a blocchi di 8 bit conviene aggiungere anche qualche bit di start, di stop, di controllo dati ecc. In giro trovi parecchio materiale su queste cose.


Si Night, esistono anche integrati (alcuni credo li faccia anche microchip) che implementano gia' di loro queste funzioni. Dipende se si vuol fare a fine didattico oppure per applicazione pratica (e rapida ).

Azz quanti dati!
I primi due link mi tornano sicuramente utili sono anni che vorrei costruire qualcosa del genere per il pc.
Si night ho trovato i moduletti bluetooth già pronti, anche quelli xbee e i normali aurel, ma sono ancora parecchio indeciso su cosa usare, mi servirebbero per farci un rover che possa anche programmare come mi pare, e visto che ci voglio montare anche una telecamera vorrei avere una buona portata. I problemi sono parecchi, voglio scegliere due frequenze molto diverse per dati e video per non avere problemi, voglio un sistema dati bidirezionale, alta potenza e velocità e possibilmente a bassa frequenza diciamo 433 sarebbe l'ideale. Ci penso da giorni e giorni ma non ho ancora deciso e l'auto regalo di natale alla fine è saltato

Ecco hell ques'ultimo è molto vicino a quello che pensavo io, ma c'è sempre il problema della bassa velocità, se devo cominciare a scrivere qualche programmino in particolare quelli per la gestione della comunicazione meglio partire già con la velocità finale, altrimenti dovrei modificare tutto più avanti compreso il protocollo.

Ahhhh che casino seguo troppe cose contemporaneamente e non so proprio che decidere


Riguardo il protocollo di trasmissione non ci ho ancora pensato bene, in un'altro progettino usavo semplicemente inviare i vari dati che mi servivano in successione preceduti da un byte di controllo, un pò come si fa nei radiocomandi per modellismo, però con questa soluzione se perdi un byte per strada il valore di un dato si può fondere con quello di un'altro.
Quindi pensavo questa volta di fare il più classico byte indirizzo e byte valore, con controllo di parità, bit di start e stop non so bene se potrebbero aiutare o no.
In questo modo potrei controllare 255 indirizzi con 255 valori ognuno, e non sono costretto a trasmettere continuamente dei dati che potrebbero restare fissi anche per lungo tempo.
Penso che già il controllo di parità renda parecchio difficile un errore, ma per evitare al massimo qualsiasi problema visto che penso ad un sistema bidirezionale controllerei costantemente i dati che ho scritto per cui....
Si, credo sia la soluzione migliore.
L'unico problema resta al solito riuscire a scrivere tutta pappardella e poi farla pure funzionare

Normalmente io preferisco usare come protocollo byte di indirizzo,byte di dato,byte di controllo e se la velocità di trasmissione lo consente, anche un byte di start e uno di stop.
Il byte di controllo può essere ad esempio l'XOR dei restanti byte oppure dei restanti byte + un valore costante (es. 0AAHex).
Il bit di parità non garantisce, secondo me, una certezza di rilevare un errore anche se c'è.

Il fatto di trasmettere solo quando ne hai bisogno non è una buona soluzione, perchè non sai se il ricevitore ha capito quello che gli hai inviato. Se tutto è andato bene la trasmissione può terminare, ma se la stessa parità (o checksum) non torna il pacchetto che hai inviato dovrebbe essere inviato nuovamente, ma tu lato trasmettitore non puoi sapere nulla dell'esito della trasmissione sempre che tu non utilizzi la trasmissione bidirezionale, che però introduce altre rogne.

Qualche anno fa ho realizzato un sistema di cronometraggio per i go-kart dove un trasmettitore, posto sul go-kart, inviava continuamente tramite i raggi IR il codice del kart (per poterlo differenziare dagli altri kart).
Quando il trasmettitore si trovava allineato al ricevitore posto sul punto di misura veniva interrotto il cronometraggio del giro appena concluso e ripartiva quello del nuovo giro.
Il discorso funzionava, ma visto che sono un po' Don Chisciotte con relative cause perse, alla fine il progetto è rimasto solo come prototipo.

Uhm in effetti la questione va studiata per bene, il byte di controllo mi sembra un'ottima cosa anche se chiede calcoli extra, per il byte di inizio ok ma quello di fine? Lo uso per convalidare la sequenza e senza annullo la ricezione della stringa?
Caspita però con tutta questa roba la ricezione richiede parecchi calcoli, sopratutto se trasmetto ad alta velocità, non so bene come si comporterà il processore.

Riguardo la modalità di trasmissione, penso che sicuramente userò un modulo bidirezionale quindi ho disponibile la conferma dei dati ricevuti, potrei ad esempio fare la somma di byte di indirizzo e di dato o robe simili, certo il tutto si complica davvero tanto chissà cosa ne verrà fuori, perchè oltre alla conferma dei dati ricevuti devo anche trasmettere i dati letti sul robot, uhm, la cosa va pensata molto bene.
Pensandoci bene poi, credo sia meglio trasmettere continuamente tutti i parametri di controllo altrimenti nel caso il robot smetta di ricevere continuerebbe a muoversi seguendo gli ultimi valori impostati e finirei col perderlo chissà dove. Però di contro se devo trasmettere una serie molto lunga servirebbe parecchia velocità altrimenti vedrei i motori muoversi a scatti come mi è successo l'ultima volta, con 11 byte + byte di start a 9600b/sec i servi andavano ancora leggermente a scatti.

Per evitare potrei rendere un pò più autonomo il controllo, qualcosa tipo: avanti 100cm, ruota 50, etc, ma così si complica ancora di più il tutto...

Ehhh! C'è davvero parecchio da fare, ma proprio tanto

Esatto,il discorso è che più controlli inserisci e più sono improbabili errate interpretazioni dei dati.
E'necessario evitare che se si verificano uno o più errori nei dati la ricezione venga considerata ugualmente valida.


Tieni presente che i controlli necessari per il checksum, byte di start e stop ecc. occupano 10-15 istruzioni al massimo, per una durata totale di 2,5-3,5usec usando un pic (che immagino sia il microcontrollore che vorresti usare) con un quarzo da 10MHz, quindi considerando che a 9600bps ogni byte ha una durata di circa 1msec, il tempo di elaborazione del dato ricevuto è di circa 300 volte più breve della pausa fra un byte e il successivo. Aggiungici poi il fatto che il controllo del checksum deve essere fatto a fine pacchetto, durante la pausa che c'è dal pacchetto seguente, e puoi stare tranquillo che hai tutto il tempo che ti serve per calcolare.


Se la comunicazione può essere bidirezionale ti puoi permettere di inviare una risposta di "ho capito" in caso di ricezione corretta. In caso di mancata risposta entro un tempo prestabilito il trasmettitore sa che la ricezione non è andata a buon fine e può regolarsi di conseguenza.
In ogni caso è meglio che la trasmissione dei dati sia sovrabbondante rispetto ai dati richiesti, onde evitare che il rover si dimentichi di fare qualche cosa solo perchè non ha ricevuto un pacchetto di dati.
In ogni caso visto che trasmettitore e ricevitore devono essere sincronizzati (normalmente fra un pacchetto e l'altro c'è una pausa che serve proprio a risincronizzare trasmissione e ricezione) converrebbe fare in modo che in caso di mancata ricezione il rover vada entro breve tempo in stand-by, fermandosi in attesa di un nuovo comando.
Praticamente se tu invii un comando di "vai avanti alla velocità n" il rover dovrebbe spostarsi fino a quando riceve dei dati validi, per poi fermarsi quando i dati non vengono ricevuti per un tot di tempo (comunque breve, dato che la trasmissione avverrà varie volte ogni secondo e quindi conviene bloccare il movimento dopo qualche secondo dall'ultima ricezione).
E' inutile, per non dire dannoso, pensare di inviare un comando "fermati". La fermata ci può essere tramite un comando apposito, ma deve essere anche automatica in caso di assenza di segnale.
Se la trasmissione non ha una qualità tale da mantenere in movimento il rover tramite apposito comando non ha senso allontanare ulteriormente il rover, ma è bene che si fermi lì dov'è in attesa di "tempi migliori", anche perchè i successivi comandi verrebbero facilmente persi a distanze maggiori.

Uhm, si comincio a schiarirmi un pò le idee, infondo non è poi complicato in se, c'è solo tanta roba da far funzionare come si deve. Mi sfugge un pochino come poter fare una comunicazione bidirezionale usando anche le risposte di ricezione corretta. Sul rover certo non subito ma prevedo di piazzarci un bel pò di sensori assortiti e sopratutto vorrei poter leggere quanti più dati possibili sul funzionamento, che è utile per mettere tutto a punto, diciamo che mi aspetto almeno una decina di valori analogici, ad esempio tensione batteria, assorbimento motori, temperature varie.
Con tutta sta roba come faccio?
Diciamo che potrei usare comandi semplici ripetuti nel tempo come consigli, tipo "avanti" che ha una durata sufficiente a coprire la distanza tra i due comandi.
Verrebbe una cosa del tipo:
Dato in uscita dal telecomando, telecomando attende conferma ricezione e poi si mette in attesa.
Ricevitore, riceve dato, invia conferma, trasmette dati, ritorna in ascolto.

Si, in questo modo mi basta una velocità di trasmissione bassa accontentandomi di eseguire i comandi con un leggero ritardo, il ricevitore può spegnere tutto appena non riceve più i dati e evita di trasmettere quando non necessario.
L'unico problema è che ad esempio lo sterzo funzionerebbe a scatti come mi è già successo.

Perfetto Gyppe, hai già capito come farei io (che poi non è detto che sia la soluzione migliore, dato che non ho la verità in mano).


Beh, a 9600bps e considerando un pacchetto composto da START,INDIRIZZO,COMANDO,DATO,STOP,CHECKSUM avresti una durata totale di circa 6msec. Considerando una pausa fra 2 pacchetti successivi di 10msec (che è già abbondante) avresti una durata totale di 16msec, corrispondenti a circa 60 trasmissioni ogni secondo.
Visto che si sta parlando di un rover, non una macchina da formula 1, il ritardo di neanche 20msec non dovrebbe essere neppure apprezzabile.

Se tu realizzi un set di comandi diversi tipo: avanti alla velocità X, indietro alla velocità X,sterza a sinistra di X, sterza a destra di X, leggi il dato analogico X, leggi la temperatura X, leggi l'assorbimento del motore X, ecc. tu avrai che nei comandi di scrittura verso il rover il ricevitore dovrebbe rispondere con un OK e basta, mentre ai comandi di lettura dal rover la risposta dovrebbe essere un valore numerico.

Si in effetti la velocità sarebbe ottima, dimentico che la prova che ho fatto io trasmettevo tanta roba e a velocità bassa, mi pare 1200, però sicuramente almeno il 90% della trasmissione andava persa.

Vero caspita non ci ho pensato, posso fare proprio così invece che trasmettere e ricevere continuamente tutti i dati.
Così posso aggiornare le posizioni di movimento molte volte al secondo e le letture meno importanti magari solo una volta al secondo o meno, dipende da quali sono, ad esempio aggiornare la tensione della batteria ogni 10 secondi non è mica una tragedia.
Si, il discorso comincia a diventare fattibile, speriamo bene
Per ora ho finito il driver per i motori, l298, 8 diodi e due resistenze + i connettori, è venuto davvero microscopico

Intanto aspetto i motori, le ruote le ho già, e dopo queste considerazioni penso prenderò due normali moduli aurel a 9600 che dovrebbero andare bene e mi risparmio tanti soldi che mancano