Problema ricevitore 315 MHz

[carloc]

Hai un data sheet del modulo TX'?

Comunque -sempre supponendo che sia un OOK- avrai due "stati" per il trasmettitore:

i) in trasmissione, radiofrequenza che esce, tensione alternata sull'antenna, onde elettromagnetiche che si propagano dall'antenna, (non so come altro dirlo)

ii) non in trasmissione, tensione in uscita nulla, nessuna emissione

Per selezionare uno dei due stati alzi o abbassi il livello al pin data, ma per sapere quando hai la trasmissione attiva devi vedere il datasheet appunto o anche fare due esperimenti....

Poi sei tu che attacchi l'etichetta "bit uguale zero" su uno dei due stati e "bit uguale uno" sull'altro e al trasmettitore o ricevitore non interessa niente cosa hai deciso e puoi fare nei due modi indifferentemente ed indipendentemente dal livello di tensione necessario al pin data che serve per ottenerlo.

Quello che ti consigliavo di provare è fare in modo che lo stato di riposo della trasmissione sia con trasmissione attiva, questo perché mentre riceve un segnale (intenso) il ricevitore si silenzia e diminuisce molto il rumore in uscita.

Buttare il primo messaggio non è esattamente la stessa cosa, un bit "nel mezzo al messaggio" potrebbe sempre essere scambiato (di nuovo) per uno start e potresti non sincronizzarti. Invece con una pausa sei più sicuro.

L'oscillogramma che hai postato non mi pare così male, a parte forse la scala dei tempi troppo compressa per apprezzare bene i tempi, hai solo i primi circa 4 ms di "caos" forse dovuti ad un transitorio nel ricevitore ma poi segue ragionevolmente.

Per essere sicuro di ricevere correttamente ci sono vari modi e ti assicuro che stai cominciando ad esplorare un universo veramente vasto e tutt'altro che banale.

Per farla brevissima ci sono codici che al costo di un certo numero di bit extra rispetto al minimo necessario a a trasmettere l'informazione richiesta sono in grado di accorgersi o anche di accorgersi e correggere alcuni errori (caso più semplice il bit di parità).
Per andare oltre potresti avere un ricetrasmettitore collegato ad entrambi i PIC e realizzare un sistema di conferma di ricezione ed eventuale ritrasmissione di pacchetti errati...

[kristian]

Quello che ti consigliavo di provare è fare in modo che lo stato di riposo della trasmissione sia con trasmissione attiva, questo perché mentre riceve un segnale (intenso) il ricevitore si silenzia e diminuisce molto il rumore in uscita.

Io non ho modo per fare questo! Quello che posso dirti è che quando non trasmetto nulla, il ricevitore manda al PIC una serie di impulsi. Forse potrei provare a far mandare al PIC 0 V quando io non sto trasmettendo nulla.

Buttare il primo messaggio non è esattamente la stessa cosa, un bit "nel mezzo al messaggio" potrebbe sempre essere scambiato (di nuovo) per uno start e potresti non sincronizzarti. Invece con una pausa sei più sicuro.

Forse mi sono spiegato male io. Allora nel momento in cui io premo il pulsante al PIC che si occcupa della trasmissione, mando un bit di start seguito dal messaggio e sicuramente questo verrà mandato più volte.
In ricezione, attendo il primo bit di start e da qui aspetto che passi il primo messaggio, dopo attendo l'altro bit di start e poi memorizzo i 3 byte che arrivano. perché dici che

un bit "nel mezzo al messaggio" potrebbe sempre essere scambiato (di nuovo) per uno start

?
Una volta ricevuto il bit di start(il secondo), i bit che seguono fanno parte dei 3 byte.

Grazie per il tuo aiuto.

[kristian]

Comunque provando a collegare i due PIC attraverso un filo, il comportamento è più o meno simile se non peggiore. Posso chiedere informazioni sul software?

[carloc]

ok prova a descrivere esattamente il protocollo che stai cercando di realizzare... come è fatto uno start, come è trasmesso un byte e tutti i dettagli ed i tempi....

BTW: ma perché non provi con l'UART del PIC? non c'è nel PIC che hai tu?

[kristian]

Allora in pratica il protocollo l'ho stabilito io. Il messaggio che viene generato dal PIC in trasmissione è composto da: un bit di start, e 3 Byte. Se il pulsante viene tenuto pigiato verranno generati una serie di messaggi distanziati di 15 ms. Il bit di start non è altro che uno 0. Per quanto riguarda i byte ho scelto di inviare i seguenti 3 valori: 170, 170, 2. Uno 0 è costituito da un impulso alto di 400 us, seguito da un impulso alto di 1.5 ms. Un 1 logico invece è costituito da un impulso alto di 1.5 ms e da un impulso basso di 400 us.
Tutto questo è presente nel codice del PIC 16f628A.
Per quanto riguarda in ricezione, vado alla ricerca di uno start bit, che appunto è uno 0, e poi memorizzo i 3 byte sucessivi. In questo caso, dato che nel momento in cui pigio il pulsante al tx, non viene generato un solo messaggio ma più di uno rischierei che il led si accendi e spegni più volte. Quindi ho inserito la variabile onetime, se questa assume valore 0, faccio commutare il led, se invece è 1 non faccio niente.
In pratica nel momento in cui arriva il primo messaggio, se i 3 byte corrispondono a quelli memorizzati, commuto lo stato del led e metto a 1 onetime. Dopo se onetime è a 1 faccio partire un timer, che se va in overflow azzererà onetime. Dato che i messaggi si ripetono ogni 15 ms, se sarà trascorso un tempo maggiore di 15 significherà che il pulsante non è più premuto e quindi il timer andrà in overflow. Chiaramente il timer verrà fermato quando giunge un secondo messaggio, se invece questo non avviene il timer continuerà a contare e andrà in overflow.
Tutto questo è invece presente nel PIC rx.

[carloc]

mmm senti ma nel tuo software di ricezione gestisci tutti i possibile casi (e.g. overflow del timer, impulso alto o basso per "troppo tempo" etc. etc.) e la ri-sincronizzazione a seguito di questi eventi?

Cosa succede se ti perdi un bit dei uno+(tre per otto)? hai un timeout che resetta tutta la macchina per predisporsi al prossimo messaggio?

Certo che il protocollo non mi pare molto robusto, un solo start-bit e poi 24 bit da trasmettere, se perdi il sincronismo è probabile che uno degli zeri dei tre byte venga erroneamente interpretato come un start e da lì continua a contare modulo 24 e non si risincronizza mai più....

Ma poi, tagliamo la testa al toro... perché non provi ad usare l'UART invece? C'è tutto l'hardware pronto da usare che fa quello che vuoi fare

[kristian]

mmm senti ma nel tuo software di ricezione gestisci tutti i possibile casi (e.g. overflow del timer, impulso alto o basso per "troppo tempo" etc. etc.) e la ri-sincronizzazione a seguito di questi eventi?

Utilizzando il filo di collegamento tra i due fili, non credo avrei di questi problemi; con il tx-rx allora si.Comunque sia il timer è in grado di contare fino a 52 ms, dopodichè va in overflow e questa è una condizione non gestita.

Cosa succede se ti perdi un bit dei uno+(tre per otto)? hai un timeout che resetta tutta la macchina per predisporsi al prossimo messaggio?

perché dovrei perdere un bit?

se perdi il sincronismo è probabile che uno degli zeri dei tre byte venga erroneamente interpretato come un start e da lì continua a contare modulo 24 e non si risincronizza mai più....

In che modo potrei perdere il sincronismo?

Ma poi, tagliamo la testa al toro... perché non provi ad usare l'UART invece? C'è tutto l'hardware pronto da usare che fa quello che vuoi fare

L'UART non l'ho mai usata. La dovrei usare sia in trasmissione che ricezione, però c'è un problema: ho acquistato un telocomando a 315 MHz che genera come contenuto informativo lo stesso del PIC in trasmissione. Grazie per il tuo aiuto.

[carloc]

Ok quindi devi clonare un telecomando ecco il perché....

prova a sfoltire il codice, ricomincia da capo con piccole routine semplici che facciano una certa cosa (e.g. trasmetto uno start e dall'altro ricevo uno start) con molte informazioni di debug sull'LCD (ma alla fine, non durante le operazioni critiche nel tempo che l'attesa dell'LCD ready potrebbe anche sballare le temporizzazioni....)


e inserisci sempre controlli per ogni cosa che potrebbe andare storta (legge di Murphy)

e metti un timeout "totale" dopo lo start aspetti 24 impulsi... ma se non arrivassero (ancora Murphy) entro un tempo ragionevole resetta tutto.

Conosci le macchine a stati finiti? Sono un buon sistema per fare queste cose senza "intrigarsi"

[carloc]

...ad esempio sfogliando velocemente il tuo codice ho notato questo:

la routine con cui misuri la durata di un impulso mi sembra questa

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

che sembra ok, ma basta un disturbo, anche brevissimo, per falsare completamente la misura

Ecco, secondo me, questo è il tipo di cose da evitare dovresti fare un codice "immune" a questo tipo di problemi. Di solito si campiona l'impulso un numero di volte durante il periodo che ti aspetti alto (che so 8 volte) e poi si decide a maggioranza (se almeno 5 sono alti allora prendo l'impulso per alto) e viceversa se voglio controllare che sia basso....

[kristian]

Allora per quanto riguarda la funzione READBYTE, ossia quella che valuta se il bit vale 1 o 0, questo è quello che faccio:
temporizzare la durata del tempo a livello logico alto, se questa durata supera 1.2 ms allora è sicuramente un 1 logico, altrimenti è 0 logico. Dopodiché attendo la parte a livello basso.
Temporizzando la sola durata del tempo a livello logico alto sono riuscito a risolvere parecchi problemi, infatti se ad esempio lo zero logico (impulso alto stretto + parte bassa più lunga) ha una parte bassa che è più corta, questo non influisce né sul bit in questione, in quanto mi interessa solo parte alta, né il bit sucessivo, il quale presenterà una parte alta più lunga ma anche questo non è un problema visto che tutto ciò che dura per più di 1.2 ms viene interpretato come 1. Mi sembra abbastanza fatto bene, no? Ma non capisco perché quando tengo premuto il pulsante partono 3 miliardi di codici. Una cosa molto strana, che usando il modulo tx e rx a 315 non accade ma che invece si verifica collegando i due PIC tramite un filo, è che il TMR3 non si azzera. Potresti dare un'occhiata?

Di solito si campiona l'impulso un numero di volte durante il periodo che ti aspetti alto (che so 8 volte) e poi si decide a maggioranza (se almeno 5 sono alti allora prendo l'impulso per alto) e viceversa se voglio controllare che sia basso....

Ma questo dovrei farlo per 25 bit? Dovrei poi richiedere la trasmissione 5 volte, prima di accendere il led? Sarebbe troppo lento così.