Comparazione in loopback

Salve, scusate la mia incompetenza in materia ma non sono riuscito a trovare la soluzione per inviare dei numeri o una stringa casuale ad esempio utilizzando il canale TX della seriale e comparare tramite un collegamento in loopback con un fotoaccoppiatore la stessa stringa che ritorna sul canale RX. Se il dato è uguale tutto ok, altrimenti deve notificarmi la differenza o l'assenza (ad esempio se il fotoaccoppiatore viene offuscato) abilitando una uscita.
Purtroppo date le mie scarse competenze in programmazione non riesco a trovare una valida soluzione se non utilizzando hardware esterno.
Qualcuno più esperto sarebbe così gentile da darmi qualche dritta ?

Spiega esattamente cosa vuoi fare.

leo72:
Spiega esattamente cosa vuoi fare.

Praticamente l'aggeggio deve fare questo lavoro:

  1. generare un numero casuale (ad esempio con la funzione random);
  2. sparare questo valore sulla TX seriale o su qualche altro pin che è connesso ad un fotodiodo;
  3. ricevere questo dato sul pin RX seriale o su altro pin che è connesso ad un fototransistor o similare;
  4. se il dato inviato è uguale a quello ricevuto ricomincia un nuovo ciclo;
  5. se il dato ricevuto è diverso da quello inviato o non viene ricevuto (timeout) si deve attivare una uscita;
  6. il loop è infinito.

Questo è quello che deve fare.

Ma non ho capito... perché fai passare un dato seriale tramite un fotodiodo?
Cos'è che vuoi individuare, di quel fotodiodo, con un pacchetto di dati?

Quanto sará il ritardo tra segnale spedito e segnale ricevuto?
Io tendo a un collegmento a 38 kHz e un ricevitore TSOP. Via random accendi e spegni la trasmissione e controlli dopo x msecondi se il segnale ricevuto é uguale a quello spedito.

Esempio Sketch per una fotocella con un LED IR e un TSOP. Devi modificarlo per il Tuo uso.

#define RXTSOP 3      //Pin TSOP 
#define TXIR 2        //LED IR
#define LED13 13      //LED on pin 13


//flag
boolean transmitting_IR; //transmission flag

// turn_off , turn_on, detect functions come as is from
// http://www.eng.utah.edu/~cs1410/Labs/lab09.html
void turn_off_IR ()
{
  // Instead of just adjusting the output on pin 11, this code also
  // turns off the timer controlling the PWM output on pin 11
  
  TCCR2A = 0; // Disconnect PWM
  TCCR2B = 0; // Stops the timer
  OCR2A = 0;  // No timer top
  digitalWrite(TXIR, LOW);  // Ensure output is off
  
  transmitting_IR = false;
}

void turn_on_IR ()
{
  //   Set up Timer2 (which can be connected to pins 3 and 11)
  //   For full details, see:
  //   arduino.cc/en/Tutorial/SecretsOfArduinoPWM
  //   The syntax here has me baffled, but the patterns of usage
  //   are clear if you look at the ATMega328 diagrams.
  //   _BV appears to stand for 'bit value'
  //   Different bits need to be set to control each timer
  //   Refer to diagrams for clarity

  TCCR2A = _BV(WGM21) | _BV(COM2A0); // This mode toggles output once per timer cycle
  TCCR2B = _BV(CS20);  // Do not scale the clock down - use 16 MHz timer rate.
  OCR2A = 210; // Divide sys. clock by 210, 1/2 cycle = 76 khz, 1 cycle = 38 khz
  
  // Output pin 11 should now be emitting a 38 khz signal.
  
  transmitting_IR = true;
}


void detectIR()
{
    if(digitalRead(RXTSOP)){
    digitalWrite(LED13 ,LOW);
    }else{
    digitalWrite(LED13 ,HIGH);
    }
}


void setup(){  
  pinMode(TXIR, OUTPUT);
  pinMode(RXTSOP, INPUT);
  turn_on_IR();
  delay(100);
}

void loop(){
  detectIR(); // search for IR
  delay(50);  
}

Ciao Uwe

Il segnale deve attraversare una specie di fibra ottica, quindi immagino che il tempo la trasmissione e la ricezione sia piccolissimo, a meno che non gli aggiungo un ritardo artificialmente. Da quello che sto vedendo dal codice non fa altro che inviare un burst a 38kHz o rileva gli impulsi in dal TSOP, l'unico problema è che nella mia applicazione sono costretto ad usare luce visibile, questo comporta il fatto che mentre in uscita al TSOP il tempo dell'impulso è pari a quello del burst, nel mio caso dovrei rilevare il singolo impulso del burst e non so se ce la fà a rilevarlo.
Che ne pensate ?

zikako74:
Il segnale deve attraversare una specie di fibra ottica, quindi immagino che il tempo la trasmissione e la ricezione sia piccolissimo, a meno che non gli aggiungo un ritardo artificialmente.

Ah, ecco. Non capivo :sweat_smile:
Beh, in teoria se passa su una fibra ottica il tempo perso sta nella conversione da segnale elettrico ad ottico e viceversa, ma la trasmissione si può dire quasi istantanea. Non preoccuparti, però, che non solo la trasmissione seriale avviene per interrupt ma anche la ricezione, per cui non perdi dati. Tutto ti viene riversato nel buffer RX, da cui puoi prelevare poi i caratteri ricevuti.

leo72:
Ah, ecco. Non capivo :sweat_smile:
Beh, in teoria se passa su una fibra ottica il tempo perso sta nella conversione da segnale elettrico ad ottico e viceversa, ma la trasmissione si può dire quasi istantanea. Non preoccuparti, però, che non solo la trasmissione seriale avviene per interrupt ma anche la ricezione, per cui non perdi dati. Tutto ti viene riversato nel buffer RX, da cui puoi prelevare poi i caratteri ricevuti.

Cioè vorresti dirmi che se sparo ad esempio con un serial.print() e subito dopo faccio un read dovrei trovarmi quello che ho sparato senza perdere nulla ? O in realtà bisogna agire su altro?

zikako74:
Cioè vorresti dirmi che se sparo ad esempio con un serial.print() e subito dopo faccio un read dovrei trovarmi quello che ho sparato senza perdere nulla ? O in realtà bisogna agire su altro?

Se perdessi dei dati ci sarebbe qualcosa che non va nel mezzo di trasmissione.

Secondo me deve creare un tester per cavi in fibra. ]:slight_smile:

nid69ita:
Secondo me deve creare un tester per cavi in fibra. ]:slight_smile:

E' facile.
Ci vogliono 2 persone: una si pone da una parte con una torcia in mano ed illumina il capo della fibra stessa, l'altra controlla se all'altro capo arriva la luce :stuck_out_tongue_closed_eyes:

leo72:

nid69ita:
Secondo me deve creare un tester per cavi in fibra. ]:slight_smile:

E' facile.
Ci vogliono 2 persone: una si pone da una parte con una torcia in mano ed illumina il capo della fibra stessa, l'altra controlla se all'altro capo arriva la luce :stuck_out_tongue_closed_eyes:

Sarebbe sprecato usare una MCU per fare un semplice tester, in realtà il fatto che il dato trasmesso deve essere sia presente e comparato con quello ricevuto è per una questione di sicurezza, perchè se il problema fosse stato semplicemente verificare che un qualcosa ritornasse al ricevitore si era già risolto, ma in questo caso specifico è necessario evitare un "man in the middle", la mia preoccupazione è che l'MCU possa impiegare molto tempo tra la trasmissione e l'analisi del buffer di ricezione non permettendo la comparazione perchè i dati potrebbero non essere rilevati nel giusto tempo.
Per quello che serve basterebbe verificare anche un singolo byte generato in maniera casuale.
Altre idee ?

zikako74, ti serve per caso per realizzare un qualche cosa legato alla ... "sicurezza" ? Perché oltre 10 anni fa ho realizzato una cosa che funzionava proprio come stai descrivendo tu (... solo che all'epoca usava un micro 8051) :wink:

Fammi sapere ... :slight_smile:

Guglielmo

Io parlerei di affidabilità del mezzo trasmissivo, non di sicurezza.
A livello fisico la sicurezza la implenti impedendo l'accesso, ma se uno ha l'accesso la devi implementare nel protocollo.
La prova che lui sta effettuando mi sembra invece una verifica del non deterioramento del segnale.

PaoloP:
Io parlerei di affidabilità del mezzo trasmissivo, non di sicurezza.
A livello fisico la sicurezza la implenti impedendo l'accesso, ma se uno ha l'accesso la devi implementare nel protocollo.
...

Paolo, t'assicuro che non è così banale :wink:

E ... l'oggetto di cui parlo, viene usato proprio a livello fisico ... immagina il concetto di "uno spago con un piombino", per sigillare qualche cosa ... ecco, lo spago con il piombino lo "viola" anche un bambino, un sistema intelligente a fibra ottica ... è un po' più difficile :wink:

Guglielmo

invia una serie di fotoni polarizzati in modo predefinito. Il ricevitore usa dei filtri polarizzanti per leggere la polarizzazione del fotone in arrivo, se il fotone è stato intercettato allora la sua polarizzazione è cambiata.
poi corri a richiedere un premio nobel, questo sistema è alla base della criptazione quantica.

BTW secondo me puoi usare una digitalwrite e una digitalread; anzi la loro versione fast che dura pochi nanosecondi.

Se accendi il led per valori casuali, e rilevi che la digitalWrite dà high di conseguenza, magari con un interrupt, il ritardo dipende dalla lunghezza del cavo, 300 000 km/s = 300m circa in 1 microsecondo, + tempo di digitalWrite ( centinaia di nanosecondi se usi le macro) + tempo reazione del led ( decine di nanosecondi in base al led) + tempo di reazione del led ricevitore ( decine di nanosecondi in base al led)+tempo di rezione dell'arduino con interrupt (??? < 1 microsec credo)

lesto:
invia una serie di fotoni polarizzati in modo predefinito. Il ricevitore usa dei filtri polarizzanti per leggere la polarizzazione del fotone in arrivo, se il fotone è stato intercettato allora la sua polarizzazione è cambiata.
poi corri a richiedere un premio nobel, questo sistema è alla base della criptazione quantica.

Si basa sul principio di indeterminazione di Heisenberg, che afferma che di una particella non puoi conoscere contemporaneamente la sua posizione ed il suo moto.
Misurare una delle due grandezze, altera la particella in modo tale che non puoi più conoscere l'altra grandezza. Intercettare un fotone ne altera una delle 2 grandezze, rivelando quindi un tentativo di intrusione nel sistema.

leo72:

lesto:
invia una serie di fotoni polarizzati in modo predefinito. Il ricevitore usa dei filtri polarizzanti per leggere la polarizzazione del fotone in arrivo, se il fotone è stato intercettato allora la sua polarizzazione è cambiata.
poi corri a richiedere un premio nobel, questo sistema è alla base della criptazione quantica.

Si basa sul principio di indeterminazione di Heisenberg, che afferma che di una particella non puoi conoscere contemporaneamente la sua posizione ed il suo moto.
Misurare una delle due grandezze, altera la particella in modo tale che non puoi più conoscere l'altra grandezza. Intercettare un fotone ne altera una delle 2 grandezze, rivelando quindi un tentativo di intrusione nel sistema.

Senza scomodare Heisenberg come ha ben capito Guglielmo (gpb01) il sistema funziona proprio a livello fisico, infatti, la fibra è utilizzata come un cordone agganciato agli oggetti da proteggere e chiuso il loop, se viene manomesso ad esempio con il taglio il sistema deve avvisarmi.
L'unico inconveniente è che se qualche esperto in qualche maniera riesce a scorticare la guaina e raggiungere il core (considerate che la fibra è di tipo plastico quindi non ha lo strato di cladding) e a sparare qualsiasi cosa sia in grado di eludere il sistema ti fotte.
Ecco perchè il sistema deve lavorare sulla trasmissione anche di un solo byte scelto casualmente e compararlo con con quello ricevuto entro un certo margine di tempo (timeout) che debba però essere di poco superiore al tempo utilizzato nella catena per poterlo ricevere e con la certezza che sia lo stesso.
Spero di essere stato chiaro...

Ma non è meglio questo:
:grin:

zikako74:
Senza scomodare Heisenberg come ha ben capito Guglielmo (gpb01) il sistema funziona proprio a livello fisico, infatti, la fibra è utilizzata come un cordone agganciato agli oggetti da proteggere e chiuso il loop, se viene manomesso ad esempio con il taglio il sistema deve avvisarmi.
...

zikako74, contattami in privato, sono tutte problematiche che all'epoca avevamo già affrontato (... il lavoro è stato fatto per conto di un grosso ente governativo internazionale) ...
... e anche noi usavamo una mono-fibra in plastica :wink:

Puoi scrivermi qui : guglielmo.braguglia (at) phoenixsea.ch

Guglielmo