Anytone AT-3318UV-D

After my Baofeng UV-82HP got banged a bit, I needed a new radio. By pure accident I’ve stumbled upon wouxun.us pages with a wide selection of Anytone radios. Loving airports and all related, I’ve got tickled by built-in AM band immediately. So I decided to go for dual-band Anytone AT-3318UV-D.

First thing I’ve noticed is that radio is much smaller than Baofeng even though it comes in bigger box. Contents are pretty much same: radio, antenna, battery, belt clip, charger, and DC adapter. Anytone additionally has lanyard while Baofeng goes an extra mile and includes a headset.

Anytone looks a bit sturdier than Baofeng, probably due to a smaller build, but I find them comparable as neither is really meant for rough handling. Battery and clip mounting are done much better on Baofeng where I found battery was impossible to remove by accident. Anytone doesn’t instill the same confidence. Further they’ve decided to mount clip on the battery instead of phone body. I find this rather weird and annoying, especially in light of having multiple batteries - each having its own clip ensures you cannot store them easily.

Chargers look equally flimsy and both have possibility to charge battery without the phone. Annoyingly Baofeng uses 10 V as input voltage and thus makes it hard to find a replacement adapter. It did work with 9 V for me but your mileage might vary. Anytone uses pretty much standard 12 V for its chargers and thus earns mega points from me.

Keypad on both uses standard 3x4 numerical layout with additional top row being used for various functions. Main Anytone advantage is having back-lit keys. If you often work in low-light situations this is awesome. On other hand its center number column is wider than ones on side, just showing it is impossible to have a standard keypad without designers screwing around at least a bit.

Baofeng has a dual PTT key, FM radio, and flashlight control on side while Anytone has a single PTT and two programmable buttons with limited function selection. I like having one of them dedicated to momentary squelch off and I prefer leaving the other one unassigned. While I was tempted to assign it as PTT for secondary channel, I rarely used that functionality on Baofeng and what I really missed was a key that does nothing except turning on the display backlight. If you leave it unassigned that is exactly what you get.

Top on Baofeng has power/volume knob and flashlight along with a handy lights showing which channel you are receiving signal from. Anytone has the same power/volume know and additionally brings another knob for rotary channel selection - that works beautifully. It is a bit strange decision to have only single receive LED (in two colors) when you can really simultaneously receive signal from two bands but I so rarely use this (or even see it in daylight) that I don’t really care. Although flashlight wasn’t really strong with Baofeng it did come in handy couple of times. No such thing on Anytone.

Specification-wise, advantage in power should go to Baofeng as it has stronger 8 W radio. However, Anytone pretty much held its own on both receive and transmit side. All repetitors I’ve used with one I could listen to with other and I had similar experience on transmit side. As my Baofeng was already damaged at the time, I cannot draw any finite conclusions but difference in performance is small if there is any.

Both support dual-band operation (136-174 MHz, 400-520 MHz) with Anytone having dual-transceiver instead of the more common dual-watch. Regardless, most of the time both worked equally good for me but for the Anytone allowing scanning and holding a conversation at the same time. It definitely offers a greater flexibility especially combined with MUCH faster scanning Anytone offers. Cherry on the top is possibility to scan CTCSS/DCS tones too - a function I haven’t noticed present on Baofeng. Although with Baofeng’s complicated menu system one can never know where everything is.

Speaking of the menu system, Anytone is a first Chinese radio I’ve used that actually has interface meant for humans. Options reachable directly from keypad are reasonably well selected and menu is good enough that you probably won’t need instructions even if you try to program all channels by hand. Setting up channel purely from handset is something that is impossible to do on Baofeng. Yes, option is technically there but it is really painful to use. Only Baofeng advantage here is allowing for seven characters in channel name instead of Anyone’s six.

Saving grace for Baofeng is Chirp. It is an open-source solution allowing for reasonably comfortable memory programming of multiple devices, including pretty much all Baofeng models. Anytone has its own solution that works badly to say the least. Yes, technically all settings are there but it is hard to say anything good about the interface not allowing for Copy/Paste. Anytone needs Chirp support and it needs it soon.

Both Anytone and Baofeng support FM broadcast band (65-108 MHz) but Anytone actually comes on top courtesy of allowing you to save channels in memory. How this is not supported on Baofeng is beyond me. Anytone additionally offers receive on AM aircraft band (118-136 MHz) strangely hidden behind the FM key. If you are next to a big airport, this one is a gem. Yes, I know you can listen to tower control online, but it is not the same.

Anytone goes even further with support for both shortwave (2.3-30 MHz) and longwave (520-1710 kHz) AM band. This is of limited use as not only antenna it comes with is completely unsuitable but these bands rarely have anything of interest. Yes, one might argue that Anytone’s definition of longwave actually also contains frequencies most commonly known as mediumwave where commercial AM stations live, but it will be a sad day when you actually go hunting for those.

This comparison might not be completely fair as Baofeng UV-82HP is only $60 while Anytone is about three time as much so I struggle to unconditionally recommend it. I find Anytone is the better radio by far but Baofeng will bring you 90% of the way. Best example is Anytone supporting proper narrow band FM. Yes, if other side is transmitting such signal you can often hear the difference as compared to Baofeng. But, guess what, most of the time everybody just uses 25 kHz FM anyhow.

On the other hand, Anytone is much more enjoyable to use as compared to Baofeng. I find it infinitely better when I am away from computer and I cannot get frequencies of repeaters in the area in advance. Not only you can quickly scan around to see which frequencies are in use but you can scan for CTCSS code they use and join the chat. And let’s not forget backlit keys and the awesome aircraft AM band.

PS: Do notice that author of this article is beginner ham at best. I find both devices are appropriate for such - these are not fancy radios nor you should expect wonders for this price.

Planned Obsolescence Is Not Black&white

I always feel like half a story is told when I hear about the planned obsolescence and how manufacturers are screwing us all. It always start with an example of device breaking apart right after warranty expires and ends with “it was better in the old times”. Is it really that black and white in the world of electronics?

If you compare “good old times” with now, you will see that electronic devices are dirt cheap. Big part of that is economy of scale and cheaper hardware chips. But it is also due to newer, smaller processes enabling manufacturers to fit more chips into the same wafer area which enables them to earn more. And yes, with all chip competition out there, more often than not these savings are passed to consumer.

But smaller process also impacts durability - chip with a foot-wide oxide layer (exaggerating a bit) is definitely going to have more durability than something done in 10 nm process. So yes, that newer, smaller, more power efficient, and undoubtedly better chip will fail sooner than one used in the phones of old. There is no escaping laws of physics.

Another complain I often hear is that nothing can be fixed these days - if something fails you must buy new. And that is bullshit too - almost everything can be fixed. Search on YouTube and you’ll find people playing with BGA level repairs all the times. Real issue is that, while everything can be fixed, it is often not worthy to do so - unless you do it yourself.

Think of the guy doing diagnostics for something as simple as dead capacitor. If he is lucky he can find it fast, if not he might spend hours troubleshooting board that costs $200 to repair. Even if final repair is just a $1, he needs to charge his time. Quite often math ends up being that cost of troubleshooting is simply too high compared to the cost of buying new. It is not that stuff cannot be repaired. It is just that’s not worth the time.

And that is without taking into account time one needs to open the damn device. If we use a phone as example, often you will find excessive amounts of glue without a screw in sight. But that is not (only) manufacturer’s problem. People want nice, curvy designs. People don’t care about the screws when they are buying the phone. I can bet you that 9 out of 10 people will just care that something looks beautiful and that it is cheap. Only time they will care about accessibility of inner hardware is when device fails.

What makes the new devices cheaper all the time is extensive use of plastic, avoiding screws to lower cost of assembly, and removing all parts you can live without. Any manufacturer that would build their devices purely for maintainability and durability would probably be bankrupt within a few years. Partially because its devices would be more expensive but partially just due to time needed to get design just right.

Do we have a problem with devices falling into the obsolescence faster and faster? I would say yes. But manufacturers are not to blame. It is us consumers voting with our wallets. As long as consumers want cheap and beautifully designed devices, repairability will suffer.

Pebble, the Second

Imagine this scenario: you are in the woods, lost, tired, all you need is to find the north. You look at your smartwatch, start compass application and you are saved.

I had lived through this scenario (minus the dramatics) and I’ve tried to use my Pebble. Year ago, with old firmware, this would work. I knew new Pebble Time firmware screwed things by requiring a phone connection in order to swap active application. What I didn’t know is that damn thing now also requires Internet access. Why? Why? WHY?

There are a couple of things I ask of my smartwatch. It has to be water resistant, it has to have battery last for a few days, it has to properly do notifications, and it has to work without phone. Pebble had it all for me until new firmware. Since they started with this Time interface my use cases got screwed up. I am not saying it is a bad interface as such - maybe there are crazies out there who like the fact now they can actually hold only one application in memory. It just became painful for me.

I know Pebble has a new Kickstarter with a bunch of new devices. And I was tempted for a while to actually back it up. However, looking at all of them, there is nothing for me there. I don’t need heart monitor as I am pretty sure my heart is working and that I’ll be the first person to notice when it stops. I don’t need the color screen - wife has one and the only difference is worst readability. And I definitely don’t need Core.

Pebble lately puts a lot of hope into tracking activities but then allows swapping applications only when smartphone (with Internet connection!) is available. It puts a lot into the battery life but then sucks the life out of it if bluetooth connection is not just right. I think their desire to cover all bases is making them produce more devices than they can realistically support. They have five different models already. Kickstarter brings this up to seven. All this brings firmware quality down…

I am not saying I won’t buy another Pebble, who knows, maybe the perfect firmware is out there. I am just saying I’ll wait for my Steel to die first. When that happens I will decide on what to buy next. And frankly, it doesn’t seem likely it will be another Pebble.

Go

After sticking with C# and its ugly step-mother Java for a while, I though it was a time to check out a new language. One that seemed interesting was Google’s Go, a simple garbage-collected, strongly-typed, and C-like language supporting Linux and Windows.

Go syntax itself is really friendly and suits me well. There are only a couple of statements around and you should know them from C, semicolon is optional at many places, and in-place variable initialization is a treat. Yes, x := 5 is not really superior to var x = 5; nor it saves you a lot of keystrokes. However, syntactic sugar is what makes or breaks a language in my opinion. And such lazy variable initialization is nice to have.

Cross-compilation is reasonably easy with just a few environment variables (GOARCH and GOOS) that need adjusting. As it is statically linked, you can count on having no additional dependencies whatsoever. One binary is all it takes. Yes, binary is a bit bigger even for the simplest of things but I’m perfectly fine with that if I can avoid .dll hell.

Speaking of compilation, it is annoying. Compiler is simply too aggressive with warnings. Great example is if you initialize variable and you don’t use it later. Damn compiler will complain and refuse to do its work. If you have unused import, the same thing. It will simply stop at any warning. One might say this is the correct behavior and that it will help you to write better code. That hypothetical guy should burn in hell next to guy who created this compiler.

Since proper debugging tools for this language are nonexistent, you are pretty much forced to use generous peppering of printf statements throughout the code together with liberal commenting out so that you can pinpoint the error. And guess what happens as you debug it? Damn compiler refuses to work just because I am no longer needing one variable I used for debugging or because I am importing package use of which is currently commented out.

And those are errors compiler correctly identifies and it could correct itself. Variable not used? Report me a warning because it might be me making a typo but compile the damn program so I can continue to debug. Same for extra package - if you are so smart to report it is unused, remove the damn thing yourself and compile. It is impossible to describe how annoying these warning are during writing and debugging of program. ANNOYING.

Syntax of Go is mostly pleasant with a couple of weird decisions most notable of which is to have variable type after the variable name, as in func x(dummy int). While designers do offer an explanation, to me frankly it seems as changing stuff just to be different. Yes, it might be more correct way of doing things but it goes against muscle memory of every developer on earth. Same goes for decision to use nil instead of null. Why?

Go is not object-oriented language and I am not really sure how I feel about it. A wonders can be done without full OO support, especially when it comes to small tools I was using it for. What I was missing were two features usually connected to OO languages.

First one is syntactic sugar of method calling syntax. I find myStr.TrimSpace() as superior compared to strings.TrimSpace(myStr). While they can both serve the same function, I find former much easier to both write and read. I sort-of expected Go to have something similar to C# extension methods where you essentially just use OO syntax for non-OO concept.

Second is method overloading. Yes, I know Go creators have excuse for this too. Who knows, they might even be technically correct. However, the need to have slightly different name for each method taking similar parameters is annoying. Have they allowed optional parameters maybe I would feel different about it but, as it is implemented now, I find this decision hurting the language.

Lastly among complaints is lack of globalization features throughout the language. It could be at least partially due to the lack of overloading but all globalization features feel as an afterthought and not as the part of language. Good luck localizing this.

As you might have guessed, I don’t find Go a particularly well designed language. I do like some of its features (especially the ease of cross-compiling) but general discomfort during development will keep it as tool of choice only when I want a single binary with minimal impact to the rest of system and not for much else.

Cananka, the Raspberry Pi HAT: Components

[This post is part three in the series.]

Usually behind component selection for any project there is a method in the madness. I will try to go through mine. :)

For the most visible part of board, we are going to need a nice CAN bus connector. I personally prefer Phoenix connectors for this purpose. As we are dealing with low voltages, I feel their MCV series is a great choice. It is a 3.81 mm pitch connector allowing for 8 A of current. Better yet, it is a two part connector so you can wire your plug in peace only connecting it to board once ready.

On the bottom we need to have a 40-pin female header. Final distance between our board and Raspberry, per specification, has to be 10-12 mm. However, that doesn’t mean your header has to be that high. Male header on Raspberry is already 2.5 mm. As long as our connector is between 7.5 and 9.5 mm, all is good.

First electronics component is easy - in order to satisfy HAT specification we need EEPROM for our settings. Here we pretty much take recommended circuit and roll with it. Maximum current CAT24C32 will take on write is 2 mA from 3.3 V rail.

Component selection is primarily driven by requirements and rarely we can see it as clear as here: As we need existing Linux driver to support our board, we are pretty much boxed into selecting MCP2515 as our CAN controller. Another obvious choice would be SJA1000 but that one is a few times more expensive. As Raspberry header pins are using 3.3V signal level, we will power it from 3.3 V rail in order to avoid level translator. Maximum of 10 mA will be used from 3.3 V rail.

Clock for MCP2515 can be up to 25 MHz but I’ve decided upon 16 MHz as this figure fits nicely with Raspberry’s divisor controlling SPI bus. It wouldn’t hurt to use higher clock-rate but 16 MHz is a value I use often in another project so I had component handy.

For CAN bus we also need transceiver and of course there is no single answer on which to select. For isolation we can go either with a dedicated isolator (e.g. Si8421 paired with MCP2561) or we can use one of rare isolated CAN bus transceivers.

As isolated transceiver already needs two power supplies, we can avoid level translator and keep each side on its own preferred level. Signal side will be powered on 3.3 V and CAN bus side will be on 5 V. One device that matches these requirements is ISO1050. Not exactly cheap but not too expensive considering it is all-in-one solution. Maximum current of 3 mA on 3.3 V side fits well within our restrictions. On its 5 V side we need 75 mA maximum from the isolated 5 V rail.

Typical application circuit for ISO1050 also mentions additional protective diodes and we shouldn’t forget those too. Searching for basic two-channel TVS diodes supporting 30V and above (in case we get to work with 24 V CAN bus) PESD1CAN comes as a first choice. And guess what NXP tells intended usage is? Yep, CAN bus protection.

There is a big chance we will need to terminate our CAN bus with 120 Ω resistor. For this purpose a place for two 1206 resistors is available. Combined this allows for about 1 W power dissipation, depending on the exact resistors used. Considering transceiver short-circuit current is 105 mA at 12 V, we are cutting it a bit close for the worst-case scenario. But, as such peak currents are not going to last for long, even at 24 V this should be sufficient.

My plan is to use nice Phoenix connectors and simply get through-hole resistor next to the wires. ISO 11898 even recommends such cable termination since that way you can disconnect node without impacting bus. What I definitely don’t want is header or DIP switch controlling this.

Speaking of which, in order to power up our 5 V goodness, we need isolated DC-to-DC power converter. Many of them come in 4-pin SIP interface and can be directly substituted for one another. I opted for ROE-0505S as it is cheap, small, uses standard pinout, and 200 mA it offers is more than sufficient for our needs. It is a bit finicky at low currents so we should put a LED to waste some of that (e.g. 15 mA). Taking into account its efficiency of 79%, we will use around 110 mA from Raspberry’s 5 V rail.

To power Raspberry Pi from CAN bus power, we get to use another DC-to-DC converter. Unfortunately Raspberry Pi is a hungry beast so we must get into bigger and more expensive choices. After taking literally every DC-to-DC converter capable of producing 5 V / 1.5 A from 12 V source available at Digikey and getting theirs pinouts, I’ve noticed essentially two groups with a few outliers. First group was of devices measuring 32 x 10 mm. These devices run around $25 and all share same pinout (e.g. JTF0824S05). Another group came in 25 x 25 mm size, sharing the same pinout, but unfortunately at a slightly more expensive $30 (e.g. JCM1512S05).

With board measuring only 65 x 56 mm, both would fit, but square one would be much easier to place due to camera slot so I’ve decided to go with that. While those are more expensive devices, for some reason they offer higher current output than their rectangular cousins so 2 A is the norm here. Fact all devices in this group use the same pinout means it will be easy to find replacement if original choice (S24SE05002NDFA in my case) becomes unavailable.

We also need a simple 2 A fuse on power-back circuit together with an ideal diode circuit as recommended by HAT specification. As with any DC-to-DC converter we have to keep minimum load in mind (usually around 10%) but Raspberry Pi is hungry device so we can ignore it this time. Even if we do not meet it, nothing bad will happen as only effect is that supply will go out of spec. As Raspberry Pi doesn’t use 5 V directly but goes over another DC-DC converter, we are safe even in sleep mode.

For those wondering why the heck we are accounting for each mA, answer lies mostly in Raspberry Pi header and 3.3 V rail. Maximum current we should pull is around 50 mA. Anything more and you might make for an unstable system unless you use a separate voltage regulator bringing beefier 5 V rail into play. On 5 V rail we are pretty much only limited by power supply used. If using normal 2 A supply, you should have round-about 500 mA available provided there are no hungry USB devices connected. If you kept with accounting, we have 15 mA usage from 3.3 V rail and 110 mA on 5 V. Well within the spec.

Onto the board.