Wednesday, February 11, 2015

Drying transformer oil

I acquired an x-ray head a bit back off of Craigslist:


and was experimenting with some screens:


to produce some images.  The setup is remotely switched and uses a webcam to view the intensifying screens meaning I don't have to be in the room while it runs.  I started to do some "low voltage" tests (maybe 50kV?) but didn't see any images.  I'm not sure what range the screens are sensitive to so I decided to crank up the voltage some.

In the past I had ran my head at 100kV for a number of experiments with no issue.  Unfortunately, as I turned up the voltage this time it generated an internal short a few seconds after turning it on.  Drat!  I had been warned these old GE heads can suck in moisture and its possible that's what happened

Fortunately, I drained the oil and it was still pretty clear indicating *potentially* no major damage.  So I'm taking two paths to get the system back online.

First, some cheap GE x-ray heads showed up on eBay so I picked up a few:




The bottom left unit is my original Craigslist special.  I have need of some high voltage DC supplies so I should be able to make use of  the lot even if they are excess to my x-ray needs.

However, these heads can still develop the same short if the oil has moisture.  I picked up some mineral oil and tried to dry it out under vacuum in a 2L reactor.  Unfortunately, it seemed to steadily bubble for some hours.

I talked to someone and they suggested that the trick is to get a lot of surface area to let the water out quicker.  So I tried to setup something resembling a vacuum distillation rig:


At the bottom is the 2L reactor with 24/40 joints.  The red hose is the vacuum feed.  The bottom hose has a siphon (like you'd find in a vacuum trap) that leads to a peristaltic pump (not shown) and then recirculates to the top.  From there it feeds a Vigreux condenser to give it lots of surface area to outgas.

I knew that the pump wouldn't prime under vacuum but figured it could be primed under atmosphere and then would circulate.  Unfortunately, the oil outgases heavily under vacuum, causing the pump to de-prime.

To solve this, the next step is to try to gravity feed the reactor into the pump.  Thus, even if it outgases, gravity will feed oil into the pump and cause it to prime under vacuum.  I'll likely have to put the reactor partly on its side which means that it could come apart and make a huge mess.  Most of the work will be trying to ensure this doesn't happen.  I have a clamp for the reactor lid and can tape the rest of the ports in.  Under normal circumstances, vacuum should hold everything together but it must be able to prime as well as survive returning to atmospheric pressure.

List of digitized chips

Collected list of chips that I know have had their layout, schematic, etc recovered: https://siliconpr0n.org/archive/doku.php?id=digitized

Sunday, January 4, 2015

siliconpr0n.org goes secure

I've had a self signed cert on siliconpr0n.org which had some limited use.  There should be a real SSL cert now.

EDIT: the map issue has been fixed

Thursday, January 1, 2015

Scaling up panotools some more

To recap, some things that I currently do to help stitch large IC photos with pr0ntools:
  • pr0nstitch.py: creates baseline .pto.  Instead of doing n to n image feature match, only matches features to adjacent images.  This reduces feature finding from O(n**2) to O(n)
  • pr0nts.py: creates image tiles from .pto file. This allows me to stitch large panoramas with limited RAM
  • Some misc wrapper scripts such as pr0npto.py that helped work around some peculiarities of tools like PToptimizer
For large panoramas, these were still a few problematic parts:
  • Big problem: PToptimizer is O(n**2).  Very slow for large image sets.  IIRC 1200 images took a week to optimize
  • Cropping and rotating .pto in Hugin is unnecessarily slow since I only use the outer images for alignment.  With n images only about O(n**0.5) are used
  • pr0nstitch.py was single threaded.  I recently picked up a beefy machine at a flea market and now had an incentive to take advantage of the extra cores
 Other issues:
  • pr0nstitch.py: I couldn't get cpfind to produce good results so I used closed source autopano at its core to do feature matching.  This has a lot of hacks to work through wine which is complicated and hard to setup
Lets see what we can do about these.

Regarding optimization, panotools has a tool called autoptimizer with a nifty feature: "-p Pairwise optimisation of yaw, pitch and roll, starting from first image."  This sounds a lot better than the O(n**2) optimization that PToptimizer dos.  Unfortunately, as stated, and, verified through my trials, it does not work for position.

So, I decided to try to see what I could do myself.  Most of the time is spent getting the panorama near its final position.  However,since the images are in an xy grid, we have a pretty good idea of where they'll be.  But better than that, since the images are simple xy transpositions we should be able to estimate pretty close to the final position simply by lining up control points from one image to another.  By taking the average control point distance from one image to another, I was able to very quickly construct a reasonably accurate optimized estimate.  The upper left image is taken as coordinate 0, 0 and everything is relative to it.  I then iterate the algorithm to fill in all remaining positions.  Presumably I could iterate the algorithm additional steps to optimize it further but at this time I simply hand off the pre-optimized project to PToptimizer.

This has a dramatic performance impact.  Here's some results from a project with 805 images:
  •  pr0npto --optimize: real    488m47.457s
    • Normal PToptimizer
  • pr0npto --pre-opt: real    0m58.843s
    • Pre-optimizer only with no PToptimizer final pass
    • rms error: 0.293938367201598 units
  • pr0npto --pre-opt-pt: real    29m39.604s
    • Pre-optimizer followed by PToptimize
    • rms error:  0.215644922039943 units
    • Took 3 iterations
--optimize and --pre-opt-pt should produce about the same final result.  I forgot to check what the final optimization score of --optimize was.  Anyway, above results show that the pre-optimizer was able to pre-position to better than average 1/3 pixel.  A final optimizer pass was able to slightly improve the result.

The next problem was crop/rotation.  There are two problems:
  • Its unnecessarily slow to create thumbnails for many images, most of which will just be thrown away
  • I'm not sure what the order of the preview algorithm is, but its much worse than O(n) on my laptop:
    • 74 images: 10.6 img / sec
    • 368 images: 2.9 img / sec
My solution: create a wrapper script (pr0nhugin) that eliminates the unused images.  This won't fix hugin's O(>n) issue but mitigates it by keeping n low.  Basically it deletes the unused images and opens a sub-project with the reduced image set.  After hugin closes the new crop/rotate parameters are merged back into the original project.

Sample results:
  • Original project: 368 images in 128 seconds
  • Reduced project: 74 images in 7 seconds
Original project in fast pano preview:



Reduced project in fast pano preview:



128 seconds isn't so bad but this is a smaller project and gets pretty bad for larger projects.  Could also probably eliminate every other image or something like that to speed it up more if needed.

Finally, I figured out what I was doing wrong with cpfind.  It was quite simple really, I basically just needed to use cpclean to get rid of the control point false positives.  Comparison of optimization results:
  • pr0nstitch w/ autopano: rms 1.09086625512561 units
  • cpfind/cpclean optimize pitch/raw/yaw xyz: rms 6.25849993203006 units
    • Only xyz should change, its optimizing things it shouldn't
  • cpfind/cpclean optimize xy: 0.510798407629321 units
    • IIRC this was through new pr0nstitch but can't recall for sure
Some quick tests  show that cpfind/cpclean meets or exceeds autopano performance.  Given the pains of coordinating through WINE (they have a Linux version but it doesn't work as well as the Windows one).

Now with the backend tool working smoother I was able to parallelize feature finding easier.  Basically pr0nstitch now spawns a bunch of worker threads that calculates features between two images.  A main thread merges these into a main project as workers complete matching sub-images.

There is also a stitch wrapper script that pulls these tools into a recommended workflow.

Summary of new round of improvement:
  • pr0nstitch.py
    • Parallelized
    •  Switch to panotools feature finding/cleaning.  Now fully open source and much easier to setup
  • pr0npto.py: new efficient --pre-opt-pt optimizer
  • pr0nhugin.py: hugin wrapper to edit reduced .pto files for fast editing
  • Added "stitch" workflow script

Friday, December 12, 2014

Need help: uxul.org data

The visual6502.org bulk data store has gone down:
http://uxul.org/~noname/visual6502/

Do you have any data from this before it went down?  If so, please contact me: JohnDMcMaster at gmail dot com

Wednesday, December 10, 2014

They're multiplying!

I've been continuing to troubleshoot the Super IIIA SEM and, by using putty, have discovered that the leak is in the column.  I'm having some trouble figuring out how to safely disassemble it to fix the leak.  More on that later.

In the meantime, I've been exploring alternate paths.  My ISI Super IIIA had a baby SEM!

I found someone selling an ISI M-7, a small tabletop SEM from the mid 70's.  The catch?  I had to drive from the SF Bay Area down to LA to pick it up (385 miles each way).  He is a semi-retired Cambridge SEM technician, not sure how the ISI unit got into the mix.  The landscape:


Its the blue unit on the right.

I was already aware that the PMT assembly had sustained some damage but was unsure how substantial.  Unfortunately the PMT tube itself was cracked:


Fortunately I found one reasonably cheap on eBay that's in the mail.  IIRC the Super IIIA uses the same PMT so I could borrow it from that if necessary.  Additionally, an IC came lose in the PMT base that doesn't really match with the socket.  Need to do some work to figure out what happened.

After sitting in the garage for some years it was a bit of a mess.  For example, here's a close up of the vacuum manifold:


After some cleaning it looked a lot better but still has a lot of rust:



Next, I wired everything up to the best I could given that not all the cables were still labeled:


I love the enormous military grade connectors.  It didn't come with an AC cord (requiring a military grade connector) but I was able to borrow one from the S3A.  A few other things are required in addition to the core equipment shown above:
  • Roughing pump
  • Diffusion pump circulation pump / cooling
  • Variac to step down 120VAC to 100VAC input voltage

Turned the power on and no smoke came out.  The "replace anode" light came on which I'm not sure what to make of yet.

Unfortunately I don't have a 5/8" adapter for my vacuum pump so I can't attempt to rough it down.  Ordered a $10 KF16 adpater from Tedpella, waiting for it in the mail along with the PMT replacement.

Sunday, October 5, 2014

Updated AmScope MU800 driver

Can be found here: http://lkml.iu.edu/hypermail/linux/kernel/1410.0/02700.html

Hopefully will get merged into the kernel soon.  Over previous candidate this fixes some minor formatting issues and removes a serial number comparison check (read: only would have worked with my camera).

I also have traces from an MU300 and might merge those in soon.  Shout out if you'd really love to see MU300 supported on Linux.