Archive for December, 2011
The batteries I rebuilt for our much-beloved Sony DSC-F505V camera back in early 2010 have faded away with constant use. Having already sawed the cases open, rebuilding three of them didn’t pose much of a challenge; this time I added a short tab of Kapton tape to help extract them from the camera socket.
Three batteries seems to be about the minimax for ordinary use:
- One in the camera
- One in the carrying case
- One in the charger
You (well, we) can’t keep track of more than three: it always seems one battery gets overused and another gets lost in the dark. We’ll see how three works in practice; there’s a set of six more raw cells lying in wait.
The new batteries produced these results on their first two charge-discharge cycles:
One battery didn’t come up to speed on the first charge, but after that they’re all pretty close.
These were cheap-after-rebate phones with 2/3 AA NiCd cells that lasted nigh onto five years. We rarely talk on the phone and even more rarely use these, so they’re on the dreaded continuous trickle charge and low usage cycle that kills rechargeable batteries. Of course, they’ve been sitting there for five years…
The rebuild was no big deal, although I had to replace the original 360 mAh NiCd cells with 650 mAh NiMH cells (with tabs) because that’s what’s available nowadays. The trickle rate will be even lower relative to the capacity, of course, which may or may not be a Bad Thing.
The packs contained a simple fuse consisting of a thinned section of the usual nickel strap connecting two cells, covered with a fiberglass sleeve under the shrink overwrap. For lack of anything smarter, I harvested the fuse and soldered it in the new pack. although the risk of a catastrophic short seems fairly low:
The final result looks about as you’d expect, complete with obligatory Kapton tape wrap:
The old pack is kaput and new pack delivers pretty nearly its rated capacity at an arbitrary 550 mA discharge (which is, admittedly, a bit stiff for the old pack):
That takes care of one phone… the other one’s probably in the same condition, so I have enough cells to rebuild it, too.
The Skeinforge Craft window presents a formidable array of buttons, one for each possible plugin:
I’ve disabled many of those plugins because, for example, limiting Z-axis speed isn’t relevant on my printer. If you’re sure you won’t use some of the plugins, remove them by editing
In getCraftSequence(), located at about the midpoint of that file, duplicate the line that lists the plugins and add an octothorpe (OK, a hash) to make one line a Python comment, then remove the plugins you don’t care about from the other line:
def getCraftSequence(): 'Get the extrusion craft sequence.' # return 'carve scale bottom preface widen inset fill multiply speed temperature raft skirt chamber tower jitter clip smooth stretch skin comb cool hop wipe oozebane splodge home lash fillet limit unpause dimension alteration export'.split() return 'carve scale preface inset fill multiply speed temperature raft skirt jitter clip smooth skin cool dimension alteration export'.split()
This being Python, do not change the indentation. If you get overenthusiastic and toss something useful overboard or just pine for the Good Old Days, swap the octothorpe to your modified line to restore the original plugin assortment.
Save the result and you’ll see only the useful buttons:
There, now, wasn’t that easy?
The script I use to fetch screen dumps from my HP8591 spectrum analyzer works fine, but it turns out that the screen images have (at least) two sizes.
The hp2xx program converts the screen dumps from HP-GL text files to PNG bitmaps:
for f in *hgl ; do hp2xx -m png -c 1436 "$f" ; done
The usual size is 593x414 pixels:
The other size is 593x395 pixels:
As nearly as I can tell, the spectrum analyzer mashes the Y coordinate when any of the soft keys along the right edge have reverse-video highlights, which print as outlined boxes. There may be other sizes; those are the two I’ve stumbled over so far. This doesn’t much matter unless I’m using the images in a column, in which case it’s awkward to have two sizes: a one-size-fits-all script to trim off the soft keys doesn’t produce the proper results.
Musing on how to figure this programmatically…
The file command gives the pixel dimensions, with the file name (which may contain blanks: so sue me) set off with a colon:
file "SMD 470 pF - Surplus.png" SMD 470 pF - Surplus.png: PNG image, 593 x 395, 8-bit colormap, non-interlaced
Judicious application of cut extracts the relevant numbers, albeit with a trailing comma that requires another pass through the grinder:
file "SMD 470 pF - Surplus.png" | cut -d\: -f2 | cut -d\ -f4,6 593 395,
Although I think a sed script might be better, that requires more skull sweat than I have available right now.
Given that, then an appropriate mogrify would crop off the softkey labels; the first one is what’s in the script right now:
mogrify -crop "540x414+0+0" SMD\ 470\ pF\ -\ Comm\ Spec.png mogrify -crop "515x395+0+0" SMD\ 470\ pF\ -\ Surplus.png
Which looks like this:
The two sizes come out pretty close to the same 1.3 aspect ratio, but resizing the smaller one to match the larger doesn’t work well:
convert -resize '540x414+0+0!' SMD\ 470\ pF\ -\ Surplus.png SMD\ 470\ pF\ -\ Surplus\ resized.png
You need single quotes around the geometry parameter to prevent Bash (or Dash or whatever) from gnawing on the bang character (yes, that’s how you pronounce “!”).
The images are lossless PNGs because they consist entirely of single-pixel lines and characters; alas, resizing by non-integer factors close to 1.0 introduces nasty picket-fence aliasing artifacts:
I resize the pix by a nice, even factor of two (which also adds aliasing artifacts, but in small and very regular doses) and set the dots/inch value so the images print at about the right size without further hassle along the production pipeline:
mogrify -density 300 -resize 200% whatever.png
Which looks like this:
Resizing from the smaller images to (roughly) the final size in one step doesn’t look quite so awful:
convert -density 300 -resize 209% "SMD 470 pF - Surplus.png" "SMD 470 pF - Surplus large.png"
Like this, still with a distinctly garbled dBm:
But it’s decidedly better than this result from a two-step enlargement, although not as wonderful as one might like:
So the script needs a tweak for the file sizes, but …
Memo to Self: It’d be simpler to not have highlighted softkeys when doing screen dumps!
Just fielded a call from Credit Card Services that got all the way to 6:35 before the final disconnection!
Based on the conversation, we have a few more details:
The slimeball outfit identifying itself as Credit Card Services turns out to be a wholesale demon-dialing operation, which leads one to wonder why the FTC can’t figure this out and take some action. I mean, sheesh, CCS must represent a substantial fraction of the total voice phone call traffic; a few honeytrap numbers should be productive.
Anyhow, when you answer the phone and “press 1 to speak with an associate”, CCS farms the call out to a variety of back-end operations that evidently pay for live prospects (i.e., suckers). In this case, I was talking with someone working for “Client Services”; she was remarkably friendly and patient, which suggests she’s very new to this game.
The minimum balance they’re interested in has dropped to $3k. Used to be $4k; must be a sign of the times.
She wasn’t representing a loan operation, but was quite hazy about the details of how her organization would reduce my loan rates, other than that they “worked with the lenders” to that end. I pointed out that, while I wasn’t mad at her, she should understand that I’m reluctant to discuss my financial affairs with someone who really couldn’t describe the proposition in any detail.
She said that she could “do her best” to get me off the Client Services calling list, but that would have no effect on further calls from Credit Card Services, as other companies would be paying for those calls. She had no idea why “pressing 3 to discontinue further calls” didn’t work, of course.
So I asked if she had a supervisor that might be able to explain how the whole operation worked, she said she’d try to find one, and the next minute produced the usual clunks and tinks that presage a dropped call.
Perhaps the pleasant voices are “make money at home” suckers fronting for the loan sharks?
I’d wondered whether suppressing RFI by picking capacitors by their self-resonant frequency, so that each cap would suppress a known input signal. Turns out that’s entirely possible, even for the amateur VHF and UHF bands:
The three caps producing that trace look like this on the brassboard PCB for the Wouxun GPS+voice interface, with spectrum analyzer input & output through RG-174 coax with 22 Ω and 470 Ω SMD resistors tombstoned on the pads at the end of the string:
The scattered solder blobs cover Z-wires connecting the top ground plane to the continuous ground pour on the bottom surface. The solder strip along the edge joins the copper tape bonding the surfaces together around the perimeter. Basically, this is as well-controlled a layout as one can rationally get, without full RF matched-impedance zaniness.
However, the whack-a-mole RFI suppression concept makes absolutely no sense whatsoever for anything other than a mass-production board with rigidly controlled component parameters, which isn’t what you see here. Basically, ceramic caps have poor tolerances, bad thermal stability, and standard values too far apart to make fine tuning practical: lining up the self-resonance with a desired frequency requires trial-and-error selection for every capacitor.
Those peaks between the self-resonances can be much higher than you’d expect, too, because they represent parallel resonances where the total impedance can approach an open circuit. Remember that caps above resonance look like inductors and caps below resonance look like caps, so two parallel caps form a nice RL tank circuit for signals between their self-resonant frequencies. The caps have very low ESR, making the Q unreasonably high.
If you were hoping for / requiring broad-spectrum RFI suppression, paralleling caps will definitely make things worse, which is probably not what you expected, either.
The whole scheme also suffers from measurement error due to parasitic inductance from the position of the SA and TG “probes”. Compare this trace:
Made with the SA and TG connected to the same pad:
With this trace:
Which involves moving the SA input to a pad on the other end of the trace, the better part of 8 mm away:
Yes, those layouts are identical when you’re talking about signals near DC.
The pigtail leads certainly contribute some inductance, as does the the PCB trace itself. I suspect you could model that effect, but I’m not sure you could generate a predictive model without a 3D field solver and a whole bunch of calibration measurements. If you really care about the location of that self-resonant peak, I’m not sure which trace / layout you’d trust.
Of course, if you use a cap with a very broad self-resonant peak, then it’s all good. Except, equally of course, that I have no idea how you’d specify one of these to your purchasing agent:
That’s a 1 nF cap from the same assortment (made by AVX, a nominally reputable manufacturer, if the eBay vendor is to be believed) that produced the other peaks. Obviously there’s something different about those caps (and the 1.5 nF caps in the next compartment of the assortment, too): it’s not a measurement error! Notice that it has the expected high impedance at low frequencies, so you’d probably want a larger cap in parallel, which would give you at least a moderate parallel-resonant peak in between.
So if there’s a single frequency that needs squelching you can probably find a suitable cap by rummaging around in your assortment. More than that, though, just isn’t practical.
Just about the only other discussion I’ve seen about this comes from the folks at Ultracad Designs, who have run the numbers much further than may seem be reasonable, even by my standards.
I set up Xubuntu 11.10 on the Dell 531S driving the Thing-O-Matic, as the Unity UI seems surprisingly like crippleware: every feature that isn’t mandatory is prohibited. However, Xubuntu’s XFCE UI also has a long list of things that should be easy and aren’t, such as enabling remote desktop sharing. Gotta have that so I can fire up the printer and monitor progress from upstairs.
It turns out that the Vino server is installed, but not enabled, so you must start by firing up vino-preferences in a terminal to set some preferences:
This is a local machine behind a firewall, so a moderately secure password with no confirmation will suffice. Your paranoia may vary.
Then drill down through the menu from Settings → Settings Manager → Session and Startup to the Application Autostart tab, then Add the Vino VNC Server to the list: /usr/lib/vino/vino-server. You can start it manually if you have the hots for immediate sharing.
This seems to be impossible in Unity, trivially easy in GNOME, and unduly mysterious in XFCE.