Archivi categoria: produttività

Flashcard per lo studio – utilizzare Anki

Visto che siamo in vacanza riprendo i miei appunti sull’organizzazione dello studio, iniziata con le schede Quick Reference, tutto con l’idea di realizzare in un futuro un manuale con esempi da fornire agli studenti. Ho ripreso lo studio delle lingue e quindi ho pensato di realizzare qualcosa in merito all’uso delle flashcard strumento che ritengo utile.

Parto da una domanda che mi è stata fatta da uno studente di seconda superiore poco prima delle vacanze natalizie:

“Prof, ma lei come studiava quando aveva la nostra età?”

È una domanda che torna spesso, e ogni volta mi ricorda una cosa importante: molti studenti immaginano che esista un “metodo segreto”, una tecnica risolutiva che rende lo studio facile e veloce. La mia risposta, invece, è sempre piuttosto disarmante: non studiavo in modo così diverso da voi. Riassunti, schemi, appunti ordinati… e soprattutto flashcard.

Le flashcard, però, non erano una soluzione “magica”. Erano uno strumento semplice, che funzionava solo a una condizione: usarle con costanza, a piccole dosi, nel tempo. Ho sempre pensato che nello studio valga una regola che sembra banale ma è decisiva: meglio poco, ma ripetuto nel tempo. È questo che trasforma un ripasso occasionale in un apprendimento stabile. E naturalmente, con gli anni, ognuno costruisce il proprio equilibrio: c’è chi rende più efficaci gli schemi, chi preferisce i riassunti, chi trova nelle flashcard la leva migliore per fissare concetti, definizioni, formule o passaggi procedurali.

Oggi, quando mi capita di usare le flashcard per imparare (ad esempio per le lingue o per memorizzare lessico tecnico), mi affido spesso ad Anki. Non perché sia “l’ennesima app per fare flashcard”, ma perché introduce un’idea molto concreta: invece di ripassare tutto allo stesso modo e negli stessi momenti, ti aiuta a ripassare solo ciò che serve, quando serve. Ti porta a fare una cosa che tende a essere faticosa ma estremamente efficace: provare a ricordare attivamente prima di guardare la risposta. E quel tentativo di richiamo, ripetuto con regolarità, è spesso la differenza tra “l’ho letto” e “lo so”.

Per gli studenti questo significa ridurre l’effetto delle maratone dell’ultimo minuto e costruire memoria a lungo termine con un metodo più sostenibile. Per i docenti significa avere uno strumento che rende più gestibile il ripasso distribuito e la personalizzazione, senza limitarsi al classico “ripasso pre-verifica”.
C’è poi un aspetto che, a scuola, conta più di quanto sembri: Anki è un progetto libero e open source (in particolare nella versione desktop), sostenuto da una comunità ampia e da un ecosistema di estensioni. In pratica, non sei legato a una piattaforma chiusa: puoi costruire nel tempo un archivio di materiali che resta tuo, riutilizzabile e migliorabile anno dopo anno.

Nei paragrafi che seguono vediamo cosa rende Anki diverso da altri strumenti di studio, quali vantaggi offre in modo concreto e come iniziare con un tutorial essenziale e due esempi pratici, subito adattabili alle vostre discipline.

Gli appunti che seguono sono una sintesi del manuale che trovate sul sito di riferimento e che ho riformulato e sintetizzato, troverete poi alcuni esempi di flashcard sull’uso di Arduino.

Anki nello studio

C’è un momento che studenti e docenti conoscono bene: hai studiato “davvero”, magari anche con impegno costante, eppure dopo pochi giorni ti accorgi che alcuni passaggi si sono sfilacciati. Non è (solo) una questione di volontà, è più spesso una questione di come ripassi e quando lo fai.

Anki è un programma di flashcard “intelligenti” che pianifica per voi il ripasso: vi mostra una domanda, vi chiede di rispondere, poi usa il vostro feedback per decidere quando rivedrete quella stessa informazione. In altre parole: voi pensate ai contenuti, Anki si occupa del calendario del ripasso.

Anki nasce esattamente per rispondere a questo problema quotidiano: non vi chiede di studiare di più, vi aiuta a sprecare meno. Invece di ripassare tutto allo stesso modo e nello stesso momento, vi porta a rivedere ciò che state per dimenticare, quando serve davvero. La logica di fondo è quella di allenare il cervello con due leve molto concrete: richiamo attivo (provare a ricordare prima di controllare) e ripetizione distanziata (rivedere a intervalli crescenti).

Perché Anki è interessante rispetto ad altri applicativi

  1. Trasforma lo studio passivo in apprendimento che resta
    Rileggere, sottolineare, “ripassare scorrendo” sono abitudini comprensibili: danno l’idea di essere produttivi. Ma spesso si basano sul riconoscimento, non sul recupero. Quando invece vi trovate davanti a una domanda e dovete rispondere senza aiuti, state facendo ciò che il manuale chiama test di richiamo attivo: è faticoso, sì, ma è proprio quella fatica “buona” che rende la memoria più stabile.
  2. Ripassate meno, ma meglio (ripetizione distanziata)
    Il cervello tende a scartare in fretta ciò che non viene usato. Ecco perché il ripasso “a ondate” (tutto la sera prima) funziona male sul lungo periodo. Anki applica invece la ripetizione distanziata: ciò che ricordate bene torna dopo più tempo; ciò che vi è difficile ricompare prima. Il risultato pratico è semplice: non ripassate “a caso”, ma in modo mirato, con intervalli che crescono mentre la memoria si consolida.
  3. È personalizzabile: funziona per materie diverse e livelli diversi
    Anki non è “solo per le lingue” o “solo per medicina”. Se una cosa si può chiedere in forma di domanda (e verificare con una risposta), allora si può allenare con Anki: definizioni, formule, passaggi di procedure, date, classificazioni, concetti chiave e potete farlo anche con materiali ricchi: immagini, audio, video, notazione scientifica (LaTeX/Math).
  4. Open source e free: vantaggi concreti
    Qui Anki ha un valore particolare, soprattutto a scuola:

    • Desktop open source: il codice di Anki è pubblicato con licenza GNU AGPL v3 o successiva (con alcune parti sotto licenze differenti, come indicato nel repository). Questo significa continuità, verificabilità e un progetto che non dipende da una “scatola chiusa”.
    • Ecosistema di add-on: Anki si estende con componenti aggiuntivi, spesso nati da bisogni reali di docenti e studenti (lingue, layout, gestione, workflow).
    • Controllo e portabilità dei materiali: puoi esportare e trasferire mazzi “impacchettati” con contenuti e media, utile per backup e condivisione ragionata.
    • Multi-piattaforma e sync: esiste un servizio di sincronizzazione gratuito (AnkiWeb) per tenere allineati i contenuti tra dispositivi.
    • Android open source: AnkiDroid è su GitHub e dichiara licenze libere (GPL-3.0, con componenti specifiche sotto altre licenze).

Nota utile per evitare equivoci: su iOS l’app ufficiale AnkiMobile è a pagamento; la pagina App Store spiega che le vendite finanziano lo sviluppo.

  1. Un “sistema” più che un’app
    Molti strumenti per flashcard si fermano al “fronte/retro”. Anki, invece, è un piccolo sistema di studio: statistiche, ricerca, tag, opzioni di pianificazione, modelli delle carte, sincronizzazione, backup. Per chi vuole ottimizzare ulteriormente, oggi esiste anche un pianificatore alternativo (FSRS) integrato nelle opzioni.

Mini-tutorial usare Anki

Continua a leggere

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 🙂

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.”

Quick References per lo studio – Prototipi hardware: sicurezza & ordine

 

In laboratorio sicurezza = metodo + ordine. Un prototipo ben organizzato non è solo più “bello”: è più sicuro, più facile da testare e più veloce da riparare. Lavoriamo con alimentazioni, correnti, componenti sensibili: le buone abitudini proteggono persone, strumenti e risultati.

  1. Preparazione dell’area
  • Banco pulito: via oggetti non necessari, liquidi lontani, cavi non incrociati.
  • Illuminazione adeguata, seduta stabile, spazio per notebook/strumenti.
  • Documenti a portata: schema, pinout, datasheet; cartellina con buste (evita “pezzi sparsi”).
  1. Alimentazione: scelte e verifiche
  • Parti sempre disalimentato: cabla a cavo staccato.
  • Tensione e corrente: verifica che la sorgente regga (es. 5 V/2 A per moduli + motori).
  • Polaritá corretta: segna rosso = +, nero = GND; no fili volanti senza colore.
  • Protezione: preferisci alimentatori con limite di corrente o fusibili rapidi; imposta limiti sul banco di alimentazione.
  • GND comune: con più sorgenti, i riferimenti di massa vanno uniti (salvo isolamenti voluti).
  1. Cablaggio e componenti
  • Cavi corti e fissati (fascette/nastro): riduce falsi contatti.
  • Breadboard: limiti (resistenza di contatto, cadute, correnti basse). Per correnti > 200–300 mA, evita breadboard → morsetti/stripboard.
  • Sezione dei fili adeguata (motori ≠ jumper sottili).
  • Polarità di LED, elettrolitici, moduli. Diodo di ricircolo con carichi induttivi (relè/motori).
  • ESD (sensori e IC): tocca massa prima di maneggiare, se possibile usa bracciale ESD.
  1. Strumentazione e misure
  • Multimetro: inizia sul fondo scala più alto; controlla sonde e modalità (V, A, Ω).
  • Misure “prima di accendere”: continuità su alimentazione (niente corto), verifica resistenze sospette.
  • Misure “dopo”: V su pin chiave, I assorbita dal sistema, calore (dito/misuratore IR).
  • Log: annota valori e condizioni (tensione di alimentazione, carico, ambiente).
  1. Procedura di test (incrementale)
  • Un passo alla volta: prima l’alimentazione, poi un sensore, poi un attuatore…
  • Stato noto ad ogni passaggio: se qualcosa “salta”, sai dove guardare.
  • Rollback: se peggiori, torna alla versione stabile precedente.
  1. Chiusura lavori (safety & ordine)
  • Spegni/disalimenta, scollega, lascia un post-it con lo stato del prototipo (“sensore X instabile; rifare cablaggio domani”).
  • Rimetti a posto componenti (sacchetti etichettati), attrezzi, cavi avvolti.
  • Backup: foto cablaggi, schema aggiornato, commit del codice con messaggio chiaro.
  1. Rischi tipici & prevenzione
  • Surriscaldamento: dissipatori/pad termici, correnti entro specifiche.
  • Corto accidentale: fili spelati, breadboard usurate, stagnature “a goccia” → isola e rifinisci.
  • Rumore elettrico: twist dei cavi segnale, condensatori di bypass (0.1 µF vicino ai Vcc), massa stellare.
  • Batterie Li-ion/LiPo: carica solo con circuiti dedicati, non perforare o piegare, mai cortocircuitare, storage a ~3.8 V.
  • Meccanica: bordi vivi, parti in movimento: occhiali protettivi se c’è rischio.

Scarica PDF A4 della guida operativaApri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "QR – Prototipi hardware: sicurezza & ordine"
version: "1.2"
autore: "<Classe/Studente>"
licenza: "CC BY 4.0"
ultimo_aggiornamento: "2025-10-05"
---

## 1) Preparazione dell’area
- [ ] **Banco pulito** (via liquidi/oggetti inutili), **luce buona**, sedia stabile.
- [ ] **Documenti a vista**: schema, pinout, datasheet (cartella o busta trasparente).
- [ ] PC/Notebook con IDE aperto e cavo **funzionante**.
- [ ] Foto “prima” del banco (torna utile per confronto e relazione).

## 2) Alimentazione (scelte & verifiche)
- [ ] Cabla **a cavo staccato**; alimenta **solo a fine controllo**.
- [ ] Tensione/ corrente **coerenti** con il carico (es. 5 V/2 A).
- [ ] **Polaritá marcata**: rosso = +V, nero = GND; niente fili volanti non isolati.
- [ ] Se possibile, **limite di corrente** sull’alimentatore o fusibile rapido.
- [ ] Con più sorgenti, **GND comune** (salvo isolamenti voluti).

## 3) Cablaggio e componenti
- [ ] **Cavi corti e fissati** (fascette/nastro); evitare anelli e incroci inutili.
- [ ] Breadboard ok per segnali/ piccole correnti; per >300 mA usa morsetti/stripboard.
- [ ] Sezione fili adeguata (motori ≠ jumper sottili).
- [ ] **Polarità**: LED/elettr. corretta; **diodo di ricircolo** con relè/motori.
- [ ] **ESD**: tocca GND prima di maneggiare IC/sensori; se possibile usa bracciale.

## 4) Strumentazione & misure
- [ ] Multimetro: scala corretta (V, A, Ω) e **sonde ben inserite**.
- [ ] **Prima di accendere**: continuità tra +V e GND (no corto).
- [ ] **Dopo**: misura V su pin chiave, **corrente assorbita**, temperatura (dito/IR).
- [ ] Logga dati e condizioni (V aliment., carico, ambiente).

## 5) Procedura di test (incrementale)
1. **Alimenta** → verifica solo la parte di potenza.
2. **Aggiungi** un modulo alla volta (sensore → attuatore).
3. **Stato noto** a ogni passo; se peggiori, **rollback** alla versione stabile.
4. Una modifica per volta (HW *o* SW), poi test.

## 6) Chiusura lavori
- [ ] **Spegni e scollega**.
- [ ] **Post-it** di stato: “sensore X instabile; rifare cablaggio domani”.
- [ ] Riponi componenti/attrezzi; avvolgi cavi.
- [ ] **Backup**: foto cablaggio, schema aggiornato, commit codice con messaggio chiaro.

## 7) Rischi tipici & prevenzione
- **Surriscaldamento** → dissipatori/pad; rispetta correnti massime; ventilazione.
- **Corto** → rifinisci stagnature; isola punti nudi; sostituisci breadboard usurate.
- **Rumore elettrico** → twist cavi segnale, **bypass 0.1 µF** vicino a Vcc, massa a stella.
- **Batterie Li-ion/LiPo** → carica **solo** con circuiti dedicati; non perforare/piegare; mai in corto; storage ~3.8 V.

Esempio – “Il motore non parte e il driver scotta”

Setup

  • Alimentazione 12 V (banco da laboratorio, limite corrente 1.5 A).
  • Driver ponte H (es. L298N o similare), motore DC 6–12 V, Arduino UNO.
  • Cavi: alimentazione 0.5–0.75 mm², segnale jumper corti.

Sintomi

  • A “start”, motore fermo o vibra; driver caldo dopo pochi secondi; LED di alimentazione ok.

Procedura di diagnosi

01. Isola blocchi

    • Scollega Arduino → alimenta solo il driver e il motore in manuale: ponticella IN1=HIGH, IN2=LOW (o usa enable).
    • Se ancora fermo, il problema è driver/motore (non il codice).

02. Verifica alimentazione

    • Misura V_motore a vuoto: ~12 V?
    • Cala a 5–6 V quando provi a muoverlo? → alimentatore in current limit (motore richiede più spunto).
    • Soluzione: alimentatore con corrente di picco più alta o soft-start (PWM graduale).

03. Controlla cablaggio e polarità

    • GND comune tra Arduino e driver.
    • Sezione fili verso motore sufficiente (evita jumper sottili).
    • Diodi di ricircolo: presenti/integrati? Se driver ne è privo, aggiungili.

04. Assorbimento & termica

    • Misura corrente di spunto (metti multimetro in serie): >1.5–2 A? Il L298N satura e scalda.
    • Opzioni: driver più efficiente (MOSFET, es. BTS7960 o ponte H moderno), abbassa tensione o usa PWM limitato all’avvio.

05. Test incrementale

    • Motore scollegato > misura V ai morsetti del driver con PWM 30/60/100%.
    • Se V è stabile e driver non scalda → il problema è carico (motore duro/ingranaggi).
    • Lubrifica/controlla meccanica; prova con un motore “buono”.

Checklist “fatto”

  • Motore avvia fluido a PWM 30→60→100%.
  • Driver < 70 °C dopo 2′ di lavoro (dito o termometro IR).
  • Alimentatore non entra in limit; cavi non scaldano.
  • GND comune, fili fissati, schema aggiornato con modello driver.

Note didattiche

Mostrare agli studenti foto prima/dopo del cablaggio, la tabella di misure (V/I a step di PWM) e un grafico corrente-tempo allo spunto: è evidente perché alcuni driver scaldano.

Quick References per lo studio – Scrivere una relazione tecnica

Una relazione tecnica ha lo scopo di rendere trasparente e replicabile un lavoro: spiega che cosa è stato svolto, con quali procedure, quali risultati sono emersi e quali conclusioni ne derivano. Il suo primo obiettivo è comunicare: anche un progetto ben fatto, se non è descritto con rigore, di fatto “non esiste” perché non può essere capito, rifatto o proseguito da altri. Per questo contano struttura, sintesi e terminologia accurata.

Nel contesto di laboratorio (elettronica, informatica, scienze), oltre al testo, servono elementi operativi: uno schema disegnato in modo corretto, un bill of materials (BOM – in italiano: lista dei materiali) con caratteristiche, l’indicazione dei punti di misura, i  datasheet e le convenzioni di rappresentazione adottate. Questa parte oggettiva permette il debug e facilita eventuali migliorie del prototipo.

La scansione consigliata comprende:

  • scopo/obiettivi;
  • materiali e strumenti (con versioni software e tolleranze/portate);
  • metodo (passi riproducibili e parametri);
  • risultati (tabelle/figure ordinate con unità e incertezze);
  • discussione (lettura dei dati, problemi, alternative);
  • conclusioni;
  • riferimenti (fonti e datasheet);
  • allegati eventuali (codice, schemi, CSV).

Criteri di qualità da tenere davanti agli occhi

  • chiarezza e sintesi: testo breve, ma completo rispetto all’obiettivo;
  • coerenza dei dati: assi etichettati, unità SI, legenda, stima dell’incertezza;
  • riproducibilità: parametri, condizioni operative, versioni hardware/software esplicite;
  • onestà tecnica: limiti, errori e problemi dichiarati e come sono stati gestiti;

Scarica PDF A4 della guida operativaApri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "Relazione tecnica – "
autore: "<classe/nome cognome>"
data: "08.10.2025"
versione: "1.0"
---

## 1) Scopo / Obiettivo


## 2) Materiali e Strumenti
- Componenti/sensori (modello, tolleranze): …
- Strumentazione (portata/risoluzione): …
- Software/Firmware (versioni): …
- Datasheet/Riferimenti: …

## 3) Schema & Configurazione
- Schema elettrico / diagramma (con punti di misura)
- Pin-out / cablaggio / indirizzi (se I²C/SPI)
- Foto del setup (facoltativa ma consigliata)

## 4) Metodo (passi riproducibili)
1) …
2) …
- Parametri: 
- Criteri di accettazione: 

## 5) Risultati (dati ordinati)
- Tabella(i) con unità di misura e incertezze
- Grafici con assi etichettati e legenda
- Eventuali schermate (Serial/oscilloscopio)

## 6) Discussione (interpretazione)
- Cosa mostrano i dati? (trend, anomalie)
- Errori e limiti (strumento, metodo, ambiente)
- Alternative e possibili miglioramenti

## 7) Conclusioni
<2–3 frasi: risposta allo scopo + prossimo passo>

## 8) Allegati
- Codice .ino / script / CSV
- Schema in formato editabile

## 9) Riferimenti
- Datasheet, articoli, pagine web (con data di accesso)

Esempio 1 – Arduino: “Soglia di luce per LED d’allarme”

Scopo

Definire una soglia “luce bassa” per accendere un LED quando l’illuminazione in aula scende sotto il livello utile alla lettura.

Materiali e Strumenti

  • Arduino UNO, fotoresistenza + R 10 kΩ (divisore), LED + R 220 Ω;
  • Multimetro (portata 20 V DC, risoluzione 0,01 V);
  • IDE Arduino 2.3.x; quaderno dati; datasheet fotoresistenza.

Schema & Configurazione

  • Divisore su A0, LED su D7. Annotati i punti di misura (A0 e Vout LED) sullo schema.

Metodo

  • Rilevare A0 ogni 200 ms per 60 s in tre condizioni: finestra aperta (giorno), tenda tirata (penombra), luce spenta (buio).
  • Applicare media mobile su 10 campioni (riduzione rumore).
  • Proporre una soglia fissa iniziale e verificare falsi allarmi.
  • Valutare soglia “adattiva” = baseline – Δ (baseline = media primi 5 s).

Risultati

Tabella 1 – Valori medi A0 (0–1023), n=300 campioni per condizione

Condizione A0 medio Dev. std Note
Giorno (finestra) 780 22 alta variabilità
Penombra 430 18 stabile
Buio luce off 120 9 molto stabile

Discussione

La soglia fissa 200 funziona in condizioni estreme, ma è poco sensibile in penombra. Con soglia adattiva (baseline – 250) impostata dopo 5 s, l’attivazione scatta appena la luce cala di circa 30–35% rispetto al livello di partenza, adattandosi a mattino/pomeriggio. Limiti: sensibilità all’orientamento della fotoresistenza e ombre locali (proporre schermatura).

Conclusioni

La soglia adattiva riduce falsi negativi in penombra. Prossimo passo: mappare A0 > lux con calibrazione a due punti e riportare sul grafico unità SI.

Esempio 2 – Fisica: “Verifica della legge del pendolo”

Scopo

Verificare la legge

per piccole oscillazioni, stimando l’errore sperimentale.

Materiali e Strumenti

Filo inestensibile, massa 100 g, metro rigido (±1 mm), cronometro (±0,01 s). Rilevazione su 10 oscillazioni per ridurre l’incertezza di misura.

Metodo

Per ciascuna lunghezza L={0,30, 0,45, 0,60} m:

  1. Misurare il tempo di 10 oscillazioni;

  2. Calcolare

  1. Confrontare T con

con

Risultati

L (m) t10 (s) T (s) misurato T (s) teorico Δ = T-Tteo Δ%
0,30 11,0 1,10 1,09 0,01 0,9%
0,45 13,4 1,34 1,34 0,00 0,0%
0,60 15,5 1,55 1,55 0,00 0,0%

Grafico consigliato:

Discussione

Scostamento max < 1%: incertezze legate al cronometro e all’angolo iniziale (non perfettamente “piccolo”), attriti trascurati. Possibile miglioramento: fotocellula per misura automatica, media su tre serie per ogni L.

Conclusioni

La legge del pendolo è confermata entro l’errore sperimentale; proporre estensione a grandi ampiezze per osservare le deviazioni.