Battery Box

I’ve been struggling with the Go-Box concept for a while now. I’m trying to balance what I *might* do with what I’m *going* to do. And what I’m *going* to do probably 99% of the time when I’m out and about with HF is operate from my Jeep. That means that I will either be operating off of the electrical system on the Jeep (I have that all cabled up with PowerPoles and everything!) or I’ll be at the tail end of the Jeep with a battery.

Oh the battery. It’s a heavy brick of energy, isn’t it? Weighs more than my rig. And when I put together an Go-Box for the rig, I wavered on what to do with the battery. It’s far more likely that any remote ops or emergency operation will be done on a battery or with generator or available power. So I got modular. I have a box for the radio, tuner, SWR meter, and cables and a box for the battery.

For simplicity’s sake, I grabbed a SLA battery that runs at the right specs for my rig on low-ish power. Then I put it into an ammo case. I had it lying around and it’s a good rough and tumble solution. Then I decided to do something more than just wire it up to PowerPoles.

Ham radio is a hobby made of scope creep.

Why just PowerPoles? Why not include a USB adapter? And if you’re going to have a battery, you’ll want to know how much juice it has in it, right? So how about a volt meter? And you can’t have that volt meter just draining your battery, you’re gonna need a switch. And you’re gonna want to put a fuse on that thing regardless of the fact that the rig already has fuse in-line on the power cable.

See? Scope. Creep.

I ended up going to Powerwerx and ordering two faceplates, a volt meter, a USB power adapter that handles conversions, a PowerPole outlet with two sets of poles, and a pretty switch. I tossed a fuse inline from the battery itself for a little extra insurance. What I ended up with was pretty slick.

The inside of the battery box, wires and all.
The inside of the battery box, wires and all.
The panel of the box powered on to show the pretty lights.
The panel of the box powered on to show the pretty lights.

I’ll note that the battery isn’t a great fit for the ammo box, but I had a chunk of foam that I used for the roll bar of my Jeep and I stuffed it in there to keep things from sliding around. It’s a pretty good use of a scrap.

The project ran over budget when I started putting pretty lights on it, but I think that it’s going to more than do the job for power on the go and that will ultimately pay for itself. (If I say that enough, I might believe it, but I doubt I will convince others of that fact).

As a final touch, I recommend putting lots of stickers on the box to make it unique. I plan to finish it off with a stencil of my callsign on the side. But I have to get out my wife’s craft cutter to make the stencils and… I’ve already exhausted my time budget for this month.

IC-7100 and the Mac

This really is a hobby made up of hobbies. And as is almost always the case, I have found ways to complicate things and tread on ground that either is seldom traveled or more easily avoided for most.

See, I used to do a lot of audio editing and recording on GNU/Linux based systems back in the late 90s/early nils. There was no more difficult way to get audio into or out of a computer. The list of hardware providers was slim and the software was almost all roll your own. Which is great if you want to spend time messing around with stuff instead of doing the thing you want to do.

Then I had kids. And I went full-bore into the Mac world. No debates. For my use cases, everything works fine. I don’t have to deal with a lot of system overhead and when I really need to step out of bounds, I drop to the command line and do my work quickly.

Which brings me here. To Ham Radio and the Mac. Which don’t go together as nicely as I’d like.

So much software is Windows only and there is more support for GNU/Linux systems than there is for the Mac. When I want to do something simple, I often get bogged down. More often than not, I have to roll up my sleeves and do a little work to save myself time down the road.

I use Alfred. And by use I mean that I’m absolutely useless on my computer without it. It’s a launcher that has workflow capabilities. What’s that mean? Simple. I can write scripts and execute them with keystrokes from anywhere in the OS. My first silly project was to get a simple callsign lookup using QRZ and their XML lookup. So I put together a workflow and now I can invoke the lookup and see Callsign, Grid Square, State, City, Country, and Name in giant print.

Callsign: W1AW
Grid: FN31pr
State: CT
Country: United States

That was pretty simple to do and I’ve used it many times since I developed it.

But back to the problem at hand. I use an ICOM IC-7100 which I still think is the best first radio for a ham if they can afford it. It has allowed me to get on local nets and do plenty of HF work including digital modes like FT8 with no additional hardware. It’s also nice and portable for field work out of the Jeep.

Getting it to work on the Mac required a lot of driver nonsense to get the USB devices set up. See what I said there? DeviceS. The IC-7100 identifies as two distinct devices. One is for audio and the other handles the CAT control of the rig. ICOM even defines them for you in the drivers. There is “IC-7100 02008919 A” which handles the CAT control elements and “IC-7100 02008919 B” which is the audio interface. Easy enough. Or it should be.

The thing is, every time you power on the unit, the Mac rediscovers it and assigns it a new device handle at the BSD layer. Which means you get something like:



Two devices means two entries. But that trailing 8 on the second one? It changes every time the device is discovered. That means that every time the rig is turned off and on again, that number changes. It goes up by 2s until reboot in my experience. The other problem is that the A and B interfaces mentioned above aren’t assigned consistently. So more often than not, I get a failure immediately when I launch WSJT-X because the trailing number on the device identifier has changed OR the A interface was assigned the device identifier without a number when it had it before.

There’s no way to defeat this at the OS level. I’ve tried. If you have a way to do it, shout! In the mean time, I did a dumb workflow that runs a simple python script and displays which interface is assigned to A. How did I do it? Easy.

Install pip if you haven’t got that running on your system.

Install pyserial

Run this at the command line:

python -m "IC-7100 02008919 A" -q

Now, because I’m a fancy guy, I put it into Alfred so I can get this on my screen:

Port A: /dev/cu.SLAB_USBtoUART10

Total time on the solution for this was…much longer than it should have been. Digging around for a way to tie a device description to the /dev entry took way too long as the pyserial option didn’t exactly boil to the top with the way I was searching. That said, the actual implementation was about 10 minutes of work. Following the above instructions if you have a Mac with Python on it shouldn’t take more than a few minutes.

So I’m putting this here in case there is another nut like me out there. The adventures in the hobby of hobbies continues!