Friday, September 27, 2013

Underground Leak Location (Failed, but interesting)

My brother has a water leak in the plastic line between his house and the street. We don't know where the pipe runs and haven't been able to find a wet spot. It's not a huge leak, so he can just shut it off at the meter most of the time.

Cool Little Amplifier

The first problem is locating the pipe, we know where it is on both ends, but there's 400ft and a concrete driveway in between.

Options

  • I found ground penetrating radar first, but it would cost way more than just running a new pipe to buy and it's well out of my capabilities to build. Maybe in a few years, but we don't have that kind of time.
  • Metal detectors don't work on plastic pipe unless you put something metal in them (steel cable), which requires disconnecting the pipe. If we had a metal detector this would be a reasonable starting point. It's still on the table, but we have other options to try.
  • A smaller wire could be pushed down the pipe and connected to a small transmitter. Then a receiver would locate the signal and pinpoint the pipe.
  • With a ground microphone and an amplifier it's possible to listen to sounds under ground. A wrench or solenoid can be used to tap on the pipe, which will transfer down the pipe a ways and (hopefully) be audible near the pipes location. The leak may also be audible within a few feet.
Schematic - Pretty much exactly as in the source link

I've build a amplifier based on a circuit for an amplified ear I found on the internet. It seems to work good, but I'm having a real problem with the microphone. It will pick up sounds from all over, but nothing from the ground. I've tried several different ideas to transfer the sound, but so far I've come up dry. I think a piezo buzzer element is the key, and I managed to break the only one I had. I've got several more on the way, but it will be at least Saturday, probably Monday before I have them. We can't start digging before Monday (call-before-you-dig), so I'm hoping for Sat.

Prototype and RevA001 PCB

Results So Far

  • It's a really cool little amplifier, Q3 varies the gain of Q1 so that faint noises are highly amplified and loud noises have little amplification. If I can sort out the microphone problem it should work really well. It would also work great as an electronic stethoscope.
  • It doesn't seem to work as I intended to use it. I really need the digikey parts before passing judgement, but I think it should have a variable bandpass filter in it to isolate the desired noises. I can hear all kinds of stuff, but not what I'm listening for.
  • I ended up connecting a piece of wire to a fish tape, shoving it down the pipe and hooking a arduino clicking a relay that shorts a (low output) battery charger across the wire to transmit a clicking noise. I only had a 50ft tape so I couldn't trace much of the line, but it looks like a bee line. I used 30 turns around a cool-whip container (approx 15cm diameter) connected to the microphone input to listen for the clicks. It (barely) picks up the clicks, but AC lines are VERY obvious (loud buzz). I think I found the pipe and the end of the tape, but gave up as I didn't feel I was accomplishing anything. I could divide the pipe into (up to) 8 pieces and find the leak, but that would mean 8 potential future leak points (and 8+ holes to dig of unknown depth).
  • Unless the digikey parts are here tomorrow and I locate and fix the leak (unlikely) we're digging in a new line with a trencher on Monday. It's not looking good. I'm not shelving this project yet though, it would be very useful for locating noises in various equipment and it should work for finding pipes, if I can come up with a working mic. Perhaps I'll modify it for a bandpass filter too. 

Notes

  • R1 is specified as 10K, but my mic element specified 2.2K and worked much better with that. For the piezo transducer and the wire coil I disconnected the resistor.
  • The audio jack is connected with wires, I didn't have time to make a footprint for the one I had.
  • I did the PCB in a hurry, and I really should redo it, I make no promises as to it's performance.
Underside of PCB

Links


Saturday, September 14, 2013

Intel Hardware Video Decoding on Linux! VDPAU, VA-API, and Flash!

My laptop has a Core 2 Duo 2.4ghz CPU with an integrated Intel video chipset (GM45). It plays flash fine, but I wondered if I could get some HW decoding like the ATI. Here goes:

Intel supports va-api, not vdpau (required by flash) I'm running Arch on my laptop, so it may require some modifications to use on other distros (or it may not work at all).

Requirements

  • xf86-video-intel
  • libva
  • libvdpau
  • libva-intel-driver (only does mpeg2)
  • libvdpau-va-gl

Optional

  • libva-driver-intel-g45-h264 - replaces libva-intel-driver (in the AUR, it does h.264 on specific chipsets, but may be worse than software decoding)
  • vainfo
  • vdpauinfo

Setup

After the required software is installed "vainfo" should return the supported decoders. vdpauinfo will return an error. Create a file (as root) /etc/profile.d/vdpau_vaapi.sh containing:

#!/bin/sh
export VDPAU_DRIVER=va_gl

Save and add execute permissions (chmod +x vdpau_vaapi.sh). Log off and back on or execute the export command above and vdpauinfo should return the supported codecs. Then modify /etc/adobe/mms.cfg and uncomment or add 

EnableLinuxHWVideoDecode=1

Next in chrome://flags enable 

Override software rendering list

Now it should work!

Notes:

  1. This works with flashplugin (11.2). I haven't played with it much, but it doesn't seem to work with pepper-flash (11.8). It has lower cpu usage than 11.2 with EnableLinuxHWVideoDecode commented out in /etc/adobe/mms.cfg, but uncommenting it has no effect. Either it's looking somewhere else for that config or it doesn't support it. 11.2 drops way below 11.8 with it enabled.
  2. Obviously different chipsets support different codecs, some may not support any at all. The VA-API Wiki page linked below has some info to that end.
  3. The Chrome flag may improve overall performance or it may break things / slow things down. you'll have to try it and see.
  4. You can check chrome://flash and chrome://gpu before and after to see what changes.

Links

My PCB Fabrication Process

Desulfator

My last desulfator design was Rev B. I decided it should be Rev A (even though Rev B is etched on the board), as it was the first desulfator board I actually built. For future reference I'm doing major revisions A, B, C, but minor (and or pre release) tweaks 001, 002, etc. So this should be Rev A 003, I think.

For more information on the desulfator see my previous post here.

Specs / Limitations


  • When I do the layout I've found I can etch down to about 0.010"(50% success), but 0.020" is much more forgiving (80+% success). So I do most of my traces as 0.020". but they won't fit between some pins, so I run a 0.020" trace as close as I can, end it, put a 0.010-0.012 trace in the tight spot, end it, and continue with a 0.020 trace.
  • I try to maintain 0.025" clearance around traces, since I don't use a solder mask it helps me avoid bridging traces.
  • I flood-fill everything I can, the more copper I leave on the board the quicker it etches.
  • So far I only do single-sided boards. Hasn't been a huge issue yet. I'd be tempted to just order 2 sided boards when I need them.

I use the toner transfer method for both the etch resist and the silkscreen. As far as prep it goes like this:
Copper Side First
  1. Sand board with 400grit (wet sandpaper) wet with just a drop of dish soap
  2. Dry board with a paper towel
  3. Apply rubbing alcohol and dry with a paper towel.
  4. Print resist on a piece of shiny paper, I have varing results with this, seems to depend on the paper I find. I read that the (glossy) whites of newspaper / magazine ads worked the best, but I find that some heavily colored ads have more of the wax / clay stuff on them and work better for me, with the exception of the silk screen side (more on that later)
  5. Align board and paper, either fold the ends over to keep it in place or use a tiny piece of tape. Then run through laminator 5+ times.
  6. Soak in cold water until paper starts to dissolve. Some times it peels off, other times I have to rub it until just the toner remains. sometimes I loose traces and stuff, if it's not too tight I continue, otherwise back to step 1.
  7. Gently dry and examine carefully, touch up little holes in the flood fills and broken traces with a permanent sharpe(3 coats).
Etching
For etching I use cupric chloride, it works really good above 60F, somewhere around 40-50F and below it's really slow. It needs to work fairly fast, the majority of the problems I've had with it were when it's cold out and instead of 20-40 minutes it took 2-3 hours.

I keep it out in the garage, as I prefer not to risk spilling stuff like that in the house. (I don't want to spill it out there either, but I have better ventilation and access to a garden hose for emergency clean-up)

    8. Etch until traces are isolated.
    9. Rinse thoroughly, then Sand with 400 grit to remove toner, should look
        like this: (note the 2 is missing from the 2013? yep, didn't transfer perfect)
Bottom
Then the Front (silkscreen)
    10. Dry then drill two holes (for through-hole parts) as far apart as possible
          (either corner would be good) and use them to align your silk screen (do
          steps 3-6). I poke a wire right through the board and paper for alignment.
          (remove wire before running through laminator) Note: I try to use mostly
          white paper for this as the colors tend to stick.
Top
When it's all assembled and tested I spray the copper side with several thick coats of Rust-Oleum clear coat.

Thursday, September 12, 2013

ATI Hardware Video Decoding on Linux! VDPAU, VA-API, and Flash!

XKCD - Supported Features
I love that XKCD. Anyway, I built a HTPC / home server around a Biostar Deluxe A681-350. It is powered by a AMD E-350 APU that combines a dual core 1.6ghz cpu and an ATI Radeon HD 6310 gpu on one chip. It's a low end system, but I don't need a lot of power here. It handles full screen 1080i video from an ATSC tuner beautifully. It won't play 360p flash smooth at 1/2 screen, and it's a slide show at full screen (1920x1200). It just doesn't have the CPU to decode and scale video. Mythtv uses hardware scaling, so it only has to decode on the cpu, and ffmpeg's software decoders are well optimized.

Today I installed Arch Linux on it. This post was going to cover that, but I discovered hardware acceleration for flash on ATI chipsets works!

Comparison

  • With software decoding and rendering flash takes 60-75% of my total cpu time (windowed, scaled as large as smooth playback allows).
  • With hardware decoding and (possibly?) rendering it takes 10-25% and plays smoothly full-screen.

 Requirements

  • A very up-to date system. (Arch hasn't supported it long, most distro's will probably take some time to, but you may find a ppa or can always compile from source)
  • kernel 3.10+
  • mesa 9.2+
  • libvdpau
  • ati-dri
  • xf86-video-ati
  • flashplugin

Optional

  • vdpauinfo (print info about VDPAU (and show's it's working)
  • vainfo (same as above, but for VA-API)
  • libva-vdpau-driver (allows va-api enabled apps to be accelerated)
  • libva

Setup

Assuming you have installed all these packages vdpauinfo should spit out a bunch of information on what's supported. If it doesn't you may need to specify the driver. I didn't need to, but you might (shouldn't) need to add something like this to your environment variables:

VDPAU_DRIVER=

Flash probably won't work until you edit /etc/adobe/mms.cfg and uncomment the line:

EnableLinuxHWVideoDecode=1

I haven't tried it in anything but chromium, so I'll stick to that for now. In chrome://flags I had to enable

Override software rendering list

Now Flash should have hardware decoding! MythTV can be configured to use vdpau decoding and it works nicely too.

VA-API

(I haven't messed with VA-API much, so this may or may not work.) For VA-API it may be necessary to add the following to your environment variables setup. (you don't need this for flash, it only supports vdpau)

LIBVA_DRIVER_NAME=vdpau

One way to do this is create a file (as root) /etc/profile.d/vaapi_vdpau.sh containing:

#!/bin/sh
export LIBVA_DRIVER_NAME=vdpau

Save and add execute permissions (chmod +x vaapi_vdpau.sh . Log off and back on or execute the export command above and vainfo should return the supported codecs.

Notes

  1. It only works with the open source driver, though there is a way to get it in fglrx. (see https://bbs.archlinux.org/viewtopic.php?id=166593&p=1)
  2. Before "top" shows flash using 120-150% cpu. After "top" shows  20-50% (dual core = 200% max)
  3. This works with flashplugin (11.2). I haven't played with it much, but it doesn't seem to work with pepper-flash (11.8). It has lower cpu usage than 11.2 with EnableLinuxHWVideoDecode commented out in /etc/adobe/mms.cfg, but uncommenting it has no effect. Either it's looking somewhere else for that config or it doesn't support it. CPU usage under 11.2 drops way below 11.8 with it enabled.
  4. Obviously different chipsets support different codecs, some may not support any at all. The VA-API Wiki page linked below has some info to that end.
  5. The Chrome flag may improve overall performance or it may break things / slow things down. you'll have to try it and see.
  6. You can check chrome://flash and chrome://gpu before and after to see what changes.

        Links:



        Tuesday, September 10, 2013

        Arch Linux Fun

        I just installed Arch Linux on my laptop, because I apparently have nothing better to do. OK, that's not true, there are lots of things I "Should" be doing, but today I'm messing with Linux instead.

        Arch Linux with Cinnamon and an Awesome Wolf Background

        Live USB Boot 

        I hit a snags right off the bat. I installed the arch iso to a thumbdrive with unetbootin and it seemed unable to locate the media. Just sat there saying "Mounting '/dev/disk/by-label' to '/run/archiso/bootmnt'" and "Waiting 30 seconds for device /dev/disk/bylabel". After a brief search I discovered this was a common problem and the simple solution was to "dd" the image over your thumbdrive. Uh, what about the other files on there? Arch needs to work on this. I know Ubuntu and Parted Magic both fine from a unetbooting usb. So I hunted a bit more and found you can specify the right device as "archisodevice=/dev/sdb1" for example. Ha! too easy, if I specified it as sdb1 it would detect the usb drive as sda. Change it to sda and it's detected as sdb. WTF! Finally I set it to sdb1 and pulled the drive as soon as the kernel had loaded, plugged it back in and it booted right up. Whew, what a PITA just to boot a live USB!

        Installation

        The installation was complicated compared to Ubuntu or Mint, but I just followed the beginners guide and it went smoothly. Wifi worked and everything. I highly recommend a second computer / tablet / etc. on hand if you decide to install Arch. One reason I wanted Arch was the lack of junk cluttering up my system, things updating in the background, etc.I admit I install a bunch of junk myself, but at least I have some control. It took a couple hours, but I have a usable OS on my laptop. Lots more tweaking to do yet. Seriously, it took longer to get the usb to boot than install the system.

        Things I Like

        There are a lot of really nice features that appeal to me.
        • Boots unbelievably fast.
        • I'd eventually like to have a single distro on all my computers. With Arch you can do a headless server, a media center, a desktop workstation or a portable laptop. The base is the same, just install the packages you need for your application.
        • A local package cache / repository on my HTPC / Server would be cool. Most distro's can do that, so I don't know that this is a major plus, but it's availible.
        • I don't mind the pacman / apt-get / emerge command line tools, but synaptic is slow, and the "linux app store" doesn't appeal to me. So far I love yaourt when used with yaourt-gui, a bash gui for yaourt. It take a little fiddling to get installed, but it will manage pacman, AUR, etc. quickly and beautifully.
        • The AUR, it's huge! if you can't get an official package, it's probably in the AUR.
        • Arch doesn't hold your hand with tons of helper scripts to make everything "just work". While that can be good or bad, I'm counting it a good, as you get a better understanding of what's going on right from the start. That (hopefully) makes problems easier to solve later.
        • It's more up to date. I loved this about Gentoo, that you had recent packages. I installed MyPaint, because it works nicely with my laptop's Wacom penabled screen, and there are all kinds of buttons and options that weren't there on Ubuntu! Ubuntu has 1.0.0-1, Arch has 1.1.0-2.
        • Rolling release. In theory once installed I should never need to re-install. just update the system when I feel like it.
        • No "Update Manager" nagging me to update all the time. I hate windows for it's constant updates (always at inconvenient times) and some Linux distros seems to want that "functionality" too. It's running in the background without my knowledge too, I don't like that.
        • No "error reporting" pop-ups I get too many of these for a supposedly stable system, I understand the need for error reports, but I'm watching a movie and have to get up to get that dumb window out of the way.

        Things I Don't Like

        • Arch is MUCH more complicated to install as opposed to Mint or Ubuntu. It didn't take me that long to have a working system, but I wouldn't recommend it to a beginner or at least not as an introduction to Linux. I used to use Gentoo, which I feel is even more complicated, but just didn't have the ambition to keep it working.
        • The installation ISO really sucked for me, YMMV.
        • I have a working system, but it's not nearly as pretty or complete as Mint 15 yet (I installed Cinnamon). I foresee a lot of tweak time to get it just the way I want. This may lead to frustration, like Gentoo years ago. I dropped Gentoo because, at the time, it took a ~3 days of compiling to install the base system and get X running with the basics (Firefox, Fluxbox, file manger, etc.) and the better part of a week for a full desktop environment (KDE at the time).

        Conclusion

        So far I like what I see. The install was a bit aggravating, but I shouldn’t have to do that too often. I love yaourt-gui, it really makes package management quick and easy.
        I think I'm going to swap my HTPC / Server over to Arch eventually. I have some performance issues with Mint 15 and haven't been able to track them down. I don't know if it's Mint or just the my hardware. Either way I hope I can squeeze a little more out of Arch.
        If you have an excess of free time try it, it's easier than Gentoo and you end up with a distro that's tailored to you. All the stuff you want with none of the stuff you don't.

        Links:

        Arch Linux - https://www.archlinux.org/
        Yaourt - https://wiki.archlinux.org/index.php/Yaourt
        Awesome Wolf Art Source - http://www.deviantart.com/art/wolf-324819837