I put together a new demo video for the Floppy Emu Model B, since the old videos had become hopelessly out of date. Enjoy!

BMOW’s product Floppy Emu needs a male DB-19 connector to mate with vintage Apple computers, but these connectors haven’t been manufactured in decades. For two years I’ve been scraping by with “new old stock” DB-19’s from warehouses around the world, but that supply has almost completely dried up. I recently found a few hundred more, but it’s clear that the end will come sometime in 2016. To prepare for the worst, I’ve been working on a design for a DB-19 substitute. After more experiments, today I decided that this path has reached a dead end.

The current DB-19 adapter for Floppy Emu is shown at left, in the photo above. It consists of a small PCB with an edge-mounted male DB-19 at one end, and a 10×2 shrouded header connector at the other end. A ribbon cable plugs in to the 10×2 header, and the DB-19 plugs into the computer’s external disk port, and everything is great.

 
Designing a Substitute

The basic idea of a DB-19 substitute is to replace the male DB-19 with sections of 0.1 inch male header arranged in a DB-19 pattern, while keeping everything else more or less the same. I first explored this idea a year ago, and the prototype worked reasonably well, but had its share of problems. The 0.1 inch pin spacing didn’t quite match the 0.109 inch spacing of a D-SUB connector, and it put square pins into round holes. Without a surrounding shield, it was too easy to misalign the substitute connector while plugging it in, so I added two rectangular LEDs as structural elements to serve as mechanical guides. It sounds dodgy, but it passed some quick tests on several different Apple computers. Then I put the prototype away in a drawer, and didn’t think about it again.

This week I received a new PCB for what I hoped would be the final DB-19 substitute design. I shrunk the overall size of the PCB, and gave it a trapezoid shape with rounded edges to invoke the spirit of a real D-SUB. I split up the 0.1 inch headers into a larger number of smaller sections, so the average offset from the nominal 0.109 inch spacing was reduced. And taking a popular suggestion from the first prototype, I made the LEDs into more than mere mechanical guides – now they light up! It’s a pretty cool effect. A side-by-side comparison of this new DB-19 substitute with the current model DB-19 adapter is shown above, and a rear view of the same connectors is below:

 
Quality Control Failure

The new DB-19 substitute passed all my initial tests, and everything was looking good. But once I started testing more carefully, I realized that the connection wasn’t solidly reliable. It worked 100% of the time on my Mac Plus, Apple IIgs, and a borrowed Apple IIc+. But when plugged into the daisy chain connector of an Apple 3.5 Drive, it only worked about half the time. And when plugged into an Apple IIc, it never worked, unless I pushed on the connector with my finger during disk I/O. Ugh. At first I thought maybe this new DB-19 substitute had some new problem, but when I tested last year’s version more carefully, it had the same issues.

I think there are several things preventing this from working reliably. While putting square pins into round holes sounds crazy, I think that’s the least of the problems. What’s more significant is that the diagonal length of each pin’s cross section is probably slightly different than the diameter of the round pin that’s supposed to be there. Combined with the slight misalignment of some pins, I believe this leads to weak or no contact for those pins inside the female connector. I don’t know if the female’s interior has flat wipers, or a true round receptacle. Maybe different models of Apple computer have different receptacle designs. It doesn’t seem like a good idea to rely on that.

The other problem is the vertical height of the whole DB-19 substitute assembly. The current DB-19 adapter has only a male DB-19 at one end, with a height of about 3/8 of an inch. But the new, reduced size DB-19 substitute assembly has a PCB directly behind the pins, with a height of about 5/8 of an inch. For most Apple computers, the extra height is no problem. But for a few systems with recessed disk connectors, the extra bulk bumps into the plastic above the recessed connector, preventing it from being fully plugged in. On an Apple IIgs, it just barely fits. On the daisy chain connector of an Apple 3.5 Drive, it doesn’t fit.

 
Alternate Ideas

What to do? I’m probably going to abandon the idea of using 0.1 inch male header, as it just doesn’t seem reliable. Another option is to use 19 individual D-SUB crimp pins, soldered into the DB-19 substitute PCB. I built one of these last year, and it’s shown at left in the photo below, along with the first generation of the 0.1 inch male header substitute.

The version with the D-SUB crimp pins is definitely more reliable, but it’s a nightmare to assemble. Crimp pins aren’t designed to be soldered into a PCB like this, and to prevent solder bumps on the pin side from shortening the effective pin length, the pins need to be soldered from the “wrong” side of the board using an ugly technique. Individual pins won’t stay straight while soldering, so a female DB-19 must be used as a jig during assembly. And when it’s done, the crimp portion of each pin must be cut off with shears. The current DB-19 adapters are factory assembled with a mostly automated process. This crimp pins design would require a cumbersome manual process, driving up the cost, if the factory was even willing to do it. And the problem with the height of the assembly would still remain.

The other option is to find a D-SUB factory that could manufacture new male DB-19 connectors. I checked into this last year, and it looked like a tough road. Negotiating that kind of manufacturing deal is difficult for someone like me, with no industry contacts or big name credibility. Most places didn’t even respond to my emails. From those that did, it looked like setup costs would be around $10,000 before they could make even a single part. Given the small scale of my business, that’s not realistic. I’d have to buy a virtual lifetime supply of DB-19 connectors, and hope that Floppy Emu sales continued on pace through 2030 or so.

This just became my new #1 problem. I’m going to work on brainstorming other solutions involving D-SUB crimp pins or other round pins, and also make another set of inquiries for manufacturing new DB-19 connectors. The clock is ticking…

 
February 23 Addendum

After mulling this over for a while, I’m coming to the conclusion that I should get new DB-19 connectors manufactured, even if it costs $10,000. It’s the only solution I’m confident will work reliably. Everything else I can think of is a trade-off of quality for cost, and nobody’s going to be happy if I switch to a new style of DB-19 substitute that’s not always reliable or that has trouble fitting certain computers.

The cost of manufacturing new connectors is high, but the alternatives aren’t free either. I priced out one possible alternative involving an empty DB-19 male housing and 19 crimp pins, and it would cost about $5 per connector including the increased labor cost to assemble it. At the current sales rate, I’d be spending about $2000/year for a solution that’s inferior to a real DB-19. Compared to that, $10,000 doesn’t seem quite so unreasonable. The other alternatives I described earlier would be cheaper to build, but seem to have reliability problems, so they’re not really viable.

I’ve been using the number $10,000 as a rough figure, but it may be less than that. Assuming the best quote I received a year ago is still valid, it would be roughly $8000 to get 10,000 DB-19 connectors manufactured and delivered. That’s about one third of the total profit I made from all BMOW product sales last year. So it’s a big number, but not completely out of the question. I don’t need 10,000 DB-19 connectors, but I could probably resell some of those over the next few years and recoup $1000 or so of the manufacturing cost.

I’ve been talking with a person at IEC about splitting a new manufacturing run with them, which would help a lot if we can reach an agreement. Another possibility is to run a GoFundMe campaign and solicit donations to “save the DB-19”. If I could get enough vintage Apple enthusiasts to chip in $10 or so, it might make a significant dent in the manufacturing cost. Maybe I could put the names of the largest donors in the silkscreen of the adapter PCB.

At the end of it all, there’s just something cool about the idea of being the guy who resurrected the DB-19. Then the world can stop seeing sad pleas like this one. Maybe I’m insane, but that’s got to be worth something. 🙂

At last, BMOW is moving into the modern world with a new online storefront! As I mentioned in the Profit and Loss discussion a couple of weeks ago, the old solution of PayPal payment buttons and order tracking left much to be desired. The new storefront isn’t anything fancy, but it’s still a tremendous leap forward in terms of ease of use for me, and is also far better looking for customers.

You can browse the new store using the “BMOW Store” link at the upper right, and it’s fully functional and ready for purchases. For the time being, the “add to cart” buttons on project pages like Floppy Emu’s will continue to point to the old PayPal payment buttons. This provides an easy back-up solution in case anything goes wrong with the new system. Visitors using the BMOW Store link will make purchases through the new system, while those using purchase links on the BMOW project pages will continue to use the old system for now.

 
WooCommerce and Friends

After looking at many different e-commerce and shopping cart solutions, and installing and uninstalling Zen Cart, I finally settled on using WooCommerce. WooCommerce is a popular e-commerce platform that’s implemented as a WordPress plugin. The basic package is free, and the developers earn their income by selling a variety of add-ons and themes. As I discovered, it’s quite easy to set up a functional and attractive storefront in just a few hours. In order to minimize the risk of conflicts with my existing, heavy-customized WordPress install, I created an entirely new WordPress installation in a subdirectory of the BMOW site, used exclusively for the WooCommerce store.

I’m still using PayPal for payment processing, but the method is now PayPal Express instead of the clumsy PayPal payment buttons. The shopping cart functionality is implemented entirely on the BMOW site, within WooCommerce. When a shopper is ready to checkout, he’ll be redirected to a PayPal page, where he can enter a credit card number or his PayPal account credentials to authorize the purchase amount. He’ll then be redirected back to the BMOW site for a final review, at which point he may cancel or submit the order. Using this method, I avoid needing to ever directly handle sensitive payment info like credit card numbers. But customers still complete their transaction experiences on my site, where I can show them a thank you page, and maintain purchase statistics.

A few additional WooCommerce-related plugins proved handy:

• PayPal for WooCommerce – Enables use of PayPal Express functionality, and tighter integration with PayPal
• WooCommerce Weight Based Shipping – Charges different shipping amounts depending on the calculated total weight of items, destination country, and shipping method
• Storefront Site Logo – The default theme inexplicably lacked a way to add a logo to the store’s header

All of these plugins were free.

 
Cleanup

The only major concern I have isn’t a technical problem, but a design issue. With the introduction of a storefront, all of my creations now have product pages, in addition to the project pages that already existed (and that formerly doubled as product pages). This will be a source of confusion. For example, which page should be considered “the” ROM-inator page: the pre-existing ROM-inator project page or the new ROM-inator product page? Which one should a reviewer link to, or a potential buyer look to for details? Which do I want to appear first in the Google search results for “Mac ROM-inator”?

This may seem like a minor issue, but I’ve spent significant amounts of time thinking about it. I definitely want to avoid a situation where the mind-share for each of my inventions is semi-randomly split between two different web pages, with duplicated information. I looked for examples of how other sites addressed this problem, but couldn’t find any similar examples. My current approach is to keep the project page as the “official” page, with the product page having a much shorter description focused on actual purchase details, with several links back to the project page for further reading. This hopefully makes it clear which page is the main one, but at the expense of removing information from the very place in the store that would-be buyers need it in order to make a buying decision. So it may actually cost me sales. I’ll evaluate how this works for a while, and consider making the product page be the main one if necessary.

Happy shopping!

About a week ago, I added an SSL certificate to the BMOW web site, in preparation for some improved shopping cart features. With an SSL certificate signed by a certificate authority (free from Let’s Encrypt), the site can serve pages using the encrypted https protocol as well as the standard non-encrypted http. Pages encrypted with https will show a padlock icon or something similar in the address bar of most web browsers, and are normally used for handling sensitive content like payment info for a web store. My plan was to continue serving the existing blog pages using http, and use https for the new shopping cart pages. But it’s technically possible to serve any page from the site using https – try it! Just manually edit the URL of this post in your address bar, and change http to https.

The main blog pages aren’t designed to be served with https, however, and they contain embedded non-secure content like images and comment forms that use the http protocol. If you view this post as https, it will work, but your browser will probably display a warning about insecure content. If you try to post a comment, you’ll see a warning about a non-secure form, and if you persist in posting the comment you’ll see an error 403: forbidden message.

Since nobody ever visits the BMOW site using https, I thought those security warning didn’t matter, until I discovered that Google has started replacing all of the BMOW links in its search results with https versions of those same links. Someone who searches Google for “KiCad vs Eagle” might see a result with an https link to my post on that topic. Following the link, they’ll get a bunch of security warnings from their browser. And after commenting on the post, they’ll get the dreaded error 403. Oops.

I learned that Google prefers to index pages as https rather than http, if it discovers that a web server supports both. After doing more research I considered a few paths out of this mess:

• Go full blown https everywhere on the site. Fix images, comment forms, and other content that use http.
• Redirect https requests to http versions of the same URL.
• Use canonical URLs to instruct search engines to index the http versions of pages, not https.

Switching everything to https would be lots of work, and wasn’t the end result I wanted anyway. Redirecting all https requests to http would probably be OK, but seems a little bit drastic, and I’d need to carve out exceptions for the shopping cart and admin pages.

Canonical URLs

Canonical URLs are a nice feature,  and I decided to use them to solve this problem. In the header section of any HTML document, you can include a link like this one:

<link rel="canonical" href="http://www.example.com/mypage/" />

and search engines will index the page as http://www.example.com/mypage/, regardless of whether they reached the page as

http://www.example.com/mypage/
https://www.example.com/mypage/
https://www.example.com/mypage/?q=vegemite

WordPress automatically adds canonical URLs to some pages, but not all, so I installed the Yoast SEO plugin to gain more control over canonical URL generation. Yoast added the canonical URLs as expected, but not in the way I needed. If I visited a page on the site using http, then Yoast would generate a canonical URL link beginning with http://. But if I visited a page on the site using https, Yoast would generate a canonical URL link beginning with https://, which was exactly what I didn’t want. I was finally able to force canonical URLs to always start with http:// by inserting this code snippet into my WordPress install’s functions.php:

function design_canonical() {
  global $post;
  if(isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == "on") {
    $find = 'https://www.exampledomain.com';
    $replace = '';
    $theurl = str_replace($find,$replace,get_permalink($post->ID));
    return site_url( $theurl , 'http' );
  } else {
    // Leave blank and Yoast SEO will use default canonical for posts/pages
  }
}

add_filter( 'wpseo_canonical', 'design_canonical' );

Fixed?

This should be all that’s needed to make Google, Bing, and other search engines use http for indexing all my content. It may take a few days for the Google index to be updated with the new links, but eventually everything will be http. And that should be enough to prevent visitors from accidentally viewing the site content as https, right? Well, maybe not. I had forgotten about the existence of browser plugins like HTTPS Everywhere that attempt to force use https wherever they can. Even if Google’s no longer sending traffic to https versions of my pages, then, other sources of https traffic still exist. And those visitors will have all the security warning and error problems I described.

I’m scratching my head, wondering how to proceed. Redirect all https traffic to http, as I’d originally considered? Or leave everything as is, and let HTTPS Everywhere visitors deal with the problems that extension creates? Maybe there’s another simpler solution. It all makes me appreciate how complex the job of a web site admin can really be.

It’s time for more Apple II love from Floppy Emu! The newest Apple II compatible firmware, apple-II-0.1M, adds a few small but important improvements:

• Fixed Smartport hard disk timing problem when starting from a cold boot (Apple IIgs, IIc, IIc+)
• 3.5 inch disk emulation is now supported on the Apple IIc+
• Floppy Emu Model B can now be connected internally on the IIc+

For hardware Model B: apple-II-0.1M-F8
For hardware Model A: apple-II-0.1M-F6

Floppy Emu is a floppy and hard disk emulator for classic Apple computers. Read more about it at the product page.
The Quirky Apple IIc+

3.5 inch disk support for the Apple IIc+ was something that had eluded me for many months. Thanks to Jeremy Moskowitz for lending me a IIc+ machine, so I could finally do the necessary troubleshooting.

If you’re curious why 3.5 inch disk emulation didn’t previously work on the IIc+, the reason is probably not what you would have guessed. The IIc+ was originally conceived as a 1 MHz machine, like the IIc. The CPU wasn’t fast enough to handle the data transfer speeds of 3.5 inch disks, so a new coprocessor chip called the MIG was added, along with some high-speed cache memory. Later the design was revised, boosting the CPU speed to 4 MHz, and eliminating the need for the unique MIG and cache system. Yet the MIG and cache remained in the final product anyway. I was virtually certain the IIc+ issues with 3.5 inch disk emulation and Floppy Emu were related to the MIG and cache, but it turns out I was wrong.

The problem was actually a limitation of the Floppy Emu design that hadn’t caused trouble previously. In 3.5 inch emulation mode, there are four control lines from the computer. These lines determine which one of 16 state parameters is being read from the drive at any given moment – info like what kind of drive it is and whether it’s at track zero, as well as the instantaneous data bits flying by the drive head on sides 0 and 1 of the disk as it rotates.

There’s no clocking or synchronization on these control lines, so Floppy Emu doesn’t really know when the computer is reading a parameter, versus when it’s transitioning to a different set of control line states. Typically the control lines don’t all change state at precisely the same time, so if the computer was reading parameter 0000 and then wanted to read parameter 1111, the Emu might observe the control lines changing in quick succession in a series like 0000 -> 0100 -> 0110 -> 1110 -> 1111. Normally this doesn’t cause any problems. The Emu briefly emits the info for the phantom states 0100, 0110, and 1110, but the computer isn’t reading these values and ignores them.

The trouble arises with parameters 1000 and 1001, which are the instantaneous data from the disk read head on sides 0 and 1 of the disk respectively. If the Emu observes a read of parameter 1001, it tries to provide data from the sectors on side 1 of the emulated disk. If the side 0 sector data is currently loaded in the Emu’s memory, it dumps it and fetches the side 1 sector data from the SD card. This takes a few milliseconds, and interrupts the flow of data from the emulated disk.
Phantom Reads

As you can imagine, an accidental phantom read of the side 1 parameter during I/O on side 0 would cause major problems, and this is exactly what was happening on the IIc+ in 3.5 inch emulation mode. The computer was repeatedly switching between parameter 1000 (side 0 data) and parameter 1101 (drive ready flag), brushing past 1001 (side 1 data) every time and causing an unnecessary load of side 1 data from the SD card, followed by another load of side 0. The Emu was caught in a perpetual cycle of reloading data from the SD card, and could never get anything else done.

How do you fix a problem like this? If the Emu had enough on-board RAM to load the side 0 and side 1 data at the same time, then there would be no penalty for phantom side switching. This is theoretically possible on the Emu hardware, but only for some disk types, and it would require some big changes to the firmware design. Another approach would be to filter control line states in hardware, and only react to a side 0 or side 1 transition after the control lines had remained at 1000 or 1001 for a while without further changes. This could easily be done in the Emu’s CPLD chip, if there were any space left to implement additional logic. Sadly the CPLD is already near 100% full with the existing disk emulation logic.

The solution I settled on was to poll the CPLD for which side is active, after handling each sector, instead of treating side changes as an interrupt. It’s not the ideal way to handle the issue, but it works. The phantom transition through parameter 1001 still happens on the IIc+, but the Emu ignores it unless it happens to fall right at the moment of polling. This happens very rarely, and when it does happen the computer treats it as a glitchy read, and simply tries the sector again.

Interestingly, I wrote another post titled Phantom Reads here seven years ago, for totally unrelated hardware that shared a similar conceptual problem.

Have you ever wondered what life is like in the “kit biz”, with a part-time business selling electronic gizmos to hobbyists? Maybe you’ve thought about selling one of your own creations, or were just curious if it’s possible to make any money this way. In the spirit of helping the hobbyist community, I’m sharing the 2015 BMOW profit and loss breakdown here. My hope is that others might provide some helpful insights, or learn something that can help their own efforts. Normally I would keep this type of information private, but I decided there’s no harm in sharing, and more knowledge can only help.

BMOW began as a place to document my personal electronics projects and musings, and remains primarily an electronics blog. But along the way, it accidentally grew into a small business too, as some of the projects generated interest from readers wanting to buy hardware for themselves. Chief among these is the Floppy Emu disk emulator for vintage Apple computers, and its related accessories. The Mac ROM-inator replacement ROM for early Macintoshes also has a small but devoted following. Today BMOW is a part-time 1-man business, to which I devote an average of about 10-20 hours per week for R&D, hardware assembly, customer support, and order fulfillment.

Total BMOW gross revenue in 2015 was $55,097. As you can see in the graph, month-to-month revenue varied more than 2x. There was an obvious bump in June and July, when the addition of Apple II emulation features boosted Floppy Emu sales. Sales also jumped in November for no discernible reason, and inexplicably slumped in December during what should have been the year’s strongest period (but recovered in January 2016).

The gross revenue figure includes all the money I collected: that’s money from product sales, California sales taxes collected, and shipping fees. I don’t really consider the latter two as income, because they go to the state or the post office, and not into my pocket, and their inclusion here makes the “revenue” figure look more impressive than it is. Accounting experts might argue whether sales tax and shipping fees should be included as revenue, or dealt with some other way. I’ve chosen to list them as revenue, with an offsetting expense listed later.

 
Expenses

Of course that money isn’t all profit. Let’s look at the expenses for the year:

I rang up $31,000 in total expenses for 2015, resulting in a net profit of $24,097. Assuming I worked an average of 15 hours per week, that’s $31/hour before paying income taxes. That’s a lot better than the federal minimum wage, which is one test not every kit biz passes. But it’s a lot less than my typical hourly rate for consulting work, or the rate I could likely earn at a full-time electronics engineering job. One of my big goals for 2016 is to reduce the amount of time spent on things like support and order fulfillment, by searching for efficiency improvements. Much of what I do now is very labor-intensive, and there’s lots of opportunity to make more effective use of time.

I collected $429 on behalf of the state of California, which is an extra hassle that involves a special tax return filed each January. PayPal and eBay took $1982, or about a 3.6% cut of gross revenue. Given how frustrating and awkward PayPal is to work with, I don’t enjoy giving them anything, but it’s about the same rate that I’d pay if I accepted credit card payments directly. I made only a couple of eBay sales in 2015, which is fortunate because they charge 10% commission on top of PayPal’s 3% fee. Ouch.

The post office must really love me: $4172 in postage fees! Sometimes I wonder how eBay sellers in Asia can ship to the USA for a dollar or two, when I can’t even send a package within the USA for less than $6. International postage for small packages to most countries except Canada starts at $13, and (as of rate increases a few weeks ago) is over $20 for the weight of a typical BMOW order. My customers pay the shipping costs, so it doesn’t directly affect me, but I wish I could offer lower shipping rates.

The $378 for equipment represents hardware development tools and machines used for testing. Office supplies like shipping boxes, paper, address labels, ink, and bubble wrap were a $327 expense. The cost for web hosting fees and a few commercial software programs totaled $265, and my city business license was $321.

 
Hardware is Expensive

The biggest BMOW expense by far was the $23,126 cost of hardware and assembly. Unlike a software publishing business, selling hardware gizmos requires spending a lot of money upfront on hardware parts first. These parts must be purchased in large quantities to get the best prices, so it’s necessary to go into debt temporarily, and make up the debt later from product sales income. In my case I didn’t literally go into debt, but for a while my year-to-date expenses exceeded revenue by several thousand dollars. I have a lingering fear that demand will suddenly evaporate just after I make a big hardware purchase, or something will happen to make my products instantly obsolete, and I’ll be left with thousands of dollars in useless inventory.

$23,126 for hardware and assembly is a big number, so let’s break it down:

Floppy Emu boards are built by Microsystems Development Technologies in San Jose, CA. The cost for parts and assembly of the “core” Emu modules came to a whopping $15,679. This doesn’t include the LCD displays and the ever-elusive DB-19 connectors, which were purchased separately for $1345 and $733, respectively. The clear acrylic case for Floppy Emu is a popular option, and I spent $2058 on materials and laser cutting services for those. A further expense of $1265 was for the SD cards used in the Vintage Software Collection. I buy a lot of SD cards.

$580 went towards making PCBs for hand-built Floppy Emu accessories: the Universal Adapter and the A/B Drive Switch. This amount also included other non-Emu projects like the ROM-inator, Sonic Bow Tie, 68 Katy, and various prototypes and experimental hardware. The chips and other components needed to populate all those PCBs ran to $1460.

 
Room for Improvement?

This was a good result for 2015, so I’m not complaining. Still, there’s always room for improvement. While I’d love to boost sales volume or drive down costs, the area that’s most ripe for improvement isn’t money but time. There’s a tremendous amount of manual labor involved in most of what I do, and some weeks it cuts into my spare time so much that I deeply resent it. And even during weeks when the labor effort is more manageable, I’d rather spend an extra hour developing a new feature, or researching a new project, than bubble wrapping and boxing. Going forward, I’m going to look for opportunities where I can pay someone else to offload some of the manual work. Even if my costs go up as a result, and my net profit goes down, I’ll still consider it a success if the profit per hour of time spent improves. After all, it’s not my goal to spend every last waking hour of my life devoted to weird electronic gizmos – there are other things.

Here are some of the time-saving ideas I’m looking at for 2016.

Testing – During assembly, Microsystems Development Technologies verifies that each Floppy Emu passes its built-in self-test. Once I get the hardware, I do further testing myself: adjusting each unit’s LCD contrast, assigning a serial number, and actually running an emulated disk on a Mac or Apple II system. That all takes time. Initially it seemed unthinkable to send Microsystems an old Mac Plus and instructions for booting up System 3.2, but now I’m considering doing exactly that. They’re smart guys, they can figure it out.

Low-Volume Assembly – The items with lower sales volumes, like the Universal Adapter and A/B switch, are hand-built one at a time by me. They don’t take more than 10 or 15 minutes at most, but sometimes I just want to ship an order without hauling out the soldering iron first. Even when I build a few at a time to keep a small stock on hand, it turns into a few hours of work here and there that I’d rather spend on something else. Microsystems might not be the right people to build these for me, but there are plenty of other low-volume assembly services like Smart Prototyping. I need to find the time to research them and make an order.

Fulfillment – The most manual of the manual labor I face is order fulfillment. That means printing invoices, picking hardware out of boxes, sorting things into little piles, bubble wrapping, boxing, and taping. I once had a summer job as a shipping clerk, and this is pretty much exactly the same thing. And it still sucks. I could improve on this a little if I had a dedicated shipping area, with big rolls of tape and bubble wrap and boxes neatly stacked and ready to go. At times I’ve paid my daughter to do this work, but she doesn’t like it much either. Maybe a part-time helper from a temp agency? The need for this help is irregular, so I’m not sure how well a temp employee would work anyway.

PayPal and Postage – In an ideal world, I would log into a web site, and click a button to fetch all my new orders. This would automatically update my sales history, print a bunch of invoice slips, calculate the weight of each outgoing package, purchase the necessary postage, and print it. But in reality this process requires a crazy combination of the PayPal site, US Post Office site, and custom software. It’s an orgy of clicking, cutting and pasting, and manual steps. PayPal requires purchasing and printing postage for each order, One. At. A. Time. The post office web site lacks a way to import shipment details, so information must be manually pasted into forms and drop-down boxes stretched across several pages of the site. And don’t get me started again about their abysmal handling of international package addressing, which I’ve discussed here before (1, 2).

For postage there are alternatives like Endicia and Stamps.com, which should allow importing shipment details and combining purchases of all postage for a set of orders. Both services have fairly poor reviews, so I’ve resisted making the switch, but they can hardly be worse than the system I’m using now. On the payments end, unfortunately I don’t see any simple alternative to PayPal. It’s often clumsy and frustrating, but it provides a basic shopping cart system and handles a wide variety of payment types from nearly every country. Square seems more geared towards physical storefronts and swiping a credit card. Amazon Payments may be the most similar to PayPal, though I don’t know much about it.

Did you ever sell a product online? What was it?

What’s your favorite maker-friendly electronic gizmo?

Have a good post office story to share? I once received a coconut mailed from Hawaii. Just the coconut, with my address written on the shell.