Saturday, July 29, 2017

Fake screw! Fake terminal block! And modifying multi-color LED ceiling lamp's default behavior

I've recently bought some LED ceiling lamps that supports multiple color temperature (daylight,warm white and "natural" white) by toggling the power switch as below.




However, I prefer the default color to be warm white instead of daylight as it will be installed in a bedroom and less blue light might help with my occasional insomnia. So I decided to try to modify since it should not be too hard since they LEDs and a constant current LED driver like below.



First I tried to open up the LED driver and have a look at the circuit inside. But when I tried to turn my screw driver on the 2 screws on the orange colored part, it didn't turn at all. Upon closer inspection, it seems that those are fake plastic molded screw!

After a while, I figured out that the entire orange colored terminal block was also fake! 😆
It is just piece of plastic held together those snap-on plastic parts.
Hahaha.. I guess this is not too surprising since it comes from the country that also produces fake rice, fake eggs, etc... 😜




I wonder why they made it to look like the conventional T8 fluorescent tube ballast choke although the PCB inside is actually 30% smaller the plastic chassis. They could have made it simpler and smaller. I could only guess that it is suppose to make it easier for electrical wireman to install without additional training.

Anyway, from the PCB and the diagram on the chassis, I could figure out that it connects to the LED lamp using 3 wires with common-anode configuration. So, it seem like there are only 2 types of LEDs in the lamp (warm white and daylight) while the third color is just simulated by mixing both.

Hence, to change the default behavior, I just have to swap the output for warm white and daylight wiring on the connector.
Originally Red V+, Green V1, Blue V1
Green and blue lines are swapped.
With this simple mod, it defaults to warm white!

Anyway, I have also measured the power consumption of the lamp with my power meter. The box says 24W but it seems that it is only consuming 22.3W.


While I like the idea that it is more energy efficient, it seems that I might be getting short changed as consuming less power means that it might not output as much lumens as stated on the box. Also the power factor seems pretty horrible. For comparison, a good 10.5W Panasonic LED bulb I bought previously measures at 10.9W and 70% power factor.

Monday, February 8, 2016

Raspberry PI's hardware random number generator for /dev/random

I've stumble upon that Raspberry PI has a built in hardware random number generator.

http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/

The BCM2835 datasheet also does not provide any info about the RNG.

I also found out that the kernel module is also loaded:
pi@raspberrypi ~ $ lsmod | grep bcm
snd_bcm2835            22317  0 
snd_pcm                92397  1 snd_bcm2835
snd                    66972  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
bcm2835_rng             2215  0 
bcm2835_gpiomem         3703  0

However, it is currently not fed to /dev/random

Also, occasionally, I realize there is a long pause when trying to log in to SSH when the random entropy pool runs out because I'm using it mostly headless so the random source are rather limited.

To do that, I just installed rng-tools with:
$ sudo apt-get install rng-tools

Default settings for rngd seems good enough as /etc/init.d/rng-tools seems to automatically detect the /dev/hwrng and automatically use it:
$ ps aux | grep rng
root     32539  0.1  0.3  26404  1312 ?        SLsl Feb08   2:12 /usr/sbin/rngd -r /dev/hwrng

Now, we can see that the entropy poll is always good, and more thatn 2000 bits while previously it can run low and down to a few hundred:
$ cat /proc/sys/kernel/random/entropy_avail
2798

As usual, we can always refer to the excellent Arch Linux's wiki for more info about rng-tools:




Sunday, January 31, 2016

Simple PIC16F72-based digital clock with DS32KHZ TCXO

Just to keep this blog updated, I've made a digital clock with a DS32KHZ TCXO to provide accurate time keeping. Details are at github: https://github.com/sonofusion82/ds32khz_clock


Tuesday, May 5, 2015

Fixing USB audio controller (CM108) for headphones

Cheap USB audio controller
Recently, I bought a cheap USB audio controller because my motherboard's built-in microphone input was dead. However, there were some problems with the stereo output. It seems to work well when it was connected to a pair of powered speakers, but there was only noise when connected directly to my earphones. When I measured the output voltage, it shows a 2 - 4 V bias voltage which is unusual because it should not have any bias voltages and normally 0 V when no audio.

When plugged into my Linux machine, lsusb shows the following:

$ lsusb | grep -i audio
Bus 005 Device 003: ID 0d8c:013c C-Media Electronics, Inc. CM108 Audio Controller

So, with a little googling for CM108, I found that the datasheet at http://www.halicky.sk/om3cph/sb/CM108_DataSheet_v1.6.pdf and also Kevin Custer's site about modifying it http://www.repeater-builder.com/projects/fob/startech-fob.html

When I opened up the device and compare it with Kevin Custer's photos, the most obvious difference was the missing capacitors.

Looking at the datasheet, it seems that the two 470 uF DC blocking capacitors was missing!
In fact, the PCB traces directly shorts the two pairs pads together. This explains why it works with speakers with built-in amplifier but not headphones. The audio amplifier circuits in the speakers probably has some built-in DC blocking capacitors at it's input or some audio transformer.


Missing DC blocking capacitors
So, I went to the local electronics store and bought some 470 uF capacitors. Unfortunately, they only have caps rated for 35 V and not have any smaller size ones with lower voltage rating.
This means that it will not be possible to fit the caps inside the existing casing. So I had to make 2 holes at the bottom casing to fit the capacitors leads and solder them upside down.
I also had to cut the PCB traces between each pair of pads as mention earlier.


In addition, I also had to cut the middle ring terminal for the microphone input because the tip and the ring was connected while my microphone's plug has ring and sleeve.

TipRingSleeve
Mic input jackMic InGnd
Mic plugMic InGnd


Cutting the middle terminal connection for the microphone jack
Finally, everything works properly. The audio input/output quality was ok and comparable to my built-in motherboard audio quality but it costed me extra time and money to fix it.

Final reassembled device with the huge capacitors!



Friday, April 3, 2015

Missing xterm on Linux Mint when installing Juniper Network Connect

I was trying to connect to company SSL VPN that uses Juniper Network Connect on Linux Mint 17 64-bit.

However, the network connect dialog keeps shutting down after launch for  a few seconds.

I've followed their support documentation at http://kb.juniper.net/InfoCenter/index?page=content&id=KB25230 but it was still not working.

After a bit digging around, I found the log fail at ~/.juniper_networks/network_connect/installnc.log shows missing xterm.

After installing xterm with sudo apt-get install xterm, I can finally connect successfully to the VPN.


Thursday, June 13, 2013

Changing nice level for transmission-daemon

Raspberry Pi has rather limited CPU power, so I wanted to reduce the priority of the transmission-daemon.
To do that I found that we can modify /etc/init.d/transmission-daemon script to add the --nicelevel option as below:

start_daemon () {
    if [ $ENABLE_DAEMON != 1 ]; then
        log_progress_msg "(disabled)"
                log_end_msg 255 || true
    else    
        start-stop-daemon --start \
        --nicelevel 5 \
        --chuid $USER \
                $START_STOP_OPTIONS \
        --exec $DAEMON -- $OPTIONS || log_end_msg $?
                log_end_msg 0
    fi
}


Monday, October 1, 2012

Running 2 ethernet connection over single CAT-5e cable

I already have an existing network cable wired from my router to my unifi iptv set-top box at the TV. Currently, I also have my HTPC connected to TV but it uses wifi for Internet connection. So I wondered if I could share the cable for both iptv set-top box and HTPC since wired connection is always better and more reliable than wireless. Adding a switch/hub at TV side will not work because the set-top box requires a dedicated VLAN port on the router that is different from general internet traffic. Since I know that ethernet up to 100Mbps uses only 4 of the 8 wires in CAT-5e, I wondered if I can use the other 4 wires for a separate network connection. I bought 2 RJ-45 splitter to try but realize they were wired parallelly (basically a Y connection for all 8 wires). Therefore I had to break open the splitter and with a little finger dexterity practice to rewire it as below [sorry for the diagram, drawing on tablet also requires significant finger dexterity :-) ].
After some wire cutting and soldering both splitters, I connected them properly at both ends and it really works! Even with heavy traffic from iptv, no error or dropped packets on PC ethernet connection.