July 20, 2010
14:10
by: Dan

Jolly Jeepers Rally 2010

This past Saturday, Taylor and I participated in our second Jolly Jeepers “Back to Basics” Rally event.  Unfortunately, we had firm commitments to other things on Friday and Sunday, so we didn’t camp or do both days.  This has become one of our favorite activities and something we look forward to the entire year.  I’ve only been home a couple of days and I’m already thinking forward to the next one.

Last year I ran the whole thing stock, with lots of skid-plate scrapes to prove it.  This year I had the lift, the tires, and a winch making it a little easier and a lot more fun.  Another big contributor to the “fun factor” was the fact that we reunited with a couple of friends from last year: Ron and Carm.  They brought two of their friends (Nick and Nick) as well, which was great.

We left camp at 7:30 Saturday morning and had a full day of fun.  The first interesting event happened when one of the guys in the group bent his drag link while trying to muscle around a tricky turn.  This resulted in his two front wheels not pointing the same direction, making it nearly impossible to roll out.  The guys on the trail ended up straightening it out a little using his winch:

After all that flexing, the bar was really far too soft to do anything for his steering, but it was straight at least.  A couple of people on the trail had a bright idea of using the handle from a hi-lift jack to sleeve the drag link.  This worked perfectly and the guy ended up staying with the group the rest of the day instead of heading back to camp.

The most notable event of the day, however, was Ron’s “axle ordeal”.  The group was making its way up a spot called “the rocky uphill”.  Another group delayed us moving through here quite a bit because of a very difficult spot up at the top.  Several stock Jeeps had made it through, but only just barely.  Ron made it all the way to the top without much trouble, but then got high-centered before the really bad part.  As the group of spotters helped him move through, something bad happened.  In the below video, note the part where Carlos asks the other spotters if the rear passenger tire is spinning:

Watching from behind, Nick and I were horrified to learn that Ron’s rear end wasn’t being powered.  The driveshaft was turning (a good sign), but no power was making it to the wheels.  There are several expensive parts between the driveshaft and the wheels, so we were worried.  It turns out that he just broke an axle rod.  I’m not sure how we didn’t get a picture at the top, but this is probably a 1″ steel bar that connects the wheel hub to the differential inside the housing.  When they pulled it out, I was amazed to see it just twisted and broke on the differential side.  It could have been a lot worse, and this is about the best possible outcome, given the circumstances.

While this was definitely the least expensive thing that could cause your rear end to behave like his, it definitely posed a challenge for the group getting him off the trail and back to camp.  The axle rod is all that keeps the wheel on the vehicle itself.  By the time Ron had been winched to the top, it was clear that his rear passenger wheel was further “out” than it should be, since the axle was no longer pinned inside.  The problem here is that it was another couple of miles of fire road driving before we could get to a point at which we could meet a flatbed trailer.

The trail fix was one that apparently many people had seen written up in 4-wheeling publications, but had never seen in person.  The group started to collect some thick branches and arrange them in a brace configuration around the rear passenger quarter of the vehicle.  One laid across his bumper and another underneath the vehicle provided a place to lay a branch across the wheel.  A roll of wrapping wire provided the structural support needed to hold it all together:

Justin did an amazing job of constructing this “field dressing”.  With this, we slowly escorted Ron out of the forest to a camping spot near one of the roads.  Russell had left earlier to head back to camp, get his truck and trailer, and come back to meet us there.  The brace held the entire way, leaving only a bit of a rubbed circle on the tire:

At the campsite, we got the jeep up on the trailer and headed for camp:

Only one more interesting thing happened that day.  The truck pulling the trailer with the Jeep ran out of gas on the way back to camp!  Given the events of the day, it seemed only fitting.  Carlos ran back to camp and grabbed a couple of fuel cans.  This allowed Russell to refuel the tow vehicle and make it back to the campsite.

At that point, we had to head down to Newport in preparation for our activities the next day.  We would have liked to stay for the dinner and prize drawings, but the timing just didn’t work out.  Hopefully Ron will get his axle fixed without too much trouble or expense so that he can come back next year and bring the Nicks with him!

Here are links to all the pictures we took (never enough, as usual) as well as all the video.

Posted in News Tagged

July 11, 2010
18:34
by: Dan

Kenwood TK-380 Self-Programming Modification

I recently purchased a Kenwood TK-380 UHF handheld radio on eBay.  This is a commercial UHF FM transceiver used by public safety organizations.  It will do 4W output, narrow or wide band transmission, and conventional or trunking operation.

This radio is Part-90 accepted, which means it can only be programmed via computer.  Unlike commercial ham radios, regular radios are not allowed to provide the user with a means to set an arbitrary frequency from the front panel.  This radio has that functionality, but it is disabled by default.  By removing a surface-mount resistor jumper inside the radio, you can re-enable it.

Start by removing the battery and antenna, and then remove the two screws at the bottom of the battery compartment.  This will allow you to separate the casing from the radio body, which should look something like this:

 

 

Next, remove the rubber gasket and speaker assembly by peeling it off the body and disconnecting the speaker wires:

 

 

Next, remove the top logic board with the display and the button pads.  It is not necessary to disconnect the ribbon cables going to the board below.

 

 

Next, remove the bottom board’s screws and flip the board over.  Note the resistor marked R144:

 

 

Remove this resistor.  This can be done by desoldering it with a fine tipped soldering pencil or by force using tweezers to crush and remove it:

 

 

When you’re done, reassemble the radio, taking care to realign the rubber button caps in the front panel.  Next, you must use the software to enable the self-programming mode in the radio.  Once you do, you can hold down the button below the PTT button while turning the radio on to enter “SELF-PROG” mode.  Navigating with the buttons on the radio is rather self-explanatory after that.  Full-size images are located in the gallery.

Posted in Hardware, Radio Tagged

June 29, 2010
13:53
by: Dan

Custom UPS External Battery Bank

When we moved into our current house, I had a Matrix 5000 UPS that I used to power my server room.  This 5kVA unit was a really impressive device that ran on 220V and could have its “brain” replaced without powering down the load.  I had four external battery packs for it, which provided over an hour of runtime at full load.  Last summer it stopped working as a UPS for some reason, and then the isolation transformer failed catastrophically six months later:

 

Unfortunately, this unit is no longer made by APC, and there isn’t much information about it online.

I really liked this setup because the UPS was in the garage, fed by a dedicated 220V 30A circuit, and the UPS directly fed a small breaker panel which took two circuits up to the server room. That way, everything was protected by the UPS from surges and small power outages. Since the failure, I’ve been running on small UPSes directly at the critical machines, and using surge protectors for the non-critical stuff.

Recently, I came into a couple of SmartUPS 3000RMXL units for a good price. Two of these have good batteries in them, but the batteries in the other two are on the way out. Since they are “XL” units, they have external battery connections, allowing you to add additional runtime by daisy-chaining 48V battery packs. I decided to construct a large battery bank for this unit and build the connectors required to hook it up.

The batteries I used are C&D Technologies UPS12-370FR, which are 100A/Hr commercial gel cell batteries designed for custom UPS systems. Why did I choose these? Well, because they are designed exactly for this sort of thing.  Oh, and I also got them for free!

I put one of the SmartUPS units on the platform I originally had for the MatrixUPS and changed my previous L6-30 (220V) plug on the wall to an L5-30 (120V) for the new unit. Then I created two 5-15 pigtails to bring two of the 15A circuits off the back of the UPS in to the two legs of the breaker panel. With this configuration, the UPS carries the entire server room, for about 2200W continuous load. With the existing weak batteries, the UPS claims about 10 minutes of runtime (although I don’t believe it).

The internal battery on the UPS connects to a port on the front near the battery bay using an Anderson SB120 plug. This is actually routed to the rear of the unit where two SB120 plugs are connected by a continuity module in normal operation. The continuity module simply connects the UPS to the internal batteries.

In order to get the external batteries into the mix (and keep the internal ones there for a buffer during maintenance) I created a cable that I expect is quite similar to what APC provides for use with its approved external packs. This cable is two 8AWG conductors for each terminal on the UPS side of the circuit, which goes to the external battery pack. An additional short 10AWG jumper also exits this connector and goes to the internal battery side. The finished cable looks like this:

A close up of the UPS-side connector:

Note that, when looking at the back of the UPS, the SB120 plug closest to the line input and circuit breaker is the one connected to the UPS’ charging and inverter circuits. The one furthest from this is the one that loops to the internal battery. I made sure that the heavy gauge wire was connected to the UPS side, with the jumper to the battery so that you don’t end up pulling all your current through the smaller jumper wire. The SB120 plugs are designed to be stacked in this manner, and have holes designed for bolts as pictured.

Next, I stacked all four of the external batteries on top of the UPS, taking care to locate them near the edges of the unit where there is most likely to be internal support for the weight. With more room and care, this could have been done better, and I may change it in the future. Once the batteries were physically placed, I started to link them up in series with short 2AWG jumper wires:

In one of the links, I added a 200A fuse to make sure that any short across the terminals wouldn’t result in a huge amount of current flow and/or an exploded battery. I also then attached the battery cable to the 48V side, leaving the cable still disconnected from the UPS itself:

Just in case you are wondering, 48V DC is plenty to give you a noticeable shock across a sweaty arm (trust me), so care should be taken once you get to this point.

After checking my connections one more time, as well as the voltage and polarity of the output at the connector, I plugged it into the UPS. Immediately the UPS’ fans kicked on to cool the charging circuit as the batteries were a few tenths of a volt lower than the UPS keeps them at normally. This subsided after a minute or two.  At that point, I reconnected the internal battery on the front. The finished connection looks like this:

Obviously I still need to do some cleanup.

Next, I logged into the UPS’ web interface and told it that an additional four battery packs were connected. The internal pack contains two sets of four 7AHr batteries in parallel to give about 14AHr of capacity at 48V. Four of these would be 56AHr, which I figure is probably close to the limit of what APC would recommend plugging into a single UPS, and may be closer to the actual capacity of the new batteries at high load. All lead-acid batteries are rated at one or two capacities, given a specific load. The faster you pull current out of them, the lower total capacity they have.

After performing a calibration test, the UPS now reports (and actually provides) 1hr45m of runtime with the additional pack. This is pretty good for a 2200W load, especially considering that the non-critical stuff gets shut down almost immediately after a power failure, lowering the load and increasing the runtime.

I should also point out that I have a very plain 3500W camping generator that doesn’t use an inverter and produces very mediocre output. It’s fine for most things (including electronics) but most UPSes are unable to handle and correct the input when running on the generator. These models have the ability to set the input tolerance very low, which allows them to run happily when plugged into the generator. The MatrixUPS was never able to do this, even on the lowest sensitivity setting.

I have a few more pictures, and high-resolution versions of the above in my gallery.

Posted in Hardware Tagged ,

June 17, 2010
19:24
by: Dan

The IBM “Jeopardy Challenge”

Most people don’t think of working at IBM as a very exciting endeavor.  At times, I’d be hard pressed to convince them otherwise.  However, there’s something very special about what a large (country-sized) company with a wealth of talent and resources can do to change the world and the way we think about technology.  When I was an intern at IBM in 2004, I had the opportunity to work with an artifact of one of those game-changing demonstrations of technological prowess.
 
I was working for the “multimodal technologies group,” specifically on voice-enabled web browsers for mobile devices.  While it really didn’t pan out (the way we were doing it, that is), the idea was that a voice interface to a web browser on your cell phone or PDA could end up making navigation much easier while walking, driving, etc.  We ended up creating a few applications to demonstrate this functionality in ways that would grab people’s attention.
 
One of the things I worked on was a voice-enabled chess game.  This was not just any chess game, however, because it had some “help” at the server end.  Sitting on a shelf at the Austin site was one of the nodes left over from the Deep Blue machine that beat Garry Kasparov at chess in 1997.  It was only one node of many that actually played the game together, but it had the custom “chess hardware” in it and the software still installed.  I coded up something that would put a web services API on the chess application and allow a web client to play against the computer.  After we got it working, one of the people in the lab figured he could probably beat just a single node, so he gave it a try.  The game was over pretty quick.
 
IBM recently announced their proposed “Jeopardy Challenge” which has a similar goal: beat a human at something mental by brute force.  However, this one makes Deep Blue look like a walk in the park, if you ask me.  Take a look:
 
 
It seems like an impossible task, but we have to get there at some point I suppose.  I’ll be watching closely to see what develops and how “Watson” does!

Posted in News Tagged , ,

June 9, 2010
22:20
by: Dan

CHIRP gains Yaesu VX-7 Support

Until now, CHIRP development has been focused on ICOM products.  In fact, you might even be tempted to think that the “I” in CHIRP was for ICOM.  Lately I’ve been using my Yaesu VX-7 and VX-8 radios a little bit more for various reasons (i.e. they’re a lot less expensive if I lose one and they’re smaller as well).  I’ve gotten so hooked on being able to program the radio via computer, that having to use the (hard to press) interface buttons all the time has been rather annoying.

I’m pleased to announce that CHIRP supports the VX-7 in the latest beta (0.1.10b9) and there will be a formal release coming up soon with it as well:

 

Reverse engineering the radios’ memory format gives you a lot of insight into how each model is designed.  It’s interesting how different they often are, and how tightly they pack bits of information to make efficient use of space.  I must say that I have a lot more confidence in the ICOM designs than the Yaesu from what I’ve seen thus far.  In the trial-and-error period of figuring out how to program the VX-7, there were many times where writing some invalid data into memory would cause the entire radio to lock up.  Often times this was so severe that a full reset was required to get it back to the point at which it would agree to power on into clone mode.  The ICOM radios are much more intelligent about it and will abort the clone as soon as you write something that isn’t valid.

I’ve got a VX-8 programming cable on order, so I hope that in a couple of months I’ll be able to claim support for it too.  Stay tuned! 

Posted in Radio Tagged , ,

March 28, 2010
21:59
by: Dan

Jabber.com DNS record issues

Recently a friend of mine signed up for and started using a jabber.com account to chat with me.  I have run my own jabber server for almost ten years now and I’ve never had problems with the server-to-server (S2S) aspect until now.  For some reason, the jabber.com SRV records seem to fail to resolve at times, which was occasionally killing the jabber.com S2S connection with my server.  It seemed like the connection would occasionally recycle, which caused my server to lookup the SRV records.  If that failed (which was happening multiple times per day) then I would be unable to communicate with jabber.com contacts for several minutes.  Their status showed as something like “404: Server not found”.  In the logs of my Openfire server, I saw items pointing to the failed DNS lookups.

After asking what to do in the Openfire forums, someone mentioned that they had the same issues due to sporadic lookup failures on the jabber.com SRV records.  They suggested spoofing the necessary records to fool my server into connecting to the proper IPs without having to perform an actual lookup.

It is pretty silly that I have to do this, but I ended up making it work by running a local copy of BIND and hosting the jabber.com zone myself internally.  This seemed to resolve the problem for me, which is good.  Later when I was working on a different project, I noticed that dnsmasq now has the ability to spoof SRV records as well.  I decided to switch to using it to do the job instead of bind.

My server is running CentOS 5.x, which has a dnsmasq package available.  I installed it via yum:

yum install -y dnsmasq

Next, I edited the /etc/dnsmasq.conf file and added the following lines:

expand-hosts
resolv-file=/etc/resolv.masq
srv-host=_xmpp-server._tcp.jabber.org,hermes.jabber.org,5269,1
srv-host=_xmpp-server._tcp.jabber.com,jabber.com,5269,1
srv-host=_xmpp-server._tcp.jabber.com,denjab2a.jabber.com,5269,1

Finally, I put the following entries in /etc/hosts:

208.68.163.220   hermes.jabber.org
216.24.133.9     denjab2a.jabber.com
216.24.133.14    jabber.com

Note that the host entries may become stale, so some babysitting of those may be required.  I decided to override jabber.org as well since I saw a few similar error messages in the logs for that domain as well.

Next,  you need to put your own DNS servers in /etc/resolv.masq so that dnsmasq knows where to forward normal requests.  Something like the following would work, substituting your own DNS server IP addresses:

nameserver 1.2.3.4
nameserver 5.6.7.8

Finally, you need to tell your system resolver to use the local machine (running dnsmasq) for queries.  Set the nameserver in /etc/resolv.conf to localhost:

nameserver 127.0.0.1

Now you can start dnsmasq and configure it to start at boot:

service dnsmasq start
chkconfig dnsmasq on

A restart of openfire (or whatever you’re using) would probably be appropriate as well.

Posted in Miscellaneous

March 3, 2010
14:47
by: Dan

Oregon ACES

In just about all areas of public safety, training and certification plays an important role in making sure that the people you trust with critical tasks in emergency situations are able to perform.  They have to have to knowledge necessary to make informed decisions, but they also have to have some amount of experience executing their duties before it becomes a life-or-death situation.  It is for this reason that police and fire are constantly training to increase their effectiveness, which often involves a periodic recertification.

Amateur radio operators looking to help with emergency communications usually expect to interact with various public safety organizations for planning, training, and of course, actual emergency situations.  Unfortunately, we rarely hold ourselves to the same standard of those that we hope to serve. There are some standardized training courses available via the ARRL, but they don’t require you to own or have ever operated a radio, nor do they require you to do anything other than sit in front of a computer for a web course.  The material in the course is good, but reading through it does not mean you are magically able to execute in an emergency.

Can you imagine if the only bar for being a police or fireman was a voluntary web course?  I don’t think that people would be willing to place their lives in the hands of such individuals, yet we do exactly that when we secure ourselves as the backup communications provider for a police, fire, or medical agency.  Can’t we do better?  I think we can.

Over the past couple of months, I have been working with a few highly-skilled people to develop a program called Oregon ACES.  The idea is to define several levels of training and certification for amateur emergency communications personnel, to provide those courses and a certification registry for those who have taken them, as well as promote frequent training opportunities in the area.  We have already enlisted a healthy list of supporters in Oregon, including multiple city and county emergency management departments, other volunteer groups, as well as a couple of counties in our neighboring state of Washington.  Additionally, we have nearly completed the process of being accredited by the NRCEV, a national group that recognizes local training programs and certifies participants with additional credentials.

We recently published our basic course outline, and have it open for public comment.  If you’re interested, please look it over and use the linked form to provide feedback about anything we missed or should elaborate on.  Even if you think it’s good as-is, let us know.  The idea here is to provide a healthy amount of classroom instruction, as well as some mandatory group and individual skills demonstration.  The basic level is aimed at a volunteer who is likely to be in the field with just a VHF/UHF handheld radio and maybe an auxiliary power source.  The advanced and other certifications will include things like HF, digital modes, and other topics.

Many existing hams involved in emcomm will wonder something along the lines of “How is this different from the ARRL course?” or “What relation does this have to ARES?”  The FAQ page should answer all of those, and if it doesn’t, let me know.

By the way, you do not have to be in Oregon to provide feedback on this program.  We’ve already received comments from Washington, Pennsylvania, and Texas and would welcome any others!

Posted in Radio Tagged ,

February 19, 2010
16:56
by: Dan

Survival Guide for Linux Hams

This is a bit of old news, but since it’s now available publicly, I suppose it’s a good time to post about my recent article in the January 2010 issue of Linux Journal.  I was approached late last year to write an article for a “Ham Radio” edition of the magazine.  There was no particular topic, so I suggested an “Amateur Radio Survival Guide for Linux Users” to explore a few common things that Windows users might take for granted.  I covered a little bit about basic contest logging, TCP/IP over packet radio, D-STAR, APRS, amateur satellite tracking, and SDR.  The goal was to provide some starting points for a Linux user that might be a new ham, but it would also interest existing hams that are looking to move to Linux for some of their operating activities.

I should also mention that I got some valuable proofing from Jason, NT7S prior to submission.  Thanks Jason!

Posted in News

January 18, 2010
18:15
by: Dan

2010 Eagle Cap Extreme Dog Sled Race

Last week, Taylor and I were in Joseph, OR for the 2010 Eagle Cap Extreme dog sled race.  This is the second year that the race administration used ham radio as its primary communications mechanism.  Without us, they are limited to mediocre satellite phone coverage or use of the unlicensed short-range radio services.

The area is quite remote.  There was some cell coverage in Joseph itself, but just yards outside of the tiny town there is no signal at all.  Mountains and canyons make satellite phone coverage spotty and completely sub-optimal, even at the extreme cost it takes to utilize them.  Over 250 volunteers spread out over a dozen locations across the 200 mile course means that there is a lot to coordinate.

The local hams utilized a pair of echolinked repeaters to blanket the area with communications capabilities.  The Joseph (Oregon) repeater provided surprisingly impressive coverage for the northern bits, while the McCall (Idaho) repeater covered the southern part.  With very few issues throughout the week, many places were able to get into one or both machines with a handheld or modest mobile radio.

I worked the 1600-0000 shift up at Salt Creek Summit.  This snow park at almost 6000 feet could hit just about everyone on simplex and provided a good backup in case either of the repeaters went down.  A ham from Pendleton brought his fifth-wheel travel trailer and parked it there for operating convenience for the duration of the event.  A Honda EU-3000i generator running 24×7 provided power for the radios, lights, and other conveniences.

This was the first year that the event attempted to utilize any sort of amateur digital transmission, on my recommendation.  I brought a packet BBS-in-a-box (a small JNOS setup on Linux) that I ran at the summit.  We also provided an old laptop and radio setup for Race Central running Outpost.  I had coordinated with Chris at Ollokot ahead of time to get him going with a similar configuration.  Since the primary race communications were on 2-meters, we hoped to use UHF for the packet system to keep interference to a minimum.  Unfortunately, we found that 35 watts from a standard mobile radio on 440 MHz wasn’t enough to fight the challenging terrain and long distances between the stations.  We had to resort to using a 2-meter frequency, which meant that packet wasn’t really usable except during periods of inactivity on the voice channel.  Thus, it wasn’t the resounding success I had hoped it would be, but the scenario was really a losing battle being on the same band.  Next year, we hope to give 6-meters a shot, which we think might be a real solution.

Taylor worked the same shift at Race Central.  She put her technical knowledge to work helping them to establish email communications with the external entities, as well as organizing the information that was flowing in and out.  She did an excellent job of making the best of the packet system from the “other side”;  We exchanged many messages during the race, timed appropriately to avoid interference with the voice channel.

We were both prepared and hoping for a bit more of a camping scenario.  At one point, it was expected that we wouldn’t have the trailer up at the summit and that we’d be in a tent.  Thus, I was over-prepared when I found myself sitting in a heated trailer with a microwave and a recliner.  Taylor, being at Race Central, was always in a heated building.  That area of the state is currently far below its expected snow level, too, which we weren’t anticipating.  All of the other checkpoints, however, were far more isolated, with only snow machine access in and out of the camps.  I think we’re both hoping that we can participate in one of those next year.

We had a blast the entire time.  It was exhausting, rewarding, and a real break from everyday life.  We’ll definitely go back next year, and I’ll be much more familiar with the terrain and operation of the event so that I can have a better plan for getting a reliable digital system up and running.

Posted in Radio Tagged ,

November 9, 2009
18:29
by: Dan

All hail Winlink 1988!

Winlink 2000 is a hot topic in the amateur community right now.  It provides a mechanism to access Internet email over several different transports, including an Internet connection, local V/UHF packet radio, and long-distance HF Pactor.  The idea is great, and in practice, it works reasonably well.  There are a lot of complaints to be made about the design and implementation of the system, but at the end of the day, those guys put in the time, effort and money and made it work.

One of the (many) complaints I have is their use of the ancient B2F forwarding protocol.  It’s fine to use that over slow Pactor links (I suppose), but why aren’t we just using something like POP3 for the Internet hops?  Rather silly, I think.  Anyway, one of the design points of the B2F protocol is the use of an even more ancient compression algorithm called “lzhuf”.

The algorithm and code for this was written in Japan in 1988 to run on a 16-bit machine.  The source, and many disparate alterations since then are sprinkled around the Internet and are easy to find via google.  However, most people use either the command-line LZHUF_1.EXE file that has been around forever, or the DLL-ized version that the Winlink applications deliver and use.  This effectively limits its use to Windows machines (and dosemu-installed Linux boxes).  When I tried to compile several of the variants under Linux, I found that the code makes a bunch of assumptions about type sizes and thus crashes and/or fails to decode compressed text as a result.  In fact, depending on where it fails, sometimes it runs off in an endless loop writing garbage to the output file until you kill it!

After spending a lot of time trying to find someone who had fixed the code to compile on a modern 32-bit system, I finally found a copy of the source that would compile on my system with g++ and actually run properly. I found the updated source code here and have archived a copy of the source on my system, as well as a static Linux binary in case you don’t want to compile it yourself.  If you run the binary with no arguments, it will print a usage message.

Now, you might ask “Dan, why does Winlink 2000 use this old, unmaintained, fragile, and obscure compression algorithm?”.  Well, in the days of freely available code, algorithms, and libraries to do advanced compression, encoding, etc, I can assure you that the top notch Winlink engineers have a good reason.  ….Right?  I figured that this obscure gem from the golden age of 4MHz PCs must be an undiscovered compression miracle, one that makes the extremely slow Pactor connections able to transfer data as efficiently as possible.  So, I decided to compress some test files with lzhuf, as well as the freely-available-and-well-regarded gzip and bzip2 algorithms and compare the results.

As input, I used the lzhuf source code itself, which is about 19KB in size.  That’s a pretty good sized email even with a potential file attachment.  Below are the results:

 Method Size  Reduced size by:
 Uncompressed   18,917 (19KB)   (n/a)
 lzhuf  5,385 (5.3KB)   72%
 gzip  4,903 (4.8KB)   75%
 bzip2  4,589 (4.5KB)   76%

So there you go: with bzip2, you’d get almost a kilobyte less data to transfer than you would using lzhuf.  Does a kilobyte really matter?  Well, Pactor-I is 200 baud (at most), with very small block sizes.  Yes, I think I’d rather save that kilobyte.

So, I ask the Winlink 2000 developers: Why not move to bzip2 compression?  It’s free.  It’s widely available.  It’s considered one of the best.  You put “2000” in your name to sound like the system is new, fresh, and modern, why not use a compression algorithm to match?

Posted in Radio Tagged ,