SugarSync disaster

It's not often that I have such a bad experience with a product or service that I feel like I need to write about it, but I'm downright angry with SugarSync. I set up this service several months ago to keep files (source code, business documents, and reference materials mostly) in sync between my home desktop, office desktop, workbench, and laptop. It seemed to be working OK at first, but things got progressively worse as time went on.

Here's the shared folder where I keep my Quickbooks files:

Argent Data Systems (from Jupiter) (Backup Apr 04,2010  06 26 PM).QBB
Argent Data Systems (from Jupiter) (Backup Jun 05,2010  06 40 PM).QBB
Argent Data Systems (from Jupiter) (Backup Mar 01,2010  08 04 PM).QBB
Argent Data Systems (from Jupiter) (from Workbench).QBW
Argent Data Systems (from Jupiter) (from Workbench).QBW.ND
<dir> Argent Data Systems (from Jupiter) - Images
Argent Data Systems (from Jupiter).QBW
Argent Data Systems (from Jupiter).QBW (from Workbench).ND
Argent Data Systems (from Jupiter).QBW.ND
Argent Data Systems (from Jupiter).QBW.TLG
Argent Data Systems.QBW.ND
Argent Data Systems.QBW.TLG

Keep in mind that I only have Quickbooks installed on one machine, so these files have never been opened or locked on another PC. Yet the files show up like they were edited in multiple places at the same time and the service couldn't resolve the conflict.

Much, much worse is what it did to my source code. I'd work on a project, come back a few days later and edit some more, and then find out that when I'd opened it the second time it had synced an old copy from another PC and I was editing that one. I've had to spend a lot of time with a diff utility trying to merge the changes.

Their support is worthless. All I can get out of the SugarSync people is that it's working as designed and making duplicates of locked files. Yet somehow it also manages to do this with files in my music collection that haven't been edited since 1997. It's also truncated photo files and made them unusable immediately after they were synced.

It looks like I essentially paid $99 to have an application trash my files in insidious ways. Avoid this service. I still need file sync, so I'm going to look into Dropbox or another competitor, but I'm very unhappy with how this turned out.

Cuyama Balloon Launch

Just got back from a very successful high-altitude balloon launch. The original intent was just to prove some hardware and software modifications prior to a bigger upcoming launch, but at the last minute I decided to fly a camcorder in addition to the tracker payload. I put together a housing for the camera yesterday in about 10 minutes, milling out a chunk of foam on the MDX-20 and taping on a piece of scrap polycarbonate for a window.

The kids and I left home around 6:15 this morning and set up in a field by Cuyama Elementary around 7:30. We had some ground equipment hiccups - my netbook (normally good for 4-5 hours on one charge) was totally dead, for starters. Apparently either the serial adapter or the USB GPS receiver I'd plugged in the night before had kept it from hibernating properly. My TH-D7 also refused to turn on, despite having been on the charger all night.

The nuvi 350 and Tracker2 combination was working just fine, though - the only deficiency being that I hadn't set it up to be able to see the balloon's altitude. The D7 provided that, so long as it was plugged in to the car, so it wasn't a major problem.

Launch was at 7:45 in very light winds. It was immediately clear that the balloon was rising more slowly than planned - I think I miscalculated when setting up my calibration weight. The ascent rate was about 400 feet/minute rather than the planned 1000 feet/minute. This pretty much threw my predictions flight path predictions out the window. We drove out to Mettler anyway and stopped there to see what it would do.

When it looked like the balloon was going to keep heading east at 50+ MPH, I decided to take 138 out to 14 and hope that it'd make it over the mountains. Before I made it to 14, though, the balloon turned completely around and headed west again. We circled all the way up to 58 and were somewhere between Tehachapi and Arvin when the balloon burst. Bill Brown, WB8ELK, called me at about this point to provide his landing prediction.

Rod, WB9KMO, had joined in the chase not long after the launch and was first to the landing area - which turned out to be only a few miles from where we'd stopped in Mettler. We met up with him about a mile from the last APRS fix, and followed that to within 1/4 mile of the landing site. I got about 50 yards from the car before I spotted the foam payload housings and the remains of the balloon in a plowed field.

Everything was intact, and I got about 2 hours of video from the Flip camera. Not enough to capture the burst and impact, unfortunately, and it spins about as much as I'd expected, but for a 10-minute job I can't really complain.

The maximum altitude reached was 113,876 feet - not too bad for an 800-gram balloon. Payload weight was about 350 grams, most of which was the camera. The lowest recorded internal temperature was -19 Celsius, and the lowest pressure was 381 Pascals. Total flight duration was about 3 hours 20 minutes.

This whole thing involved rather more driving than I was expecting, but I'm very satisfied with the results. The updated tracker firmware performed flawlessly, the GPS receiver worked as expected at high altitude, it withstood very cold temperatures over a much longer than expected flight, and the lighter, less tangle-prone 16" rubber duck antenna proved to be more than adequate, even at 500 mW.

Video to follow shortly.

Balloon Launch

Just launched a new balloon payload this morning. As I write, it's headed for Point Arguello at 16,000 feet. More info here later. Above is what the payload looked like the other day during testing.

http://aprs.fi/?call=N1VG-11

The payload is a custom board with an OpenTracker+ RT series tracker, temperature and barometric pressure sensor, SRB MX146LV transmitter, two CR123A batteries, a USB interface for configuration, and a Prolific GPS receiver (not the one pictured here). It's all sealed in 2" heat shrink tubing. The temperature just reached 1C, hopefully it'll stay warm enough.

Standalone MON08 Device Programmer

Abraham Lincoln once said, "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." In that spirit, I spend a lot of time building and refining the tools I use. So far, I've never regretted a minute of that effort, regardless of how much of a pain it was at the time.

My packing bench automation system is probably the best example of that, and I'll devote a post to it some other time, after I've added a few more of the features I've got on my list. But here's what I've been working on for a good portion of the past week:

It's a prototype of a standalone device programmer for Freescale HC08 microcontrollers, like those used in the OpenTracker+ and Tracker2. It's shown here with anMC908JL16 processor for the OT1+, which is presently the only thing it's set up to work with.

The hardware required to connect to an HC08 is actually very simple. I built my first programmer (way back before the OpenTracker 1) with parts I found in my junk box. I later upgraded to a board I bought from an outfit in the Czech Republic, and eventually to a USB pod from P&E Micro, of which I now have roughly a double handful thanks to package deals on development kits, freebies from Freescale, seminar handouts, and so on.

But all of those have required the use of P&E's programming software. Fortunately it's available for free, but they don't make it easy to find, and more importantly, they don't want you using it for automated production programming. For that, you'll need one of their $500 or $900 gadgets, or a nicer ($1200 + programming algorithms) system from one of their competitors.

I've never bothered, because with some creative use of a keyboard and mouse scripting tool I've been able to reduce the programming process to a single keystroke. Programming takes 30 or 40 seconds, much of which is avoidable overhead caused by P&E's software. It's a good job for a temp, and when the kids are out of school for the summer I can put them to work building up a stockpile of programmed MCUs.

Still, it's far from perfect. It could be much faster, and on occasion it'll choke and require some attention from a trained operator to get going again. More importantly, it requires a PC and it isn't something I can easily send off to a contract manufacturer. I'm making a major effort right now to reduce all of the post-assembly programming and testing operations to automated, standalone processes that can be easily run by anyone with minimal training - i.e., put the board in the programming fixture, press a button, and get a pass/fail result and maybe a test result printout on receipt tape.

Since I really need several of these things, and the $500 units aren't exactly what I want anyway, I decided to spend some time doing it myself. It's meant a few days at my workbench muttering and cursing - the programming process requires having the target processor boot a built-in program in ROM, then communicating with that program to load another program into RAM (which I had to write), starting that second program, and then communicating with it to actually do the erasing, programming, and verifying. And the one I/O pin you're guaranteed to have access to is not connected to any serial hardware, so it's all bit-banged. That tiny program, roughly 200 bytes, required several hours of coding and debugging. But the worst is over, and it's up and running now.

The unit shown above programs and verifies an OT1+ MCU in roughly 8 seconds. Pop the MCU in the socket, hit the button, and wait for the 'done' message. Lather, rinse, and repeat. P&E's "high speed" algorithm takes 20 seconds just to do the program and verify operation, not counting algorithm loading and user interface overhead. I haven't put any real effort into speeding up the process yet, but I think I can cut it down to 4 or 5 seconds without much trouble.

The code is still immature and doesn't elegantly handle error conditions (it just stops and displays a message, with no automatic retries or anything) but I've already added one useful feature I haven't seen elsewhere - it automatically detects when you've removed the target MCU, so it can clear the 'done' message and avoid any possible confusion when the operator gets distracted and forgets whether the chip in the socket is really done or if they just haven't pressed the button yet.

Total cash outlay for this prototype was roughly $10, including the perfboard (I hate FR-2, but the FR-4 perfboards were $30 and weren't the right size), button, ribbon cable, and connectors. Everything else I already had on hand. The green PCB is an AW-PROTO board, one of several dozen I had made for in-house prototyping of circuits build around the MC9S08AW series MCUs. I've got a big pile of those 16x2 backlit LCD modules, probably from when Electronic Goldmine or someone had a clearance sale. I actually got it mounted upside down, but I decided it doesn't really matter which way the board faces.

When the device is more mature, I may offer it as a commercial product. Might not be worth the effort required to document and support it, though. But in any case, I ought to be able to distribute a few to my overseas resellers to handle re-flashing of corrupted OT1+ and Tracker2 processors, and I'm looking forward to integrating it with the new automated OT2m test fixture that's in the works now.

OT2m Version 2.0

Pictured above is the first hand-assembled OT2m prototype with the new version 2.0 PCB. It's working well, but I think I'm going to make one or two small tweaks before it enters production.

The most obvious difference between version 2.0 and version 1.0 is that the demodulator is a CML Micro MX614 instead of the NJM2211 from NJR. Getting consistently good performance from the 2211 has been a pain. The switch to the MX614 is going to mean a cost increase of at least a few bucks, but I think it'll be worth it for the improved RX performance and decreased testing and tuning burden.

Less obvious is the addition of ESD suppressors on all external connections. I have yet to attack it with my ESD zapper, but it should be considerably more resistant to static discharge than the previous version. I won't guarantee that it'll survive a nuclear EMP, but it should tolerate some rough handling. The ESD suppressors also introduce some capacitance that should help improve RFI immunity, though that's never really been a problem with the 1.0 board and its existing inductive filtering.

The power supply section's be rearranged a bit and has proper reverse-bias protection now, that also protects the VN920 solid state relay - correcting an oversight in the last version that resulted in a couple of accidental magic smoke releases. D11 is undersized in this picture because I forgot to order the proper part.

The solder jumper SJ1 is there to bypass the reverse bias protection. This is in case you want to power the unit through the high-current pads and still want the supply voltage measurement to work.

What you can't see under that pretty black solder mask is that the board routing has been completely redone, mostly by hand. Eagle PCB's new follow-me router makes it much easier to lay out traces manually and resulted in a better arrangement of components, especially in the sensitive audio input section. The most critical traces are 14 mils wide there (version 1.0 was mostly 8 mil traces) and only a few of the shorter traces are under 10 mils anywhere.

This batch of boards was also made with twice as much copper - 2 oz per square foot, versus 1 oz for the version 1.0 production boards. This means more power handling capability in the solid state relay section in particular. The prototypes were done with a lead-free HASL finish, but I've had the production boards quoted with electroless nickel / immersion gold like the OT1+ boards.

The only other real change in this version is that the (never used) FRAM expansion has been removed, and those four I/O lines have been rerouted to the MON08 header at the front of the board. This should make it easier to wire up a keypad to go with an LCD display if I can ever find the time to finish the coding for the user interface.

Absolutely no firmware changes are required for the new board. Transmit audio is still generated by the processor, not the modem IC so it's still capable of 300 baud or PSK31 output. There's also some extra filtering on the audio output.

Decode performance is quite satisfactory. With the WA8LMF Track 2 test, it decodes 987 packets. The best I've heard reported for any other TNC is 970 for the uTNT. My KPC-3 scored 967. The highest ever recorded, to my knowledge, was 991 for an early Tracker2 connected to the output of the same KPC-3's TCM3105 chip. I'd have considered the TCM3105 for the new T2 board, but they've been discontinued for years.

It looks like the OT2m is going to be out of stock for a little while. The existing stock is enough for maybe two weeks at this rate, and it's going to take at least twice that long to finish testing the new board, make some minor tweaks, source all of the new parts, and get production started - which means new pick and place programming and a new solder stencil. I think six to eight weeks is more realistic.

I'm also going to have to have more enclosures produced, which doesn't usually take that long, but I've been a little unhappy with the consistency of the last batch or two from my current supplier. I've got a small pile of case pieces that just won't fit with the others. It wastes parts, and wastes time when you get an out-of-spec cover or end panel and have to disassemble it again.

Accident

Just my luck... Car accident exactly on the city line. Police and CHP are still trying to sort it out. No one hurt, thankfully. Car's going to be out of commission for a while, though.

Vacuum Molding

I picked up a vacuum former the other day for under a hundred bucks, figured I'd see if I could put it to use making radomes and such, or at least to prototype packaging. I ordered a bunch of different plastics from McMaster-Carr, and Charlie and I spent the evening molding shapes out HDPE, ABS, PETG, Acrylic, and (unsuccessfully) PVC. Haven't tried the polycarbonate yet. I'll post more of my results later, but shown above is the most functional thing we've come up with so far.

We used Jeff (the same scarab carving that served as a test subject for the MDX-20's piezo scanner, 3-axis milling, and urethane casting) to make a mold in 1/32" FDA-approved HDPE and then mixed up a batch of Jello Jigglers and cast a Jello Jeff. Shown above are the original, vacuum-formed mold, and Jello casting. Jeff's got a bit of an undercut around the base, so de-molding the Jello is tricky. Still, it worked reasonably well.