Thursday, August 22, 2013

Roku 3 enhanced remote number two: repair

My second Roku remote has broken.  This is my replacement Enhanced Remote that Roku sent me under warranty.  About one month of use on this remote, and it has failed in the same mode as the first one did.  One of the antenna modules has fallen off, because the solder joint failed.


I posted on the Roku forums stating this is a design flaw.  Internal parts shouldn't fall off.  Some of the forum veterans replied, saying that they haven't heard of any failures like this.  I'm glad to hear that, because it wouldn't be good for anyone if this was a common problem.

Rather than ask Roku to replace it again, I've repaired it myself, shown in the pictures below.


In the second picture, I am showing the component staged before soldering.  I have soaked a piece of solder braid with solder.  Next I place it in contact with both solder lands on the board.  I added some paste flux, and then put the antenna in contact with the lands as well.  I heated the braid, which heated the lands, and hopefully the antenna leads as well.  Then I slid the antenna into place before the solder cooled.


In this third picture, you can see the reworked component, and a small bit of the lands extending out.  This took me about three tries to get an acceptable solder joint.


Next, I coated the board with silicone conformal coating.  I wish I had thought of a better solution though, because my goal was to make this an "indestructable"  repair.  I would have liked a stronger reinforcement like epoxy, since my solder job is probably not very good.  I would like the remote to last a decade if needed.  For example, my kids have been using the same single Wiimote since 2009.

The remote works, and probably will stay repaired.  The first remote would have continued to work as well, except that the loose component may have shorted somewhere, because that one stopped working altogether.

In conclusion, I still think that this particular design and manufacture process is flawed, regarding the attachment of these antennae.  It's also possible that my kids mistreated the Enhanced Remote, although I have taught them to be careful with things.  Either way, the company shares some responsibility when a solder joint fails.  Please share with comments if you have had internal parts fall off any handhelds, including phones, GPS, remotes, Wiimotes, calculators, etc.

Thursday, August 15, 2013

Bitcoin and cryptocoin lucky charms

Bitcoin and cryptocoin mining involves an element of chance as to how long it takes for each block to be solved.  What kind of lucky charms might be interesting to miners, if any?  I'm envisioning something rare, that might be placed on or near Bitcoin mining rigs.  Maybe a decal, precious metal, or a meaningful symbol.  How about putting magnets on your network cabling, or a wall clock with a tritium pendulum?  Post your ideas, I'd love to exploit them.

Wednesday, June 26, 2013

Roku replaced my remote for me

Internal parts antenna falls off

One of the antenna modules fell off inside my roku3 remote.  This is just inside the 90 day warranty.  It is debatable whether faulty soldering or extreme shock is the cause.  Roku gave the customer the benefit of doubt and replaced the remote at no charge.  That is the kind of company we want!

Friday, June 21, 2013

ADL detected more, less devices GPUs than OpenCL

Can't see all GPUs when mining

Where:  #bitcoinmining with #gentoo and radeon hardware.  AMD fglrx drivers.

What:  bfgminer, cgminer giving an error because it can't see both GPU

"ADL found less devices than OpenCL!
There is possibly more than one display attached to a GPU
Use the GPU map feature reliably map Opencl to ADL
WARNING The number of Opencl and ADL devices did not match!
Hardware monitoring may not match up with devices!"

Why:  You can't enable Xinerama if you want to mine with all your cards.  If you enabled Xinerama in CCCLE, go back in and turn it off.  You can use clinfo or bfgminer -n, to see which GPUs are available.  You may run into this while experimenting with multiple monitor setups.  I have also read that attaching more than one monitor to a card will cause its memory clock to stay at full speed.

Makin' bitcoins

Wednesday, June 19, 2013

Bitcoin Mining with Radeon Southern Islands FOSS Driver on Gentoo Linux

Mining with Open-Source radeon Southern Islands 7870

When I read that Radeon Open-Source drivers could do mining, I knew I wanted to try it.  I have multiple screens and I use VTs, so the OS drivers are better than Catalyst on all fronts: faster VT switching, better multiscreen support, and freedom.  I looked at the code at Tom's dev blog, and found that his work had already been merged upstream.  Since OpenCL was still a WIP for Southern Islands, it looked like a long shot.

I emerged live ebuilds for mesa, libdrm, libclc, and newer xorg-server, and BFGMINER 3.1.0-r1.  My 7870 began mining away, WOW!  Okay, well not too fast though.  Using Catalyst 13.04 I was running about 320 MHash, and with vanilla open-source I am only getting 50 MHash.  I didn't look into why.  It may be that the card is sitting in its low power state, with the GPU running 300MHz.  It could be that the code is not optimized for Southern Islands. Either way, I'm proud of the open-source community and these devs in particular for making this happen.  I am sure that we will have GCN kernels on 7990s someday soon.

#bitcoin

#bfgminer version 3.1.0 - Started: [2013-06-18 17:25:55] - [  0 days 16:40:15]
--------------------------------------------------------------------------------
 5s: 50.1 avg: 52.3 u: 51.7 Mh/s | A:722 R:9+0(1.2%) HW:0
 ST: 2  GF: 1  NB: 83  AS: 0  RF: 0  E: 0.98  U:0.7/m  BS:1.64k
 Connected to stratum.bitcoin.cz diff 1 with stratum as user blah.blah
 Block: ...1fe0db02 #242309  Diff:19.3M (138.4Th/s)  Started: [10:01:45]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 OCL 0:  34.0C         |  52.3/ 52.3/ 51.7Mh/s | A:722 R:9+0(1.2%) HW:0
--------------------------------------------------------------------------------

 [2013-06-19 09:49:06] Stratum from pool 0 requested work update
 [2013-06-19 09:50:03] Stratum from pool 0 requested work update
 [2013-06-19 09:50:52] Accepted 572cb86d OCL 0  Diff 2/1
 [2013-06-19 09:50:56] Stratum from pool 0 requested work update
 [2013-06-19 09:51:45] Accepted aa0edbf5 OCL 0  Diff 1/1
 [2013-06-19 09:51:52] Stratum from pool 0 requested work update
 [2013-06-19 09:52:30] Stratum from pool 0 detected new block
 [2013-06-19 09:52:32] Stratum from pool 0 requested work update
 [2013-06-19 09:52:38] Accepted 4f6995b7 OCL 0  Diff 3/1
 [2013-06-19 09:53:27] Stratum from pool 0 requested work update
 [2013-06-19 09:54:21] Stratum from pool 0 requested work update
 [2013-06-19 09:55:16] Stratum from pool 0 requested work update
 [2013-06-19 09:55:19] Accepted a8fa2501 OCL 0  Diff 1/1
 [2013-06-19 09:56:11] Stratum from pool 0 requested work update
 [2013-06-19 09:56:14] Stratum from pool 0 detected new block
 [2013-06-19 09:56:18] Stratum from pool 0 requested work update
 [2013-06-19 09:56:34] Accepted ba1ba833 OCL 0  Diff 1/1
 [2013-06-19 09:57:11] Stratum from pool 0 requested work update
 [2013-06-19 09:58:06] Stratum from pool 0 requested work update
 [2013-06-19 09:59:02] Stratum from pool 0 requested work update
 [2013-06-19 09:59:58] Stratum from pool 0 requested work update
 [2013-06-19 10:00:46] Accepted 92db9604 OCL 0  Diff 1/1
 [2013-06-19 10:00:53] Stratum from pool 0 requested work update
 [2013-06-19 10:01:45] Stratum from pool 0 detected new block
 [2013-06-19 10:01:46] Stratum from pool 0 requested work update
 [2013-06-19 10:02:38] Accepted 901e037e OCL 0  Diff 1/1
 [2013-06-19 10:02:42] Stratum from pool 0 requested work update
 [2013-06-19 10:03:36] Stratum from pool 0 requested work update
 [2013-06-19 10:04:26] Accepted bbb5494e OCL 0  Diff 1/1
 [2013-06-19 10:04:31] Stratum from pool 0 requested work update
 [2013-06-19 10:05:27] Stratum from pool 0 requested work update

Thursday, June 13, 2013

make: execvp: Permission denied

Where I was:  #Gentoo with SELINUX, running # genkernel all


What:  A build breaks, mentioning  make: execvp: Permission denied. (busybox was trying to build)

Why:  /tmp is mounted noexec.  make is trying to launch a script, (called gen_build_files.sh) but the script resides on /tmp thus the error.

Code snippet:
make: execvp: /tmp/genkernel/8529.32051.23452.9923/busybox-1.20.2/scripts/gen_build_files.sh: Permission denied
*make: *** [gen_build_files] Error 127
*make: *** Waiting for unfinished jobs....
*/bin/sh: scripts/basic/fixdep: Permission denied
*make[1]: *** [scripts/basic/fixdep] Error 1
*make: *** [scripts_basic] Error 2
My fix:  Temporarily set TMPDIR in genkernel.conf to another mount.  A fix for other instances of this error could be fixed by setting PORTAGE_TMPDIR in make.conf.