Ma nel caso in cui si debba montare al volo un circuito costituito da pochi componenti la soluzione è o usare la basetta millefori oppure usare una basetta ramata sulla quale appoggiare i componenti.

La basetta ramata è ideale per costruire circuiti che lavorano a radiofrequenza, vantaggio dovuto principalmente all’ampia area di massa, lo svantaggio è che i piedini dei componenti che non vanno a massa devono rimanere sospesi facendo attenzione che non tocchino lo strato di rame sottostante.
Per evitare ciò bisognerebbe creare delle isole sul rame sulle quali collegare tra loro i piedini che altrimenti sarebbero sospesi in aria.

Dopo aver realizzato qualche circuito con le isole fatte a mano con un trapanino e una fresa, mi sono chiesto se potevo fare di meglio, disegnando il percorso con Inkscape e fresando la basetta con la piccola MF70 modificata cnc.
Il problema maggiore di questo approccio è che non esiste un software specifico per questa applicazione, per cui ho dovuto scriverlo da 0 o quasi.

In pratica si tratta di convertire un layer di un file SVG prodotto da Inkscape in comandi gcode, per far questo ho scritto un interprete minimale che converte le forme e le linee SVG in percorsi, la difficoltà maggiore devo dire che è stata quella di implementare gli archi e le curve di Bezier, delle quali però non potevo fare a meno perchè uno stampato con le curve è più bello di uno tutto squadrato ( anche l’occhio vuole la sua parte).
Alla fine è venuto fuori un codice usabile che sto utilizzando con soddisfazione e che ho deciso di condividere con voi che mi leggete.
Ecco uno dei circuiti realizzati con questa tecnica, si tratta di un triplicatore di frequenza da 40 a 120 Mhz che serve come oscillatore locale (LO) di un mixer di un convertitore di frequenza che sto cercando di realizzare… in realtà questo sw è un sottoprodotto del progetto del convertitore.

Il codice è scritto in Python, non usa particolari librerie, è stato testato su Ubuntu 10.04.

Una volta copiati i 2 sorgenti python in una cartella, il programma che genera il gcode a partire dal file svg è svg2gcode.py, il nome del layer che contiene il path della fresa è “path”, gli altri layer possono essere usati per metterci i componenti e i collegamenti.

Per generare il gcode a partire dal file svg il comando è “./svg2gcode.py “.

Su Inkscape le unità di misura vanno settate in millimetri, la posizione (0,0) del foglio coincide con la posizione (0,0) del gcode.

Il gcode prevede che la posizione home dell’asse Z sia a una profondità tale da incidere la basetta.

Trovate il SW qui.

Una menzione particolare agli ottimi progetti CairoSVG e canvg, alcune parti del loro codice mi hanno fatto risparmiare molto tempo nella scrittura del parser.

Riferimenti

• Inkscape
• CairoSVG
• canvg

Il metodo è molto semplice:
Una volta aperta la bottiglia e consumata una parte del contenuto, travaso il restante in una bottiglia di plastica, di quelle usate per confezionare l’acqua minerale.

A questo punto schiaccio la bottiglia finchè il vino arriva fino al tappo ( ne faccio uscire un pochino per essere sicuro di non lasciare aria all’interno) e chiudo la bottiglia, sempre mantenendola schiacciata.
Il risultato, non molto elegante, è quello che vedete nella foto.
In pratica con l’operazione di compressione il volume della bottiglia viene ridotto a quello del vino, non c’è più aria a contatto con il vino!

Da varie prove che ho fatto usando questo metodo ho notato che il vino si conserva molto bene, il consiglio è comunque quello di non farlo rimanere troppo a lungo nella bottiglia di plastica, personalmente non sono mai andato oltre la settimana.
Usate una bottiglia di plastica appropriata, a seconda della quantità di vino che avanza:
500, 750 o 1500 ml.
Il procedimento può essere ripetuto più volte ovvero è possibile “estrarre” un bicchiere di vino al giorno dalla bottiglia e poi richiuderla schiacciandola sempre di più fino a farla diventare una sottiletta.
PS: Se volete un risultato impeccabile anche dal punto di vista estetico potete usare una bottiglia da campeggio del tipo “Foldable and Collapsable Water Carrier”, come per esempio questa.

Il Single Board Computer in questione è in questi giorni preordinabile presso due grandi distributori di elettronica on-line.
Io ovviamente non potevo non prenotarne almeno uno.

Riferimenti

• Il lancio del Raspberry
• Video introduttivo sul Raspberry Pi
• Documenti tecnici sul Raspberry Pi
• Datasheet del BM2835
• ARM1176 Processor
• Raspberry Pi su Wikipedia

In pratica, partendo dalla sequenza di N osservazioni di velocità e direzione, si calcola la media delle componenti nord/sud e est/ovest dei vettori.

La velocità e la direzione media sono quindi

dove flusso = 180 per e -180 per

Volendo implementare l’algoritmo descritto per mediare i valori della velocità del vento sulla mia stazione meteo, ho scritto una funzione in C che ho poi integrato nel programma wu2300 del pacchetto open2300.

La stazione, il cui sensore è collegato alla base tramite filo, restituisce i dati ogni 8 secondi, i dati vengono mediati con l’algoritmo descritto e poi postati in rete.
Nel mio caso il numero di coppie velocità/direzione mediate sono 8, la media è mobile, in questo modo ho una media degli ultimi 8*8 = 64 secondi.
L’implementazione in C contiene anche il codice per salvare/prelevare i campioni su un file e un semplice algoritmo per il calcolo della raffica, che la stazione meteo non restituisce.
Nel mio caso la raffica viene calcolata sugli stessi 8 campioni, applicando queste regole.
In pratica, le raffiche vengono riportate quando la velocità di picco del vento raggiunge almeno 16 nodi e la variazione di velocità tra i picchi e le pause è di almeno 9 nodi.

Trovate l’implementazione in C qui.

• Meteorological data processing
• Vector Computations
• Calculating an average value of the wind direction
• Mathematical Formulas su Infographics, per la generazione delle immagini delle formule

php cleaner.php <directory> [pattern da eliminare]

Lo script quindi processerà la directory e tutte le sue sottodirectory alla ricerca di files conteneti il pattern, contenuto nel file “patternfile” oppure dal file specificato da linea di comando.
I files contenenti il pattern verranno modificati e ne verrà creata una copia di backup con estensione “.bak”.

Modificando leggermente il codice è possibile fare in modo che lo script sostituisca il pattern ad un altro piuttosto che cancellarlo.
Nella scansione delle directory lo script ignora una serie di estensioni di files, anche queste possono essere cambiate agendo sulla variabile $excludepattern settata all’inizio.

Raccomando comunque di fare un backup della directory prima di usare lo script.

Potete scaricare il file da qui

Ho usato una economica La Crosse 2350 che avevo ferma da tempo, fornita con anemometro, pluviometro e centralina esterna con termo-igrometro.

Come schermo per la centralina ho usato un tubo bianco smaltato, con sopra dei piatti a protezione della pioggia e sotto una ventola per PC,  di quelle a 3 velocità, per garantire una ventilazione adeguata e quindi ( spero ) una maggiore affidabilità della misura.

Ecco qualche foto… è proprio quello che sembra… un terminale di uscita dei fumi della caldaia, che poi ho ancorato ad un palo tramite l’apposita staffa. Sono semplici articoli di fumisteria facilmente reperibili in ferramenta.

Montato il pluviometro e l’anemometro ho collegato i connettori alla centralina igro-termometrica che correttamente trasmetteva i dati alla console, dentro casa.

OK è fatta, ora basta collegare la console alla Linux Box ed installare Open2300 per cominciare a postare i dati.

Collego il convertitore USB<->RS232 al PC, che correttamente viene installato e visto come /dev/USB0,  collego la seriale alla 2350, configuro open2300 e lancio il comando “fetch2300″… niente, non funziona.

Forse il problema è il convertitore USB<->RS232, mi sono detto. Provo allora con un vecchio PC con Ubuntu che ha le seriali classiche: niente, nemmeno su questo va.

Provo anche con un PC Windows con il convertitore USB<->RS232 e non va nemmeno li… l’unica prova che mi rimaneva era Windows con una seriale classica ma non l’avevo a disposizione.

Forse sarà il cavetto RS232<->RJ11 che collega la seriale alla stazione, su internet trovo il pinout e faccio la verifica, sembra ok ma… dal pinout scopro con sorpresa che manca il pin 5, Signal Ground,  i segnali collegati sono 4, RX, TX, DTE e RTS. Come fa a funzionare sta 232 senza Signal Ground ? Di certo, anche se funziona, non è questo il modo più ortodosso per collegare una RS232!

Vuoi vedere che in qualche modo usa i due segnali DTE e RTS per fare un convertitore TTL/RS232 al suo interno ?

Incuriosito apro la stazione e mi metto a cercare il circuito che dovrebbe fare questa cosa, individuo i pin RX e TX TTL, lanciando fetch2300 verifico con l’oscilloscopio che il segnale dalla 232 verso il piedino RX arriva, si vede anche che il microprocessore risponde pure sull’altra linea ma il segnale non viene convertito nel corrispondente livello RS232 ( che dovrebbe essere duale e invertito rispetto al TTL).

Forse il driver non setta bene i segnali DTE o RTS ? Ma sai che ti dico, ma se ci mettessi un bel MAX232 ?

Detto e fatto, in una basetta monto il circuito raccomandato nel datasheet, collego il tutto, mi metto con l’oscilloscopio sui due pin RX e TX e lancio fetch2300.

Ecco che vedo sull’oscilloscopio il PC chiacchierare con la WS2350 e dopo poco come per magia apparire sul terminale del PC i dati della stazione. Funziona ! Ora facciamo un bel foro per un connettore DB9 femmina ( di spazio ce n’è da vendere) e proviamo il tutto, ora va su Linux con seriale classica, con l’adattatore USB<->RS232 e anche sul PC con Windows!!

Ora posso finalmente usare un cavetto DTE-DCE standard sulla RS232, va benissimo uno di un vecchio modem.

Non mi resta che,  dopo aver applicato questa patch che corregge un problema con la richiesta http, mettere in crontab l’eseguibile wu2300 e il gioco è fatto.

La stazione è di nuovo operativa. Potete vedere i dati su Weather Underground.
 

Riferimenti

• Open2300
• MAX220,MAX222… +5V-Powered, Multichannel RS-232 Drivers/Receivers

• Request headers (fase 1)

In questa fase sono disponibili gli header della richiesta http che effettua il client, come esempio in questa fase abbiamo a disposizione i cookie, lo user-agent, i parametri in GET

• Request body (fase 2)

In questa fase è disponibile il body della richiesta http ovvero tutto quello che segue gli header, esempio i parametri in POST, oppure un file che si sta uploadando sul server

• Response header (fase 3)

In questa abbiamo gli header in risposta che  il server intende trasmettere  al client (es. gli header per settare i cookie, la cache, etc)

• Response body (fase 4)

In questa fase abbiamo a disposizione anche il corpo della risposta che il server intende mandare al client, esempio tutta la pagina html

• Logging (fase 5)

Questa è una pseudo-fase finale, può essere utile per loggare la richiesta, che comunque è già stata mandata

Tutte le fasi meno che l’ultima sono bloccabili, ovvero si può configurare mod_security in modo da fare in modo che la richiesta non segua il suo corso normale.

L’ eventuale azione di blocco della richiesta andrebbe presa prima possibile, nella fase 1 o 2, per fare in modo che l’eventuale client o bot disturbatore non vada a consumare troppe risorse.

Le fasi 3 o 4 servono sostanzialmente per controllare quello che il nostro server sta per trasmettere al client:  l’utilizzo principale è quello di controllare che i dati non contengano script dannosi per il client.

Questo può essere molto utile al webmaster di un sito che mette a disposizione blog o spazi a utenti che non conosce e vuole in qualche modo bloccare eventuali pagine ospitate  che contengono script o codice indesiderato.

La configurazione di mod_security si basa su regole che prendono in considerazione le variabili a disposizione in quella fase, applicano delle operazioni su tali variabili (dopo averle eventualmente pre-elaborate con le funzioni di trasformazione) ed eventualmente eseguono delle azioni se le operazioni hanno esito positivo.

Tanto per capire la potenza e la configurabilità dell’oggetto, è possibile indicare come operazione  uno script  in linguaggio LUA, questo rende possibile l’implementazione di filtri di qualsiasi tipo.

Le azioni sulle regole possono essere omesse, in quanto può essere specificata un’ azione di default.

Le azioni disponibili consentono di bloccare la richiesta  ( disruptive actions ), di fare qualcosa ma non bloccare la richiesta ( non-disruptive actions ), di modificare il flusso delle regole ( flow actions ), o azioni informative o dichiarative  ( meta-data actions e data actions).

La tipologia di ogni azione è descritta nella documentazione ufficiale.

Ma veniamo al dunque con un esempio pratico.

Ammettiamo di avere un sito che accetta commenti ma che non ha un sistema di filtri spam molto efficiente, per cui siamo stati costretti a pre-moderare i commenti ma con tutto questo nella coda di moderazione finisce sempre qualcosa di indesiderato.

Nell’esempio ispezionando i commenti indesiderati notiamo che la provenienza è quasi sempre da IP russi o ucraini e che spesso contengono link a siti che vendono medicinali o siti di gioco online.

Un set di regole potrebbe essere questo, il set di regole è stato inserito nella sezione VirtualHost del sito di esempio in questione.

<IfModule security2_module>

  # accendiamo SecRule
  SecRuleEngine On
  # abilitiamo l'ispezione del body request ( necessario per i parametri in post)
  SecRequestBodyAccess On
  # setto il body a un numero alto dato che il sito prevede upload di foto
  SecRequestBodyLimit 9999999
  SecRequestBodyNoFilesLimit 9999999
  SecRequestBodyInMemoryLimit 131072
  # non ci interessa esaminare il body della risposta
  SecResponseBodyAccess Off

  # l'azione di default è negare e loggare
  SecDefaultAction "phase:2,deny,log"

  # setto il nome del db degli IP che userò per filtrare i commenti
  SecGeoLookupDb /usr/local/geo/data/GeoLiteCity.dat

  # con queste regole disattivo l'invio di commenti da parte di IP russi o ucraini
  SecRule &ARGS_POST "@eq 0" "skipAfter:AFTER_GEO_CHECK,pass,nolog"
  SecRule REMOTE_ADDR "@geoLookup" "chain,deny,msg:'Geo filter on %{REQUEST_BODY}'"
  SecRule GEO:COUNTRY_CODE "@rx RU|UA"
  SecMarker AFTER_GEO_CHECK

  # con questa regola blocco tutti i commenti che contengono le parole specificate, ignorando se minuscole o maiuscole
  SecRule ARGS "pharmacy|casino|viagra|cialis|prescriptions|drug" "t:lowercase"

</IfModule>

Nell’esempio il file che mappa gli Ip con le informazioni geografiche è GeoLite City di MaxMind.

Ora probabilmente l’esempio è un pochino estremo in quanto non consente ad IP russi o ucraini di fare commenti ma è possibile modificare la regola in modo che sia meno selettiva, per questo dal filtro  vengono loggati  i commenti bloccati  nell’error-log: Se cominceranno ad arrivare commenti validi potremmo agire sulle regole.

Intanto ecco una linea del file di log dove si vede uno spammer appena catturato.

Come si vede  il filtro ha pizzicato un IP russo o ucraino, il commento, come si evince dal payload, è sicuramente spam: il filtro ha fatto il suo lavoro.

Installare mod_security è molto semplice e si trovano parecchie guide in giro, in Ubuntu è presente nel repository standard ed è sufficiente usare il comando

apt-get install libapache-mod-security

Questo è solo un piccolo esempio di quello che è possibile fare con ModSecurity, le sue potenzialità sono enormi, degno di nota è il  ModSecurity Core Rule Set Project, che mantiene un set di regole per ModSecurity  utili a fornire una efficace protezione per le vulnerabilità spesso presenti nelle applicazioni web.

Se volete approfondire un buon inizio sono i riferimenti riportati sotto.

Riferimenti

• ModSecurity
• Install and Configure mod_security on Apache
• OWASP ModSecurity Core Rule Set Project

Secondo quanto riportato su Wikipedia, il tempo record di percorrenza sui 10000 metri piani maschile è di 26’17″53, che corrisponde ad un passo medio di 158 secondi per km, ovvero 2min e 38 secondi al km, per una velocità media di 22.81 km/h !!!

Riferimenti

• La corsa
• 10000 metri piani

Per avere una stima del consumo di carburante è sufficiente resettare il contachilometri parziale quando si fa il pieno.
Dopo aver percorso un certo numero di km si torna dal benzinaio a fare il pieno facendo attenzione a quanti litri entrano nel serbatoio.
Il consumo si calcola moltiplicando per 100 i litri e dividendoli per i km percorsi es. se ho percorso 160 km e i litri sono 12, 12*100/160 = 7.5. Il consumo è in questo caso 7.5 litri per 100 Km.
L’efficienza è semplicemente il numero di km diviso i litri ovvero nell’esempio 160/12 = 13.3 km per litro.

Riferimenti

• Fuel efficiency
• Schede tecniche di tutte le auto