Un circuito di identificativo chiamante con sintesi vocale senza microcontrollori

Pubblicato il -
Questo articolo potrebbe contenere link di affiliazione, ovvero link a pagine in cui, se viene effettuato un'acquisto, potrebbero generare una commissione a settorezero ma comunque senza incidere sul costo finale dell'oggetto acquistato. E' un modo per non avere pubblicità invasiva (che, se non avete notato, abbiamo rimosso) e nel contempo garantire al sito di continuare ad esistere.

Tempo fa ho letto con interesse la pubblicazione di Stefano Purchiaroni che ringrazio fin da subito per il materiale messo a disposizione. Prendendo spunto dal suo circuito Filtro contro le telefonate anonime ho realizzato un circuito per identificare il chiamante senza utilizzare microcontrollori: ho pensato di collegare il decoder CLI (Caller Line Identification) MT88E39 direttamente al PC tramite un convertitore UART/USB.

Sul PC ho quindi realizzato un software scritto in C# tramite il quale faccio pronunciare il numero o il nome del chiamante sfruttando la classe speech messa a disposizione dal .NET Framework. E’ inoltre possibile respingere le chiamate da numero anonimo come nel progetto originale di Stefano.

Ricordiamo che, ad ogni modo, per riuscire a identificare il numero del chiamante è necessario avere il relativo servizio attivo sulla propria linea telefonica. Per chi utilizza l’operatore TIM/Telecom, il servizio si chiama “Chi è“. Per ulteriori informazioni sui servizi di identificazione chiamante fate riferimento al vostro operatore telefonico.

Descrizione del circuito

Il decoder CLI MT88E39 è disponibile unicamente in formato SOIC 1.27mm, per cui volendo realizzare il circuito su una millefori è stato necessario saldarlo su un adattatore: io ne avevo a disposizione uno da 20 pin ma è sufficiente uno da 16 pin oppure è possibile utilizzare protoboard per SMD che abbiano l’area per IC soic delle dimensioni adatte. Per tutte le informazioni relative alla funzionalità del decoder CLI vi rimando all’articolo di Stefano.

Anche nel mio circuito il decoder funziona in MODO 0 (pin 14 a GND) cioè come Master e, appena decodifica i byte CLI, li invia sulla linea DATA (pin 10) alla velocità di 1200 bit/sec. Il modulo FT232RL viene configurato dal software per operare proprio a questo baudrate, inoltre la sua uscita DTR (pin2 del modulo) controlla l’ingresso di Power Down (pin 13) del decoder. Con questa configurazione il PC resta in attesa del primo squillo, successivamente abilita il decoder CLI ponendo a livello logico basso l’uscita DTR e si mette in ascolto dei byte in arrivo dal decoder.

Al secondo squillo torna a disabilitare il decoder ed interpreta i dati ricevuti. Il rivelatore di squillo telefonico deve filtrare i disturbi sulla linea e riconoscere solo il treno di sinusoidi costituenti lo squillo telefonico. Lo squillo è costituito, in Italia, dalla sovrapposizione alla tensione di linea di un treno di 25 sinusoidi con periodo di 40mSec (25Hz) di ampiezza pari a 80Veff (226Vpp). La durata dello squillo risulta essere di 1 secondo.

Questi sono i valori che ho misurato personalmente sulla mia linea di casa.

Per evitare inconvenienti dovuti a impulsi spuri ho aggiunto un filtro + trigger di Schmitt al rivelatore di squillo. Si sarebbe potuto usare un 74HC14 ma, per risparmiare spazio, e per giocare un po’ con il simulatore SPICE l’ho realizzato con due mosfet BS170.

Il filtro si è reso necessario per evitare false rilevazioni dello squillo, in particolare quando si solleva o si chiude la cornetta sulla linea telefonica è presente un gradino di tensione di 37V – 10V (circa 27V). Questi step di tensione attraversano il condensatore presente prima del fotodarlington H11G2 e producono un impulso spurio di 6-8mSec come si vede nella foto sottostante:

Il diodo zener evita che durante l’impegno della linea (Off-Hook) il segnale elettrico sulla linea raggiunga il rivelatore. Il condensatore C3 si carica durante la semionda positiva tramite la resistenza R10 mentre si scarica durante quella negativa tramite la serie R10-R12.

La tensione del condensatore C3 viene poi monitorata dal trigger di Schmitt realizzato con due mosfet BS170. Con i valori scelti di R16 e R17 le soglie del trigger sono all’incirca di 2.5V per quella alta e 1.3V per quella bassa. Il condensatore C6 da 220pF porta lo Slew Rate del circuito di trigger a circa 250V/mSec.

Questo è quello che si può misurare con l’oscilloscopio, la carica del condensatore e l’ingresso della linea CTS del modulo FT232RL:

Il filtro genera un ritardo quantificabile in 250mSec all’inizio e di 200mSec in coda allo squillo.

Simulazione SPICE

Mi sono divertito a simulare il circuito suddetto usando lo SPICE, riporto di seguito lo schema:

Nella simulazione, Il fotoaccoppiatore è rappresentato dal transistor Q1 alimentato dai due generatori di tensione V1 e V2 i quali, combinati insieme, riproducono i 25 impulsi di onda quadra presenti all’uscita del fotodarlington quando arriva lo squillo. Il generatore V4 si è reso necessario per tener conto della Vce del darlington del foto accoppiatore.

Di seguito il plot della simulazione con lo SPICE:

Nel grafico sono indicati:

  • In verde la tensione nel punto (In)
  • In Viola la tensione nel punto (A_Out)
  • In Blu la tensione nel punto (B_Out)

Questa invece è l’immagine reale ottenuta sull’oscilloscopio:

Se volete provare a simulare il circuito, al paragrafo Downloads potete scaricare la netlist che ho usato.

Alimentazione

Dato l’esiguo assobimento non ho previsto una sorgente di alimentazione separata: il circuito viene alimentato direttamente dalla porta USB tramite il modulo FT232RL, per questo motivo il ponticello del modulo deve essere posizionato su 5V per fornire appunto tale tensione in uscita.

Interfaccia UART-USB

Il modulo interfaccia che usato è un modulo economico acquistato da BangGood che monta un FT232RL clone di quello originale della FTDI.

A differenza dei moduli originali FTDI, più costosi, l’integrato clone FT232RL che vi è montato sopra non ha al suo interno la EEprom per la personalizzazione. Ciò significa che se vengono usati più moduli dello stesso tipo sullo stesso PC il software di gestione non può distinguere un modulo dall’altro; è però possibile usare due o più moduli senza EEprom distinguendoli in base alla porta USB in cui vengono inseriti (vedi Sorgente del software CLI_GUI). Nel caso vengano usati i moduli FTDI con integrato FT232RL originale e quindi costruito con la EEprom interna si può usare l’utility MProg fornita dalla FTDI per personalizzarli.

Collegando il modulo FTDI232RL windows dovrebbe installare correttamente il convertitore USB-UART cercando i driver in rete. Qualora questo non accada potete installare manualmente i driver recuperandoli dal sito ufficiale della FTDI.

Sono disponibili due tipi di driver: Virtual COM Port (VCP) e il driver direct (D2XX). I driver VCP emulano la porta standar seriale del PC RS232 mentre i driver D2XX permettono l’accesso diretto al FT232RL tramite interfaccia dll.

Il mio software lavora con i driver D2XX perché accede al modulo FT tramite l’interfaccia dll (FTD2XX_NET.dll) è quindi sufficiente installare questi ultimi anche se in automatico windows li installa entrambi.

Realizzazione

Tutto il circuito l’ho provato prima su una breadboard:

Successivamente ho eseguito lo sbroglio della basetta usando un software CAD anche se alla fine ho realizzato tutto con basetta millefori, questo mi ha permesso di ottimizzare i collegamenti e rendere la realizzazione, anche se su bassetta millefori, molto compatta ed “elegante”:

Caratteristiche interfaccia Telecom

A titolo informativo riporto le caratteristiche principali della linea telefonica definite dall’ETSI (European Telecommunications Standard Institute) estratte dal documento ETSI ES 201 970 V1.1.1 (2002-08):

  1. Intervallo di corrente del loop: quando un resistore con un valore compreso tra 0Ω e 500Ω è collegato tra i fili A e B (Tip-Ring) sull’NTP, deve scorrere una corrente CC di loop minima di 18 mA e che non deve superare 70 mA. Si raccomanda che la corrente cc di loop sia nell’intervallo da 25 mA a 40 mA.
    NOTA 1: 18 mA è la corrente minima richiesta per soddisfare i requisiti di accesso TE.
    NOTA 2: la corrente minima tiene conto della lunghezza del cavo e delle resistenze interne sia di centrale che di apparato utente.
  2. Interruzioni di corrente loop causate dal terminale: brevi interruzioni di corrente del circuito (dove la corrente diventa inferiore a 1,0 mA) fino a 20 ms non devono causare alcun cambiamento di condizione all’NTP.
  3. Una corrente di loop non superiore a 3,0mA, non deve essere riconosciuta dalla rete come un segnale di impegno di linea.
  4. La rete non deve riconoscere una condizione di impegno di linea quando la corrente del loop passa dallo stato di riposo allo stato del loop impegnato per un periodo inferiore a un valore dichiarato dall’operatore. Questo valore non deve essere inferiore a 10 ms.
  5. La rete deve riconoscere una condizione di impegno di linea quando la corrente di loop è superiore a 10mA per un periodo di tempo dichiarato dall’operatore ai fili A e B dell’NTP e comunque non superiore a 150ms

Quando si ascolta il segnale CLI l’interfaccia NTP dovrebbe essere chiusa su 600Ω come indicato:

Nelle note applicative dell’  MT8841 (altro circuito integrato per l’identificazione numero chiamante che però non è usabile in europa a causa del diverso standard) è anche presente uno schema in cui un relè chiude l’interfaccia NTP su 600Ω durante la trasmissione del CLI ma, nel caso della mia linea telefonica, non è stato necessario implementare anche questa ulteriore specifica. A titolo di completezza è possibile scaricare questa nota applicativa al paragrafo downloads.

Descrizione del Software

Per realizzare il software lato PC ho utilizzato Visual Studio Community 2017 scrivendo un programma in C#. Nel paragrafo Downloads potete scaricare sorgente e binario (già compilato) della versione 1.0 per poterla personalizzare e adattare alle vostre esigenze. Il programma utilizza l’interfaccia utente (GUI) e la sintesi vocale per annunciare la chiamata in arrivo.

Per funzionare, il software deve avere questi tre file nella stessa directory:

  • cli_gui.exe : eseguibile in CLR (ha bisogno del supporto .Net FrameWork)
  • FTD2XX_NET.dll : librerie wrappate in .Net per la gestione del FTDI
  • Rubrica.txt : File testo contenete la rubrica telefonica da personalizzare

Il file rubrica.txt è un file di testo piatto dove vanno inseriti nome e numero di telefono che potete realizzare con il blocco note o applicazione simile. Se il numero non è presente nel file il software annuncia la chiamata in arrivo pronunciando per intero il numero telefonico.

Il file rubrica.txt va scritto utilizzando questa semplice sintassi:

Pippo,3355635466
Pluto,3382442567
Paperino,065879766

Non devono esserci spazi, nome e numero sono separati semplicemente da una virgola. Ogni nominativo viene separato da un ritorno a capo. Va inserito un ritorno a capo anche dopo l’ultima riga.

Il software non esegue controlli sulla formattazione del file quindi occorre attenersi scrupolosamente a queste indicazioni.

Il main del programma instanzia un Form, al caricamento del medesimo vengono istanziate: la voce e l’oggetto FTDI che successivamente viene aperto mediante la sua descrizione. Nel mio caso la descrizione non è modificabile e corrisponde alla stringa “FT232R USB UART”.

Viene quindi avviato un thread separato che rimane in attesa dell’arrivo dello squillo telefonico. Al suo arrivo il thread si predispone in attesa dell’arrivo dei dati dalla seriale. I dati a 1200 baud vengono interpretati secondo il protocollo CLI e il risultato viene passato al thread principale tramite un delegate.

Il thread ritorna in attesa dei successivi squilli contandone il loro numero. Fin dal primo squillo viene attivato un timer da 7 secondi che viene rilanciato ad ogni squillo. Allo scadere del timer si considera conclusa la chiamata, viene visualizzato il numero di squilli e il thread secondario ritorna in attesa del primo squillo della successiva chiamata.

Il thread principale, che gestisce l’interfaccia utente, controlla se il numero ricevuto è presente nel dizionario interno. Il dizionario viene inizializzato leggendo il file testo “rubrica.txt” che, come dicevo, deve essere presente nello stesso percorso dell’applicazione.

A questo punto, in base alle informazioni ricevute dall’interfaccia CLI il software annuncia la chiamata in arrivo.

Installare la voce Italiana

Il software utilizza il dispositivo audio di default del PC, e pronuncia il nome del chiamante se questo è presente nella rubrica oppure pronuncia direttamente il numero telefonico se il nome non è presente, come detto in precedenza. Nel caso di chiamata da parte di numero anonimo (#31#) il software annuncia l’arrivo di una chiamata anonima e se non viene risposto entro il quarto squillo la chiamata viene respinta.

Per poter ascoltare gli annunci nella lingua italiana occorre che sul PC sia installata una voce Italiana e che sia stata impostata come voce di default del sistema.

Windows10 in Italiano ha tutto questo già impostato, per i sistemi con Windows XP e Windows 7 occorre installarla. Al paragrafo Downloads potete scaricare la voce “Silvia”: per installarla basta lanciare l’eseguibile.

Occorre poi selezionare Silvia come voce di default per il sistema: andare su Pannello di Controllo – riconoscimento vocale – Sintesi Vocale e selezionare la voce italiana precedentemente installata come da immagine:

Ci sono purtroppo alcuni problemi per far funzionare questa voce sui sistemi operativi a 64bit: dopo aver proceduto ad installare la voce “Silvia” occorre modificare il Registro di windows modificando il path “Voice Data” coerentemente con quello installato nel vostro sistema. Bisogna creare un file di testo inserendo le seguenti stringhe:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Speech\Voices\Tokens\ScanSoftSilvia_Dri40_16kHz]
"LangCode"="ITI"
"Language"="Italian"
"Frequency"="16"
"Encoding"="112mrf16"
"Reduction"="DRI40"
"VoiceName"="Silvia"
"VoiceData"="C:\\Program Files\\ScanSoft\\RealSpeakSolov4\\speech\\components\\data\\Silvia.dat"
"CLSID"="{CAC6785B-655E-4ae1-A656-BDEFD18DC46C}"
"410"="ScanSoft Silvia_Dri40_16kHz"
@="ScanSoft Silvia_Dri40_16kHz"
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Speech\Voices\Tokens\ScanSoftSilvia_Dri40_16kHz\attributes]
"Gender"="Female"
"Vendor"="ScanSoft, Inc"
"Name"="ScanSoft Silvia_Dri40_16kHz"
"Language"="410"

Il file va salvato come “Add_Silvia.reg” e lanciato. Successivamente occorre selezionare la voce di default per il sistema lanciando:

C:\Windows\SysWOW64\Speech\SpeechUX\sapi.cpl

…e selezionando “Silvia”. Non è detto comunque che la procedura vada sempre a buon fine. Al paragrafo Downloads potete scaricare il file di registro già pronto con le istruzioni che avete appena letto.

Se ancora questa seconda procedura non dovesse andare a buon fine, scaricare la voce eSpeak italiana per Windows 7 a 64 bit dal sito ufficiale e settarla come voce predefinita di sistema. In alternativa esiste anche la voce di Lucia scaricabile dal sito Microsoft: le istruzioni sono qui.

Ad ogni modo tutti questi work-around sono riportati in un file, nel paragrafo Downloads, insieme al file di registro già pronto.

Downloads

Se questo articolo ti è piaciuto, condividilo su un social:
      
Se l'articolo ti è piaciuto o ti è stato utile, potresti dedicare un minuto a leggere questa pagina, dove ho elencato alcune cose che potrebbero farmi contento? Grazie :)