Vai Indietro   PcTuner Forum > Sezione Hardware > Programmazione PIC
Arcade Registrazione Blogs Regolamento Feedback FAQ Lista Utenti Calendario Segna come Letti

Ultimi 5 blog pubblicati su PcTuner Blog
Data Titolo

Rispondi
 
Strumenti Discussione Modalità Visualizzazione
Vecchio 24-04-2008, 11.41.09   #1
Registered User
 

Iscritto da: 10-07-2007
Messaggi: 56
Feedback: (0)
Problema di sincronizzazione con Aurel

Salve a tutti,
sto utilizzando 2 moduli aurel RTF-DATA-SAW (ognuno dei quali può trasmettere e ricevere). L'algoritmo di decodifica lavora così:
-il pic (16F690) ha l'interrupt sensibile alla transizione di salita;
-ogni volta che arriva un livello alto ne misura la durata così da stabilire se lo
deve interpretare come come uno zero o un 1.
In questo modo ricostruisco il byte.
Concettualmente mi sembra logico però ho notato che la sequenza di dato 01010101 viene facilmente confusa con la 10101010. Credo sia un problema di aggancio col bit di start. Il quesito è il seguente (supportato dall'immagine che allego per chiarezza): quando il TX non trasmette il pic del ricevitore riceve comunque degli impulsi dovuti al rumore quindi si attiva l'interrupt e il pic, ignaro di essersi agganciato al rumore piuttosto che al bit di start, inizia il suo lavoro di ricezione/decodifica terminando con un ovvio errore. Vi chiedo:come posso fare in modo che si agganci precisamente al bit di start?
Grazie a tutti

Marco
Immagini Allegate
Tipo di File: jpg Sequenze_jpeg.JPG‎ (37.1 KB, 109 visite)
marcot Non in Linea   Rispondi Citando
Vecchio 24-04-2008, 12.21.49   #2
Registered User
 
L'avatar di  Camillo
 

Iscritto da: 31-01-2006
Locazione: Genova
Messaggi: 1,525
Feedback: (0)
Il rumore c'è e non puoi eliminarlo il sistema non deve agganciarsi allo start bit ma ad un serie di impulsi tutti uguali di preambolo.
Guarda il data sheet del HCS300 della Microchip se vuoi informazioni.
__________________
Camillo

Internet ti fa vedere tutto ma non ti fa toccare niente. (Camillo Ferrari)
Camillo Non in Linea   Rispondi Citando
Vecchio 24-04-2008, 13.05.37   #3
Registered User
 
L'avatar di  devil_evoxxx
 

Iscritto da: 15-02-2007
Locazione: Villimpenta (near Mantova & Verona)
Messaggi: 290
Feedback: (0)
Camillo sei un pozzo di sapienza, tempo fa quando stavo lavorando con i moduletti aurel avevo letto qualcosa in giro riguardo l'hcs300 ma non gli avevo dato peso. Ho usato codifica manchester tutta gestita via software e ho quasi risolto i problemi che ha anche marcot.

Ora però mi vien da domandarti due cosette:

1) con che cosa programmo l'hcs300?(ce qualcosa gia integrato in mplab per lavorarci su con l'icd2?)
2) Se l'hcs300 in uscita genera un pwm che poi andrà passato al modulo aurel tx, esiste il suo complementare che "riceve" dal modulo RX e mi da la stringa trasmessa??

Perchè potrei semplificare di molto il circuito che ho realizzato per il trasmettitore, e quindi semplificandomi anche la vita dal lato Firmware

Grazie in anticipo,

Ciao, Davide
__________________
devil_evoxxx Non in Linea   Rispondi Citando
Vecchio 24-04-2008, 23.39.30   #4
Registered User
 
L'avatar di  Camillo
 

Iscritto da: 31-01-2006
Locazione: Genova
Messaggi: 1,525
Feedback: (0)
00) Grazie per l'apprezzamento ma è solo trentennale esperienza.
0) Un consiglio: lascia perdere HCS300 ma creati la tua stringa magari generata con il suo metodo fisico ma la tua codifica, non penso che tu abbia bisogno di un codice variabile (hopping code). Se però ti vuoi cimentare nel sito Microchip trovi la documentazione necessaria per fare la decodifica, anche del codice già scritto.
1) Non saprei proprio se c'è possibilità di programmazione tramite aggeggi ufficiali Microchip. Per me la cosa risale ad una decina di anni fa. A suo tempo feci un programma che girando su PC (sotto DOS) da in pasto un numero incrementale (numero di serie) ad una scheda con un 16C57 che gestisce la programmazione di HCS300 (cerca 545 sul sito Gesco).
Allego l'incipit dei programmi dove c'è la spiegazione generale.
Codice:
/*****************************************************************************

				   RXPROG.C


		    GESCO s.n.c.  by Camillo Ferrari

					Data inizio:		16/07/98
					Data ultima modifica:	22/07/98 08.51
					Data ultimo ritocco:    29/09/98 10.07

					Versione  #   1.00

 Programma di comunicazione tramite la porta parallela ad un'apparecchiatura
  in grado di programmare i trasmettitori di radiocomando.
 Viene inviato un numero seriale autoincrementante di 32 BIT prelevato
  da un file su cui era stato scritto l'ultimo numero inviato.

Mentre la comunicazione Š cos fatta:
 vi sono 2 linee chiamate 'clock' e 'dati' per cui Š un sistema
 sincrono con dati validi sul fronte di discesa. Altre 2 linee comunicano
 dall'esterno il loro nome Š 'pronto' e 'stato'. 'Pronto' quando Š basso
 indica che si pu• inviare i dati mentre 'stato' quando Š basso
 indica se la programmazione del chip Š avvenuta regolarmente.
La comunicazione avviene con un preambolo di 32 BIT tutti a 0 seguiti dai
 32 BIT di numero seriale. Al termine dell'invio deve avvenire la
 programmazione con comunicazione del risultato.

*****************************************************************************/
e questo è quello per la schedina programmatrice:
Codice:
; TITLE "RXPROG programmatore per il trasmettitore radiocomando."

; SUBTITL "RXPROG  GESCO S.n.c. - By C. Ferrari"

 LIST	P=16C57,N=0,C=132,F=INHX8M,R=DEC;,X=Off;,E=0

 ERRORLEVEL 0, -305

;VER_ALF equ	'A'
VER_NUM equ	'0'


; In compilazione da:
;	Errors   :      0
;	Warnings :      0 reported,     0 suppressed
;	Messages :      4 reported,     0 suppressed

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

;	Data inizio:		   16/07/98 13.27
;	Data ultima modifica:      22/07/98 08.00
;	Data ultimi ritocchi:


;	Ulteriori modifiche o commenti
;Ver.	Data

; 1A Versione iniziale.


;=============================================================

;			   FUNZIONAMENTO

;Programma il radiocomando con il numero di serie ricevuto dal PC
; attraverso la porta parallela.
;La programmazione dello HCS300 contenuto nel radiocomando avviene
; rispettando (o quasi) il protocollo indicato sul manuale Microchip alle
; pagine 5 e seguenti (3) e 11 e seguenti (6).
;Mentre la comunicazione da/verso il PC Š cos fatta:
; vi sono 2 linee dal PC chiamate 'clock' e 'dati' per cui Š un sistema
; sincrono con dati validi sul fronte di discesa. Altre 2 linee comunicano
; da qui al PC il loro nome Š 'pronto' e 'stato'. 'Pronto' quando Š basso
; indica che si Š in grado di ricevere i dati mentre 'stato' quando Š basso
; indica se la programmazione del chip Š avvenuta regolarmente.
;La comunicazione avviene con un preambolo di 32 BIT tutti a 0 seguiti dai
; 32 BIT di numero seriale terminati i quali si davvio alla programmazione.
;
;=============================================================
2) Ti ho risposto in parte nel punto 0. Vengono utilizzati dei codici di codifica/decodifica di tipo privato più un numero seriale diverso in ogni trasmettitore. Dopo la procedura di apprendimento del trasmettitore da parte del ricevitore questo è pronto a riconoscere il trasmettitore tramite il suo numero seriale ed un numero che si incrementa ad ogni trasmissione.
Una cosa abbastanza semplice, mi pare, o nò?!

Mi sa che il tuo ultimo comma sia da rivedere!
__________________
Camillo

Internet ti fa vedere tutto ma non ti fa toccare niente. (Camillo Ferrari)
Camillo Non in Linea   Rispondi Citando
Vecchio 25-04-2008, 01.40.30   #5
Registered User
 
L'avatar di  devil_evoxxx
 

Iscritto da: 15-02-2007
Locazione: Villimpenta (near Mantova & Verona)
Messaggi: 290
Feedback: (0)
Grazie mille per i chiarimenti Camillo..ora inizio a capirci qualcosa di più.
Ultimamente stavo pensando che per semplificare il firmware che gestisce la creazione della stringa che invio e relativa codifica manchester(tutta gestita via software) , potrei far passare il dato che devo trasmettere in una porta xor in cui l'altro operando è un onda quadra a frequenza doppia di quella di trasmissione (non del modulo). In teoria ciò mi permetterebbe di creare la codifica manchester "hardware", devo pero valutare se il gioco vale la candela...


Grazie ancora

Ciao, Davide
__________________
devil_evoxxx Non in Linea   Rispondi Citando
Vecchio 28-04-2008, 14.29.49   #6
Registered User
 

Iscritto da: 10-07-2007
Messaggi: 56
Feedback: (0)
Salve, grazie per aver risposto.
Ho notato che molti suggeriscono l'utilizzo di un'onda quadra di preambolo per far agganciare il ricevitore; tuttavia non riesco a capire come dovrebbe essere utilizzata...se non riesco a farlo agganciare al bit di start del dato perchè dovrebbe agganciarsi a quest'onda quadra? potresti chiarirmi le idee?
Ti ringrazio.

Marco
marcot Non in Linea   Rispondi Citando
Vecchio 28-04-2008, 19.23.40   #7
Registered User
 
L'avatar di  Camillo
 

Iscritto da: 31-01-2006
Locazione: Genova
Messaggi: 1,525
Feedback: (0)
Diciamo che questi impulsi di preambolo con duty al 50% (ma ci sono anche altri metodi) sono un certo numero (HCSxxx ne manda 16) la routine di ricezione ne deve riconoscere un certo numero di fila (poniamo 8) dopo di che quando il duty cambia ecco che è arrivato il primo bit utile. Chiamalo start se vuoi ma non è strettamente necessario perché questa funzione è fatta dal preambolo.
Se dai un'occhiata ai vari data sheet degli HCSxxx ne puoi trovare altri anche con codice Manchester.
Ti ricordo che i primi bit trasmessi vengono travisati dal ricevitore per cui vengono persi, per questo ne vengono mandati 16.
__________________
Camillo

Internet ti fa vedere tutto ma non ti fa toccare niente. (Camillo Ferrari)
Camillo Non in Linea   Rispondi Citando
Vecchio 05-05-2008, 12.57.58   #8
Registered User
 
L'avatar di  elberto
 

Iscritto da: 28-08-2005
Messaggi: 1,131
Feedback: (0)
Suppongo sia un ricevitore superreattivo, il tuo stesso problema l'ho avuto con quelli, infatti altri come il BC-NBK non hanno questo problema, solo non sono così sensibili.
Potresti fare una cosa del genere: interrupt su fronte di salita, parte il timer da 0 a xxx, imposti l'interrupt sul fronte di discesa.
Quando viene chiamato l'interrupt sul fronte di discesa controlli il valore del timer: se corrisponde al tempo di bit, allora è agganciato, altrimenti è solo rumore.
__________________
Materazzi squalificato!? Tanto alla fine...
elberto Non in Linea   Rispondi Citando
Vecchio 16-01-2011, 11.26.08   #9
Registered User
 

Iscritto da: 19-06-2006
Messaggi: 365
Feedback: (0)
Salve,
anch'io ho grossi problemi di rumore in ricezione con questo modulo, e non capisco come faccia a funzionare il progetto che ho realizzato, in cui due schede comunicano tramite questi due moduli: se in mancanza di trasmissione c'e' tutto quel rumore, "dentro" a ogni zero ci saranno un sacco di picchi, come fa il controllore in ricezione a distinguere il segnale dal rumore?

Ho provato ad agganciarmi col controllore a un ricevitore a 433 MHz montato su una stazione meteo, e non vede assolutamente nessun rumore in assenza di trasmissione, proprio calma piatta!
Ed è un modulino addirittura piu' minuscolo di questo RTF-SAW, ma non capisco che chip usa, contiene solo un TL052CN che non mi parfe un demodulatore.

Ho lo stesso problema anche con un ricevitore AC-RX2, sempre Aurel.

Potrebbe dipendere dai condensatori? Non ho un ceramico "da almeno 100.000 pF" come dice il datasheet , quindi ci ho messo un poliestere da 0,10uF, è lo stesso?
__________________
-- JumpJack --
------------------
Meglio sys 16384 o sys 64738?
jumpjack Non in Linea   Rispondi Citando
Vecchio 18-01-2011, 23.25.24   #10
RockModerator
 
L'avatar di  RockRibelle
 

Iscritto da: 07-01-2009
Locazione: Lugano
Messaggi: 1,509
Feedback: (0)
Quote:
Originariamente inviato da jumpjack Visualizza Messaggio
Salve,
anch'io ho grossi problemi di rumore in ricezione con questo modulo, e non capisco come faccia a funzionare il progetto che ho realizzato, in cui due schede comunicano tramite questi due moduli: se in mancanza di trasmissione c'e' tutto quel rumore, "dentro" a ogni zero ci saranno un sacco di picchi, come fa il controllore in ricezione a distinguere il segnale dal rumore?

Ho provato ad agganciarmi col controllore a un ricevitore a 433 MHz montato su una stazione meteo, e non vede assolutamente nessun rumore in assenza di trasmissione, proprio calma piatta!
Ed è un modulino addirittura piu' minuscolo di questo RTF-SAW, ma non capisco che chip usa, contiene solo un TL052CN che non mi parfe un demodulatore.

Ho lo stesso problema anche con un ricevitore AC-RX2, sempre Aurel.

Potrebbe dipendere dai condensatori? Non ho un ceramico "da almeno 100.000 pF" come dice il datasheet , quindi ci ho messo un poliestere da 0,10uF, è lo stesso?
Il ricevitore del modulo contiene un circuito che agisce come un controllo automatico di guadagno. In questo modo, e trasmettendo un preambolo, il ricevitore adatta la soglia di detezione in funzione del livello di segnale ricevuto. Ovviamente bisogna filtrare adeguatamente il segnale all'uscita del ricevitore, in modo da discriminare quello che é rumore dal segnale utile. Secondo i vari datasheet, potrebbe essere necessario un preambolo di qualche centinaio di millisecondi, fino a 300 ms, per adattare la soglia di discriminazione del ricevitore.
__________________
..Indomabile..
RockRibelle Non in Linea   Rispondi Citando
Vecchio 19-01-2011, 09.05.43   #11
Registered User
 

Iscritto da: 19-06-2006
Messaggi: 365
Feedback: (0)
Quote:
Originariamente inviato da RockRibelle Visualizza Messaggio
Ovviamente bisogna filtrare adeguatamente il segnale all'uscita del ricevitore, in modo da discriminare quello che é rumore dal segnale utile. Secondo i vari datasheet, potrebbe essere necessario un preambolo di qualche centinaio di millisecondi, fino a 300 ms, per adattare la soglia di discriminazione del ricevitore.
Il problema è che dal ricevitore esce un segnale già digitale, come faccio a filtrarlo?!?
E' vero che c'e' anche un'uscita analogica, ma è solo un "punto di ispezione", mostra com'e' il segnale prima del convertitore A/D, ma non posso "trattarlo". Ho anche trovato sul ricevitore un trimmer non documentato nel datasheet: pensavo servisse a modificare la soglia dell' "1" , ma a quanto pare non è così, perche' il rumore digitale permane per qualunque posizione del trimmer.

A questo punto mi chiedo se non mi conviene ignorare del tutto l'uscita digitale, e mandare nell'MCU il segnale analogico e convertirlo "a mano": ha degli ingressi analogici a 1024 valori, quindi dovrebbe essere possibile...
__________________
-- JumpJack --
------------------
Meglio sys 16384 o sys 64738?
jumpjack Non in Linea   Rispondi Citando
Vecchio 20-01-2011, 22.14.10   #12
RockModerator
 
L'avatar di  RockRibelle
 

Iscritto da: 07-01-2009
Locazione: Lugano
Messaggi: 1,509
Feedback: (0)
Non credo che tu possa così migliorare la situazione. Devi far precedere il tuo segnale utile da un preambolo, con un treno di impulsi di durata tale che non venga confuso per un dato valido, poi lo fai filtrare dal microcontroller. Ovviamente prendi l'uscita digitale, perché se utilizzi quella analogica e filtri nel micro, non vai avanti di tanto..
__________________
..Indomabile..
RockRibelle Non in Linea   Rispondi Citando
Vecchio 21-01-2011, 13.46.25   #13
Registered User
 

Iscritto da: 19-06-2006
Messaggi: 365
Feedback: (0)
mah, in effetti prendendo in ingresso l'analogico riesco a tirar fuori un digitale perfetto senza rumore, perche' la soglia la decido io.... pero' così mi tocca riscrivere la libreria che elabora l'ingresso digitale!
__________________
-- JumpJack --
------------------
Meglio sys 16384 o sys 64738?
jumpjack Non in Linea   Rispondi Citando
Rispondi Per le vostre immagini su questo forum potete usare PcTunerUp!
Iscriviti gratuitamente alla nostra newsletter.


Utenti attualmente attivi che stanno leggendo questa discussione: 1 (0 utenti e 1 visitatori)
 
Strumenti Discussione
Modalità Visualizzazione

Regole di scrittura
non Puoi inserire messaggi
non Puoi rispondere ai messaggi
non Puoi inviare allegati
non Puoi modificare i tuoi messaggi

codice vB è Attivo
Smilies è Attivo
[IMG] il codice è Attivo
Il codice HTML è Disattivato
Trackbacks are Disattivato
Pingbacks are Disattivato
Refbacks are Disattivato
Vai al Forum


Tutti gli Orari sono GMT +2. Attualmente sono le 02.50.09.


Powered by vBulletin Versione 3.6.12
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright © 2010 - Master New Media S.r.l. a socio unico - P.I. 02947530784. Tutti i diritti di proprietà letteraria e artistica sono riservati- Privacy
www.pctuner.net è testata telematica registrata presso il Tribunale di Torino, n. 39 del 07.05.2008, Editore Master New Media S.r.l.