Shapeoko 2 calibration runs

Background

After some issues with accuracy drilling holes in PCBs and concern about backlash with the GT2 belt drive that makes some real machinists roll their eyes, it was time to do some initial calibration investigation.

Bill P brought in a USB microscope for such use some time ago, and at the great personal cost of a virus infection, Daniil found a good driver for it.  We put a viewer and the driver on the SO laptop and got pictures!  The lines scribed on my dear old 6″ Craftsman vernier caliper served as a good linear calibration reference.

MicroscopeMounted2334_HDRThe microscope friction fit perfectly in a scrap of PVC pipe we clamped in place of the spindle.  As a “crosshair”, we taped a .007″ strand of hookup wire across the bottom of the ‘scope.  We found we needed WholeSetup9831_HDRmore light than the little built-in LEDs provided when we zoomed in like we wanted, so we clamped a reflector lamp near by to provide that light.  Here’s the whole setup.

I had to disassemble the movable jaw from the caliper to let the ‘scope get close enough.  That’s the first time it’s been off in the 50+ years (!) I’ve LookingAtCaliper1910had that caliper.  It went back together perfectly after the testing.

MicroscopeViewThe image from the ‘scope was very nice.  The white stripe is the crosshair wire.  A finer wire would have been even better.  The marks shown are spaced at 0.025″.

 

The calibration runs

As soon as we started playing using UGS jog controls to move the gantry, the backlash was clearly visible.  We decided to record observations every 0.2″ for the 6″ of movement the caliper allowed, going first one direction, then coming back the other way.  Based on the informal backlash observations, we were careful to approach the initial mark going in the right direction.  We did a run each way in X, then moved the caliper and did another pair in Y.

Since the 0.2″ steps should always have fallen exactly on a (long) etch line, we recorded the error at each point.  We started out using “wire diameters” as the unit of measure, but as some errors became larger, we switched to eyeball estimates based on the 0.025″ line spacing.  The red lines are X, green are Y.  CalibrationChartThe dotted lines are coming back in the reverse direction (toward X|Y=0).  Observations:

  • Especially in X (solid red), the first couple of inches of steps were right on – and then got worse.  Similar patterns in all runs suggest some belt stretch.  Of course the X and Y stretch happening about the same place is coincidence.  (And no, I don’t think my caliper is stretched at that point.)  The fact that there’s a clear overall worsening of error with larger displacements from 0,0 supports belt strech.
  • Backlash is completely obvious.  Taking difference between average of observed values going forward and backward, average backlash on X is 0.0055″; on Y 0.0125″.  Similarly with max values, the worst case backlash on X is 0.0146″; on Y it’s 0.026″.  I wonder how new belts would behave.
  • In terms of the real-world task requiring the highest precision we’ve asked of the SO2 RelativeErrsso far – drilling PCBs – the results are “interesting”.  With holes from my favorite #64 drill at about 0.039″ diameter (black circle), the average absolute error in X (red) of about 0.0028″ and even worst error of 0.0053″ aren’t bad at all.  The Y (green) average error of 0.0062″ isn’t too bad, but the worst case error of 0.013″ is a third of a hole diameter – worth some concern.  (There must be a better way to present this visually.)

Of course the backlash observed with the microscope involved no loading of the gantry.  If we tried isolation milling of PCBs, adding some load deformation to that backlash might result in requiring much larger features (like traces) than we’d like.  Of course it would be much poorer than the photo PCB process, but at least it would involve no tool-rusting vapors!

Possible next steps

Another possible calibration approach would use an optical belt scavenged from a printer or scanner.  Its 350mm length is plenty to observe the full 200mm or so of travel on each axis.  From a good graticule on a loupe, I believe the lines are 1/180″ (0.00555…”).  A laser diode scavenged from one of the laser levels and some scrap lens assembly may focus the beam to small enough to resolve the lines at the focal point.  While the resolution isn’t as good as the microscope, with an Arduino sending gcode steps and counting bars, it could provide an automated tool with lots more points and no human error.

Given the possibility of stretched belts and Inventables price of $2/foot for 6mm G2 belting, a $10 investment in all new belts probably makes sense.  And with automated calibration runs of old and new belts, it would provide an interesting observation experiment as well as a probably a more accurate Shapeoko.

Posted in Shapeoko, Uncategorized | Tagged , , | 1 Comment

Shapeoko 2 PCB drilling – and scale error

Thanks to some urging from Steve S, we finally got geared up to try PCB drilling on the Shapeoko 2 at the space last Thursday (8/13/15).  (We had planned to use it to drill badge boards last September, but during initial accuracy verification we found it was off by a lot – 0.1″? – over 8 inches or so.  I was shocked, but we didn’t have time to troubleshoot it, and so bought a couple of Dremel drill presses and drilled all the boards by hand.  SO2 PCB drilling dropped out of view after that.)  The first test for Steve was again accuracy verification.  But this time it was over just a few inches, so I was pretty confident it would be OK.

We rediscovered that we used the pcb-gcode User Level Program in Eagle to generate drill gcode.  We downloaded the latest version, rediscovered how to use it, generated some gcode, and were ready to test.

Well, almost.  Since we wanted to drill from the bottom (foil) side of the board, we discovered that the gcode generated for a bottom drill was mirrored in X, with all values negative.  Bill, Steve and I did a LOT of talking and waving our hands around trying to get our heads around the problem and find a solution.  We finally did so, and after a couple of air-drills, mounted a #64 carbide bit and actually drilled the holes for Steve’s test adapter board in foam.  There’s little question that the machine can actually drill PCB material, so all we needed from the foam was an accuracy test.

It passed!  NiceHoles8836A piece of 0.1″ header – a quite accurate ruler/test gauge that’s always around – fit the holes for a header very well.  Steve didn’t have an etched board to drill, but went home happy with the accurately drilled foam for show and tell.

Nanino and the dreaded scale error

I was pretty confident that once we could get good gcode the SO2 would work, and wanted to bring a board we could actually drill that night.  I found a nice minimal, single sided Arduino (no USB chip) called Nanino.  I downloaded the Eagle files (thanks, robelix!), made up the board as usual, and it looked fine.  Or so I thought.  We generated the gcode, did the magic X axis inversion, used one of the fiducials I’d cleverly included in the corners of the board to set, jog, and reset workpiece home.  Just to be sure, we jogged to the opposite fiducial – and it was off – by more than 50 thousandths!  WTH?  We did lots of measurements, including with a digital caliper and the venerable 0.1″ header as ruler.  The problem was that board was just slightly too big.  And by enough that holes didn’t have a prayer of lining up all over the board.  We gave up on the board and went home.

ScaleCompare3209At home the next day, I did some more checking.  The check plot on paper – which I always do to make sure it’s placed correctly before printing the artwork on clear film – was much closer.  You can see the comparison on the left.  (The check plot is reversed wrt the board.)

This is the third time I’ve had boards come out the wrong size – but close enough to not be caught until it was almost time to populate the board.  The first was with latch boards for the never-finished scrolling LED display I inherited from Rich, Inc.  The second, and most expensive, was some 40 badge boards that got etched and some drilled GimpPrintSetupProblembefore we found it.  As I recall, at least one of those first 2 was due to some arcane print setting in gimp.  By ignoring or not, it decided to scale to fit the page under some rare circumstances.

BadPrintSettingThis one turned out to be similar:  In the Epson custom PCB printing settings I’d recreated after somehow losing them, I’d selected “Borderless prints”, which enabled some arcane “Enlargement” feature.  When I set that to “Retain Size” instead of “Auto Expand”, my plots using the custom PCB settings came out the same size as the check plots (which used default document settings that didn’t fall prey to “Enlargement”).  I resaved those settings as “PCB 2”, printed new artwork, and made up a new board.  This time a header actually lines up with the pads!

Drilled and working Nanino!

DrilledBoardFrameI took the board to the space, did all the magic setup and rechecked the far fiducial.  It was right on!  FinishedNanino3239We drilled a piece of paper, and the holes lines up with the board beautifully.  We drilled the board, and it looked great – probably better/more consistent than I could do by hand on the drill press.  (Sorry for only a fuzzy video screen snapshot.)  I stuffed and soldered the board, and got a working Arduino!  Although it doesn’t have an ICSP header, it’s still a very usable Arduino.  I’ve already tested it with strandtest and some Neopixels, and it works fine.

Gory registration details (updated)

A critical setup step to getting holes drilled in the right places is how to register the board so the X,Y coords in the gcode match the physical board.  Pcb-gcode will provide either or both top drill or bottom drill gcode files, and we chose to drill the board from the foil side – the ‘bottom’.  That adds an extra layer of obfuscation, since Eagle’s view is always from the top of the board.  I used Universal Gcode Sender to talk to the SO2’s Arduino running (hacked) grbl0.9g., so the instructions below are with that tool in mind.

I laid out a registration hole in each corner, such that the 2 holes along each edge changed only the X or the Y value.  That proved very valuable, though any 2 holes fairly far apart and whose Eagle coordinates were known would have worked.

Since we’re drilling from the foil side, the ulp rotates the board around the Y axis at X=0.  It picks the far right edge of the board up and flops it over into negative X space so you’re looking at the bottom of the board.  If the bottom edge of the board used to go from say X=0.2 to X=3, it will now reside at X=-0.2 to X=-3.  The Y coordinates are unchanged, but all the X coordinates are the same values, but negative (assuming they were all positive to begin with).   Knowing that the hole in the corner nearest the N in Nanino was at -o.85,0 and the second was at -2.7,0, I tried the following steps (now simplified using G92)and they worked.  This all assumes the board is accurately horizontal so if the bit is just clear of the surface at one point it will be just clear of the surface at any other point!

How and where we locate the board needs to reflect the X-axis mirroring we get by drilling on the foil side.  Say the board is 3″ wide.  Looking from the top/component side, some corner (call it the ‘home’ corner) will be near 0,0 in Eagle coordinates.  Instead of being near the corner of the plastic registration guides on the SO2, when viewed from the foil side, the ‘home’ corner will be out in the middle of the spoil board – maybe 3″ or 4″ to the right of the registration guide corner.  Nothing changes for the Y axis.

Place the board so the ‘home’ corner is off to the right and near the “bottom”/X axis plastic guide, and the left edge is comfortably clear of the far left registration guide.

BOARD REGISTRATION STEPS:
– Locate the board comfortably on the base and temporarily tape it down.  I used a corrugated cardboard spoil board under the PCB.

– Manually position drill bit precisely over one known hole (here, the one at -0.85, 0).
– Drill the hole using the UGS jog controls.  Drill into the spoil cardboard.  Raise the bit to barely clear the surface – maybe 0.5mm.  This will be Z=0.
 – In the UGS Command tab, manually enter gcode to set the workpiece coord system to match the coords of this hole.  Because we’re drilling the foil side, all the X coordinates – including this hole – are NEGATIVE – so be sure to reflect that.  For our first hole, that gcode would be:  G20G92X-0.85Y0Z0.  Never move the gantry by hand after this!
– Raise the bit up with the jog controls to give you access to the hole – maybe 2″.

– Now insert a pin (0.39″ diam rod or wire would be nice, but a 0.025″ square pin will do) thru the hole in the board and into the spoil board.  Gently untape the board.  At this time, the board and the machine’s coord system match at that one hole.
– Manually enter gcode to move to the absolute X,Y coords of another known hole and say 0.05″ above the surface.  Here that hole was at -2.7,0.  (G20G90G0X-2.7Y0Z0.05)  Going to Z=0 is risking the bit.
– Carefully rotate the board around the pinned first hole until the second hole is exactly below the bit.  If you can’t get it exactly below, you have some other problem!  At this point, your board is exactly in position.
– Tape or clamp the board down securely, and recheck the second hole.  Pull the pin out of the first hole.  You should be ready to go!

I hope that conveys what it took us a fair bit of time to become comfortable with.  I think Bill said he even found doc that corroborated what we’d figured out.

PCB design rules

Since we had some issues with how Steve’s board was designed – trace and clearance widths and hole sizes in particular – I’ll abuse this space to start collecting PCB design rules for the photo process (I and) Workshop 88 uses.  Folks accustomed to sending designs out to board houses think in term of different limitations than our homebrew PCB system requires.   Some of this is “how I’ve always done it”; some is what I think we can/can’t get away with.  Yeah, I suppose they could be entered into a design rules file, and while that’s exactly what the DRC is for, that seems somehow excessive for a hacker process.  But that’s probably just me.

Trace widths

My usual practice is 16 mil traces, with 24 or 32 mils for power and ground.  The photo process can handle those traces on a bad day, with a headwind, and when your timing’s off.  16 mils is way overkill for the current carried by most any Arduino-class project.  I’ve done 12 mil with little difficulty, and even a few 10 mil sections under duress.  And the 8 mil (!) traces on Steve’s board came out looking quite good, so my 16 mil traces remain VERY conservative.  I’m unlikely to change that standard.

Clearance between traces

I almost always leave (at least) 16 mil clearance between traces.  Again, this is very conservative for a well-tuned process.  I guess I’d have to say that 12 mils was quite safe.  I’d start getting uncomfortable  with anything less, tho.

Other clearances

I also try for 16 mil clearance between anything else – traces and the corners of pads, between pads, etc.  Since there are most aways some nice 16 mil traces nearby, it’s pretty easy to eyeball that clearance.  I guess I’d get uncomfortable with anything under 12 mils.  Obviously some SMT components force smaller clearances than that.  You do what you’ve gotta do.

Hole sizes

A perennial problem with component footprints from imported libraries is that the holes in the pads are too big.  I drill almost everything with a #64 (carbide) bit (0.039″), and if the hole in the pad is bigger than that (or even if it’s that size and I miss centering the hole a little), there will be an unsolderable gap between the pin and the copper pad.  I never want the process to make soldering more difficult than necessary.

I’ve redefined many parts so the pads have the smallest offered drill size – maybe 0.019″.  All the new footprints I make have those holes.  That way there’s a nice small target if I’m drilling by hand; the small hole helps center the bit; and there’s always copper all the way to the edge of the hole.

A possible downside would be if drilling with the Shapeoko and if the hole location and drill bit location didn’t exactly match, the centering effect of the hole might exert a lateral force on the bit, potentially breaking it.  I’ve never seen this happen, but I’ve only drilled a very small number of boards.

Pads and vias

I often use oblong pads to give a little more copper to solder to while increasing the space between pads in case I have to put a trace thru there.  By using oblong pads with holes near one end, I can get a little more space “down the middle” of dual row 0.1″ headers.  When I need a jumper, I use a via.  I try to make it 0.07″ or even 0.086″ so I have a fair place to solder to.  As always, holes are as small as possible.

Single sided prototypes for designs ultimately to be sent to a board house

I’ve made single sided boards as prototypes for designs I want to send to a board house, and had fairly good luck.  I try to minimize the number of traces on the back of the board, and use my oversize vias for the jumpers.  I route the trace on the other side of the board in Eagle, so I have indication where the jumpers go (although I obviously turn off the layer for that side of the board when printing).

Posted in Shapeoko | Tagged , , , , , | Leave a comment

Security camera

This is a sort of an append-only history of details of the camera project.  After I get all the software and server hardware running, I should make a nice concise writeup of the whole thing.  Someday.

IntendedTree2692

Overhang2690

I’ve about given up on trying to mount a security camera in a tree in the parkway outside the house, even though it would have exactly the view I’d like the camera to have.  Power is the issue – I could get the data to the house by radio.  If instead I mount the camera under corner of the generous eave overhang, I can get a workable picture, and I can get wires to the camera!  Pics here taken with my SD600 on the end of a stick, probably considerably different lens than the actual camera.

I got an Escam QD 520 PeashooterEscam 720p wired IP camera for $36/free on Ebay.  It supports ONVIF open protocol, so I hope to be able to cobble together something to grab snapshots every 10 minutes or whatever.  It defaults to 192.168.1.10, so I had to put a machine on that net to talk to it initially.  The camera contains a web server that requires Active-X, so IE is best.  With that, I reset its IP to 192.168.99.222 and tried it on the home network.  Pointing IE to it seems to provide a ‘live’ feed.  I’ve also been able to get VLC on the main PC to display the video (with more delay) using rtsp://192.168.99.222:554//user=admin&password=&channel=1&stream=0.sdp.  There’s also an ONVIF viewer app I can run on my phone or tablet.

FromBothCamsOK, let’s get some idea how the 2 camera lenses compare.  Here are pics from the same place (Escam is from 2″ lower than my SD600), matched at right edge, scaled to same width.  Original Escam was 970×540.  The Escam (top) gives a slightly wider but much shorter field of view.  With that lens comparison info and the outside pics above, I think I could move the camera a little closer to the door (but still as close to the outside edge of the overhang as possible).  I might have to give up a sliver of sky, but should still get a very usable view.

The camera seems pretty good (and seems to get good reviews) for the price.  It’s color and has IR cut for more natural colors.  It also has a light sensor and automatically switches to B/W mode and turns on its IR LEDs at night/low light.  That seems to work in an indoor test.  There’s an audible click when it changes over – which I suspect is mechanically moving the IR cut filter.  The IR LEDs glow dim red, which some reviewers looking for a stealth night camera have complained about, but isn’t a concern for me.

Software

I’ve seen a couple of references to getting a jpeg snapshot with something like this:

ffmpeg -ss 2 -i rtsp://ip:554/h264_2 -y -f image2 -sameq -t 5 /path/to/output/$MONT/$DATE/$DATETIME.jpeg

None of the ffmpeg binaries on my Win7 machine support rtsp protocol.  I installed it on the Dell Mini 9, but now it’s out of disk and doesn’t work well.  One more thing on the list.

Wiring

I made up a pair of passive POE adapters, using the brown/white pair bonded for +, blue/white for ground, with 2.1mm barrel connectors to match the camera’s connector.  (Orange/white, green/white are straight thru for the network.)  Seems to work with a 50′ patch cable between the adapters.  I figured the actual run at maybe 70′, so it’s probably OK.  I considered running a piece of lamp cord along with the Cat 5E for power, but I think I can get away with DC over those other 2 pairs.  I was a little reluctant to add the pair of RJ45 connectors – one essentially outside, though protected – but went that way for convenience of assembly, testing, repair, etc.

I got 100′ of brown Cat5E solid for the run.  Working in the attic won’t be fun, and I don’t really know how I’m going to get to the corner where the camera will be located.  I could probably take the USB-camera-on-a-cable up there with a laptop (or the Win8.1 tablet?), snake it down between the roof and the wall top plate on the end of a stick (8′ furring strip?) and get a reasonable view of what’s down there above the soffit, but that would probably cost an extra trip to the attic.  It would be really nice if I could make it all in one trip.

There’s already a piece of Cat5 run in the attic and thru the soffit right in the corner near the front door – diagonally opposite where I need it – but I can’t figure any way to use that to save the dreaded trip into the attic.

OK – I finessed some aluminum soffit down (thanks for the suggestion, Ed!) to get a look under it and found – wood.  There’s sheathing (presumably the old soffit) under all the aluminum near where the camera will be mounted – and probably everywhere else, as well.  Yeah, yeah, there must be some kind of vent holes – maybe only near the vented aluminum panel?  The good news is that I can mount the camera with longish wood screws instead of just sheet metal screws into the aluminum.  There’s 1/2″ between the main flat areas of the aluminum and the wood above, but I’ll deal with that later.

That means I can’t see what’s above that wood until I go thru it (and thru the aluminum!)  Ed suggested a hole saw – good idea – but since I’m working so close to the outside edge of the soffit, to locate the hole I need to know where the rafters are.  (Or more accurately where the “soffit bearers” tying the rafter ends to the wall are.)  Maybe I can find the nails that attach the fascia board to them?  Yes!  I RafterFinder3044made a nail finder by taping a nice hard disk magnet to a yard stick.  Sweeping that along the fascia board, it stuck very satisfyingly to (what I presume are) the nails holding the fascia to the rafter ends.  Very sensibly and conveniently, the aluminum fascia is attached with aluminum nails, so I don’t even get false positives from those.  Now I know where not to cut my access hole!

Given no access to nice long fiberglass fish poles, one possible approach for pulling the wire would be to plop a magnet on the end of a pull string up just inside the access hole, and fish for it with a magnet on the end of a 8′ furring strip that also had the USB camera attached by heading for the daylight.  If I can see any.  Maybe stick an index card up thru the hole to make a larger lighted target?  If I could set that up before I went into the attic, and if I could grab the end with the magnet and pull it up into the attic, I could tape the pull string to the end of the Cat5 I’d just run, leave enough slack nicely laid out so it would pull smoothly, go down and pull the wire with the string, and never have to go back into the attic!  If.

Progress!

FishingMagnet3084Here’s the magnet taped to the end of my 8′ furring strip “fishing pole”.  I left the original mounting bracket on and bent it hoping to bring the field lines from the stick surface of the magnet closer to the exposed surface, hoping to make it more attractive to the magnet on the pull string.  Time to go up to the attic.

CardInHole3052Here’s the view down into the soffit – much less obstructed that I’d feared.  (No USB-camera-on-a-wire needed.)  You can see the card I stuck thru the hole.  That worked out well.  It’s waaay over there, appropriate for having located the hole as close to the corner (where I originally wanted the camera) as I dared put it, considering the as yet unseen rafters, etc.  Time to go fishing.

PullString+Cable3055I never heard a ‘clunk’ of the magnets getting together, but they did, and on the first try.  And here’s the phase 1 payoff picture:  The end of the successfully fished pull string and the cable it’s DisturbedInsulation3074about to be taped to!  I was hoping for a selfie of me working in that corner of the attic, but it was way too unpleasant to bother setting it up.  Here’s the after-the-fact picture of the disturbed insulation where I was working.  It was beautifully laid down before.  You can just barely see the Cat5 to the camera sloppily running across the top of the insulation.

ABeautifulThing3063And here’s a beautiful thing!  Some might just see it as yet another hole in the house, or another wire dangling out of something.  But those of us who have been there and done that know it’s a FirstCameraTest3082Beautiful Thing.

Of course I had to see if I could actually get pictures over the new cable, so I hung the camera from a piece of baling wire, the crude POE pigtail dangling.  It works!

As I got the parts assembled, thought and rethought what I’d need to optimize that unpleasant forray into the attic, collected intel about where I could/should put the hole, I came to feel real urgency to get closure on pulling that dumb wire.  It was a huge relief/satisfaction when I got it thru.  Interestingly, now that it’s pulled, my feelings about actually mounting the camera and getting that all sealed up are much more “pretty soon, when I get around to it”.  I still don’t understand how my head works.

Getting pictures

The software that comes with the Escam includes a viewer that runs on IE (only) thru an unsigned Chinese Active X plugin.  It provides access to quite a variety of config parameters in the camera itself, including the critical IP address.  It displays video vlcsnap-2015-07-09-18h59m26s781streamed from the camera, and can record it.  There’s a snapshot button, but it always reports failure.  I did make a brief recording, played it through VLC, and used that tool’s snapshot feature to get the first actual still from the system.  This is essentially what the final 1280×720 results will look like.  I still have no snapshot software.  It looks like cameras like this often have a jpeg snapshot mode, but after playing quite a bit, I’m pretty convinced that this camera just doesn’t support direct jpeg.

I downloaded an Onvifer app to my phone that takes advantage of the open ONVIF protocol the camera supports.  Results – with the phone on wifi to the same segment the camera is on – are poor.  You can see a picture, but it’s usually badly distorted, and performance is surprisingly poor.  Fortunately, that wasn’t a target use case.  VLC on the phone provides good, smooth video.

ONVIF is just a standard management protocol to talk to the camera for internal params, PanTiltZoom, etc.  The actual streaming video goes over the also standard rtp over rtsp protocols.  Fortunately, those are standard enough that VLC and many other streaming players can start and read them, using the rtsp:// URL above.  The Onvifer dev replied to a rating comment I made on Playstore and included a pointer to the Windows app ONVIF Device Manager (hosted on the besmirched sourceforge).  That very nice software can also talk to the camera (on 192.168.99.222:8899) and mess with most, but not all of the in-camera params.  I guess only the supplied Chinese Active-X plugin supports all the local device extensions.

It’s quite interesting that now that there’s an actual video camera mounted up there, scope creep is rearing its head.  (OK, it’s not actually mounted there yet.  But Real Soon Now.)   The vision – from way back when I thought I could get the camera in the tree – was to get a still picture maybe every 5 minutes.  But maybe I should take advantage of the hardware and capture actual live video to some local storage.  Maybe 24 hours at 1 frame/sec, rolling over automatically?  Heck, storage is cheap.  A 38 sec test recording at 5 F/s was 5.5 MB, or 13 GB/day.  I guess thumbdrive flash isn’t suitable for the application, but I certainly have old hard disks that would hold that or a lot more.  Or that no-longer-hot-stuff 230 GB USB-connected external hard disk.  That’s 2 weeks @ 5 F/s!  And I bet that spare PogoPlug could handle it and maybe even serve it!  Of course there’s the question of how to make all that work, including snapshots, and freezing or archiving or something in case of emergency.  “But that’s just software.”

Looking at memory needed for stills, a jpeg compressed 16:1 compared to a png looked really good at 200% display in gimp.  That jpeg (still 1280×720) was 90KB.  The latest plus one/hr for 24 hours is 2.3MB – trivial even if I pushed them up to my hosting account.  Or I could just host them on the Pogo.  Decisions, decisions.

If I want to serve from a machine at home:  I had some free DDNS service, but I had to log in every so often to keep it active.  For the access I need to the home server, keeping a bookmark in my phone, laptop, tablet with just the IP address is probably good enough, especially given that the U-verse IP address doesn’t change often.  Heck, I could just put the home IP address off in a corner of the main HA page.

Mounted!

BaseMounted3124To get a sound mounting for the base, I put three 1/2″ thick wood blocks (with holes for the screws) between the aluminum soffit and the old soffit board.  The screws went through the soffit board, and it’s nicely solid.  I put silicone caulk under the edge, mainly to fill 3 wire chase holes, but later realized there’s such a gap between the camera ball and the big fixed part of the base MountWithWoodRelieved3140that the caulk was a waste of time.

Unfortunately, the ends of the blocks covered enough of the hole that I couldn’t fit the connectors thru any more.  A little work with a chisel made the hole usable, if even uglier.

To best protect the two RJ-45 connections that would live forever above the soffit, I took 2 steps.  TapedCablesPartA3136First, I sprayed the actual contacts with Caig Pro Gold G5 snake oil.  (I suppose I should write up my actively conflicted reactions to that stuff some time.)  AllTapedUp3145As outermost protection, I wrapped the whole thing – Cat 5 cable, POE splitter, OEM camera connector – with self bonding silicone tape.  First I did the easy part – camera and splitter – at the comfort of my bench.  Then I plugged the cable in and did the rest on a ladder outside.  A bit of incompletely wiped off snake oil softened/compromised some of the self bonding tape over the punch-down RJ female into which the cable was plugged.  Hope it lasts OK.

TapeSeparators3155The first part took just 10″ of tape; the outside part 5.5″.  It was easy to come up with those numbers after the fact by measuring the backing liner from the 2 pieces.

InPlace3149The final assembly was almost anticlimactic.  I’d managed to do things in the right order, and by that time I could get good live video on my phone, so even the last bit of aiming/alignment was easy to do standing on the ladder.  The soffit doesn’t look stained like that to the naked eye – not sure what caused that.  But the outside (and attic) work is all done!  Now it’s just computers and software. 🙂

Online!

Update 7/26/16: Just (barely) in time for our Kirkwood vacation, I have snapshots every 2 minutes from the camera, hosted on the Pogo.  Looks like our outside IP address thru U-verse is pretty stable.  Some look-up-my-ip site showed it as a static address.  I set up a cron script to check it and email me if it ever changes.  Anyway, a bookmark to that IP address in phone, tablets, laptop should be fine to find it even without DDNS.

I used a shell script calling avconv (successor to ffmpeg) to get the snapshots.  The camera doesn’t seem to serve the brief new sessions to get those snapshots if it is also streaming, so probably no 24×7 video capture.  Boo.

And in an inappropriate fit of boldness, I hacked my main home automation stuff to push the latest image out to the web server on my hosting account, and added a link at the very top of the page to the picture.  It seems to work, but changing both the main HA program and the main web page was a very brash thing to do hours before leaving home on vacation.

Update 10/19/15:  I just checked the latest pic, and it was from a day ago.  OK – now what?  I restarted the cron job on the Pogo with all watering turned off yesterday – could that have done it?  Then I realized I had zero recollection of how the snapshots worked.  Here are the current ugly details.

The script  ~/gosnaps running on the Dell Mini reads from the camera and writes a snapshot every 2 minutes to a hard coded path on the locally attached Free Agent external drive.  (I had unplugged the drive – wondering why it was plugged in – to use the mini as a portable controller for the watering while shutting it down yesterday.  I saw no need to plug it back in.  Wrong.  Dumb, but wrong.)  Gosnaps calls ~/putpic which ftps the latest pic to the Pogo, twice:  once with its timestamp name (like snap10-19-13-16.jpg), again as “latest.jpg”.  The hack referred to above is to 485pollC.pl to ftp latest.jpg up to the hosting server.  There’s a cron job on the Pogo to clean out pics older than 2 days, but nothing on the mini to clean off the Free Agent!  Fortunately, it looks like it’ll take a long time to fill it up.  Plugging the external drive back in seems to have fixed it.  Ubuntu automagically remounted it – thanks!

It’s a crude and non-resilient way to do it, but at least next time I’ll be able to look it up here.  (Which, after all, is why these notes are here!)  I guess I wanted to keep some pics, but didn’t want to thrash flash on a thumb drive or something.  I think I was reluctant to host it on the Pogo out of performance fears which I didn’t have time to confirm/allay.  Hopefully I’ll put something more appropriate in place before I break it again.

Update 7/26/16 ~2AM: I happened to notice that the “latest.jpg” was from 12:53 on 7/25/16 (yesterday).  After chasing a bit (doing ps and df on jimsdellmini and the pogo) it looked like nothing was out of disk, and gosnaps was still running.  I was very pleased to find these notes so I had a clue how this stuff worked.  Very suspicious was that there was a lot of stuff dated 7/25/15 – just a year ago.  Was there a collision since the timestamps had no year?  I think even when there’s a crash, files should just get overwritten, so I think that shouldn’t be a problem.

There was a comment in gosnaps saying
# Added timelimit in hopes of avoiding problem where avconv hangs for days if
# it can’t connect or something.  Not tested 🙁  12/3/15 jw
and it looked like avconv had a valid “-timelimit 60”, to kill after one minute.  There was a running avconv process:
jim       8940  3482  0 Jul25 ?        00:00:57 avconv -v quiet -timelimit 60 -vframes 20 -i rtsp://192.168.99.222:554//user=admin&password=&channel=1&stream=0.sdp -vsync 1 -q:v 15 -r 0.1 -t 1 -y /media/FreeAgent Drive/pics/snap07-25-12-55.jpg
– trying to write the next pic after the stuck one.  I killed that process, and it all started working again.  I hate to have to put yet another watchdog in to manage hung avconv processes, but if it happens while we’re out of town it would take an awkward double ssh session to get into jimsdellmini to fix it.

I suppose an additional watchdog on the GoDaddy host to check for old pic wouldn’t be too hard (as there are a couple already).  <checks wd2.pl script>  Oops – there’s already one there – with a threshold of 21 minutes.  <checks for text on phone>  Why didn’t it trigger?  Ahh – I bet the pogo kept sending the same “latest.jpg”, thus updating the timestamp on the host, which is what the script checks for.  I guess that script functions correctly to catch failure of the pogo to send pics – just doesn’t check the actual time of the pic.

Yeah, I suppose I could include a timestamp file as well as the jpeg, yada, yada.  Ugh.  I suppose the next approach would be a cron script on jimsdellmini to check for a hung avconv process, try to kill it, and report.  Ugh.  Or maybe just check for old timestamp on latest.jpg, try to pkill avconv, and send a text.  Shouldn’t be too hard.  Hmm – looks like jimsdellmini doesn’t know how to send text and email yet.  Still shouldn’t be too hard.  Of course, based on the timestamp in the comment, the problem has only happened about every 6 months.  How much effort do I want to put into it?  Of course if I’m on vacation when it happens…  Ugh.  But at least it’s running again today, and I know a pkill has some chance of fixing it.

Update 8/30/17:  This is a dup of an update to the “resurrecting the pogo” post.  I’ve been fighting on and off with being out of storage on the “camera drive” on jimsdell mini.  It’s been running a 1GB thumb drive for a while, and just failed again.  Thankfully the “house picture old” watchdog fired and sent email.  Turns out once again the drive was full.  There’s a cron job purging files matching a find -mtime +30, but that wasn’t aggressive enough.  After I manually deleted several days’ worth of pics, it started working again.  How many days’ worth will the drive hold?  It looks like nite pics are ~26KB, while day pics are more like 110KB.  Doing on ls |wc gave 10586 files, while df showed 658048K used.  So that averages about 62KB/pic.  At 24*30 pics/day, we burn about 45MB/day, so the 1GB drive should hold around 22 days of pics.  I changed the cron job to -mtime +15, so it should take care of itself now, and run around 30% free.  We’ll see.

Update 2/20/18: File space on the little camera drive is stable.

The camera proved extremely useful to support worry about snow removal while we were in Texas for a couple of weeks.  I’m not pretty interested in having more views.

After resolving a flurry of worry about my new iSmart C8018DN2 P2P camera exposing itself to malware with a firewall rule blocking all outgoing from its static IP, plus telling it both its gateway and both DNS servers were its own IP (that sucka ain’t gonna talk to nobody outside), I thought to worry about the ESCAM.  I used the sniffer cable I’d used for the iSmart and watched its traffic.  Nothing scary at all.  Some harmless ARP and bursts of RTP traffic every 2 minutes.  Good.

In the process, I checked and discovered that it does in fact have an open telnet daemon.  With the help of my friend Google, I discovered its root password was xmhdipc.  Very interesting, tho not useful.  7/21/19:  Wrong.  Since I can’t get in with the original unsigned Active X plugin any more, I can’t set the date.  But logging in (yes, root/xmhdipc) gave a linux environment, and the date command worked with immediate effect to change the on-video date.  Yay!

Update 8/6/18 on camera software: The snapshot processing train has failed from time to time.  Running out of disk space is a popular cause, but a hung avconv is a more insidious one after dumb disk management problems have been resolved.

Troubleshooting that has progressed, and there’s currently a section in gosnaps in the initial comments on finding a hung avconv, and even a script (gofix) to try to fix it.  I’ve made a couple of attempts at using some kind of timeout to keep avconv from hanging, but only added the linux sledgehammer facility timeout a few days ago.  This post is to document the possibility of a best case outcome that avconv doesn’t hang the snapshot system ever again.  (Of course, there’s a datestamped commend in gosnaps with that change as well.)  We’ll see.

Posted in Home Automation | Tagged , , , , , , , , | 2 Comments

Over engineered tennis ball on a stick

OETBOAS3049The lady said we needed tennis balls on sticks to clean the floor after the dance weekend, so that’s what we have.

The exit holes for the zip ties were surprisingly easier to drill than the entrance holes.  The cutout for the stick was best chomped out with a nice diagonal/wire cutter after a single access hole.  Though it left sharp places I didn’t like, there’s just enough of the free end of the ties to grab with a pliers if they need tightening.  That was a tough call.  There’s a chunk of closed cell foam from pipe insulation inside to spread the force of the end of the stick.  The hardest part was digging thru the collection of old broomsticks to select ones that provided proper chromatic bracketing of the ball color.

The whole thing, including the writeup took just under an hour.  Sometimes things go smoothly.

Posted in Home Repair | Tagged , , , | 2 Comments

Re-registered TPMS – despite FTDI

Background:

My new Prius 5 (not V) came with 17″ wheels/tires – rather than the 15″ ones that came with lower trim levels.  Great! (I thought.)  Larger tire diameter will translate to smoother ride!  Well, No.  The wheels are larger, but they have skinny/low aspect ratio tires for an overall near-identical diameter.  (P195/65 R15 vs P215/45 R17)

Some would say the skinny tires look cooler, but I don’t care at all.  Some would point out better handling with the shorter, stiffer sidewalls.  Look, I’m never going to push this family sedan hard enough to detect any difference.  But all agree the ride is significantly harsher, and (my wife and) I really don’t like that.

OldvNewI posted on Craigslist for a trade for stock 15″ wheels/tires.  Eduardo showed up a few days later, parked his Prius next to mine, and in less than half an hour we’d swapped all 4 wheels, shook hands, and he was off.  His tires had a few thousand miles, so he gave me $60 for the difference.  We were both happy with the trade.  (I was even clever enough to verify that his wheels had TPM sensors.)  My wife and I agreed the ride was much nicer with the new old tires.  Mileage is alleged to be a little better with the 15 inchers.  Great!

And then, of course, both our TPMS warning lights came on, as our ECUs no longer saw the TPMS IDs they expected.  He paid $20 at a tire shop to have his new TPMS registered, but I wasn’t quick enough to ask him to have them read the old TPMS IDs from his ECU.  I’ve heard Toyota typically charges ~$100 to read and reset the TPMS, so I thought 20 bucks at a tire place wasn’t too bad.

I had a cheapie ($8?) ELM327 Elm327BTBluetooth OBD2 adapter that would talk to the car, but wouldn’t talk to the ECU in charge of tire pressure.  MVCIcableFor that you need a much fancier adapter/cable and fancier software.  This goes for between $22 and $1500.  I chose the $22 version (with free shipping from China!)  OK, for this price, it’s cheap clone hardware and ripped, cracked software.  If I were using this for business in a repair shop, I’d buy the real thing.  But I’m not.

Fun with FTDI

The cable came with a driver (on an unlabelled writable mini-CD).  The driver wouldn’t install.  I even wrote to the Ebay vendor and asked for help.  But soon the light came on:  I FtdiAdapter3035remembered reading something about FTDI pushing out a driver that bricked counterfeit USB-serial chips.  I dug deeper and found the VID:PID of the MVCI cable was 0403:0000 instead of the expected 0403:6061 for the FTDI chip it pretended to be.  (An old USB serial adapter with a real FTDI chip was invaluable for checking PIDs, driver versions, etc.)  Sure enough, both the Win8.1 tablet I planned to use in the car with the cable and my main Win7 desktop were running the dreaded 2.12.00 FTDI driver.  And with that PID, even an old XP machine with an old driver wouldn’t recognize the cable.  (I did write back to the Ebay vendor and told him that the problem was with counterfeit FTDI chips.  Not blaming him for that – I knew what I might be getting into – but so he might help other customers with the same problem.)

After reading up on the situation – including a LOT of (justified) railing against FTDI (and Microsoft, for pushing the nasty driver out thru no-longer-well-trusted Windows Update) – I learned the damage was a ‘soft brick’ – just the PID rewritten to the invalid 0000 that made Windows not even look for a driver for it.  I tried the PID writer FTDI has on their web site (there are legit reasons to change the PID), but could never make it work.  Fortunately, I did get the ft232r_prog utility running on a Linux box, and rewrote the PID to 6061.  Of course plugging the cable into either the tablet or the desktop immediately broke it again.  But fixing again was trivial.

The 2.10 driver (freely available in the ‘No longer supported’ section on the drivers page of the FTDI site) was deemed safe, and I downloaded and installed it.  I managed to uninstall the 2.12 driver, and removed it from %Windir%\System32\DriverStore\FileRepository (after some sleuthing involving file dates.  I think from the dates I even figured which Microsoft KB update contained the driver, though I’ve lost that info.)  There are actually 2 drivers:  ftdibus.inf… and ftdiport.inf… .By going thru an ‘update driver’ dance including “Browse my computer for driver software” and “Let me pick from a list…”, I was finally able to convince both the tablet and the desktop to run 2.10.  When I plugged in the MVCI cable, it worked!

It looks like the mini-CD had version 9.00 of TIS/Techstream software, so the 9.30 I’m running must have been downloaded from somewhere.  It’s not hard to find (though I’m sure malware-infected versions abound).  There seems to be a TISKEY.exe file that somehow enables the pirated software.  While various sets of instructions say to choose the Europe locale, mine seems to be happy with North America.

TPMS IDs

OK, I had a cable that worked, drivers that didn’t brick it, and fairly current Techstream that could talk to the car.  Unfortunately, Techstream would only register user-provided TPMS IDs, but not read and report the IDs it saw.  The IDs are written on each TPMS – but on the body that lives inside the tire.  Not helpful here.

The devices to trigger/awaken the TPMS and read its ID were $150 or more.  I could justify the cost of the cheap Techstream/OBD2 stuff, as it has lots of potential uses, but the single purpose TPMS reader wasn’t worth it.  A call to my local Discount Tire (I’ve been quite happy with them) revealed that they would reset the TPMS  for free!  The service rep said to just pull into the tire check station in front of the last bay.  No paperwork – just ask them for a TPMS reset.  Great!

I pulled in but the tech could only get the front 2 IDs, possibly because the car sat and the sensors went to sleep, or (more likely) because he held the reader near the wheel instead of the tire, so the 125 KHz wakeup signal was blocked by the rim.  After failing on the rear 2, he couldn’t even read the front ones again.  He was frustrated and mystified, and I said thanks for trying and left.  A second visit a week later (with the car freshly moving as I pulled up) got all 4 IDs with no problem (front 2 matched first reading), probably using the same reader (but not the same guy).

Success!

With IDs in hand, I  fired up Techstream, navigated to the TPMS section and its Utility to register new IDs, and in only 2 tries, got all 4 tires registered.  I did a TPMS recalibration by holding the button hidden under the steering column for 3 flashes of the TPMS light, and went for a test drive.  The light stayed out, though I’ve heard it can take 20 minutes or more for it to come on.  (Update weeks later:  The light has not come on since.)

tire900After I got back I fired up Techstream again, went to the TPMS Data List page, and saw not only the IDs, but tire pressure and temperature data from each tire.  It must really be working!  The pressures after the drive were ~34 PSI, and the temps ~92F.  The capture on the right was taken later, after the tires cooled back down.

I need to do one more round of setting pressures precisely but maybe 3PSI over recommended, then recalibrating.  That will bring the low warning threshold up by 3PSI, so it should give earlier warning.  I’ll back the tires down to standard pressure after the calibration.  Then I’ll be all done!

Posted in Uncategorized | Tagged , , , , , , , , , | 3 Comments

‘Fixed’ 5.5V USB supply

There was a nice little wall wart USB charger in the electronics lab at the space for general phone charging, running Arduinos, etc.  But when I tried to charge my new phone (Moto G) with it, it wouldn’t  charge.  Huh?

ChargerLabel3025Looking at the label, it claimed it was good for an amp – nice.  And it said “5.5V”.  It was pretty light – no significant transformer – so I figured it was just another cheap 400V-cap-as-series-voltage-dropper supply.  OK, maybe 5.5V open circuit, then it would drop as it was loaded down.  Put a meter on it – sure enough, 5.5V open.  Loaded it to half or 3/4 of an amp – and it was still very close to 5.5V.  WTH!?  Was it really switcher?  (And why 5.5V?)  Looking at the output under load with a scope, there was a tell tale ~50KHz ripple.  Sure it enough, it was a switcher, and nicely regulated, too!

Lights began to come on:  Some sensitive devices will protect themselves from cheap chargers by refusing to charge if the voltage is too high (or too low).  And 5.5V really is out of spec for USB power.  OK, that’s probably why my phone didn’t charge.  (Wrong.)

But this is such a nice little supply.  Surely there is some way to use it!  I considered a healthy Schottky diode in series, but that was kind of crude.  Can I just hack it to lower the set voltage?

ItsASwitcher3024When I cracked open the sealed case, sure enough, there were in fact two small inductors.  An 8-pin DIP turned out to be a VIPer12A switcher controller with built in MOSFET.  Near it was a 4 pin opto isolator to provide feedback while keeping the output isolated from the line.  Nice.  As I looked around, I found a 1N4735 1W 6.2V zener.  That’s probably what I’ll have to replace.  Humpf.

The PCB was just single sided, and I started to look at the circuit.  That zener was DIRECTLY across the USB power pins.  Must be some kind of overvoltage protection – but clearly not what was regulating the output voltage.  I needed to dig deeper.

5.5VUsbSwitcher3014-700WireList3028To reverse engineer the bit of the circuit between the USB connector and the feedback opto isolator, after a couple of false starts I tried an approach I hadn’t used before.  I took a picture of the foil side of the board, labelled the traces, and then went about making an accurate wire list – which component was connected to which trace – with no effort to figure out what was going on.  Then I redrew the components into a rough schematic to see what was what.  That simplistic, mechanical task worked well for my foggy brain in the wee hours when I was working on this.  Maybe if I were more awake I wouldn’t have needed it.

InferredSchematic3027Anyway, this is what I came up with.  I couldn’t read the part number on the TO-92 transistor, so just marked its leads ‘T’ on the wire list.  I guessed about it for the schematic, but what I drew seems pretty likely, and makes sense.  Two blue metal film resistors with so many bands I couldn’t read them formed a voltage divider across the output.  That drove the feedback opto (via a transistor).  Great – tweaking a thru-hole resistor is easier than finding a specific non-standard zener.

HackResistor3019After a bunch of cut and try, I ended up with an extra 680 Ω in series with the lower (~10K) resistor.  That dropped the output voltage from 5.49 to 5.24.  That should keep anybody happy.

I epoxied the case back together, verified that it would in fact charge my phone, and tossed it in the box to bring back to the space.  Done!

Of course why they built this nice supply with a standard USB A connector but out-of-spec 5.5V output remains a mystery.

Update a hour later:  Damn.  I almost never write that I’ve done something until I’ve actually physically done it.  But I did it this time – and it bit me.  I did remeasure the output voltage (5.24V) after I closed up the case (while the epoxy was still wet).  But I finished writing the post before I tested it on my phone.  Sure enough, my phone does NOT in fact recognize the charger.  Damn.

HackResistor1K3031Update, a few hours later:  Wow.  Cut it open again and played with resistors some more.  With a 1K resistor, output was 5.18V.  Now that HAS to be OK.  Tried it with the phone.  Nada.

Using my USB breakout cables, tried the phone with my good HP power supply – at 5.0V.  Didn’t recognize it.  Swapped in another cable.  Same.  Tried it with another known good charger.  Worked.  Whoa.  Read up on USB charger wiring specs.  In the simplest setup, chargers are supposed to connect the D+/D- wires with <= 200Ω.  Shorted the data wires.  Phone now sees both the power supply and the rehacked (5.18V) charger.  Since the case was open, it was a one minute task to jumper the data pins inside the charger, and then both my phone and an iPhone 5C recognized it.  Wow.

I knew some phones – iPhones for sure – were fussy about the data lines and chargers, but I never thought MY Android phone would do anything like that.  But it does.  It probably would have worked at 5.24V – heck, maybe even at 5.5!  I epoxied the case back together again.  After it set, I re-verified that my phone worked.  Really this time.

So now I have what I really need – and thought I had at the beginning:  A nice general purpose charger/supply that will charge my phone (and most others) in the lab and provide 5(.18)V when needed.  I learn more stuff every day.

Update 6/30/15: It looks like that TO-92 device was probably a TL431 shunt regulator.  See updated schematic in the comments.  Thanks, er!

Posted in Workshop 88 Stuff | Tagged , , , , , , | 5 Comments

Low tech garbage pickup indicator

ViewFromWindow2994Garbage day always brings the question “Has it been picked up yet?” as I look out the window at the cans.  Sometimes I hear the trucks rumbling down the street and watch the mechanical claw pick up the can, dump it, and set it roughly back down.  But often not.  The well-designed emptying system rarely leaves the lid open showing the can has been emptied.

A scrap of 3/4″ white laminate covered shelf propped up against the can provides an extremely reliable visual indicator.  A similar Indicator2997sized chunk of furring strip serves on those rare occasions that I have to put both cans out.

It’s a pretty effective remote annunciator for something that doesn’t even have a processor in it!

Posted in Miscellaneous | Tagged , , | Leave a comment

Project Notes hacked

HandjobSantaI’ve had a problem over the past few months with someone hacking these Project Notes.  The symptom is a link with text “handjob santa” added very intermittently to the title block of the pages.  It has appeared immediately after “Jim’s Projects” and after “Workshop 88”.  The link points to a non-existent or expired domain (opengadgets.net/handjob-santa).  Thankfully, the hack isn’t very harmful.

HandjobSanta2I first saw it very briefly (and then not there – triggering the usual “Did I really see that!?” reaction) this April.  I called GoDaddy support April 18 but got no insight.  The rep raised the question of whether it might be a hack to my browser rather than the site.  Two kind commenters told me they’d seen it – Brad on May 3 and Andrew on May 13.  Thanks, guys!  So I’m not crazy, and it’s not just my browser.

Ssh’d into the root of my hosting account, I tried a find . -exec grep “handjob santa” {} \; -print , hoping to discover how the hack had been embedded.  Unfortunately, GoDaddy has a robot that kills processes that run for more than a minute or so, so that command didn’t complete.  I tried several variations of that find, including just running from the wordpress directory, but still got no joy.  Of course there are lots of ways to obfuscate a text string, so that was hardly a definitive exploration.

While googling for evidence of other sites with a similar hack, I found none, but was startled to see several hits on my own pages.  Of course following the links showed the current pages – with no hacked string.  But bless Google’s digital heart, the green link with the URL just below the main line in each hit has a pulldown which includes a link to a cached copy of the page.  Sure enough, those cached copies contain the hacked in link!  Now I had several nice static instances to examine.

SourceLooking at the page sources, the added links on both the “Jim’s Projects” and “Workshop 88” instances  were immediately before a “</div>” tag:  one at the end of the “site-title” div and the other at the end of the “site-description” div.  That might be helpful.

Armed with that, I called GoDaddy support again today (5/16/15), and Justin provided some valuable help.  He pointed out that it might be related to the WordPress “theme” I was using.  That makes sense.  If you wanted your hack link to show up well, the site title and description sound like good places to put it.

But even better, he had me check my WordPress dashboard to see if there was an update to my theme.  Such an update probably just overwrites the whole wp-content/themes/<this_theme> directory, and so might wipe out anything hidden in there.  There was an update, I installed it, and it might have fixed the problem!  Unlike my experience, Justin consistently saw the hack link on live pages of my site.  After the update, they were gone!

I made a script to get the filenames and sums of all the .php files under wordpress, and ran it to get a snapshot.  I think that will let me spot any changed .php files if it happens again.  I also tarred and gzipped a copy of the themes directory in case they do the same thing again before there’s a new themes version to conveniently overwrite the bad stuff with.

What a nuisance!

Posted in Miscellaneous | 3 Comments

Getting Tiny core working with Arduino 1.6.3

The first time I tried to compile for an AT Tiny84 with Arduino IDE 1.6.3, it failed with a warning and an error.  The warning was “Third-party platform.txt does not define compiler.path.”  The error was “Error while compiling: missing ‘recipe.cpp.o.pattern’ configuration parameter”.  I gave up and used good old 1.0.5 ERW, and everything was fine.

When I chased it a little later, I found that while high-low tech had a tiny core for 1.6, the google code hosted Arduino-tiny I’ve been using did not.  The latter did have versions for 1.0 and 1.5, so I downloaded arduino-tiny-0150-0020.zip.  When I tried that one the ‘recipe’ error went away, but the ‘compiler.path’ warning was still there.  It did compile, though.

I looked thru the platform.txt file for the main Arduino 1.6.3 install, and found this line:
compiler.path={runtime.tools.avr-gcc.path}/bin/

When I changed the platform.txt file in the new tiny core by replacing the line
compiler.path={ide.path}/tools/avr/bin/..
with the one above, the warning also disappeared.  While it would be nice if the Arduino-tiny kept fully up to date, at least my installation works (and with this note, I can rebuild it if needed.)

Boards.txt

I copied the boards.txt I’ve been using for some time (with tiny84@8 MHz and a hack to make the tiny2313 entry work for 4313s) to the new tiny core directory, and my boards showed up fine.  But when I tried programming a Tiny84 with an ICSP header and my USBAsp programmer, I had trouble.

I found a very helpful pointer that to program using a programmer (rather than the bootloader), there is an option in the IDE under File->Upload Using Programmer.  Cool!  I saw it work once, but later it complained “Error while uploading: missing ‘upload.tool’ configuration parameter”.  When I added this line to my boards.txt in the tiny84@8Mhz block, it compiled and uploaded thru the USBAsp:
attiny84at8.upload.tool=usbasp

I added corresponding lines to the blocks for tiny85@8MHz and tiny2313@16MHz (hacked for 4313) as well.  So now I think my 1.6.3 environment is up to date and stable for my favorite tinys.

Posted in Tiny 85 stuff | Tagged , , , , , | 2 Comments

Analog joystick

Joystick2768I found this nice-feeling joystick for $2 at Goodwill, and thought it might make a good controller for an early demo of the LED wall display at the Northside Mini Maker Faire.  I’d originally planned to use a drum pad, but this is probably better.

As a non-gamer, I had no idea what the interface to this thing was, and it had absolutely no brand/model info.  But the discovery/learning process went well.  Googling “image pinout 15 pin joystick” got me well Inside2760on the way.  An ohmmeter showed analog resistance changes on the X and Y pins, though the buttons were a little strange.  Opening it up let me ring out the cable and see what was going on.  Seems nicely made.  Joysticks were 100K pots to +5 wired as variable resistors.  All the buttons went thru a little PCB that got +5 and ground and was mounted to the “Auto” switch.  Seems to provide ~6Hz square wave auto firing on the trigger and big buttons (not on other 2).  Here’s the detail:

DB-15 Joystick    function     DB-15 to      Arduino
pin   cable color              Arduino color pin
1     Whi/blk    +5V           Red           +5
2     Blu        Btn 1 (trig)  Ora           A5
3     Grn        X1            Whi           A4
4     Brn        Btn ground    Blk           Ground
5     -            
6     Ora        Y1            Brn           A2
7     Blk        Btn 2 (big)   Blu           A1
8     -            
9     -            
10    Red        Btn 3 (left)  Whi           A3
11    -            
12    -            
13    Gray       Speed         Grn           A0
14    Yel        Btn 4 (right) Grn           A0
15    -

Arduino interface

ArduinoAdapter2775I found an old DB-15 female in the junk box and moved a couple of  wires around to get red/black for power and populate the other needed pins.

The pots give ~65K to +5 when centered.  To get a reasonable analog voltage from them, I made a voltage divider from their pins to ground with 43K.  Seems OK.

Arduino+Interface2783I needed 3 analog inputs plus 4 digital inputs for the buttons, and +5/ground.  I could almost get away using just the Arduino header row with A0-A5 and +5/ground, and that neat connection was very appealing.  So I cheated:  I tied one button (right) and the “speed” pot both to A0.  To read the button, do an analog read and check for near 0.  To read the pot, if the analog value is very low, ignore it.  I wrote a little test code and it seems to work OK.

Overall, it was a pleasant little adventure, and for $2 (plus some time) I got a useful controller for the LED display demo that will probably also be a useful input device for some future Arduino projects.

DrumPad2787And a big plus:  It lets me get the large, clunker Harmonix USB drum pad I dug out of the spider hole at the space out of the house and back to the hole!  That earlier intended wall display controller does in fact work (well, the 3/4 of it that’s still there), as demonstrated by the older, free Drum Machine windows app from Andrew Rudson.  But the joystick provides what I need with not only less work but with a smaller volume of junk in the house – and that’s a win!

Posted in Miscellaneous | Tagged , , , , , , | 1 Comment