Menu

Yay! The hardware design for the new MicroModem is now finished, and has become something I feel that I can ship! What a great feeling! There’s been many revisions, many small changes, various experiments and general mocking around, but in the end, I feel that MicroModem is now at a point where it is actually a really great product. It’s been an interesting journey, and there’s been many different choices along the way. I’d like to share a few of them! If you don’t feel like reading all my blabberings, here’s the short version: All is good, hardware and software is ready, MicroModems are back in the shop!

New features

Before I start yapping about everything and nothing, I better just quickly list some of the new features of this version:

Integrated design, everything on one board

Dimensions are just 2.9 x 4.9 cm (I think this is the worlds smallest full-featured TNC)

The Hardware Journey

When I first designed MicroModem, I wanted to make a modem that more or less anyone, with only some basic electronic skills could build. I think the topic of digital communication is extremely interesting, and my motivation was really just to make that topic more accessible to others in a direct experience way. I think and hope I succeeded in that goal, and while the new MicroModem might not be something you’d want to build yourself, the formula is essentially the same, and all of the old resources are still available for the “DIY” version, that will work just as good as it always has. I’m not leaving any users in the dark in regards to software updates either, all of the new software works on the first generation of hardware as well, but more on that later.

When I started selling the MicroModem builds based on the Microduino and the MicroModem expansion boards, it quickly became apparent that this was a really bad manufacturing process. It took ages to get new Microduino boards from the manufacturer. It took a lot of time to assemble the boards. The cost for the modules was way too high. There were quality issues with the Microduino core modules and USB modules, that basically meant I was running very near a net loss in making these modems. Bad plan if you want to make great products, and continue doing so! Well, sometimes you gotta make some mistakes to learn how to do it right!

Obviously these challenges prompted me to rethink the manufacturing process of the modem. It became clear rather quickly, that if I wanted a manufacturing process that was more smooth, I would need to make everything from scratch. That way, all the components would be easy to source, and would only have lead times of a couple of days, instead of several weeks. That’s really key when you’re doing small production runs as I am. The amount of modems I sell doesn’t really warrant me shopping components for hundreds of modems at a time. Hopefully that will change in the future! But until then it’s important to have a flexible source of parts, so I can just order components when stock starts running low, and then be ready with more modems before stock runs out.

But going to a fully custom design also meant a lot of research! I wanted to make the modem fully Arduino compatible, so you can just plug it into your computer and program it from the Arduino IDE. That basically meant designing an “Arduino clone” with the modem ciruictry integrated on the board. I drew up a quick prototype and send off a PCB order. Fingers crossed! Luckily it turned out to be less trouble than I had thought, and the first “Arduino” prototype actually worked flawlessly… Well, almost… At least it did after air-rigging in an extra resistor I had forgotten in the schematic and PCB! Well, I guess that’s what prototypes are for!

It also meant moving from through-hole components, that I was very comfortable with, to surface mount technology. Yikes! Those things are small! I had never done ANY surface mount work before, and I was a little scared it would turn out pretty difficult. I can tell you now though, that if you have been thinking of doing surface mount designs for some project, do yourself a favor and just do it! I was amazed that it is actually easier and a lot quicker than through hole designs! Yeah, the components are small, but it’s not a big deal. Just go spend four bucks on a nice pair of tweezers, and you’re good to go! For prototyping stuff, you can easily hand-solder SMD components, but of course you need a reflow oven for manufacturing. So I set out to put one together, and after some Youtube-education, a trip to a hardware store and bunch of modifications, I had myself an temperature-controlled SMD reflow oven. There’s plenty of videos and tutorials available on how to build one, and all I can say is that it works great! No reason to go spend several thousand bucks on a fancy oven, when you can build one yourself for much, much less.

Connectors, Colors, Compromises and Mishaps

Tools and skills in hand, the actual work on designing the board flowed great. There’s been quite a few iterations. I always ended up wanting to just improve that last little thing, but even though it’s dragged out the process a bit, I think it has paid of in the end. There’s also been a few compromises. I initially promised that the finished boards would be with a black solderscreen finish. Well, I will have to take that one back. I did make a small batch of black modems, but the quality is just not as good as with the normal green mask, which lead to me having to manually fix little errors on about 50% of the boards. The silkscreen (the text on the board) also had this strange habit of turning pink when reflow-soldered on the black boards. Apparently I’m not the first one to come to this conclusion. Oh well, even though the black boards looked really cool, I hope you’ll agree that the quality is more important! I might go with another fancy color in the future, if I can find a PCB manufacturer that can do them in good quality, but for now, green it is! I have a small batch of the black boards, and since they’re all working, and just have some cosmetic flaws, I will be selling them at a bargain price, since I figured it’d be a shame just to bin ’em.

I would also never have imagined how much of the design process is taken up looking for components! You have no idea how much time I have spent looking at different connectors, finding just the right ones, ordering some to test, only to find out they didn’t live up to my expectations. Try again! There’s an ocean of different connectors out there, and quite frankly many of them are crap! The one’s I ended up going with are not. They’re low profile, so they don’t take up much vertical space, but they still have a nice gripping action when inserting a pin or jumper cable in them, and they look good as well! Also, on another strange note, the connectors have ended up being some of the most expensive components of the board, taking up roughly 30% of the total cost of the modem! I wouldn’t have guessed beforehand. And no, I didn’t just buy the most expensive ones I could find. They’re not the cheapest ones either, but proper connectors are apparently just expensive! I had to settle for a price for the modem a bit higher than the previous version, to not drive myself out of business. MicroModem is still the cheapest full-featured TNC/AFSK1200 Modem on the market though, so I think it’s a still a pretty good deal! There will be a cased version of the modem as well, but I won’t have time to finish the design until after the holidays.

In the department of compromises, I had to sack the ADC-reference detect feature. As you might know, I had earlier promised an “auto-detect” feature for detecting whether the modem’s ADC was running from a 5V or a 3.3V reference. In the end I was not able to implement this in a satisfactorily reliable way. You want this feature to work every time, not just 99.999% of the times, and unfortunately I could not get to the level of confidence that I wanted, so I ended up deciding that it was better to simply offer different firmware builds, one for 5V and one for 3.3V, and include easy switches in the source code, so you can select it yourself if you’re brewing your own firmware. It might not be as slick and cool, but it’s safe and reliable.

The Great Code Cleansing

As you might now, I have been in the process of rewriting the entire codebase for the APRS-oriented firmware, MicroAPRS. Why be so mad when the existing firmware had just gotten to a point you could call “feature-complete”?! Well, mostly because I like flexible, and the way the firmware had developed was anything else than flexible. When I started writing it, I based it on the BertOS SDK, because it has a lot of really nice features and shortcuts for developers. Like not having to write your own serial driver, which is really nice! But it also carries a lot of bloat and ugly staticness, and made the firmware about as portable as a pint of syrup in a shoe. One of my goals with MicroAPRS is to offer a codebase that can compile on many different MCUs, not just the 328p. This was not really going to work with BertOS, so I decided to do the right thing, and start over before it was too late. The results are now in, and I’m glad I did it! Resource usage, both in terms of flash and RAM is almost halved. That’s some pretty big savings on a small processor! And this has also allowed me to fulfill another goal: creating an APRS library for the Arduino IDE. You can now create your own APRS firmwares for MicroModem, right from the comfort of the Arduino IDE. Also, as a small teaser, I can say that I have an unreleased version that runs on the ATmega1284p. More on this in the future though, I’m not going to go into detail with it here.

Ready to go

In conclusion, I also want to say a huge thanks to all of you who have helped out with ideas, found bugs, made great suggestions, and made awesome things based on MicroModem! This is really what makes it so much fun to design a product like this! I hope all of you will come to enjoy using the new MicroModem as much as I did designing it!

I have a small batch of modems ready to ship out now, and will have many more available after the holidays. Thanks for the fun ride so far!

Hi Shawn!
Thanks! That’s really interesting. I will have to try that myself at some point as well. Maybe that will be an update for a later hardware revision. The chips you mention are not very expensive, so I might be able to include it in a future revision. Hardest part might be fitting it on the board though 😉 I’ll have to do a test with the TNC test CD on the new modem as well 🙂

Hi Phil!
It does not have an onboard GPS, this is a modem/TNC only, so you would have to connect an external GPS. It is a lot more open and flexible than the Argent micro. MicroModem can be reprogrammed from the Arduino IDE for instance. Whether or not this is a plus depends on what you want to use it for! If you just want a “plug-and-play” tracker with built-in GPS, the Argent micro is probably a better choice for you!

The Argent Micro is a fantastic little device, and is a full blown tnc that can do anything from KISS, to digipeating, to multi-profiles, yet is super easy to use, affordable, and reliable. The custom scripting ability adds alot of the needed functionality for customizable hardware/cmds. Or just about anything you could want. Their T3 mini board with all 12 Dig I/O and 4 analog inputs make telemetry and control very easy too. The restricted source code is the only downside. But It hasn’t slowed me down too much!

I do like the open source abilities of the micromodem, and for the ultimate in custom firmware, this would be it, some digital I/O and analog inputs would be nice though.

please excuse my dumb questions but I am new to building my own radio equipment. I would like to set up a RX-only APRS IGate with a Raspberry Pi 2 B and your modem.
The signals should come from an old scanner I have laying around (Uniden UBC220XLT). Can I use the normal audio output of the RX or does it need a discriminator output?
Second question: How can I connect the modem and the Pi?

Hi Holger!
No worries, there’s no stupid questions! The setup you’re describing should work great. You should have no problems using your Uniden scanner as an RX-only radio. I have a Uniden scanner myself (not the exact model you have though) and use that for testing with the modems often.

You don’t need to use the discriminator output, it can pass just fine over the normal audio output or headphone port.

To connect the modem and the Pi, just use a standard mini-USB cable. That will provide power for the modem, and allow the Pi to talk to the modem over the serial port.

The Raspberry Pi is a great little board for this kind of stuff. I’m running my own APRS station with a MicroModem and a Raspberry Pi 🙂

You will have to make the GERBER files yourself according to the process of your local manufacturer 🙂 These change from plant to plant, so I cannot provide a set for every possible producer out there 😉 The eagle files are readily available though, so just download them and export them! You can also generate a BOM from the eagle source files 🙂

Very interesting and smart project. I’m wondering if would be possible to double up the speed (2400bps) for a non APRS project, but still using the mic input of the radio. (voice audio range).
There is a Half duplex modem CMX469AD3 that may do the job, however with your approach, I have access to the whole process (microcontroller +Softmodem) .
My intention is to send ID+LAT+LONG everytime PTT is keyed.
I would like to know your opinion when time is right for you

I’ve run some tests on this with modems just connected by wire, and they can do 2400bps fine that way. It might be stretching it when running over cheap handhelds though, but I’ve had some success. Probably needs some more tuning of the software filters to get it to work well.