Newsgroup: it.hobby.elettronica.digitale
Titolo: Livelli CMOS TTL - GM862

Ciao a tutti,
devo interfacciare un PIC18f458 con un modulo gsm GM862GPRS utilizzando
l'interfaccia seriale a bordo pic.
Il pic è alimentato a 5V, il datasheet riporta che il modulo GSM deve
essere alimentato a 3.8V (range 3.4-4.2V, max 1.9A impulsivo) e i pin
di comunicazione accettano segnali a livello CMOS 2.8V (max 3,75V,
quindi inferiore alla tensione di alimentazione).
Sul datasheet del GM862, fanno riferimento come regolatore di tensione
a un LT1528CQ mentre per la conversione 5V-2.8V della seriale
utilizzano dei BCR22PN.
Entrambi questi componenti mi risultano di difficoltosa reperibilità.
Qualcuno ha avuto modo di utilizzare questo modulo gsm oppure mi sa
dare indicazioni su componenti alternativi (meglio se non smd) ?
Grazie.

 dare indicazioni su componenti alternativi (meglio se non smd) ?
Credo che una scelta adeguata dei componenti debba essere fatta tenendo
conto delle esigenze che hai. Devi alimentarlo a batteria? Devi
realizzarlo in serie, oppure è un dispositivo unico?
Suppongo nel seguito che si tratti di un progetto fatto per hobby,
senza troppe pretese in termini di alimentazione.
Credo che per alimentare il modulo tu possa realizzare un piccolo
riduttore lineare. Una soluzione "quick and dirty" potrebbe essere
partire dai 5V dell'alimentazione e ridurla a 3,8V usando un paio di
diodi raddrizzatori al silicio. Fai attenzione che l'esatta tensione
non è regolata e dipende un po' dalla temperatura, ma il modulo è di
bocca buona ed accetta variazioni abbastanza vaste, vedo. Se hai a
disposizione una tensione più elevata di 5V da qualche parte, puoi
provare a vedere se si puo' adattare un LM317 o similare, in una
versione che accetti le correnti richieste. Partendo da 5V il dropout
è un po' troppo piccolo per una situazione del genere. Esistono
comunque regolatori a basso dropout, cerca qualcosa del tipo 'low
dropout regulator'. Credo pero' che la soluzione con due diodi sia
abbastanza semplice e si adatti bene alla situazione.
Attento a filtrare bene l'alimentazione del modulino, altrimenti ti
ritroverai l'oscillatore del PIC perturbato dai picchi di corrente del
modulo.
Per quanto riguarda l'adattamento dei livelli, puoi utilizzare un
driver a collettore aperto, oppure configurare i pin di comunicazione
del PIC (se puoi, ovviamente) di modo da essere a collettore aperto e
poi utilizzare delle resistenze di pull up rispetto alla tensione
corrispondente al livello alto richiesto dalla tua logica. Il valore
delle resistenze è un compromesso tra la velocità richiesta, la
massima corrente che puo' entrare nei piedini dell'integrato che usi e
il consumo. Non credo che tu abbia esigenze di velocità eccessive;
puoi puntare a valori intorno ad uno o due kOhm, oppure anche di più.

 puoi puntare a valori intorno ad uno o due kOhm, oppure anche di più.
La velocità richiesta dall'applicazione è 19K2 e i pin della seriale
non sono configurabili come oc.
Adottare un level-translator componenti discreti per tutti i 7 segnali
utilizzati, mi costringe ad utilizzare 7npn + 7pnp + 35 resistenze
esterne.
Il componente proposto nel datasheet contiene per l'appunti una coppia
npn+pnp+relative resistenze di polarizzazione.
Il problema è che è smd e che non riesco a reperirlo.
Mi servirebbe un level-translator multicanale e doppia alimentazione
(5/3V) di facile reperibilità.
Nessuno nel gruppo ha avuto modo di utilizzare questo GSM fono ad ora ?

 utilizzano dei BCR22PN.
Mi ricordo di aver visto uno schema elettrico della Telit di una loro
evaluation board. Lì la traslazione dei livelli veniva fatta con un
semplice buffer 244 (non ricordo la famiglia precisa), penso facilmente
reperibile.
Dovrebbe essere alimentato alla stessa alimentazione del modulo GSM (3.8V)
ma dovrebbe distinguere correttamente i livelli CMOS 5V in ingresso (ingressi
5V tolleranti). In uscita sono compatibili con la logica 3.8V.
Ma sei sicuro che ti servono i 7 segnali della seriale? Li usi tutti con
il tuo PIC? Mi sembra strano...

utilizzano dei BCR22PN.
Per l'alimentazione ho usato sia il classico LM317 che pero' scaldava un po, 
che un integrato Switching della National per la precisione si tratta del 
LM2575T ADJ entrambi sono in normale contenitore quindi facili da saldare 
quest' ultimo non dava ilproblema del eccessivo surriscaldamento, comunque 
dipende dalla applicazione che stai sviluppando se si tratta di qualcosa che 
comunica poco con la rete LM317 va benone.
Puoi dirmi dove li compri ed il prezzo magari se non vuoi fare pubblicita' 
mi puoi contattare in privato. 

 LM2575T ADJ
ho fatto un errore l'integrato e' LM2596T ADJ 

Grazie a tutti per le risposte,
penso di avere trovato una buona soluzione, sto facendo alcuni test e
mi sembra che sia tutto ok.
Per la parte di alimentazione utilizzo un LM1085IT-ADJ configurato per
i 3,8V, mentre per la conversione dei livelli (visto che il micro deve
essere per forza alimentato a 5V e che i livelli sella deriale devono
essere a 3V) utilizzo due 74LCV4T45 alimentati a 5V e 3V ( i 3V li
ricavo dai 3.8V).
Riesco a comunicare a 56k e 115k senza problemi.
Anche se i pin collegati potrebbero essere solo 3 (tx,rx,gnd,a parte
power on e reset), l'applicazione richiede tutti i pin per la massima
affidabilità, per es. quando ci si collega in gprs e si scambiano
grossi volumi di dati o quando si richiede un aggiormaneto del
firmware).
Il problema maggiore sarà quello di saldare a mano i connettori del
gsm per i primi prototipi (essendo solo 4 i componenti smd, la lastra
di serigrafia pasta la farò quando sarò sicuro di tutto).
Per ora ne ho saldati un paio e sembra tutto ok, ma serve la mano molto
ferma ;-)
Ciao, Roberto

firmware).
Attenzione allora stai usando il gm862 per fare cose complesse, questo 
modulo ha parecchi bug se cerchi nel newsgroup probabilmente troverai 
qualche messaggio a riguardo


Ad ora non no trovato particolari problemi, a parte la saldatura del
connettorino a 50 pin smd fatta a mano.
Cercando su ihed non trovo niente che riconduca a problemi di
funzionamento.
Riesco a trovare modulo+connettore a meno di 70euro e mi sembra buono
considerando che ha il lettore sim integrato, prima utilizzavo i moduli
siemens ma costano quasi il doppio.
Hai esperienza particolare in merito ?
Ti sarei grato se mi mettessi al corrente dei problemi che hai
incontrato.
Ciao, Roberto

incontrato.
Se per te non e' un problema potresti dirmi dove li compri?
ti riporto il messaggio a cui mi riferivo scritto se non ricordo male dall'
utente Orlando:
Lascia perdere quei moduli... ho perso un mese a cercare dei workaround a
tutti i bachi che hanno nella comunicazione seriale e purtroppo ho fallito.
Alcuni bachi sono talmente grossi che non possono essere aggirati.
La loro risposta è stata... "Ehm... sì, in effetti quei problemi ci sono, ma
il firmware non lo correggiamo", tradotto liberamente in "Attaccatevi al
tram".
Quali sono i bachi?
C'è una race condition tra l'acquisizione dell'"attenzione" del modulo e
l'invio di "unsolicited response codes". In pratica, per avere delle
risposte non ambigue la prassi è che tu mandi il tuo comando "AT+CPIPPO" il
modulo risponde con l'eco di AT+CPIPPO e con la risposta (mettiamo "OK").
Tra l'invio del carattere "A" dell'eco e OK<cr><lf> non deve essere
inserito nient'altro. Invece, c'è una finestra temporale dopo l'invio
dell'eco nel quale il modulo ci infila un URC o qualche carattere corrotto.
Il RING/+CRING è ancora più subdolo perché non viene proprio effettuato
locking, se stai digitando un comando e arriva un RING, il buffer del
comando viene svuotato e tu perdi quello che stavi mandando, quindi non ti
arriverà mai l'OK e se il comando è uno di quelli con 180 secondi di
timeout non hai neppure modo di capire cosa è successo prima di tre minuti.
Ah... nonostante quanto dichiarato nella documentazione, XON e XOFF
semplicemente non funzionano :)
Ti segnalo anche che in diverse occasioni i moduli si sono bellamente
piantati, talvolta rispondendo con l'eco, talvolta senza.
Ah, dimenticavo, le chiamate outbound sono sempre in stato Alerting (con
AT+CLCC), anche se il telefono remoto non esiste, è spento, etc..
Uh... ce n'è un'altra... dopo l'hangup di una chiamata il modulo risponde di
essere deregistrato (con AT+CREG) anche se non è vero.
Dimentichiamoci pure delle stranezze con AT+IPR...
...e che manca il timeout di 30 secondi per l'inserimento dei comandi...
...e che mancano tutte le notifiche con +CIEV...
...e che non supportano l'acknowledge degli SMS Phase2+...
...e che non supportano il multiplexing con AT+CMUX...
...e che non puoi disattivare il sidetone sull'ingresso audio handset....
...e che non hanno l'audio digitale...
...e che l'ingresso handset ha forzatamente un guadagno mostruoso e si tira
dentro tutto il rumore immaginabile...
...e questi sono solo i più gravi...


...
Molto strano, io non ho trovato i problemi elencati.
Mi sorge il dubbio che magari i caratteri 'anomali' fossero dovuti a
disturbi dovuti ad una non efficiente schermatura della parte logica
dalla rf.
Chi mi ha commissionato il lavoro mi ha indirizzato verso questi moduli
perchè già utilizzati con successo in altre applicazioni.
C'è poi da dire che del GM862 esiste la versione gprs (in phase-out),
modem, phyton...
Forse era una particolarità del modulo o dell'applicazione (mi sembra
di avere intuito fosse un gateway voip/sms-gsm).
Per non fare pubblicità ti ho mandato un msg in pvt con il fornitore.
Ciao, Roberto

Per non fare pubblicità ti ho mandato un msg in pvt con il fornitore.
Non mi e' arrivato nulla, hai tolto nospamsepossibile dalla mia email?
Una curiosita' con che tipo di linguaggio stai facendo il firmware per il 
Pic? per la mia applicazione ho usato qualche riga di Pic Basic Pro della 
Melabs.

 Melabs.
In parte assembler, in parte CCS.