SMD EL driver

Posted on by
Reply

As mentioned on a previous post, I got a few Optrex F-51159 graphics LCD that have a electroluminescent foil lamp (EL) backlight.

I plan to use them in a few projects, but before committing PCB space I decided to test a standalone EL driver and ended up selecting the Supertex HV857 lamp driver chip, since a design can be found online that directly follows its datasheet reference design. This chip acts as a step-up converter, storing the high voltage into an external capacitor by means of an inductor and then through another internal oscillator circuit provides the alternating current necessary for the correct operation of the EL backlight.

I etched the circuit, soldered the SMD parts, which include 0603 (1608 metric) and MSOP08 (3×3mm body), the result was quite satisfactory as seen above. Since the circuit is so small (0.75×0.63in = 19×16 mm) I took the opportunity to etch about 12 boards at the same time, to avoid handling such a small thing. The next step is to design the full driver, which includes the LCD negative biasing circuit, to connect to a microcontroller.

rtl-sdr

Posted on by
Reply

About a month ago an enterprising fellow discovered that a DVB-T USB receiver based on the Realtek RTL2832U chip sends the raw I and Q streams directly to the computer for demodulation. This is fairly interesting since a cheap $20/16€ device can be used as the front-end for a software defined radio (SDR).

Soon after some other people wrote simple software to extract those streams to a file for testing and created a module that can be used as a block on a gnuradio flowchart.

The latter allows someone to easily create a circuit block for demodulating every kind of signal imaginable, even in real time, subject to the frequency range of the receiver tuner, sampling rate and cpu power.

After reading about this on hackaday I followed the links to dx to get one but after a week or so of no order status update I decided to cancel and try my luck through ebay. I managed to find a seller with the same model as the one being sold at dx and ordered it from there. At the same time a subreddit was created where I read a few reports of scams on Ebay , so I felt apprehensive about my purchase. When I got my hands on it about a month later, I checked the lsusb ids and was happy to find that they matched:

~$ lsusb
(...)
ID 0bda:2838 Realtek Semiconductor Corp.

To allow a user in the ‘plugdev’ group access to the dongle I added the following udev rule:

ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", MODE="0660", GROUP="plugdev"

The dongles that use the Elonics E4000 like this one can receive from 64MHz to 1.7GHz and the Realtek chip is limited to 8bit samples but has a nice 3.2MSample/second rate.

After compiling the required software packages to make it all work (rtl-sdr , gr-osmosdr, gnuradio) I adapted a simple flowchart example from the gnuradio source package.

~$ git clone git://git.osmocom.org/rtl-sdr.git
~$ make rtl-sdr/build && cd rtl-sdr/build && cmake ../ && make -j3 && sudo make install
(...)
~$ git clone git://git.osmocom.org/gr-osmosdr.git
~$ make gr-osmosdr/build && cd gr-osmosdr/build && cmake ../ && make -j3 && sudo make install
(...)
~$ git clone http://gnuradio.org/git/gnuradio.git
~$ make gnuradio/build && cd gnuradio/build && cmake ../ && make -j3 && sudo make install
(...)

I was able to receive and demodulate commercial radio stations on the 88-108MHz band (Wide Band FM) with the short provided antenna and some other local public services using Narrow Band FM in the UHF range, with audio output in real time through the computer sound card. As an example of the former, see the screenshot that I took below:

GNU Radio with ezcap RTL2832U+E4000

There’s a lot of people using this dongle on youtube and quite a few interesting applications: HF receiver with a transverter, aviation radar with 3d map overlay, P25 receiver with decryption, etc.

dovecot Maildir compression gzip vs bzip2

Posted on by
Reply

Having recently migrated my dovecot imap server storage from mbox to maildir format I decided to activate dovecot’s support for on-demand read/write (de)compression. I changed the relevant parameters on the configuration file and my MDA is set to be dovecot-lda. I use some other plugins, so only zlib is shown below:

~$ doveconf -n
(...)
plugin {
  (...)
  zlib_save = bz2
  zlib_save_level = 9
}
(...)
protocol lda {
  mail_plugins = " zlib"
}
protocol imap {
  mail_plugins = " zlib"
}
(...)

As can be seen above I’m using bzip2 for compressing files.

With a partial copy of a gnuradio mailing list archive from 2011, comprised of about 6747 messages with mostly ascii/html text and no binary attachments:

~$ # file * | sed 's,.*:\s\+,,' | sort -u
~$ # regex are nice, but this is easier:
~$ file -b * |sort -u
ASCII mail text
ASCII mail text, with escape sequences
ASCII mail text, with very long lines
FORTRAN program
HTML document text
ISO-8859 mail text
ISO-8859 mail text, with very long lines
Non-ISO extended-ASCII mail text
Non-ISO extended-ASCII mail text, with very long lines
OS/2 REXX batch file text
UTF-8 Unicode mail text
UTF-8 Unicode mail text, with very long lines

Running a simple on-liner to compress each file individually, mimicking the dovecot-lda execution:

for f in *; do bzip2 -9v "$f" ; done

the following results are obtained (du -bc *.{bz2,gz} ):

original            : 161 335 374 bytes
gzip -9 compression :  41 367 973 bytes (3.90 ratio)
bzip2 -9 compression:  40 876 163 bytes (3.95 ratio)

There’s no much difference between each compression algorithm, so either should be adequate to use with the Maildir format, ignoring the bzip2 higher cpu requirements. Just out of curiosity, let’s try to compress files as a whole, which might be of interest when using a mbox or maybe mdbox file:

tar gzip -9 compression : 36 103 806 bytes ( 4.47 ratio)
tar bzip2 -9 compression: 30 489 102 bytes ( 5.30 ratio)
tar xz                  : 16 078 624 bytes (10.04 ratio)

Note that dovecot does not support xz compression.

sky.fm and di.fm amarok script (new version 0.3)

Posted on by
Reply

Updated my sky.fm/di.fm amarok script so that it works with Amarok >4.3 (tested with KDE 4.8.0 and Amarok 2.5.0). I joined the streams for sky.fm and di in one level, to avoid Bug 259241.

It can be installed directly from Amarok -> Settings -> Configure Amarok -> Scripts -> Manage Scripts -> Search for Sky.fm  -> Install. (It can also be downloaded from KDE-apps , but it’s more difficult to install that way)

To enable you will have to restart amarok and toggle the skyfm button at Amarok -> Settings -> Configure Amarok -> Scripts.

I also added a python script that converts the generated xml file into a pls file (xml2pls.py), which can be used with other multimedia players, without the need of having a browser open. All the GPLv3d source code can be found at my public sky fm amarok script git repository, including the json to xml converter (json2xml.py).

As usual this is an unofficial script, not supported by the sky.fm people.

electronic ballast repair

Posted on by
5

WARNING: Electronic ballasts are dangerous, not only because they are usually connected directly to the mains but also they generate very high voltages: the one described below has 600V output, much higher than the 110/220V mains voltage.

So by no means try this at home without proper training and certification! Please read Safety Guidelines for High Voltage and/or Line Powered Equipment

I had a fluorescent desktop lamp go dark for no apparent reason. I opened it and found an electronic ballast with the following markings:

Landlite
Electronic Ballast for Fluorescent Lamp
Model: EBCF-127-120V-LPF
Input: 120/60Hz 0.38A
Lamp: PL 27W
Output Voltage: 600V

After a few minutes of eye inspection (and nose:) ), I couldn’t find anything with burning marks or any foul smell. The small fuse had continuity along with the connecting wires, which made me think the culprit was the bulb, as the glass was fairly dark near the filaments, although in hindsight the latter came from its age and constant use. The bulb has 27W and 6500Kelvin color temperature. Without much thinking I got a new bulb but when I received it a few days later it didn’t switch on.

So going back to the ballast I went through the circuit, testing the likely culprits in the high voltage section: open/short capacitors, diodes or transistors and finding none, the mystery deepened. I cycled the power and then I went around poking the voltages to find that the mains rectifying circuit was working fine but when prodding with the multimeter probes next to the diac suddenly the bulb flashes! Humm, maybe the diac broke since it’s used to start the circuit, somewhat replacing the old mechanical/thermal starter that pairs reactive ballasts.

Testing a diac is more tricky with just a multimeter so I checked the circuit around it, finding to my surprise an open 510kΩ resistor (R1 in the circuit) with no burning or overheating marks. This resistor is responsible for the charging of capacitor C2 which, when reaching a high enough voltage to overcome the diac breakdown voltage, turns on transistor Q2 to provide the initial kick in the oscillator circuit. Replacing this resistor brought the circuit back to life and now the lamp was working again with no issues.

I took the time to extract the schematic as seen below , which can be downloaded in eagle, png and pdf formats, along with relative placement of the parts on the original pcb.

Some interesting references can be found at

diy fume extractor

Posted on by
Reply

The obligatory testing video.

Parts:

  • two 12V 0.65A DC brushless fan motors (88mm diameter)
  • one fan grill
  • assortment of screws, nuts and washers.
  • metal plates
  • carbon activated filter (Weller WSA350F)
  • 12V 1A SMPS power brick
  • DC power jack, male, 2.1mm pin / 6.2mm diameter / 9.5mm length (Jameco 101178)

Tools:

  • screw driver
  • electric drill and respective drill bits
  • metal saw

My initial construction started with a small cardboard box but after some experiments I realized that it would use too much valuable bench space. Most of the commercial available desktop fume extractors use some kind of stand to avoid this issue and a good substitute might be to use a broken desktop lamp, removing the bulb support and putting the fan and filter pair somewhere there. Since I don’t have one right now, it will have to wait.

To attach the filter to the two consecutive fans, which extract air away from the filter, I used a few metal plates that I removed from old computers. Actually, all the main parts of this project come from old computers and the power brick was obtained from some other electronic appliance or someone gave it to me, I cannot tell since there’s no identification markings. The only thing I had to purchase was the filter, which come in a pack of 3 and fairly cheap to obtain from any electronic parts distributor.

I started by locating the screw holes where to drill the screws to attach the vertical metal plates, in between the two fans. After drilling and putting the screws and nuts in place, I followed by putting temporarily the filter in front of one of them, paying attention for the air flow arrow to point away from it and marked on the base plates the attachment screw locations. The base plates have a short L at one of the extremities which are useful to keep the filter in place.

After drilling and attaching the base plates we still need to make some kind of slot to hold the filter upright. I use one more metal plate, which was bended and cut to size. Drilling holes for the supporting screws and by doing it twice got me two slots that work just fine.

For finger protection I attached a metal fan grill on the air flow output, since while soldering it’s fairly common to relocate the filter with your hands and a misplaced finger and fan blade combination is somewhat painful.

The next step is to provide power and for that hot glue was used to attach a convenient DC jack to be able to connect the power brick. An alternative to all this would be a small plastic box and stand, but I’ll probably leave that for some other time.

There are many other similar projects easily found through google or instructables.

SAX parsing performance comparison between Python and C++

Posted on by
Reply

Wanting to parse and convert a few hundred XML files and insert the data into a sql(lite) database, I wrote a python SAX handler to be used by a parser from the python Qt bindings (PyQt). Python has extensive support for xml SAX and DOM handling, but I’m using Qt since it’s to be part of a PyQt application I’m developing and for this purpose it’s also easier to compare the Python overhead to a direct C++ implementation by using the same underlying XML library.

Initially, even processing just one file, a quick profiling using the cProfile module found that committing a sql transaction for each object created from the XML data wasn’t the best of ideas. I changed the code to use the executemany() and a on-the-fly mapping (iterator) generator and the performance increased dramatically:

(put here the before and after profiling and the mapping function + executemany() code snippet)

Next I wrote it in C++ and the 3 minutes processing time when running with the Python implementation were dramatically reduced to mere 17 seconds:

xfce weather plugin

Posted on by
Reply

My friend JM , which I met long time ago through our common amateur radio interests, wanted to run some linux experiments on his old laptop computer, so sometime last year I recommended him to try xubuntu. Recently he complained about the xfce weather plugin not working anymore and upgrading to a newer ubuntu version was my suggestion, but he was unable to do it for some reason.

To troubleshoot the issue I told him to connect his computer to one of my personal vpn networks through openvpn, using a key I gave him some time ago, and using ssh+vnc we tried to find what was causing the problem.

We changed the station settings, units and some other basic things, but the weather plugin kept showing N/A instead of the relevant weather information. I couldn’t find any reference to this problem on the usual places (launchpad bug report, xfce webpages,etc) so I decided to try to look at the network traffic, since the plugin uses weather.com to get the meteorological information.

I used tcpdump and dumped the traffic to a file with something like:

tcpdump -w network.log -n -i eth0 not host my.remote.openvpn.server.ip and not port domain

Now that I think of it I could have probably just used host weather.com, but I wasn’t sure about the exact ip address the plugin would connect to.

By restarting the plugin and waiting a few seconds, tcpdump was able to capture the communication to the weather service. I followed by copying the resulting
network dump file to my computer and analyzed it with wireshark and found the error within the HTTP communication:

wireshark xfce weather plugin

Searching for this *invalid key* error I found a few hints about the API key used by the plugin not being valid anymore and so not to waste more time, and since i have an updated xubuntu machine running just fine with the same plugin, I decided to upgrade my friend’s machine remotely.

Opened a screen session, setup the upgrade process and after a reboot (not forgetting to enable the vpn on boot beforehand) I managed to upgrade his machine and bring the weather plugin back to life. I took the opportunity to install a few more packages, including a few science meta packages and gave him a few more tips afterwards.