Compleanno bisesto

Il 29 Febbraio del 2012 aprivo questo sito. Grazie alla sapiente scelta della data, devo scrivere un articolo che ricordi la ricorrenza solo una volta ogni quattro anni. Sono sempre stato un gran furbone. Il XXIX II MMXII la situazione economica era la seguente: petrolio a circa 140 $ al barile; un euro valeva circa 1,40 $; lo spread btp-bund era oltre i 500 punti. Il governo regolarmente eletto era stato costretto a dimettersi. La situazione di oggi XXIX II MMXVI è questa: petrolio a circa 30$ al barile; un euro vale circa 1,10$; lo spread btp-bund è a circa 100 punti ed abbiamo avuto tre governi non eletti democraticamente. Nonostante gli immensi vantaggi che provengono dalle mutate (e favorevolissime) condizioni economiche globali, la gran maggioranza della gente vive molto male e non riesce “ad arrivare alla fine del mese”. Gli economisti non sono in grado di fare “i conti della serva” e i politici non si accorgono che il mondo è profondamente cambiato. Un Paese viene considerato “governabile” solo se la maggioranza non ha opposizione, oppure se l’opposizione può essere messa a tacere con “un voto di fiducia”… Il bello è che con un terzo dei votanti (non degli aventi diritto al voto) si può prendere la maggioranza del parlamento, rendendo così, di fatto, la forma di governo in atto come una “dittatura a tempo”. Questo mi rattrista profondamente.

Normalmente, utilizzo questo sito come “contenitore” per i miei appunti su elettronica e informatica e per condividere con altri l’esperienza che ho acquisito negli anni e i risultati delle piccole prove che continuo ad eseguire perché sono ancora mosso dalla stessa curiosità che avevo da ragazzino. Questa volta, in occasione del primo “compleanno bisesto” del mio sito, ho voluto anche aggiungere questa amara constatazione sullo stato delle cose in questa Italia che comincia a puzzare di marcio.

Non temere, occasionale lettore di questa pagina… da domani si torna ai bei giochi dell’elettronica e dell’informatica. Anzi, per sorridere un po’ voglio pubblicare qui un “certificato di partecipazione”. Di che si tratta ? Inviai il mio nome alla NASA nell’anno 2008 (anche questo bisestile !!!) perché fosse incluso nella lista che sarebbe stata messa a bordo della sonda Kepler, lanciata poi nel 2009 verso le profondità dello spazio. Se la sonda troverà una forma di intelligenza lassù, mi aspetto di essere contattato, magari per una consulenza pagata in crediti stellari ! Per aspera ad astra…

certificate_border01a

Interfacciare il modulo ESP-01 con una porta USB

Ho di recente realizzato un progetto basato sul dispositivo ESP8266. Quando ho cominciato a lavorare sul dispositivo, ho acquistato un modulino ESP-01 su un “noto negozio on-line” e poi, per fare le prime prove, ho pensato di collegare il modulino ad una porta USB del notebook, in modo da scrivere qualche programma di test. Ho quindi realizzato questo circuitino di prova:

Il circuito montato

Il circuito montato

Questo circuito è costituito da tre blocchi, due dei quali sono l’interfaccia USB-TTL e l’ESP-01, mentre il terzo elemento è autocostruito. Ecco i tre blocchi:

I tre moduli del circuito

I tre moduli del circuito

A sinistra vediamo il circuitino autocostruito, al centro l’interfaccia USB-TTL e a destra il modulo WiFi ESP8266. Il circuito autocostruito è montato molto “alla svelta” come si evince dalle foto (fronte e retro):

il circuito autocostruito, fronte e retro

il circuito autocostruito, fronte e retro

Lo schema del circuito è questo (disegnato a mano, spero sia comprensibile) :

Schema elettrico del circuito e del collegamento dei moduli

Schema elettrico del circuito e del collegamento dei moduli

Nota: nel mio prototipo non c’è più spazio nemmeno per uno spillo, ma se ve ne costruite uno un po’ meno “compatto”, aggiungete una resistenza da 1K in serie al pulsante di reset dal lato Gnd, così pure sul jumper “re-flash”, sempre verso Gnd. Questo servirà a proteggere i segnali di I/O qualora nel modulo ESP-01 sia stata caricata una versione di firmware diversa da quella “base”, magari con i pin GPIO16 o GPIO0 non impostati come ingressi.

Sul modulo USB-TTL che ho usato io, ci sono solo 4 pin, che sono Vout, Txd, Rxd e Gnd, ma ci sono altri moduli che hanno più collegamenti. Quelli che servono, sono Gnd, Txd, Rxd e un quarto pin che porta la V_Usb, cioè il 5V preso dalla porta USB. Sul mio modulo c’è un jumper per scegliere se portare sul pin di uscita la tensione di 5V dalla presa USB oppure la 3.3V ricavata da un regolatore interno del chip. La tensione di 3.3V andrebbe bene, ma la corrente fornita dal regolatore interno è insufficiente, così useremo la 5V e creeremo la 3.3V con un regolatore LM1117-3.3, che è in grado di fornire al modulo ESP-01 i 3.3V e la corrente necessaria per funzionare. Il ponticello chiamato: “re-flash jumper” serve per fare l’update / upgrade del firmware contenuto nel modulo ESP-01, mentre il pulsante di reset serve… a resettare il modulo WiFi.

Sessanta e… stop ? No, avanti (adagio) !

veni, vidi, risi

veni, vidi, risi

Avevo deciso di chiudere tutto… e l’avevo fatto, ma due buoni amici mi hanno detto che era un peccato; allora ho deciso di ascoltarli e piano piano sto rimettendo tutto in piedi. In questa “ristrutturazione” ho deciso di recuperare anche alcuni miei vecchi siti web (il primo lo realizzai nel 1997); lo stile di queste pagine “datate” sarà differente, ma in fondo la denominazione del sito è “DISORDINE !” e quindi dovrebbe andare bene. Comunque, credo che i contenuti siano più importanti della forma. A mano a mano che recupererò il vecchio materiale, aggiungerò i link nella colonna a destra: “I miei vecchi siti”.

Esperimenti su USB OTG

Ho acquistato dei connettori plug micro USB per fare degli esperimenti. Sto costruendo un dispositivo che sfrutta un phablet (phone-tablet) con lo schermo da 6.5 pollici e sistema operativo Android, come interfaccia utente per un sistema di controllo luci casalingo. Ho collegato una interfaccia USB-Serial al cavetto in dotazione al phablet (quello che ha un plug microUSB e un receptacle USB-A) ed ho scritto un programma di prova (perfettamente funzionante) che mi permetteva di colloquiare tramite la porta seriale disponibile, col resto del mio apparato. Bene, però non è pratico avere il phablet con il cavetto adattatore, l’interfaccia USB-Serial e lo spinottino di alimentazione collegati. Ho pensato: adesso aggiungo al mio circuito un chip di convertitore USB-Serial della FTDI e faccio un cavetto che parta direttamente dalla scheda e finisca nel phablet, nel receptacle microUSB presente. Sarebbe bello, ho pensato, sfruttare lo stesso cavo ANCHE per alimentare il phablet e ricaricare la sua batteria. Con questa idea in testa, sono andato a leggere un po’ di documentazione sulla USB OTG ed ho trovato che oltre ai soliti 4 segnali, ce n’è un quinto. Questo segnale viene definito ID ed ha molteplici funzioni. Quella di base è semplice: se viene messo a GND, “avvisa” il dispositivo che deve comportarsi come un USB HOST e deve anche generare la tensione di 5V tipica di un dispositivo di questo tipo. Si noti che ormai praticamente tutti i dispositivi tablet, smartphone, phablet funzionano con una batteria da 3.7V (che in full charge è a 4.2V) e che quindi è necessario, all’interno del dispositivo, un regolatore step-up in grado di portare la tensione della batteria un pochino più in alto, per raggiungere i fatidici 5V. Questo step-up, ho scoperto a mie spese, ha una corrente limitata e qualche volta non è protetto (maledizione). Per cui, se provate a collegare, per esempio, un motorino elettrico ai contatti positivo e negativo del connettore USB, il telefono …si guasta 🙁 Nello specifico, il mio Samsung Nexus non voleva più saperne di spegnersi. Premevo il pulsantino di lato, si spegneva per tre secondi e poi si riaccendeva da solo. Certe volte passava più tempo, ma alla fine si riaccendeva da solo. Essendo fuori garanzia, ho costruito un connettorino microUSB con una resistenza, che prende il livello di una delle linee di dati e lo riporta sul pin di alimentazione. Così il telefono “vede” di nuovo una situazione regolare sul connettore microUSB e funziona come prima. La scocciatura è che ho sempre questo piccolo plug attaccato alla base del telefono. Un amico mi ha chiesto: “ma che cos’è che hai attaccato lì sotto ?”. Ed io ho mantito dicendo che si trattava di un dispositivo per diminuire l’influenza delle microonde sul mio cervello. Tornando al regolatore step-up presente nel dispositivo, sono andato a cercare quale fosse la corrente tipica disponibile e ho trovato su un solo documento un riferimento ad un’applicazione con Imax = 8mA. Leggendo le varie opzioni dei costruttori di chip con funzione di USB OTG, ho notato che il pin ID è collegato anche a dei comparatori interni, quindi non è solo un pin di on/off, ma fornisce al controller diversi possibili “stati” in funzione della tensione presente. Ora, dato che internamente c’è una resistenza di pull-up (verso il positivo), la tensione presente sul pin ID dipende dalla resistenza verso GND che mettiamo sul nostro circuito esterno. Tolta la resistenza da zero Ohm (che è quella vista in precedenza), ci sono altri valori tipici (e precisi) che permettono di “avvisare” il controller di come deve comportarsi il circuito. Addirittura, in un modello di chip, è possibile collegare una tastiera a questo singolo pin ! Ogni tasto viene decodificato in base al valore di resistenza che mette a GND. I valori “standard” per le funzioni più importanti dovrebbero essere 36.5K / 68K /120.4KOhm.
Quello che interessa a me è di poter “dire” al phablet che deve comportarsi da HOST, cioè deve “vedere” la mia interfaccia USB-Serial e utilizzarla come accessorio USB, ma che NON deve generare il 5V con lo step-up, perché il 5V lo voglio fornire io dall’esterno per ricaricare il phablet. Quindi, ho costruito un cavetto e mi sono messo a fare delle prove.

Il primo cavo costruito per le prove

Il primo cavo costruito per le prove

Per prima cosa, ho cercato la piedinatura di un connettore plug microUSB e l’ho trovata subito in internet. Ho costruito il cavetto e non funzionava in nessun modo. Per forza… gli schemi che avevo trovato su internet erano SBAGLIATI ! Ho preso un multimetro e dei fili molto sottili ed ho fatto delle misure in Ohm. Trovata la giusta piedinatura, ho proseguito nell’esperimento. Nella foto sotto potete vedere il mio connettore con i piedini giusti.

Il secondo cavo., quello usato nel prototipo completo

Il secondo cavo., quello usato nel prototipo completo

Poi sono andato avanti per vedere come raggiungere il mio obbiettivo. Secondo la documentazione, il dispositivo dovrebbe fare quello che ho scritto prima se “vede” una resistenza da 36.5KOhm. Non ho questo valore tra le mie resistenze e quindi ho usato una 33K con in serie un trimmer multigiri da 5K. Ho misurato il valore preciso di 36.5KOhm ed ho collegato il circuito, ma niente, non faceva quello che mi aspettavo.
Ho deciso, allora, di usare un trimmer da 100KOhm, senza resistenza in serie, e sono partito da zero salendo poi di un pochino per volta. Arrivato tra 3.9K e 4.7K il phablet, improvvisamente, si è messo a fare quello che volevo. Come l’ho capito ? Avevo un voltmetro messo sui pin Vbus (Vcc, il +5V della USB) e GND. Con la resistenza di zero Ohm sul pin ID, si vede il tester che segna immediatamente 5V (lo step-up interno è stato attivato) salendo verso i 3KOhm il 5V è scomparso, quindi lo step-up doveva essere stato disattivato. Ora c’era da vedere se il phablet riconoscesse l’accessorio USB, perché mi servono entrambe le cose. Lo riconosceva. Ho provato ad aumentare ancora il valore di resistenza e sono arrivato a circa 6KOhm e a questo punto l’interfaccia USB-Serial non veniva più riconosciuta. Allora ho messo sul mio circuito una resistenza da 4.7K e via.
Attenzione, su un altro dispositivo (di marca diversa) la cosa non funziona. Ho notato che queste “regole” sulla USB OTG vengono, come dire, “interpretrate” dai vari costruttori secondo le proprie esigenze. Comunque, il metodo rimane valido. Si costruisce il cavetto e si provano le resistenze tipiche per ottenere la tal funzione. Se la tensione di 5V scompare e un dispositivo accessorio USB (ovviamente alimentato esternamente) viene correttamente riconosciuto, allora si può ricaricare il telefono / tablet attraverso i pin Vbus (VCC) e GND del connettore microUSB.

Ricordo a chi volesse provare, che un errore significa bruciare il circuito interno, quindi se leggendo queste righe vi è venuta voglia di provare e così facendo rompete il vostro dispositivo (o quello di un imprudente amico che ve l’ha prestato), non venitevi a lamentare con me. Vi metto in guardia: IL DISPOSITIVO SI PUO’ ROMPERE, SE SBAGLIATE QUALCOSA.

Bene, chiudo qui. Il mio phablet mostra il segno di ricarica ( e si ricarica ! ) e contemporaneamente “vede” il circuito esterno come un accessorio USB. Quindi, dal mio circuito al phablet c’è solo un piccolo cavo, che da una parte ha un connettore a vaschetta (tipo IDC) e dall’altro un plug microUSB. Job done.

Un altro telecomando TV per smartphone Android

Sì, l’ho fatto ancora. In un mio precedente articolo descrivevo come costruire una interfaccia da collegare al telefonino per poterlo usare come telecomando per il TV. L’applicazione Android permetteva, in quel caso, di controllare un TV di modello Sony Bravia, che utilizza un protocollo a infrarossi di tipo NEC. Ora non ho più quel televisore ed ho un piccolo Telefunken, che però usa un protocollo a infrarossi di tipo RC5, che è completamente diverso. Allora ho scritto una nuova applicazione, mantenendo sempre la stessa interfaccia hardware. E’ da notare che la distanza di funzionamento di questa versione è inferiore alla precedente. Purtroppo, la frequenza generata col sistema descritto nella pagina citata a inizio articolo è sempre di 38.4 KHz che è molto vicina ai 38 KHz “standard” del protocollo NEC, ma purtroppo è un po’ distante dai 36 KHz canonici del protocollo Philips RC5. Comunque, funziona lo stesso, dato che il notch filter del ricevitore non è proprio così stretto in frequenza, ma ha una “campana” ampia a sufficienza per tollerare questo errore in frequenza… Per la corretta temporizzazione delle fasi di “pieno / vuoto” ho utilizzato i pattern che derivano da 11 bytes di valore 0x5B per il “pieno” (burst di frequenza) e 11 bytes di valore 0x00 per il “vuoto” (pausa). Durante la trasmissione di 11 bytes di valore 0x00 si avranno comunque dei “glitches” di 8.68 uS attivi alti, perché questi sono gli “stop bits” della trasmissione che non posso eliminare. Per fortuna, i circuiti di ricezione presenti nei TV hanno una funzione di “filtro” che elimina questi disturbi. I filtri sono indispensabili perché alcuni tipi di illuminazione domestica (specie i tubi al neon) emettono disturbi nello spettro dell’infrarosso con una potenza notevole (provare per credere). Senza una “ripulita” del segnale, i telecomandi sarebbero poco efficienti. Comunque, i prossimi controlli remoti per TV saranno via radio, con i soliti 2.4GHz che ci stanno rendendo le case simili a forni a microonde… 🙂

Perché il tutto funzioni, è necessario che la versione Android sia in grado di gestire le periferiche USB, naturalmente. Nella figura sottostante potete vedere lo screenshot del programma in funzione.

Il programma in funzione: iRemUSB-RC5

Il programma in funzione: iRemUSB-RC5

La App iRemUSB-RC5.apk è scaricabile gratuitamente dalla mia pagina di Google Play.

“Pedrone” Part #4 – drive it using web browser and WiFi

This is the last step. “Pedrone” is now complete. Please, remember that this is just a toy, you can’t use it to discover any sort of life on Mars ! I wrote a small Android application that acts like a mini web-server receiving commands from a standard web browser. I realized a demo video, capturing the screen while driving Pedrone with my web browser (SeaMonkey). Here it is:


pedrone3 di robotop

The Android application is relatively simple. It receives commands as “get” requests and, depending on the parameters, outputs the sound sequence to communicate with the microcontroller. Acting this way, the Pedrone executes the requested movement. After moving, the application takes a picture of the new situation (position) and gives the answer to the browser, that is still waiting. The process is a little bit slow, ‘cause the full path for the command is: 1) you click a “button” on the navigation map on the browser 2) an internet request is sent to the mini webserver 3) the webserver executes the command and send a sound sequence to the microcontroller 4) the microcontroller decodes the command and runs the motors for half second (short move) or one second (long move) 5) the application takes a picture 6) the application sends back an answer to web browser, changing the name of the image to force the browser to reload (no-cache) 7) the browser sends a new “get” to download the updated image. A screenshot of the Android application is here:

Screenshot of the Android App Pedrone-Rx3 (click to enlarge)

Screenshot of the Android App Pedrone-Rx3 (click to enlarge)

If you want, you can freely download and install this App from the Google Play Store.

For the mechanical part, I used the Lego Technic (my “children” have given me when they left university) with addition of some small screws and strong glue to create the adapters from Servo-motors to wheels and from structure to Servo-motors. In the following picture you can see how it was realized.

Three different views of "Pedrone" (click to enlarge)

Three different views of “Pedrone” (click to enlarge)…

The microcontroller circuit is not changed, look at Part #2 for complete schematics. The firmware has some changes. You can download the C source and the compiled HEX packaged in a zip file from the link : pedrone3x.zip ; the password to unzip is : eficara. Remember to set the correct fuses configuration when burning the micro. You can read such configuration in the first lines of the C source file. Here is the full C source list.

Finally, note that you can drive the “Pedrone” on your local net using a PC / Tablet / Smartphone connected on the same WiFi subnet, but you can also control it from everywhere in the world if you set your modem / router with the following rules:
1) force the router to assign a fixed IP to the MAC address of the WiFi interface of the smartphone you use as “receiver”, es: assign local IP 192.168.1.6 to MAC address 11:22:33:AA:BB:CC; this way the “Pedrone” smartphone will have every time the same IP on your local network.
2) modify the router’s firewall rules to accept incoming connections to port 8080, redirecting the requests to the IP assigned to the “receiver” (192.168.1.6 in the example)
3) get a free account on some Dynamic Dns service, as no-ip or dyndns or others and set the relative username and password in the router’s Dynamic Dns settings.
After this, you can reach “Pedrone” from everywhere in the world (if there is an internet connection !) with a standard web browser, writing the address http://my-assigned-dynamic-ip.com:8080 in the navigation bar.

Historical notes:
The idea for this project was born in August 2009, when I was in France for a sabbatic time and my smartphone was equipped with WM6. I realized a circuit and a couple of applications to test the motor driving using DTMF tones. After that, I published a video on YouTube describing the general concept. After some months I removed the video ‘cause Google acquired YouTube. I think that too much power in the hands of a single subject is very dangerous, but now that all the world is fulfilled by Android devices, it’s impossible to stop the “Masters of Universe”… Anyway, the original video is now stored on “DailyMotion”. If you want, take a look here:


dtmf_remote di robotop

“Pedrone” Part #3 – 16 commands using sound protocol

This is the third step. The previous version of the firmware was able to recognize three tones and the demo used a single tone for a unique operation. Now, I used a “protocol” to send multiple tones and create 16 possible commands. I used Audacity, a fantastic sound editor, to create the sound sequences. Here is an example:

The sound file for command 1011

The sound file for command 1011

A “command” is composed by a “start” tone (1200Hz) and four bits starting from the most significative. The “ones” are 1600Hz, while the “zeroes” are 800Hz. In the picture is represented the code 1011. A full “transmission” is always 500mS. Every sound has 50mS duration, followed by 50mS pause. For sound file output, I used the format “ogg” because is compatible with Android and iOS smartphones.

To test the firmware, I wrote a small application on Android smartphone. This is a screenshot of the application running:

Screenshot of Pedrone-Rx2 application

Screenshot of Pedrone-Rx2 application

The three buttons in the middle are just for compatibility with the old version of the firmware, while the cursors at the right and at the left are the controls for the motors. There are five positions for each motor : Fast Forward, Slow Forward, Stop, Slow Backward, Fast Backward. So, at this moment, I used only 10 of the 16 commands available. The App was not published on Play Store because is just for testing purposes, but if you want, you can download it and install from this link: Pedrone-rx2.apk .

The schematic of electronic circuit has not been modified, while the firmware has been improved. If you want to load the C source and the HEX file to burn the micro, both of them are packaged in a zip file that can be downloaded from this link : Pedrone3.zip (use password eficara to unzip) . Here is the full list of the C source file ; the hex comes from compilation with IAR V5.50.0. To burn the micro, use the fuses configuration that is described in the first lines of the C source.

“Pedrone” Part #2 – connecting to smartphone

After the Part #1, with the Servo Motors control program, now I connected a smartphone to the circuit. The software on the phone (in the next future) will do all the Internet job, receiving commands and sending pictures. Anyway, a connection is needed to control the hardware (motors) for moving “Pedrone” via web commands. A very simple solution is to use the headphone jack and send some tones to activate the motors. As first option, I decided for one DTMF tone decoder, but after some considerations, like the absence of noise on direct connection, I decided to use single tones. The hardware is very simple (stereo version is shown, but you just need one channel) :

Particular of the schematic (click to enlarge)

Particular of the schematic (click to enlarge)

This circuit is a mixer of Left and Right audio channels coming from the headphones jack of the smartphone, followed by protection resistor and diodes to safely connect to the ICP1 pin of the micro ATmega48. The ICP1 is the input capture pin of Timer 1 (TMR1). I used such peripheral to measure the period of incoming frequency. There are three frequencies: the first is considered as “start” signal and the other two as “0” and “1”. The protocol isn’t still implemented (will follow soon). At this moment, the test program just recognizes the frequencies and does a programmed action for anyone of them. The frequencies are 800Hz, 1200Hz end 1600Hz. All the tones have 50 mS duration. The complete schematic (including the servo motors outputs) is in the following picture

The complete schematic (a PDF version is in the downloadable project's zip file) - click to enlarge

The complete schematic (a PDF version is in the downloadable project’s zip file) – click to enlarge

If you are interested in the C source list and in the hex file to burn into the micro, you can download both of them (plus the schematic PDF), from this link: Pedrone2.zip
(password for zipped file: eficara)

There is a small video to show the program running. The application for Android smartphone has not been published on Play Store, because it’s just for testing purposes, but if you want you can download the apk directly from this link: Pedrone-rx.apk.


Pedrone part 2 – connecting to smartphone di robotop

Here is the C source list for the test program (compiled with IAR V5.50.0).

“Pedrone” Part #1 – Trimming stop point on modified servo

I am going to build my new “Pedrone” (Pedestrian Drone), a device that can be remotely controlled by smartphone, running at home. I did the same in 1998, now it’s time to make one better. In the picture below, you can see the old model. The internet server was set on the home PC and the data exchange with the rover was done by means of 866 MHz transceivers using half-duplex packets communication. The “camera” was a GameBoy gadget modified for the purpose, giving a fantastic 128*128 pixels gray scale image at every command received from the Internet.

My first Rover, built in 1998, controllable via a standard browser on the Internet.

My first Rover, built in 1998, controllable via a standard browser on the Internet  (click to enlarge)

For the new model, I decided to use a couple of cheap Servo-Motors, purchased on ebay at VERY low price. The servo motors have a good torque and so are very efficient. The second advantage of servo motors is that they just require a single microcontroller output to be driven in both directions. Obviously, a servo motor has to be modified, because its purpose is to move in the arc of 180° (someone more, some other less). I want a continue rotation to drive a wheel in both directions, plus a stop condition. I have written a small test program on Atmel ATmega48 microcontroller to generate a waveform to control the motor, then I have modified the servo substituting the feedback potentiometer with a couple of smd fixed resistors, both of the same value. Connecting the servo to the microcontroller, I had a problem: no one of the values that can be set in pulse width gave a real STOP condition. One value gave slow rotation clockwise, one other slow rotation counterclockwise. This problem can happen if the center tap of the two resistor is not exactly the median point, or because the pulse width is not exactly 1.5 mS or for the combination of the two things. Actually, my solution for controlling 2 motors with a single 8 bit timer (TMR0) using two output compare registers (OCR0A and OCR0B) gives me a step factor of 64 uS on a full range of 256 * 64 uS (the total repetition time is 16.384 mS, that’s inside the specs for servo-motors). The classical 1.5 mS center point can’t be set, cause 1500uS / 64uS is not an integer value (23.4375) and then we have to decide if the center point is 23 (*64uS = 1.472mS) or 24 (*64uS = 1.536mS). In any case the stop position depends upon the feedback supplied to the motor controller by the potentiometer (in our modified servo, the couple of SMD resistors with the same value).  To solve the problem, I decided to use an external multiturn trimmer (in place of the smd resistors) to trim the correct stop point. In the picture below you can see that I connected three wires on the pads where the potentiometer was originally soldered.

Servo circuit. Internal potentiometer has been disconnected

Servo circuit. Internal potentiometer has been disconnected (click to enlarge)

I modified the slot in the plastic cover to have enough space to go out with the 3 additional gray wires, then I soldered a multiturn trimmer to set the stop point. Note that the internal potentiometer was 5KOhm, but I used a 10KOhm trimmer without problems. Anyway, the best solution is to measure the resistance of the original potentiomenter and then buy a 10 turns linear trimmer of such value.

The 10 turn trimmer soldered on gray wires

The 10 turns trimmer soldered on grey wires (click to enlarge)

Finally, I used a biadhesive tape to fix the trimmer on the case of the servo-motor.

Trimmer fixed on the Servo-motor case

Trimmer fixed on the servo-motor case (click to enlarge)

Alternative version: using 2KOhm trimmer, a couple of resistors and a filtering capacitor makes easier setting the stop point.

Modified circuit (1KOhm resistors used, but 1.5K is better) - click to enlarge

Modified circuit (1KOhm resistors used, but 1.5K is better) – click to enlarge

Well, after connecting the servo to the microcontroller prototype board (using a default pulse width for stop position), I rotated the trimmer near its middle position, finding the exact point for motor stop. Actually, with my microcontroller’s test program, the stop point is at value 22, while the full speed in one direction is 15 or 30 in the other.

Driving two modified servos di robotop

My prototype board (the one visible in the video) has this schematic:

Schematic diagram of the prototype (click to enlarge)

Schematic diagram of the prototype (click to enlarge)

The C source file, the HEX object to burn the micro and the schematic in PDF format can be downloaded in the zip file EF190Pedrone.zip (when you unzip it, give password: eficara). Here is the C source listing compiled with IAR V5.50.0.

Constant Current 300mA Led drive with a battery charger

Li-ion battery chargers use the CC/CV algorithm. CC means Constant Current and CV is Constant Voltage. When a battery is under charge, the device supplies a constant current until a threshold voltage is reached (typical 4.2V), then applies a Constant Voltage. When the charging current drops below the 10% of the set value, the battery is disconnected (float). I tried to use a battery charger to light a white led at 300mA constant current. The trick is that the led (obviously) does not recharge, so the charger remains continuously in CC mode, with the current set as programmed.

The prototype working with a power white led

The prototype lights a power white led (click to enlarge)

I built the circuit on a proto board, using a self made adapter for the smd IC TP4056. Note that this IC has a metal pad on the bottom side, for thermal dissipation. I soldered a wire under the chip before placing it onto the adapter. The schematic is very simple:

Hand-made schematic. The IC accepts max 8V in input. I used 6.2V supply (click to enlarge)

Hand-made schematic. The IC accepts from 4 to 8V as input. I used a 6Volts battery for the test (click to enlarge)

Detail of the prototype board :

The prototype. Note the wire that comes out from the bottom side of the IC (click to enlarge)

The prototype. Note the wire that comes out from the bottom side of the IC and the metallic stripe used for thermal dissipation (click to enlarge)

Now it’s time to test. I used a trimmer for setting the value of charging current. For 300mA the value must be 4K Ohm. If you don’t want to use a trimmer, such non-standard value can be obtained paralleling two resistors: 10K and 6.8K (the result is 4.04K). The image below shows the current measured with a multimeter.

Led ON, driven with 300mA current (click to enlarge)

Led ON, driven with 300mA current (click to enlarge)

Note the 1N5819 diode at the charger output. This is important. The white led I used has a typical Forward Voltage of 3.42 Volts and if you connect it directly to the BAT signal of the IC (pin 5) the charge does not start. You will have a current that is the 10% of your settings, so about 30mA. The IC “starts” if there is a voltage near 3.7V ; the diode 1N5819 has about 0.35V voltage drop at 300mA, so 3.42V of led plus 0.35V of diode makes 3.77V and the circuit start “charging” at 300mA. I also tested one commercial board I purchased some time ago on ebay. I just modified the charge set resistor and added the diode at the output. Please note that if you set higher currents, the IC will be hot. I don’t recommend current values higher than 300mA, without any thermal dissipation. This IC is not made to be a led driver. For professional results, use one made for that purpose.

test with a commercial board (click to enlarge)

test with a commercial board (click to enlarge)

Here is a table for values of resistor to set a specific current and the position of such resistor on the circuit.

Change the circled resistor to modify the charging current (click to enlarge)

Change the circled resistor to modify the charging current (click to enlarge)