Month: June 2015

I have really arthritic hands.  So, last night, I was thinking, “Winding a toroid, how hard can it be?”

Turns out it can be very hard.  My hands still ache 🙂  Anyway, here is the one I wound.

Those familiar with the EARCHI End-Fed Matchbox may recognize this — because that’s what it’s for.  A 9:1 UNUN that goes in a little box with some hardware, and you attach about 35′ of #18 insulated wire and a counterpoise to get an “emergency” antenna that does 40-6 (with a tuner) and handles 100W.  I bought one of these assembled in 2013 as a “get on the air” antenna and it worked pretty well when I strung it as a vertical from a Jackite kite pole.  If I’d known then what I know now, I would also have added a counterpoise, but there was no ground terminal on the one I bought that would have made that obvious.  Apparently they changed the design after I bought mine, because now it does call for a separate counterpoise ground terminal.

I had idly considered buying another one for my shack-in-a-box, but EARCHI no longer sells the assembled antennas.  So I hammed up and bought the parts to make my own.  They are, absent arthritis, pretty doggone easy to build.

I spent some time the other night with a hex editor and a fresh default copy of an .rdt file for the MD380, thinking, “How hard can this be to reverse engineer and build an actually decent and usable contact manager?”

Oh, honey.  It’s hard.  Because the record format is a mess.  (This, I hasten to add, is Moto’s fault — not Tytera’s.  It’s Moto’s file format, they’re just living with it.)

They have a whole bunch of settings — some of which have no relationship to others — overloaded bitwise into single bytes.  Now I don’t really have a problem with that, it’s a standard way to save space in a record format for yes/no checkboxes and multi-choice lists, but really, they should have arranged things better; it’s like they tried to cram everything they possibly could into a single byte, then ran out of room (or someone woke up and realized what a Charlie Foxtrot they’d made of the record structure, but by then it was too late if they wanted to preserve backward compatibility) and started using other bytes in a slightly-more organized fashion.

What really blew my mind, though, was how they set frequencies for channels.  I would have thought they might have used a floating-point, real number for that purpose; two bytes would easily suffice if they did.  But no, they use four bytes and they set them to contain the actual digits that you type into the frequency box.  For instance, if you are setting a frequency of 443.850 MHz, the file contains four bytes as follows: “00 50 38 44”.  That is a faux little-endian method of storing the number; reading it from the right-most to the left-most byte gives you the frequency, which is always stored by DMR2 in the format nnn.nnnnn .  This doesn’t really upset me much, because it isn’t that difficult to read those four bytes and convert them to eight characters of text in a text box.

But it shouldn’t be too hard to suss out the bit settings for the other data, and of course any text in the record (i.e. the channel name) is just plain old 2-byte Unicode.  It’s just a shame that Moto/ConnectSystems/Tytera haven’t felt the need to produce a truly usable piece of modern contact and channel management software to go with their space-age radios.

I’ve been working with the DMR2 programming software that shipped with the Tytera MD-380 and I have to say, as a programmer and interface designer myself, it really isn’t particularly intuitive or user friendly.

First, it opens a blank RDT called, imaginatively, “default1”.  It does not open the last file you opened and it doesn’t provide a list of recently-viewed files in the File menu.  That’s just annoying, not buzz-killing.

Second, rather than using a tabbed interface like so many modern Windows programs do, it opens a separate MDI window for each item you click on.  So you can end up with a buttload of windows open and not even realize it.  You can use the Window menu item to navigate between windows, but wouldn’t a tabbed interface make more sense?

Next, as seems usual and proper for most radio-oriented software, there is no integrated help file.  Since the manual for the radio is nearly unreadable to a native English speaker — well, I exaggerate, but the Chinglish factor is high — that is a significant omission.

Programming a contact is fairly simple once you understand all of the options you can set and which of them you need to leave the hell alone.  But, for instance, let’s look at what I had to do in order to add the Parrot channel to the Indy zone (for some reason it didn’t pre-exist in the CS700 codeplug I hacked for the MD-380).

First, I looked at one of the other Parrot channels that was already in place.  I created an Indy Parrot channel based on those settings, and programmed it with the information for the Floyd Knobs Parrot which was right above it at the end of the list.  I only had to change the repeater frequencies so they matched the W9AMT repeater in Indy.

I tried to find a way to move the new channel up the list so that it would be in the same part of the list with the rest of the Indy channels, but no dice on that.  No huhu, you set the channel number and assign it to a zone in another part of the program.

Yeah, that’s right.  You now have to assign the channel to the zone IN A COMPLETELY DIFFERENT WINDOW.  So you run up the list to Zone Information, and click on the Indy zone.  That brings up a selection window, and you run down the list, find the Indy Parrot you just made, highlight it, and click the “Add>>” button.  That adds the channel to the smaller list of channels that are specific to the Indy zone.

For some reason it didn’t penetrate my head that I had to take that second action.  I made the channel and updated the radio and “Indy Parrot” wasn’t in my Indy zone.  After some head-scratching, I realized my mistake, and took the second action to add it to the zone, and re-uploaded the codeplug.  Ah!  Now I have an Indy Parrot.

It seems to me that this ought to be part of the channel programming information, and I thought it was — because I did set the Scan List parameter in the channel screen to “DMR Indy”.  I know now that that is not the same as adding the channel to the Indy zone.

At the very least I would have thought that would be in the help file.  Oh, wait — no help file!  And frankly, the information on the web that “explains” how to program a DMR radio isn’t all that great.

These radios are just aching for someone like RT Systems to come along and write usable programmers for them.

I thought I was going to do that with the ConnectSystems CS7000, but CS is taking way too long to bring that radio to market.  So when State of the Art Communications in Russiaville got in a load of Tytera MD-380 DMR handhelds and put them on eBay for under $200 shipped, and with the programming cable to boot, I bit.  (That link looks like it’s good till about July 4, unless they sell them out before that.)

I think I ordered it Sunday and I got it today.

I was a bit irked however that the Hoosier DMR group doesn’t actually offer a codeplug for the MD-380.  In fact they seem to be more interested in throwing DMR repeaters up all over the state than in keeping their website up to date and useful.  It is not simple to program one of these handhelds by hand, and you probably wouldn’t want to, anyway, since the codeplug I ended up hacking (originally for the CS700) contains over 700 digital contacts.

So I did manage to hack the codeplug with my copy of UltraEdit, no huhu, and used the DMR2 software that I downloaded from TYT to load it in.

My only irk at the moment is that the battery is taking God’s own time to charge.  It was showing a full battery indicator when I powered it up the first time, but I thought I’d stick it in the charger and top it off as the manual recommends.  I did see a review somewhere that carped about this radio taking “hours” to charge…I don’t think they were lying.

And the manual…is written in liberal Chinglish.  It is not unreadable but it is not something I’d take to bed with me, because it would irritate me too much.  And interestingly enough there is no photo anywhere in the book that tells you what the different icons on the (very nice) color LCD screen are.  I guess you just have to guess.  This radio could benefit from someone doing a significant edit on it like the one that was done for the Baofeng UV-5R.

All that said, the sound is pretty good for digital.  Nice and crisp and punches right out there except when someone gets too close to the end of the repeater’s rope, and then it just cuts off.  The cool thing was powering it up and hitting the SCAN button and immediately being rewarded by hearing a QSO between a guy in Ontario and another guy in Florida on the North America talk group.

The radio has a nice shape and size — some reviewer likened it to a brick, both in shape and in heft — and appears quite well made, although I imagine the plastic spring belt clip will not last long.  It has a typical stock rubber duck, of course, but it’s a 70cm radio so the shortness probably isn’t all that critical.  It does have a standard SMA connector, though, so I might try the Diamond SRH77CA from my Yaesu VX-8G on it just for kicks.

And because I am a nice guy, here is the codeplug I’m using, with my call and radio ID edited out of course, so you’ll need to load this into the software to change it.  It’s a .ZIP file because WordPress objected to the bare .RDT file.

md380hoosierdmr06-01-15-generic-rdt