BMOW Tries Amateur Radio
How do older electronics nerds have fun? With an amateur radio license, of course! Some recent conversations with friends spurred me to learn more about ham radio operation, and I threw myself into studying. I’m now scheduled to take the technician and general class license exams back-to-back on March 19, and if I pass I’ll receive a call sign and can get on the air. Watch out, world.
What exactly do amateur radio operators do? Until recently, I only knew what I’d seen in movies, where hams working at night try to make voice contact with other radio operators on the opposite side of the planet, using huge antennas. This is called DXing and it’s certainly a big part of the hobby, but now I’ve learned there’s much more. Many hams begin with simple handheld radios operating on VHF and UHF frequencies, where they can talk to others in their local area. Most cities have repeaters on hilltops and tall buildings that can rebroadcast these low-power transmissions, effectively increasing the coverage area. Where I live in California’s San Mateo County, there are over 50 such repeaters available for amateur radio use!
Other fun things to try: talking to the International Space Station, bouncing signals off the moon, and patching communications through amateur radio satellites. There are also radio-internet gateways that can stream radio traffic across the internet for part of its journey. And beyond voice communications, there’s all manner of digital radio communication too. Packet radio, RTTY, image and video transmission, you name it.
Much of the hobby revolves around building and tinkering with the radio equipment and antennas, in order to get the best performance. For people who enjoy experimenting with electronics, this is a good challenge.
To broadcast on an amateur radio frequency, you must be licensed. This theoretically prevents inexperienced people from accidentally screwing-up the EM spectrum for everybody else through improper operation of their radio. There are currently three levels of license, from the beginner-level technician license, to the general license, and the top-tier amateur extra license. Your license class determines what frequency bands you’re permitted to broadcast on, and the maximum permitted power level. Technicians are mostly restricted to VHF and UHF frequencies (with a few exceptions), while the general license opens up more lower frequency bands that propagate further and are better suited for chatting with people 10 time zones away. Amateur extra licensees can broadcast in any amateur band and are also eligible to get shorter, more-memorable call signs.
Before I knew anything, I assumed the amateur radio license exams would be quite difficult. “Difficult” is a relative idea, but now that I’m familiar with the tests, I’d say practically anyone could pass the technician exam with about 5-10 hours of study. If you already have some background in basic electronics and physics, like most readers of the BMOW blog likely do, then you’ll find it easier. The technician exam is roughly one-third electronics and radio theory basics, one-third practical radio operation skills, and one-third FCC regulations. The general exam goes deeper into the theory, but it’s nothing too scary. All the tests are multiple choice, and knowledge of Morse Code isn’t needed.
Initially I’d planned to study for the technician license, but after I realized I already knew about half the material on the general license exam, I decided to double-up and do them both at once. This seems to be a fairly common path for people who already have some electronics and physics background.
See you on the airwaves! If you’re in the SF Bay Area, hit me up after the 19th if you’d like to try some on-air conversation.
Read 7 comments and join the conversationFirst Look at the RP2040 – Raspberry Pi Microcontroller
In response to my last post, a few readers suggested looking at the Raspberry Pi Foundation’s RP2040 microcontroller for possible use in a future Floppy Emu hardware refresh. The RP2040 was announced in January 2021, first as part of the Raspberry Pi Pico development board, and later as a stand-alone chip. While Raspberry Pi’s other offerings are essentially full-fledged computers, the RP2040 is a traditional microcontroller that will compete directly with familiar products from Microchip, ST, Espressif, and NXP. So what does it offer that might set it apart from the competition? Is it worth a look? Here’s my take.
Strong Points
RP2040 is a 133 MHz dual-core ARM Cortex M0+ microcontroller, with 264 KB of RAM, and a unit price of $1 USD. Right off the bat, that looks appealing. I don’t know of any other microcontroller from a major vendor that offer a better ratio of hardware specs per dollar. 133 MHz is quite zippy, and 264 KB of RAM is substantially more than any of the alternative parts I’ve been considering. Dual core is just icing on the cake.
The hardware also includes two programmable I/O (PIO) blocks with interesting potential. These are hard to describe in a single paragraph, but they’re like high-speed specialized coprocessors that could replace much of the software-based bit-banging that’s often needed in microcontroller applications. They’re a good fit for high-speed bit twiddling, independent of the main cores. For the Floppy Emu, PIO blocks could probably be used to replace some of the specialized logic that’s currently handled by a CPLD programmable logic chip.
The documentation looks well-written. So far I’ve reviewed the chip datasheet, hardware design guide, the C/C++ SDK documentation, and the Getting Started Guide.
The RP2040 is available and shipping in large quantities right now, which is quite an accomplishment given the current shortages everywhere else in the industry. DigiKey has over 50000 in stock. You can also order the chips directly from Raspberry Pi.
Weak Points
There’s zero flash or non-volatile memory for program storage on the RP2040. All the application code and data must be stored in an external flash chip. Six dedicated pins are used to communicate with a separate QSPI flash, using execute-in-place (XIP) technology to run code directly from flash without needing to copy it to RAM first. A 16 KB XIP cache helps speed up this process. Relying entirely on external flash helps keep the RP2040 price down, and lets the user choose a flash chip whose storage size matches their needs, but it also has some serious drawbacks for my purposes.
The biggest worry is code execution speed. If most of the code fits into the 16 KB cache, then the code should run as fast as any other CM0+ microcontroller with similar specs. But for uncached code, and especially for application startup code when nothing is yet cached, I fear it will be slooooow, slower even than 8-bit AVRs with much lower system clock speeds. I used section 2.3 of this Atmel document to understand what XIP traffic looks like for a QSPI interface. Fetching a 32-bit value requires 20 SPI clocks, which is 80 system clocks using the RP2040’s default settings. A 32-bit value can hold two 16-bit Thumb instructions, so it looks like 40 system clocks per instruction, or 3.3 MIPS at 133 MHz. Slow.
For many time-critical routines, code can be pre-loaded into RAM with some extra effort, where it will run much faster. But for application startup code there’s really no way around this bottleneck. I’m not sure if this would be a serious problem, or if I’m worrying over nothing.
There’s no easy place to store settings information, like the EEPROM on an AVR. Presumably settings would need to be stored in the same external flash as the program code. This would require copying some section of code to RAM and executing it, which would deactivate the XIP interface and use standard SPI flash commands to update a few bytes, before re-enabling XIP and resuming the program.
The RP2040 bootloader could be considered both a strong point and a weak one. There’s a built-in USB bootloader in mask ROM, which is activated if the external flash is missing or deactivated. To the computer it appears as a USB mass storage device, so you can update the firmware with a simple drag-and-drop. This is great if your product already has a USB device (USB-B) connector on it, but the Floppy Emu doesn’t and doesn’t need one. I could roll my own pseudo-bootloader as part of the main application code, to load firmware updates from the SD card, but it wouldn’t be in protected memory like a real bootloader. If something went wrong during the update, it might corrupt the pseudo-bootloader and effectively brick the device.
While I admit I haven’t tried it, the C/C++ development toolchain doesn’t look great. Ideally I’d hope to see an IDE like Atmel Studio or STM32 Cube, with hardware-specific tools to help configure the peripherals, GUI settings for all the build options, an integrated simulator and debugger, and so on. But the reality is more like a pile of libraries, header files, and build scripts. Changing any kind of build settings relies heavily on editing CMake files and adding new defines whose existence you may not have known about. Sure you can use the VSCode IDE, but it doesn’t seem to do much more than function as a text editor, and you’ll still be tearing your hair out struggling with CMake. The build environment is also clearly geared towards Linux, and while setup is possible under Windows, it appears to be cumbersome.
My last worry is over the RP2040 development community, or really the lack of a community. If you’re developing for an AVR, or Atmel SAM, or STM32, you’ll find thousands of helpful resources on the web with example code, discussion forums, and sample projects. There’s very little of this for RP2040, and most of what does exist is geared towards Micro Python and Circuit Python, rather than bare metal C/C++ development. The only discussion forum I’ve found is a small subsection of the main Rasperry Pi forums. This doesn’t make it impossible to develop – the documentation seems thorough and there is some help on the web. But it’s a far cry from working “in the herd” and developing for a more popular microcontroller family.
Conclusions
So is the RP2040 the future of the Floppy Emu? It’s hard to say, but I think probably not. It may help to compare it against some other possibilities, like the Atmel SAMD21 (48 MHz CM0+ with 32 KB RAM) or SAMD51 (120 MHz CM4 with 128 KB RAM), which cost around $4 each in large quantities. Compare these to an RP2040 plus an external flash chip, with a combined cost of about $2. The RP2040 solution is half the price, but both alternatives are cheap enough, and I would choose whatever solution will make development easiest.
The extra RAM of the RP2040 is welcome, but I’m unsure what I’d do with it. 32 KB is more than enough to buffer a disk track plus other application data, and unless I had 1MB or more to buffer a whole disk, additional RAM might not be immediately useful.
133 MHz is greater than 48 MHz, so maybe the RP2040 is much faster than the SAMD21? Or maybe not, given the overhead of XIP code execution?
All these differences in favor of the RP2040 look interesting, but if they aren’t critical for my specific application, then are they worth the trade-offs of the build environment, development community, and concerns about external flash?
For the specific case of the Floppy Emu, I think the best argument in favor of the RP2040 is the PIO blocks. If those could replace all of the logic that’s currently handled by a CPLD programmable logic chip, then I could eliminate the CPLD entirely, and greatly simplify the whole design. But if the PIO blocks can only replace some of the logic, then I still need a CPLD or something similar, and the advantage of the RP2040 is much less. But that’s a difficult question to answer by just reading the docs, and I’d need to really dig in and try building it.
Read 32 comments and join the conversationBMOW Business Update – Good, Bad, and Scary
It’s been a while since I last shared any business updates for BMOW. The past few years have been an exciting trip, as my personal technology blog has grown into a side hustle and then into a bona fide business. Initially BMOW was something I did in my spare time away from my real job (video game development), then it was something I did while I was between jobs, and now for the past few years it has been my real job. The experience has been great, but now the global chip shortage has scrambled everything, and the future outlook is growing scary.
The Good
First the good news. The gradual transformation from blog to store began in 2014, when a few blog readers started asking to buy the Macintosh floppy disk emulator that I’d been writing about. I sold about $18000 of hardware that first year, doing all the assembly and fulfillment by hand. It didn’t leave a huge profit after subtracting all the cost of parts, tools, and other business expenses, but it was a thrill to be making something that people wanted.
In the time since then, sales have grown consistently every year. I’ve moved the assembly work to dedicated manufacturing partners, added many new products to the BMOW line-up, and even hired a part-time employee to help with order fulfillment and customer support. In 2021 I sold several thousand Floppy Emus, plus lots of other products too, which was amazing. Gross revenue was into the hundreds of thousands. My net income after all expenses is less than I could earn as a software developer here in Silicon Valley, but it’s still a respectable number, and being my own boss is fantastic. I couldn’t imagine going back to a regular full-time job now. Sure, I’m always complaining about the challenges of international shipping or payment processing disasters or something else, but that comes with the territory of running my own business.
The Bad
If there’s anything bad here, it’s the overall fragility of the business. A great business would have revenue from many diverse products, with reliable sources of supply, and a large and growing market. I have none of that. The market is owners of obsolete computers from 25+ years ago. There simply aren’t many of those, and the number is shrinking every year as some computers break and can’t be repaired. How many working Apple II and classic Macintosh systems even exist today? Ten thousand? Ten million? I really don’t know. I keep thinking that I must have saturated the market already, but it hasn’t happened yet.
Product diversity is another weak point. BMOW sells eighteen different products, but 80 percent of revenue comes from the Floppy Emu Disk Emulator. Everything else is basically just a distraction. If anything threatens the supply or sales of Floppy Emus, then the business is in big trouble.
The Scary
Friends, the global chip shortage is very bad. For over a year columnists keep predicting it will get better soon, but it only gets worse and worse. This won’t continue forever, but how much longer will we have to endure this crunch? Six months? A year? Two, or three? And what will the landscape look like then? Will semiconductor makers take this opportunity to discontinue some of their oldest and least-profitable chips, the chips that are needed for vintage computer hardware?
The Floppy Emu uses two primary chips: a microcontroller and a programmable logic device. The mcu is an Atmel ATMEGA1284 and the logic device is a Xilinx XC9572XL. Both are relatively old technology, like 15+ years old. Both have seen their prices double or triple in the past couple of years. And both now have very limited or zero stock everywhere, with little hope of getting more stock anytime soon. Maybe I can get more in six months, or a year? Maybe never?
The last time I did a Floppy Emu manufacturing run, it was very difficult to find parts, particularly the ATMEGA1284. I almost gave up. My manufacturing partner made a lot of calls, and eventually found a surplus parts broker who could fill the order for a nosebleed price. As of today, I have enough finished Floppy Emus to last until roughly September at my normal rate of sales. I don’t know what happens after that. If I can’t find the required parts, or redesign the board around new parts, then I’m basically out of business.
Strategizing
What would you do in this situation? I can’t decide, and I’m spinning my wheels trying to decide what to do, while the clock is ticking and time is running out.
One option is to redesign the Floppy Emu hardware around new parts with better availability. The existing parts are pretty old anyway, so a refresh would make sense. But what new parts should I choose? It’s not just the ATMEGA1284 that has supply problems – it’s virtually all microcontrollers from Microchip, ST, TI, everybody. And the options for programmable logic parts are even worse. There’s very scarce availability of any programmable logic parts, and the few that are available are actually less capable than the old Xilinx part, or cost five times as much. Sure, you can sometimes find parts with a few hundred at one supplier and 1000 at another, but it’s usually one specific oddball package or variant while the rest of the family is out of stock. That’s a fluke, not a reliable supply. To feel comfortable betting the farm on a new chip, I’d want to see all the members of its family with deep stock in the many thousands, at multiple suppliers.
If I redesign the Floppy Emu hardware, should I redesign around the best available parts options today, or around a blue-sky vision of the best-suited parts for the task regardless of current availability? A redesign will be a major time-consuming effort, and I can’t afford to get it wrong. It’s a gamble. If I redesign around the best available parts today, that greatly limits my choices. I could be locked into sub-optimal parts for a long time to come. That might make it much harder to add new features, or might create new supply problems in the future, or increase my costs. If I redesign around the parts I’d like to use in a perfect world, then I could have to wait a very long time before they become available again. The redesigned hardware might never see the light of day except for a few prototype units.
Given how much time any redesign would require, and the uncertain results, there’s another option I’m seriously considering: do nothing. Place some back-orders now for the ATMEGA1284 and XC9572XL, and then forget about it. Use the coming months to work on Yellowstone features or develop some cool new product, instead of redesigning the Floppy Emu. Hope that the parts become available before I need them, and if they don’t, it will be lean times at BMOW. I would still probably want to revisit the Floppy Emu hardware design in another year or two, to take advantage of the capabilities of newer parts, but I would do it after the chip shortage is over and there’s a clearer picture of what parts I can safely bet on.
Read 15 comments and join the conversationAmazon Pay, Part 2: $2300 Lost and Found
A few weeks back I wrote about my struggles with Amazon Pay, and $2300 of customer payments I was unable to move to my bank because of a mysterious recurring transfer failure. Amazon Pay’s customer support was initially so robotic and ineffective that I gave up hope for ever finding a resolution, or even finding someone who could understand what I was reporting. My first angry Amazon Pay essay attracted the attention of someone higher up at the company, who apologized and was very attentive to my case, but wasn’t able to do much to explain why all the bank transfers were failing. Now after seven weeks of trying, I’m happy to report that the long-expected money is finally in my bank account. Who identified the problem and fixed it – Amazon Pay support? My bank? Nope, it was me.
Here’s what happened: my business bank account number is 10 digits, but the attempted disbursement transfers from Amazon Pay were consistently coming in with only 9 digits in the ACH transfer data, with the last digit missing. This caused several days of delay for each attempted transfer, culminating in eventual failure and reversal of the funds. I confirmed with my bank that the 10 digit account number was the correct one to use, and this number works just fine for ACH transfers with several other business services that I use.
But… I also have a personal account at this same bank, and it has a 12 digit account number where the first two digits are zeroes. I asked the bank about this, and they said the zeroes aren’t required on their end, but it’s OK if they’re present. So I went back to Amazon Pay, re-entered my account number as a 12 digit number with two leading zeroes, and boom! Money delivered.
Why didn’t the regular 10 digit account number work here? I think the only possible explanation is a serious bug in Amazon’s payment systems. That seems tough to believe, given how many transfers a company like Amazon must process every day, and the size of their team dedicated to electronic banking. But I’m confident I didn’t mistype the account number at Amazon Pay the same way multiple times, and the regular 10 digit number works fine with other payment processing services, my payroll processor, the California tax authority, and electronic transfers to suppliers.
Maybe Amazon Pay doesn’t allow for the possibility that a single bank might have different types of accounts with different numbers of digits? I just don’t know.
Whatever the underlying cause, I can understand that bugs exist. My real gripe is the Amazon Pay customer service experience, which was initially so unhelpful that I couldn’t get anyone to even understand what I was describing. Over and over, I was told the same thing about how to set up my bank account, with agents reading from the same script. I explained that I’d already set up the bank info, and then the attempted disbursement transfer had failed, resulting in the automatic removal of the bank info, multiple times. But this didn’t seem to be a node in the customer support decision tree. And rather than getting a reply like “that doesn’t sound normal and I’m referring this case to a banking specialist”, I just got scripted replies for problems that were not my problem, while agents seemed to willfully ignore the specific details I was telling them. To make matters worse, my support case was twice closed by Amazon even though it wasn’t resolved, with no way to re-open it, so I had to open new support cases and start the whole song and dance over again.
After my first essay about this mess, I was contacted by someone higher up at Amazon Pay. He apologized for my bad experience, and said he would talk with the customer support team and review their procedures to help prevent something like this from happening again. He was very nice, and I appreciated his help. But if I hadn’t possessed enough minor internet fame to get decent attention on that first essay, would I ever have heard from this guy? Or would I have been stuck in tech support purgatory forever? What’s most concerning is that even after this new person intervened, he still wasn’t able to solve the problem or find any explanation for it. In the end, it was up to me to hit on the solution. The Amazon rep promised to share the details with the appropriate engineering team, so maybe the next customer of my bank who signs up for Amazon Pay won’t have the same trouble that I did.
Read 5 comments and join the conversationHello New Zealand, Goodbye Hong Kong, International Shipping Dumpster Fire
International shipping in recent months has been a total disaster. Anyone who hopes we’re getting back to normal on this global supply chain stuff will be very disappointed. Between COVID-19 emergencies, a shortage of commercial airline flights to carry mail, customs clearance backlogs, and local destination transit service and postal system restrictions, most international shippers are experiencing major service disruptions. It’s especially bad for shipments sent by USPS First Class Package International Service, the cheapest available option and the one that most BMOW customers choose. FCPIS disruptions can sometimes cause unexpected delays of weeks or even months, and FCPIS shipments to some countries have been halted entirely. Pretty much every day I hear from a customer outside the USA asking “why is my shipment taking so very long?” Just how bad is it? A customer in Spain recently told me of an FCPIS shipment that had just arrived after four months. Ouch.
Since this post is specifically addressing people outside the USA, I should probably clarify that “dumpster fire” is American slang for a chaotic or disastrously mishandled situation. Because when things get really bad, we Americans apparently like to run around searching for open dumpsters full of garbage, then set their contents aflame while rubbing our hands with glee at the unholy mess. Which is a pretty good metaphor for international shipping today.
The US Postal Service “temporarily” suspended most mail delivery to Australia on September 3, and it remains suspended more than four months later. New Zealand service was similarly suspended on October 1. The lone bright spot here is the resumption of some classes of mail service to New Zealand on January 14. But on the same day, USPS mail service to Hong Kong was halted. Win some, lose some. Sorry Hong Kong.
Insanity is doing the same thing over and over and expecting different results
This is all becoming a familiar refrain. A search of the BMOW blog turns up many past laments about the difficulties of international shipping:
2013 International Shipping Hurts!
2014 International Shipping Meltdown
2016 Crikey! USPS International Shipping Costs
2018 International Shipping Struggles
2020 Sorry, Europe. International Shipping Woes
2020 The International Shipping Mess
2021 US Customs Export Control Says: I’m Screwed
2021 Temporary Suspension of Australia Shipping
2021 New Zealand Shipping Suspension
Something Better?
In an attempt to chart a path around this mess, BMOW has started offering some new shipping options. For most countries you’ll see an “Economy International” shipping option, which is priced similarly to FCPIS, and with a similar median delivery speed, but (hopefully) better worst-case delivery speed. It uses a crazy three-legged delivery scheme in which BMOW mails packages to a sorting warehouse in the USA, then a private shipping company applies a new shipping label with local postage for the destination country. Shipments going to the same country are batched together and sent in bulk by private shipper. Once the bulk shipment reaches the destination country, the individual parcels are dropped into the nearest mailbox for final delivery. If you’re wondering how this complex process could possibly be faster than simply mailing a package directly to the destination, let me refer you back to the FCPIS dumpster fire above.
For those customers who are willing to pay a little more for shipping, BMOW now also offers DHL and UPS shipping to most countries. This arrives in about a week, and is generally much more reliable than FCPIS, with better and more-detailed package tracking too. But it comes at a price: around 40 to 45 dollars, or more than twice the cost of typical FCPIS shipping. This might be acceptable for a customer who’s buying 250 dollars worth of hardware, but few people are willing to pay 40 dollars shipping on a 40 dollar purchase.
I’ll continue to hope that the international shipping landscape begins a return to normalcy later this year. Until then, thank you for your understanding as BMOW copes with this difficult shipping environment.
Read 1 comment and join the conversationYellowstone Manufacturing is Go!
The i’s are dotted, the t’s are crossed, and Yellowstone manufacturing is underway! I want to say something satirical like “I never thought I’d live to see this day”, but truthfully this has been a long, long, loooooooong time in the making. General availability of Yellowstone is expected sometime around the middle of March. Development started in the summer of 2017, so you can do the math on total development time.
I’ve created a Yellowstone product page. This will be the official home for everything Yellowstone, including an overview of what it is and why you might want it, compatibility information, links to the instruction manual, firmware updates, and more.
Yellowstone is a universal disk controller card for Apple II computers. It supports nearly every type of Apple disk drive ever made, including standard 3.5 inch drives, 5.25 inch drives, smart drives like the Unidisk 3.5 and the BMOW Floppy Emu’s smartport hard disk, and even Macintosh 3.5 inch drives. Yellowstone combines the power of an Apple 3.5 Disk Controller Card, a standard 5.25 inch (Disk II) controller card, the Apple Liron controller, and more, all in a single card.
Need to attach a disk drive to your Apple II? Yellowstone should be your first choice, because it does virtually everything that every other Apple disk controller can do, plus more. The retail price for Yellowstone is planned somewhere in the mid-$100s range. This is a nice value, given that an Apple 3.5 Disk Controller Card costs $200+ and used Liron cards sell for $300+ on eBay, and Yellowstone can do much more than either of those cards.
Apple Disk Controller Card Comparison
Disk Controller | Supports 3.5 inch drives | Supports 5.25 inch drives | Supports smart hard drives | Supports Macintosh drives | 20-pin ribbon connector | DB-19 connector | Number of connectors |
Disk II Controller Card |
✔ | ✔ | 2 | ||||
Disk 5.25 Controller Card |
✔ | ✔ | 1 | ||||
Apple 3.5 Disk Controller Card | ✔ | ✔ | ✔ | 1 | |||
Apple Liron Card | ✔ | ✔ | 1 | ||||
Yellowstone | ✔ | ✔ | ✔ | ✔ | ✔ | ✔1 | 2 |
[1] optional DB-19F connector
Since I know people are going to ask, I’m not taking pre-orders at this time, but you can sign up for the BMOW Newsletter if you want to be informed when Yellowstone is ready for sale. There should be plenty of Yellowstone cards to meet demand for at least a few months, so there’s no worry of an immediate sell-out. But in the medium to long term, the global semiconductor shortage and general meltdown of supply chains will be a problem. I couldn’t build additional Yellowstone cards right now, even if I wanted to, because the necessary parts just aren’t available anywhere. So if you want one of these, maybe don’t wait too long beyond March to grab one.
Want all the nitty-gritty usage details? You can read the Yellowstone instruction manual here. Now the waiting begins…
Read 23 comments and join the conversation