Progetto Anti Smarrimento: brainstorming sugli schemi elettrici dei dispositivi

Presentazione dello schema elettrico dei dispositivi Master e Slave ideato per la prima release (beta) del progetto Anti Smarrimento. Seguono alcuni consigli per coloro che disegneranno il layout dei PCB ed infine una breve descrizione degli strumenti firmware indicati per l’hardware scelto.

Introduzione

Il lavoro presentato di seguito descrive una prima versione di test delle schede Master e Slave nel progetto Anti Smarrimento. Tale fase di produzione ci consente di implementare i risultati ottenuti con CPUStick su delle breakout boards che montano gli stessi componenti scelti per il prodotto finale, prima di passare a lavorare sulle schede miniaturizzate vere e proprie.

Nel pacchetto di file che ho allegato troverete:

  • Schema elettrico;
  • Layout dei PCB;
  • Lista dei materiali (BoM);

ognuno dei quali è stato prodotto con il software Eagle PCB Layout 6.3.0 .

Riguardo gli ultimi due elementi, comunque allegati ma fittizi, essi NON vanno presi in considerazione dal momento che Signolo ha espresso il desiderio di poter realizzare il layout delle schede. Li ho lasciati lo stesso tra i file nel pacchetto, nel caso si utilizzasse lo stesso software e si volesse continuare a lavorare direttamente su di essi.

 

NOTA A SEGUITO DELL’ARTICOLO “ CPUStick: testing per il progetto di antismarrimento: più avanti inviterò il/i disegnatore/i del layout delle board ad inserire dei test point nel PCB. Non ne avevo previsti di specifici, ma leggendo l’articolo scritto da Zohan85 penso che una coppia che non dovrebbe mancare è quella relativa ai rilevamenti amperometrici per il consumo di corrente.

 

Schema elettrico scheda SLAVE

La Figura 1 mostra lo schema elettrico ideato per il dispositivo SLAVE:

 

Figura 1 – Schema elettrico della scheda Slave

 

Potete notare come questo schema sia l'essenza della semplicità: alimentazione, transceiver, antenna, un paio di LED e qualche componente passivo.

Infatti, essendo quasi banale l’azione di tale dispositivo (inviare ogni tot secondi un segno di vita alla scheda master e poco più), il relativo PCB deve essere essenziale e consumare poca energia.

Vediamone i dettagli.

Tutto ruota intorno al transceiver CC2530 della Texas Instruments ( http://www.ti.com/product/cc2530 ) ,  siglato “U1” nello schema, che ricordo essere un SoC in formato QFN a 40 piedini con a bordo un microcontrollore 8051 ed un modulo radio a 2.4 GHz integrati, il tutto progettato per essere conforme allo standard IEEE 802.15.4 (ZigBee) .

Nello schema, entrambi le sezioni “U$1P” ed “U$1S” si rifericono al CC2530: la U$1P mostra le connessioni ai pin di alimentazione del chip, mentre la U$1S mostra quelle relative ai segnali.

 

     Figura 2 – Sezione “Power” del CC2530

 

 

         Figura 3 – Sezione  “Signal” del CC2530

 

Riguardo la prima, il datasheet del transceiver non riporta particolari accorgimenti circa la sua connessione alla linea principale di alimentazione (come potete vedere in Figura 4 a pagina seguente), mentre una serie di app-notes della Texas che ho letto suggeriscono tutte di stabilizzare bene ogni singola linea “xVDD” (sia analogica che digitale) del chip, presumo per le onerose operazioni di utilizzo del modulo radio. Nello schema ho pertanto inserito una serie di singoli condensatori sui vari pin di alimentazione del transceiver: suggerisco al/ai realizzatore/i del PCB di disegnare sia un master che li preveda, sia uno che preveda un unico condensatore, così da capire se ci servono davvero tutti o se potremo recuperare spazio usandone di meno.

 

Figura 4 – Schema tipico di un circuito basato su CC2530 (proposto da T.I.)

 

Passando invece ai segnali, lo schema prevede quattro macro aree:

  •  stadio oscillatore a 32 MHz (più uno aggiuntivo –opzionale– a 32 KHz), quarzo siglato “Q1” con due condensatori da 22 pF ;
  • due led di stato, il primo (LED1 STATUS, pin 19) che pulsa all'invio del messaggio alla scheda Master, il secondo (LED2 BATTERY, pin 18) che segnala quando la batteria è scarica;
  • l'antenna da 50 ohm con balun specifico per il CC2530  (il chip 2450BM15A della Johanson Technology, siglato “F1” nello schema, vedi app-note: http://www.johansontechnology.com/ko/technical-notes/integrated-passives-rf-comp/2450bm15a0002-appnote.html  ), pin 25 e 26;
  • la connessione al debugger HW (pin 20, 34 e 35), necessario alla programmazione ed al debug in-circuit del firmware che caricheremo sopra al CC2530. Nota: come già accennato sul blog, sulla User’s Guide del transceiver ( http://www.ti.com/litv/pdf/swru191c ) ho letto che è anche possibile caricare un nuovo firmware sul transceiver inviandolo via radio. Al momento questa feature non ci serve, ma quando si passerà alle schede in miniatura ci tornerà utile visto che il connettore di debug potrà essere tolto dal PCB;

Inoltre è presente una connessione ad RBIAS (pin 30) che il datasheet del transceiver descrive come “External precision bias resistor for reference current” (pag. 18): sinceramente non se sia necessaria al nostro scopo, ma sul Forum della Texas Instruments ho seguito un lungo thread in cui un tizio non è riuscito a far funzionare un PCB praticamente uguale al nostro finchè un’anima pia non gli ha suggerito tale connessione: sapete com’è, nel dubbio……….
Nella fase attuale del progetto, questi mi sono sembrati gli aspetti principali su cui basare lo schema elettrico. Graditi commenti e proposte, ma tenete sempre a mente che per gli scopi futuri:

più funzionalità -> più energia -> batteria più grande -> PCB più grande

 

Schema elettrico scheda MASTER

A livello hardware, è praticamente uguale alla scheda Slave con l'aggiunta di un pulsante di accensione e di un buzzer da 3V DC che avverte del mancato rilevamento di uno Slave . Ecco come si presenta:

 

Figura 5 – Schema elettrico della scheda MASTER

 

Il pulsante (o, meglio, l'interruttore) di accensione ha senso sul Master piuttosto che sugli Slave per il semplice fatto che sul primo ho un controllo diretto e sempre disponibile, quindi lo tengo acceso o spento in base alle esigenze del momento, mentre i secondi devono essere sempre accesi poiché se me li perdo almeno ho modo di accorgermene tramite il Master (sennò tutto il senso del progetto Anti Smarrimento si va a far benedire….. 🙂 )

In questa release beta del progetto, tale schema scarno e poco “ortodosso” può andar bene per le nostre prove preliminari (vedi ad esempio il mancato ricorso ad un mini relè per far arrivare al buzzer una tensione piena); invito comunque la crew a cominciare ad interrogarsi sulle funzionalità che vorrebbe vedere implementate sulla scheda Master in futuro, così da capire che tipo di dispositivo occorre progettare.

Alcune possibili domande:

  • Il master deve avvertire dello smarrimento di uno qualunque degli Slave (sufficiente il buzzer?) o di quale specifico Slave si è perso (serie di led, schermo LCD?) ?
  • I dispositivi Slave da associare al Master come vanno configurati ? Procedura da pc (connettore USB a bordo scheda)? Procedura dalla scheda stessa (a bordo scheda)?
  • Quanto grande deve essere il dispositivo Master ? Va portato con sè (interazioni tramite touchscreen) ? Va indossato (interazioni minimali tramite pulsanti) ?

 

Consigli sul layout dei PCB

Come già detto, i file di layout dei componenti e la lista dei relativi materiali (BoM) allegati sono fittizi e lasciati solo ed esclusivamente ai disegnatori del PCB come iniziale riferimento.

Libero sfogo alla loro creatività personale, ma permettetemi comunque di dirvi la mia in merito ai seguenti punti:

  • Componentistica: in questa fase sperimentale, ricercare già la miniaturizzazione serve solo a complicarci la vita. Vedrei più utile lavorare comodamente per comprendere bene l'elettronica con cui abbiamo a che fare, l'ottimizzazione poi verrà da sé. Suggerisco di evitare ove possibile componenti SMD microscopici, di dare adeguato spazio tra le varie piste e magari di prevedere dei test-point sui PCB per evitarci di dover mettere i probes dell’oscilloscopio in punti improponibili durante le prove;
  • Application-notes: come in informatica si invita spesso a riutilizzare il codice già scritto, in elettronica vi invito a non disdegnare i progetti (schemi, layout, gerber file etc.) che i vendor di componenti rendono disponibili attraverso app-notes. Un esempio lampante è il link al balun della Johanson Technology che avete incontrato all’inizio di pag 7: oltre a descrivere il suo chip (utile per non farci l’adattamento di impedenza a mano…), la casa produttrice presenta dettagliatamente il progetto di una evaluation board che impiega praticamente tutto ciò che serve a noi , dallo schema elettrico ai dettagliati layer che compongono il PCB finale. È un modo utile per non partire da zero!
  • Antenna: visto che al momento le dimensioni del PCB non hanno grande rilevanza, l’antenna potrebbe anche essere stampata direttamente sulla board. Di seguito il link ad un Design Note della Texas in merito alla stampa di antenne direttamente su scheda ( http://www.ti.com/litv/pdf/swra351 )
  • Connettore di programmazione/debug: il programmatore HW che sto usando con il CC2530 è il “CCDEBUGGER” della Texas Instruments ( http://www.ti.com/tool/cc-debugger ), pratico ed economico, un po’ l’equivalente del PicKit per chi viene dal mondo dei microcontrollori MicroChip. Per questa release iniziale del progetto ho previsto nello schema un connettore per tale dispositivo, così da avere facile accesso al CC2530 quando vorremo modificare il nostro firmware. Se vi steste chiedendo perché non programmare le board da PC tramite un comune connettore USB piuttosto che uno strumento specifico, la risposta è che lavorare con l’USB è un gran casino, richiede conoscenze HW sul protocollo usato non indifferenti. Se però qualcuno tra voi si intende di comunicazione USB a livello HW, di sicuro ci tornerà utile nella fase 2.0 del progetto.  Il connettore a bordo del debugger presenta una doppia fila di pin MASCHIO a passo 2.54mm, ordinati secondo i riferimenti iniziali indicati. Di conseguenza, a bordo dei nostri PCB occorrerà montare una doppia fila di pin FEMMINA aventi lo stesso passo. Vi allego anche un’immagine dei segnali che devono arrivare sui vari pin (seguendo solo lo schema elettrico, tale informazione non si evince) :

            

 

Figura 6 – Segnali sul connettore del CCDEBUGGER

 

Strumenti FIRMWARE

Come già detto nei thread del progetto, da un’analisi sui prodotti offerti dal mercato la soluzione firmware che mi è sembrata più abbordabile è composta nel seguente modo:

  • Linguaggio di programmazione: C .  Ottimo controllo del flusso, non serve né scendere a livello di Assembly né salire verso la programmazione ad oggetti ;
  • Ambiente di sviluppo: IAR Embedded Workbench for 8051 . E'  l’ambiente che prevede il compilatore ed il debugger per il micro 8051 a bordo del nostro transceiver. Unico neo: non esiste una versione Lite ma solo la evaluation a 30 giorni, poi va acquistato (non ho ancora scoperto il prezzo, ma non credo di poter scegliere tra questo e l’IMU….  🙂 );
  • Stack ZigBee:  API BasicRF.  API BasicRF non è uno stack ZigBee come quello fornito ufficialmente da T.I. (lo Z-Stack) ma semplicemente un insieme di API che permettono l’impacchettamento di un messaggio in un formato IEEE 802.15.4 compliant. Questa scelta, valida solo per le prove in questa fase beta, è data dal fatto che tale strato firmware è molto più snello e semplice da usare rispetto ad uno stack completo, e dal momento che fornisce funzionalità per l’RSSI, un (semplice) meccanismo di crittografia per i messaggi ed altre cosette utili ad Anti Smarrimento, al momento potrebbe fare al caso nostro. Va comunque notato che T.I. disincentiva l’uso di tali API per prodotti commercializzabili, poiché di fatto non si tratterebbe di “veri” dispositivi ZigBee: se la cosa rappresenterà un problema, vedremo di impiegare lo Z-Stack, comunque disponibile, ed adeguare l’HW.

Nella fase successiva del progetto, appena disponibili le schede, comincerò a testare il firmware che ho scritto nelle mie prove di questo periodo su entrambi i dispositivi, Master e Slave

 

Conclusioni

Inizialmente l’idea era di scrivere un documento più corto, ma poi ho preferito “abundare quam deficere”… 🙂
Credo infatti che avere una serie di dettagli ("sudati"...) a disposizione possa far comodo a chi deve prendere in mano il testimone nella catena di lavoro.
Per il momento mi fermo qui, rinnovando comunque il mio invito alla partecipazione attiva da parte di tutta la crew (ogni tanto riprovo a mandare l'input che ci manca l'algoritmo per il calcolo della distanza... 🙂 ). La strada verso il prodotto finale è ancora lunga e ognuno può dare un contributo importante al progetto, anche se non ha in mano un saldatore!

Scarica subito una copia gratis

9 Commenti

  1. Avatar photo Piero Boccadoro 17 Dicembre 2012
  2. Avatar photo signolo 17 Dicembre 2012
  3. Avatar photo signolo 17 Dicembre 2012
  4. Avatar photo Emanuele 18 Dicembre 2012
  5. Avatar photo Emanuele 18 Dicembre 2012
  6. Avatar photo zohan85 18 Dicembre 2012
  7. Avatar photo delfino_curioso 21 Dicembre 2012
  8. Avatar photo Luigi Francesco Cerfeda 19 Maggio 2013
  9. Avatar photo delfino_curioso 19 Maggio 2013

Rispondi a signolo Annulla risposta

Seguici anche sul tuo Social Network preferito!

Send this to a friend