Archivi categoria: i miei allievi

Quick References per lo studio – Preparare un’esposizione orale

Una buona esposizione orale nasce prima di parlare: dalla struttura chiara, da esempi concreti, da transizioni semplici e da un tempo rispettato. L’obiettivo non è “dire tutto”, ma guidare l’ascoltatore: dichiarare dove stai andando, mostrare perché fidarsi (dati, definizioni, ragionamenti) e chiudere con ciò che vuoi che resti.

Per questo conviene usare una struttura guida: apertura breve che aggancia e definisce il perché (tesi/obiettivo), tre idee chiave sviluppate con esempi/definizioni/prove, una chiusura che sintetizza e collega a un’azione o domanda finale. Se c’è tempo per le domande, preparane alcune probabili e risposte essenziali.

Prima di esporre:

  • Scrivi un outline (schema) e non un copione; usa cue card (scheda promemoria) con parole-chiave.
  • Prova con un timer (2–3 volte), segna dove inciampi e accorcia.
  • Prepara definizioni precise, un esempio numerico (se serve), una figura/schema semplice.
  • Organizzi transizioni (“Ora passiamo a…”, “Questo ci porta a…”).

Durante:

  • Parla chiaro e piano; frasi brevi; verbi attivi.
  • Guarda l’aula o i docenti (dipende dal contesto), pausa dopo concetti importanti.
  • Se usi slide, ricordati: 1 idea per slide, titoli informativi, caratteri leggibili.

Errori tipici da evitare:

  • Riassumere il libro senza una tesi o un perché.
  • Correre sul tempo o superarlo (allenati con timer).
  • Esempi vaghi, definizioni imprecise, transizioni assenti.
  • Leggere tutto a voce o riempire le slide di testo.

Scarica PDF A4 della guida operativaApri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "Esposizione orale – "
autore: ""
durata_target: "<3–5 min / 7–10 min>"
contesto: ""
versione: "1.0"
ultimo_aggiornamento: ""
---

## 0) Obiettivo & messaggio centrale
- Obiettivo: 
- Messaggio centrale (tesi): 

## 1) Apertura (30–45″)
- Gancio iniziale (domanda/curiosità/dato breve):
- Contesto in 1–2 frasi:
- Tesi/Obiettivo dichiarati:

## 2) Idea chiave #1 (≈ 1–2 min)
- Sottotitolo informativo:
- Definizione/dato essenziale:
- Esempio (concreto, breve; numerico se utile):
- Transizione verso l’idea #2:

## 3) Idea chiave #2 (≈ 1–2 min)
- Sottotitolo informativo:
- Evidenza (esperimento/argomento/immagine):
- Esempio / controesempio:
- Transizione verso l’idea #3:

## 4) Idea chiave #3 (≈ 1–2 min)
- Sottotitolo informativo:
- Collegamento con #1/#2 (perché ha senso insieme):
- Applicazione pratica / implicazione:
- Transizione verso chiusura:

## 5) Chiusura (15–30″)
- Riepilogo in 1 frase (torna alla tesi):
- Messaggio finale / domanda guida:
- (se richiesto) Call to action / cosa fare dopo:

## 6) Q&A — domande probabili (prepara risposte brevi)
- D1:
- D2:
- D3:

## 7) Supporti (facoltativi)
- Slide/immagine/schema n. 1: 
- Oggetto/esperimento: 
- Link/QR a risorse: 

## 8) Prova con timer (log)
- Prova #1:  — note:
- Prova #2:  — tagli/aggiunte:
- Prova #3:  — ok per esposizione

## 9) Checklist rapida
- [ ] Messaggio centrale chiaro
- [ ] 3 idee chiave ben separate
- [ ] Esempi concreti e comprensibili
- [ ] Transizioni pronte
- [ ] Tempo rispettato
- [ ] Linguaggio semplice e preciso

Esempio 01: “Diagrammi di flusso nella vita reale: decidere come andare a scuola” (3–5 minuti)

NOTA: i tempi indicati sono solo di esempio.

Obiettivo & messaggio centrale

  • Obiettivo: far capire come i diagrammi di flusso aiutano a prendere decisioni chiare e a prevedere i casi.
  • Tesi: “Un buon diagramma di flusso rende visibile la decisione e riduce gli errori nei casi particolari.”

Apertura (30–45″)

  • Gancio: “Quante volte arrivate in ritardo perché non sapevate se prendere bici o bus?”
  • Contesto: decisione quotidiana con variabili (tempo, meteo, orari).
  • Tesi: “Il diagramma di flusso traduce il problema in domande sì/no e azioni.”

Idea 01 – Simboli base e logica sì/no

  • Definizioni: Start/Stop (ellissi), Azione (rettangolo), Decisione (rombo), Connettori.
  • Esempio: blocco “Leggi orario e tempo residuo” -> decisione “Tempo ≥ 25′?”.
  • Transizione: “Capito il linguaggio, lo applichiamo al nostro problema.”

Idea 02 – Esempio concreto

  • Input: orario attuale, tempo residuo, meteo (piove sì/no), bici disponibile, orario bus.
    Flusso:

    • Se tempo < 25′ > controlla bus in arrivo ≤ 10′. Se sì -> BUS. Se no -> chiama passaggio/avvisa.
    • Se tempo ≥ 25′ -> se piove -> vai a BUS; se non piove -> se bici ok -> BICI, altrimenti A PIEDI.
  • Nota visiva: mostrare una mini-mappa o uno schema (anche disegnato) con 2–3 rombi e azioni.
  • Transizione: “Funziona, ma che succede nei casi speciali?”

Idea 03 – Gestione eccezioni e miglioramenti

  • Eccezione: bus pieno > ramo alternativo (seconda scelta).
  • Miglioramento: soglie personalizzabili (25′ > 20′ se cammini veloce).
  • Collegamento: stesso metodo per “scegliere metodo di studio” (Cornell/Pomodoro).

Chiusura (15–30″)

  • Riepilogo: “Dal problema all’azione, senza buchi logici.”
  • Messaggio finale: “Disegnare il flusso prima di agire fa risparmiare tempo e riduce le decisioni impulsive.”

Q&A previste

  • “Se ho due bus alternativi?” -> Aggiungi un rombo “Bus A entro x min?” -> se no, “Bus B entro y min?”.
  • “E se non ho i dati (orari)?” -> Prevedi un ramo “Recupera info” prima della decisione.

Timer (prove)

  • Prova 1: 6′20″ > taglia spiegazioni di simboli.
  • Prova 2: 4′55″ > ok.

Esempio 02 – “Legge di Ohm: capire la relazione tra V, I e R” (7–10 minuti)

Obiettivo & messaggio centrale

  • Obiettivo: mostrare come la legge di Ohm descrive il legame tra tensione, corrente e resistenza e come usarla per prevedere il comportamento di un circuito semplice.
  • Tesi: “V=R⋅I possiamo stimare e progettare rapidamente circuiti, riconoscendo anche quando il modello non basta.”

Apertura (30–45″)

  • Gancio: “Perché a volte un LED si brucia in un attimo?”
  • Contesto: corrente e resistenza di limitazione.
  • Tesi: “La legge di Ohm è la base per evitare errori e dimensionare componenti.”

Idea 01 – Definizioni e formula

  • Definizioni: tensione (V), corrente (I), resistenza (R) con unità SI.
  • Formula: V=R⋅I, grafico I-V lineare per resistori ideali.
  • Esempio numerico: con 5 V e R=220 Ω -> I=5/220≈0,023 A (23 mA).
  • Transizione: “Applichiamola ad un caso pratico con LED.”

Idea 02 – Caso pratico: LED + resistenza

  • Dati: LED rosso Vf ≈2,0 V; alimentazione 5 V; desidero I≈15 mA.
  • Calcolo resistenza: R=(5−2,0)/0,015≈200 Ω > uso 220 Ω (standard).
  • Mostra schema semplice; suggerisci una figura o foto del cablaggio.
  • Transizione: “La legge funziona, ma quando non basta?”

Idea 03 – Limiti e casi non ideali

  • Lampadine a incandescenza: resistenza varia con temperatura -> non lineari.
  • Cavi lunghi/contatti ossidati: resistenze parassite.
  • Misura reale con multimetro: piccole differenze ammesse.
  • Collegamento: serve anche a dimensionare partitori, sensori e a capire cadute di tensione.

Chiusura (15–30″)

  • Riepilogo: “Ohm = relazione semplice che evita errori grossolani.”
  • Messaggio finale: “Fai sempre il conto prima di collegare: risparmi tempo e componenti.”

Q&A previste

  • “Perché il LED brilla meno con 330 Ω?” -> Corrente più bassa: I=(5−2)/330≈9 mA.
  • “Perché una lampadina non segue I-V lineare?” -> Resistenza dipende dalla temperatura del filamento.

Timer (prove)

  • Prova 1: 10′30″ > ridurre spiegazione casi non ideali.
  • Prova 2: 8′50″ > ok per interrogazione lunga.

Buona interrogazione 🙂

Dirimere i conflitti con il pensiero computazionale – educazione civica – Definizione del problema – lezione 01

La violenza, dai conflitti globali alla violenza verbale quotidiana, nasce spesso dal non-ascolto e dalla prevaricazione. Nel laboratorio di sistemi elettronici trasformiamo i principi di convivenza civile in processi chiari: condizioni, regole, passi verificabili. Il lavoro in gruppo e la scrittura dell’algoritmo favoriscono la riflessione e il senso di giustizia che nasce dal confronto tra pari, non dall’imposizione. In un’epoca di bombardamento continuo di notizie che rischia di normalizzare la violenza e di farci sentire impotenti, progettare insieme percorsi di dialogo è un dovere civico oltre che un’attività didattica.

Contenuto dell’attività

Obiettivi

  • Distinguere fatti da interpretazioni in un conflitto.
  • Formulare il problema in una frase chiara.
  • Definire regole minime di dialogo e condizioni di sicurezza.

Durata: 60–75 minuti
Materiali: scheda cartacea o digitale (tabella), post-it, pennarelli.

Fasi

  1. Rompighiaccio (5 minuti)
    • Brainstorm: dove incontriamo conflitti (classe, chat, famiglia, social, ambiente)?
    • Raccogli su post-it parole chiave (ascolto, rispetto, tempi, diritti, minoranze).
  2. Fatti vs interpretazioni (15 minuti)
    • Consegna una scheda con due colonne:
      • Colonna A: FATTI (osservabili, verificabili).
      • Colonna B: INTERPRETAZIONI (opinioni, giudizi, attribuzioni di intenzioni).
    • Ogni gruppo (3–4 studenti) compila la tabella su un caso realistico proposto da te.
  3. Regole minime del confronto (10 minuti)
      • Stabilire 4 regole operative: niente insulti, parlo di me non accuso te, no interruzioni, tempi uguali.
        • Cosa si intende per: “parlo di me non accuso te”
          • Esempio 01: “Io mi sento confuso quando parliamo tutti insieme, perché non capisco. Ti chiedo di alzare la mano.”
          • Esempio 02: “Io mi innervosisco quando vengo interrotto, perché perdo l’idea. Ti chiedo di farmi finire.”
      • Decidere la condizione di sicurezza: se non è un buon momento, si prevede un time-out.
  4. Definizione del problema (15 minuti)
    • Ogni gruppo formula 1 “frase problema” chiara e neutra (max 20 parole).
    • Esempio: “Nel gruppo di laboratorio c’è disaccordo sulla divisione dei compiti e sui tempi di consegna”.
  5. Condivisione e feedback (10 minuti)
    • Ogni gruppo legge la frase. Feedback degli altri: è chiara? è neutra? evita accuse?

Lista elementi per la valutazione formativa

  • Chiarezza della frase problema.
  • Distinzione corretta fatti/interpretazioni.
  • Qualità delle regole proposte.
  • Partecipazione e rispetto dei turni.
  • Sintesi finale.

Buon lavoro 🙂

Dirimere i conflitti con il pensiero computazionale – educazione civica – presentazione

Esercitazione di Educazione Civica nelle ore di Laboratorio di Sistemi Elettronici

Desidero condividere la scheda di lavoro del percorso di educazione civica che avvierò oggi con i miei studenti. Come sapete, l’educazione civica è affidata a tutti i docenti del consiglio di classe e viene insegnata con un approccio trasversale e interdisciplinare. Per quanto mi riguarda, condurrò le prime tre ore di lezione a partire da oggi, integrandole con i contenuti della disciplina che insegno: Laboratorio di Sistemi Elettronici.

Condivido la scheda così come l’ho progettata nei giorni scorsi: modificatela e adattatela liberamente dove ritenete opportuno. Vi ringrazio fin d’ora se vorrete darmi un riscontro sia sulla validità della proposta sia sull’eventuale sperimentazione nelle vostre classi. La sto testando e con ogni probabilità apporterò modifiche in itinere.

Perché fare educazione civica in laboratorio di sistemi elettronici

Perché progettare un algoritmo è progettare una convivenza: si definiscono condizioni, stati, ingressi/uscite e verifiche di esito. Nel laboratorio trasformiamo i principi di costituzione, diritti e responsabilità in procedure operative che gli studenti possono vedere, toccare e migliorare.

In più, scrivere l’algoritmo e svilupparlo in gruppo porta inevitabilmente a riflettere su questi problemi, a cercare modi concreti per affrontarli e, soprattutto, a coltivare un senso di giustizia che nasce dal confronto civile. È nella pratica del “decidere insieme” e non nell’imposizione dall’alto tipica di leadership autocratiche che si progetta la pace: solo così, con regole condivise, possiamo contribuire a rendere migliore questo mondo.

Infine, in un contesto in cui il bombardamento continuo di notizie rischia di assuefarci a una falsa normalità della violenza e di farci sentire impotenti di fronte ai problemi globali, il laboratorio offre un antidoto: riflettere e progettare insieme percorsi di dialogo e cooperazione. Farlo non è solo un’opportunità didattica: è un dovere civico, un esercizio concreto di responsabilità verso il bene comune.

Ho previsto una versione base che, secondo la mia progettazione, richiede circa tre ore. Non so se durante le prossime lezioni o più avanti proporrò una versione avanzata, che integra criteri di valutazione, punteggi: questa seconda forse la farò sviluppare quando la classe avrà acquisito maggiore dimestichezza con la programmazione, ma osservo e nel caso troverete su questo sito la proposta avanzata integrata all’interno delle tre lezioni che vi condividerò settimanalmente (credo) con lo sviluppo di una proposta di soluzione del diagramma di flusso, pseudocodice e Sketch Arduino.

Scheda di lavoro

In questa attività uniamo educazione civica e competenze tecnico-scientifiche per riflettere su conflitti che toccano la nostra società: escalation di guerre, fenomeni di apartheid e discriminazione, crisi climatica, violenza verbale online e offline. Al centro c’è un’idea semplice e credo potente: molte forme di violenza nascono dal non-ascolto e dalla prevaricazione, dal non tenere conto del pensiero altrui e dei diritti delle minoranze.
Useremo il pensiero computazionale (diagrammi di flusso, pseudocodice, automazione con Arduino) per progettare procedure di dialogo e mediazione: la logica degli algoritmi diventa un modo per rendere trasparente, equo e verificabile il percorso verso una soluzione condivisa.

Obiettivi formativi

  • Civici: sviluppare ascolto attivo, rispetto reciproco, gestione non violenta dei conflitti, attenzione ai diritti e alle minoranze.
  • Tecnici: saper rappresentare un processo con diagramma di flusso e pseudocodice; tradurre la procedura in uno sketch Arduino semplice con input da seriale e feedback visivo/sonoro.
  • Metodologici: passare da opinioni generiche a passi operativi (regole, turni di parola, verifica di comprensione, decisione).

Struttura del percorso (3 lezioni)

Lezione 1 – Definizione del problema

  • Analisi di casi: conflitti quotidiani (classe, social, famiglia) e macro-temi (discriminazione, clima, linguaggi d’odio).
  • Riconoscere attori, interessi, regole e condizioni minime per un confronto sicuro.
  • Distinguere fatti da interpretazioni e formulare il problema in una frase chiara.

Lezione 2 – Diagramma di flusso e pseudocodice

  • Costruzione di una versione base dell’algoritmo di mediazione:
    controllo sicurezza del confronto > turni di parola > parafrasi reciproca > generazione di opzioni > decisione o richiesta di mediazione.
  • Stesura del pseudocodice con variabili in italiano e commenti esplicativi.

Lezione 3 – Sketch Arduino

  • Implementazione su Arduino con input via Serial Monitor e feedback con LED integrato (e buzzer opzionale).
  • Test guidato: simulare conversazioni e verificare come l’algoritmo aiuta a ridurre ambiguità, toni aggressivi e fraintendimenti.

Competenze attese

  • Competenze civiche e sociali: ascolto, empatia, negoziazione, responsabilità.
  • STEM: modellazione di processi, astrazione, controllo di flusso (condizioni e cicli), debugging di procedure.
  • Comunicazione: parafrasi, sintesi in una frase problema, linguaggio tecnico chiaro.

Materiali essenziali

  • PC con Arduino IDE, scheda Arduino UNO (o equivalente), cavo USB.
  • Serial Monitor per l’interazione, LED integrato (pin 13) e buzzer opzionale su pin 5.
  • Fogli per diagrammi/pseudocodice; regole di dialogo condivise.

Valutazione (formativa)

  • Qualità del diagramma di flusso (chiarezza, completezza, uso corretto di bivi e cicli).
  • Aderenza del pseudocodice al diagramma.
  • Funzionamento dello sketch e qualità dei commenti.
  • Comportamenti osservabili di ascolto e rispetto durante le simulazioni.

Inclusione e clima di classe

  • Ruoli rotanti (moderatore, portavoce, time-keeper, osservatore del linguaggio).
  • Consegnare una griglia di frasi utili per “io-messaggi” e parafrasi.
  • Tempi scanditi e check-point per favorire la partecipazione di tutti.

Progettiamo la pace 🙂

Quick References per lo studio – Nomi file & versioni

Dare un nome chiaro ai file e gestire le versioni non è pignoleria: è ciò che ti fa trovare subito ciò che cercate, capire al volo quale documento è l’ultimo e collaborare senza caos. In classe e nei progetti di gruppo capita spesso di avere decine di file chiamati “Relazione definitiva (nuova)”, “Relazione_ultimissima (1)”, “prova2_bis.pdf”. Risultato: si perde tempo, si consegna il file sbagliato, si confondono revisioni e correzioni del docente.

Un buon naming (come chiami il file) e un semplice versioning (come tenete traccia delle versioni) risolvono questi problemi perché:

  • i file sono ordinabili in modo naturale (per data, per progetto, per autore);
  • il nome racconta cosa contiene e a che punto è (v1.0, v1.1, v2.0…);
  • lavorare in gruppo diventa più semplice (ognuno segue la stessa convenzione);
  • la consegna è pulita: il docente vede subito cosa aprire, senza dubbi.

Non serve un software complicato: basta una regola condivisa e costante. Con una convenzione semplice, in 1 secondo capisci versione, tema e autore; in 2 clic trovi tutto ciò che ti serve.

Esempio sintetico:

  • Nomi coerenti = cercare e condividere senza perdersi.
  • Regola: AAAA-MM-GG_progetto-parole-chiave_vX.Y_autore.ext.
    Ordinabile per data, leggibile da tutti, facile da versionare. Evita spazi e caratteri strani; usa trattini.
  • Cartelle consigliate: /classe/materia/progetto/gruppo/.

Scarica PDF A4 della guida operativaApri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "QR – Nomi file & versioni come i pro"
version: "1.1"
autore: "<Classe/Studente>"
licenza: "CC BY 4.0"
ultimo_aggiornamento: "2025-10-05"
---

# Perché una convenzione aiuta
- Trovi i file subito (ordinamento per data e nome).
- Capisci a colpo d’occhio contenuto e versione.
- Meno conflitti/doppioni nei lavori di gruppo.
- Consegne pulite e professionali.

## Convenzione base (da usare)
`AAAA-MM-GG_progetto-parole-chiave_vX.Y_autore.ext`

**Spiegazione**
- `AAAA-MM-GG` = data (es. 2025-10-05)
- `progetto-parole-chiave` = tema + 1–3 parole utili (senza spazi; usa trattini)
- `vX.Y` = versione (X=major, Y=minor: v1.0, v1.1, v2.0…)
- `autore` = cognome o nome-cognome / nome del team
- `ext` = estensione (.pdf, .docx, .ino, .csv, .pptx…)

## Struttura cartelle consigliata
/classe/materia/progetto/gruppo/{dati,codice,relazione,media}

## Regole d’oro
- Usa trattini `-` o underscore `_` (no spazi, accenti, emoji).
- Minuscole coerenti; nomi descrittivi.
- Incrementa solo la parte necessaria della versione.
- Esporta un PDF finale per le consegne.

## Versioning semplice
- Inizio: v1.0 (prima consegna “completa”)
- Piccole correzioni: v1.1, v1.2 …
- Cambio sostanziale: v2.0
- Se arrivano commenti del docente: crea una nuova versione (non sovrascrivere)

## Modelli pronti (copia e incolla)
- Relazione (PDF): `AAAA-MM-GG_relazione-_vX.Y_.pdf`
- Codice Arduino: `AAAA-MM-GG__vX.Y_.ino`
- Dataset CSV: `AAAA-MM-GG_dati--_vX.Y_.csv`
- Presentazione: `AAAA-MM-GG_presentazione-_vX.Y_.pptx`
- Immagine/Figura: `AAAA-MM-GG_fig--_vX.Y_.png`

## Esempi rapidi (solo nomi, da imitare)
- 2025-10-05_relazione-arduino_stazione-ambientale_v1.0_rossi.pdf
- 2025-10-05_codice-sensore-luce_v1.3_rossi.ino
- 2025-10-05_dati-luce-umidita-aula3_v0.3_teamB.csv

## Checklist finale
- [ ] Stesso formato per tutti i file del progetto
- [ ] Versione aggiornata (vX.Y) coerente
- [ ] Niente duplicati “finale_definitivo(3).docx”
- [ ] PDF esportato per la consegna

Esempio 01 – Consegna di gruppo (Arduino)

  • Cartella: /3B/info/stazione-ambientale/teamB/
  • File:
    2025-11-12_relazione-stazione-ambientale_v1.2_teamB.pdf
    2025-11-12_dati-luce-umidita-aula3_v1.0_teamB.csv
    2025-11-12_codice-lettura-sensori_v1.3_teamB.ino
    2025-11-12_fig-01-schema-cablaggio_v1.0_teamB.png

Esempio 02 – Correzioni del docente > nuova versione

  • Prima: 2025-11-12_relazione-stazione-ambientale_v1.2_teamB.pdf
  • Dopo correzioni: 2025-11-15_relazione-stazione-ambientale_v1.3_teamB.pdf
  • Changelog (facoltativo): “2025-11-15 v1.3: aggiunte unità SI; rigenerato grafico con etichette leggibili.”

Home Assistant a scuola: la guida “a puntate” per elettronica & automazione – 02


Prima di iniziare con l’installazione del software procediamo con la configurazione base dell’hardware, nel mio caso dispongo a scuola di un Raspberry Pi 4 Model B – 4 GB RAM e su questa versione opereranno gli studenti, ovviamente la scelta di un modello superiore con maggior memoria è consigliabile, ciò che ho fatto per la mia versione casalinga con un un Raspberry Pi 5 – 8 GB RAM.

Questa prima parte è estremamente semplice e richiede pochissime competenze tecniche, installeremo le alette di raffreddamento e la ventola di raffreddamento collegandola ai pin di alimentazione che troviamo sulla GPIO.

Note per chi inizia: Cos’è la GPIO del Raspberry Pi

GPIO = General Purpose Input/Output: è il pettine a 40 pin sulla scheda che vi permette di leggere/scrivere segnali digitali e, quando necessario, usare funzioni: come I²C, SPI, UART, PWM ecc. Sulla Pi 4 solo 28 sono utilizzabili per la programmazione. La GPIO del Pi 4 è identica, per posizione e funzioni base, a quello dei modelli precedenti con header a 40 vie: quindi HAT e cablaggi restano compatibili. Al termine della guida è indicato la piedinatura della GPIO ed i pin a cui connettere la ventola di raffreddamento.

Raspberry Pi 4 offre molta più potenza dei modelli precedenti e, sotto carico sintetico (cioè durante test artificiali che stressano intenzionalmente CPU/GPU per misurare il “la situazione peggiore di utilizzo”), può scaldare rapidamente fino a innescare il throttling (taglio automatico della frequenza per protezione termica). Le misure ufficiali con il firmware iniziale mostrano picchi fino a 72,1 °C in 60 s e l’avvio del throttling dopo circa 65 s; gli aggiornamenti firmware successivi hanno ridotto consumi/temperature e posticipato il momento in cui il taglio di frequenza interviene, ma in carichi intensi il rischio resta. Per chi usa il Pi 4 in modo continuativo (es. Home Assistant), aggiungere alette di raffreddamento + ventola aiuta a mantenere la CPU sotto soglia, evitando cali di prestazioni e migliorando stabilità e longevità del sistema.

Di seguito due immagini della scheda realizzate con la termocamera in fase di test.

Per maggiori informazioni vi rimando all’articolo tecnico che trovate sul sito Rapberrypi.org

Situazione in fase di riposo

Raspberry Pi 4 VLI, SDRAM (idle)

Situazione in fase di load

Raspberry Pi 4 VLI, SDRAM (load)

Di cosa abbiamo bisogno

  • Kit dissipatore in alluminio per Raspberry Pi 4 (molti includono doppia ventola + thermal pad + viteria).
  • Cacciavite a croce di piccole dimensioni.
  • Alcol isopropilico + panno morbido (per pulire i chip prima del fissaggio delle alette).
  • Facoltativo: fascette/clip per gestire i cavi.

Sicurezza e prevenzione

Sembra banale, ma meglio specificarlo, soprattutto per i giovani studenti che iniziano attività laboratoriali:

  1. Scollegare l’alimentazione del Raspberry Pi.
  2. Lavorare su superficie pulita; toccate una parte metallica messa a terra per scaricare l’elettricità statica (se disponete di un braccialetto antistatico meglio).
  3. Pulire delicatamente CPU/RAM/controller USB con un panno leggermente inumidito di alcol isopropilico e lascia asciugare.

Applicare le alette di raffreddamento

Sono acquistabili su qualsiasi store online, andranno montate sulla CPU, sulla RAM e sul Bridge PCI e USB 3.0. Incollate, come indicato nelle foto che seguono, le alette di raffreddamento, ogni aletta è dotata di nastro biadesivo.

Serraggio e alimentazione della ventola

In funzione del kit che avete acquistato o stampato in 3D la ventola di raffreddamento, alimentata a 5V è da fissare sulla struttura mediante 4 viti autofilettanti.

L’alimentazione della ventola avviene direttamente connettendo direttamente i pin di alimentazione della GPIO secondo quanto indicato dall’immagine che segue.

Poiché potrebbe servire in altre applicazioni condivido la mappa della GPIO del Raspberry Pi 4.

Per alimentare la ventola utilizzerò il +5V, preso sul pin 2 ed il pin 6 per il GND, come indicato nell’immagine che segue (datasheet Raspberry Pi 4)

Nell’immagine che segue è ben evidente il collegamento:

Procedere al servaggio della ventola al vetro supporto.

Buon Making a tutti 🙂