Category Archive: DMR

Again with MMDVM

Apparently there is an incompatibility between “Pi-Star:3.4.16 / Dashboard: 20180806” and the 1.3.7 MMDVM firmware that prevents things from working properly (the Pi-Star just sits there scrolling “IDLE”, nothing shows up in the activity display, and the Trx field under Radio Info is blank instead of at least saying “Listening”.  (Indeed I think my Pi-Star wasn’t receiving any activity at all.)  So I upgraded to the 1.4.6 firmware and it appears to be listening again, but other than my own test with the Parrot earlier this morning, nothing has shown up.

Weird.  Would be nice if there was some coordination where you could actually find out about these things before Pi-Star simply auto-upgrades you into oblivion.

Hmm, OK, seems to be working now, I just heard someone on 3118.

Cautionary MMDVM tale

I’ve been fiddling around with my original JumboSPOT, trying to get it to CW ID, and I did finally figure that out; you have to go into the Expert configurators, choose MMDVMHOST, scroll down to the section called “CW ID”, and change the “Enabled” parameter to 1, save then reboot.  But it did not seem to be working with this particular JumboSPOT (although it was working fine with the other one, which is intended as a mobile hotspot).

So I thought, hmm, the firmware is kinda old (it was “ZUMSpot 1.0.2”) and maybe it just needed an upgrade.

After searching all over hell’s half acre for the instructions to do that, I found somewhere (and I can’t find the link now) a video that explained how to pull down the latest firmware and install it.  Effectively, you log into the SSH terminal, set the session to RW (with “rpi-rw”), and then clone the git repository for MMDVMHost with “git clone https://github.com/juribeparada/MMDVM_HS”.

At that point, you do

cd MMDVM_HS/scripts

and you can “ls” to find out what you’ve got in that directory:

pi-star@pi-star(rw):scripts$ ls
build_fw.sh                install_fw_hsdualhat.sh    install_fw_rpi.sh
install_buildtools.sh      install_fw_hshat-12mhz.sh  install_fw_usb.sh
install_fw_custom.sh       install_fw_hshat.sh        mmdvm_hs_hat_fw.bin
install_fw_duplex_gpio.sh  install_fw_librekit.sh     STM32F10X_Lib
install_fw_duplex.sh       install_fw_nanodv.sh       zumspot_rpi_fw.bin
install_fw_gen_gpio.sh     install_fw_nanohs.sh
pi-star@pi-star(ro):scripts$

Points to make:

  • You MUST ensure that the GPIO20 and GPIO21 pins can connect between the JumboSPOT and the Pi (in this case, a Pi Zero W).  Otherwise you won’t be able to update the firmware no matter what you do.  My first JumboSPOT/Pi Zero W unit did not have this connection, so I had to take the thing apart and add a pin socket to the JumboSPOT and a pin header to the Pi Zero W in this location.  The second JumboSPOT I bought already had this covered, and when I put the second Pi Zero W together I installed a full-length GPIO header, so again, covered.
  • You MUST ensure that you choose the right firmware installer.  Clue:  It’s NOT “install_fw_rpi.sh”.  You can flash it, and it boots, but it never actually initializes the listeners (although Pi-Star it claims it does).  I figured out by checking the working unit — that was running “HS_Hat:1.3.3” — that it had to be the “install_fw_hshat.sh” installer.  Once I reflashed the unit with the correct firmware, it worked fine.

I’ve said it before and I’m going to say it again:  Pi-Star needs formal documentation to explain all of this shit.  I cannot understand how such a complex operating system can be released for use by thousands of hams and the only way to figure out what some of the arcane settings are, and how to get the silly thing running in the first place, aren’t clearly documented in a published manual (which for all of me could be a wiki).  I know that hams don’t read manuals, but I’m in the software business myself, and if you don’t have published manuals, nobody takes you seriously, even if they never read the damn things.

I also understand that Pi-Star is free.  That’s no excuse, or it’s the excuse of a lazy developer who doesn’t document anything except in release notes.  The documentation could be crowd-sourced using a wiki, for crying out loud.

Videos take too long to watch when you read 500 WPM.  Give me text any time.

DMR anywhere redux

Man, these little Chinese knockoff ZumSPOTs are pretty robust:

pi-star@pi-star(rw):~$ uptime
15:34:35 up 13 days, 5:33, 1 user, load average: 1.23, 1.16, 0.68

It’s been running all that time on the battery box, although the battery box has been on the charger since last weekend.  It ran the batteries down from 12.6 volts to 12.0 volts in five days.  (It very quickly took the batteries from 12.8 volts in that photo to 12.6 volts.  As I noted elsewhere online, these batteries aren’t spring chickens.)

It is a bit annoying that I had to go into expert mode and open the SSH window to issue an ‘uptime’ command, though.  That ought to be on the dashboard, and unless I’ve somehow missed it, I don’t see it there.  (I mean, I see the load averages, but I don’t see the “up 13 days, 5:33” part.)  Ah well.

Much as I hate to buy another Chinese knockoff, I’m seriously considering it, since the “official” ZumSPOT boards are still not available.  I see that they’re trying to add NXDN capability now.  Hopefully at some point they’ll poke it with a sharp object and declare it finished, but meanwhile, everybody and his aged grandmother in Shenzen is selling JumboSpots dated 11/17/2017 for $42 and free shipping, I have a spare RPi Zero W and an OLED screen sitting here, and could put a second one together as soon as I have the JumboSpot in my hands…et voila, I have one to mount permanently in the car.

This is, FWIW, the same reason I gave up on Connect Systems’ vaporware CS7000 handheld (still in R&D!) and bought a Tytera MD-380.  You can beat your product to death and keep adding features and swatting bugs and tweaking it till hell won’t have it, then finally get the product out there and find others have moved on.  The Chinese are selling ZumSPOTs right now for half the price the developers say they’ll be selling them for through HRO, sometime in the sweet by and by.

Stick a fork in it, gentlemen.  It’s done.  And your market is drying up fast.  You didn’t protect your IP well enough and the Chinese are eating your lunch in the marketplace.

DMR anywhere

100% portable JumboSpot.  Possibly a bit over-batteried…

The cake, by the way, is a lie.

The firmware upgrade instructions for the MD-9600 say (in Chinglish):

“Press P1+ Alarm key(red key) to connect the power of  MD-9600, ( NOT JUST TURN ON THE RADIO!!!!!!)display blinks and open upgraded software”

This seems to translate to most American English speakers that one should press and hold P1 + Alarm and then hit the power button.

Nope.  That gets you exactly nowhere.  And I can see how they tried to explain it (“connect the power”) and why an American English speaker would misunderstand it.

The actual sequence goes like this (and it’s documented here and there on the web; I can’t remember now where I found it):

1) Turn the MD-9600 on.

2) Turn off the power supply connected to the MD-9600.  (Do not turn off the MD-9600 first!)

3) NOW press P1 + Alarm key (red key) and hold them in

4) Turn on the power supply connected to the MD-9600.

 Blank screen will blink on and off, you are now in Firmware Upgrade Mode.

They also get the concepts of “upload” and “download” backward, in my book.  The button that says “Download Update File” really ought to say “Write Update File to Radio” or something like that.  But eventually you get the idea.

Exit question:  Would it kill Tytera/TYT to hire an English-As-First-Language speaker to at least edit their documentation?

MD-9600 working fine

The TYT MD-9600 is up and running with the latest Hoosier DMR code plug (I used the one for the MD-2017 dual band handheld; the code plugs are interchangeable).  I’ve just got it sitting on my desk in the office, hooked up to my old 23W power supply, and connected to a Slim Jim J-pole that’s just hanging in the window.  So not a fabulous receiving setup, but I did get a really good signal back from the Parrot when I tested it earlier. I haven’t been able to raise the W9AMT VHF DMR repeater yet, but I think I need to use 1) a better antenna that’s 2) mounted up a little higher to get line of sight on that repeater. That’s been a constant problem from here with the hand-held transceiver, and generally having trouble reaching both the UHF and VHF DMR repeaters here is why I invested in the MD-9600. (Cue Tim Allen shouting, “MORE POWER!”)

I like this radio.  It seems like a robust unit, the mic is better than the one that came with my Tytera TH-9800, and if I had a complaint about the radio in and of itself, it would be that the radio doesn’t have a detachable control head.  Which is OK, because I’m going to put it in my go-box anyway, but it would be nice to see TYT/Tytera come out with one of these in the same case as the analog TH-9800.  Then I’d consider putting one in the Escape.  Given that I’m sure this radio has the same guts in it that they use for more expensive commercial DMR radios, I doubt that will happen.  But a ham can dream.

Which brings me back to my major bitch about this radio, hinted at in the previous post.  If you’re going to put this much thought and care into building a DMR radio, why in hell would you ship it with a cheap-ass USB programming cable that was probably bought from the cheapest cable maker in Shenzhen, and which broke before it was even used the first time?  Just because the thing said “TYT” on it isn’t good enough.  Just ship a decent generic USB cable and be done with it.

Otherwise, I have no complaints; I got the radio from Grapevine, down in Texas, and I couldn’t be happier about the service; Jason kept everyone advised about the status of their preorders, and he was even shipping radios out while Harvey was wreaking chaos down in the southern half of the state.  It’s not his fault that the cable that shipped with the radio was sub-standard, and I didn’t even bother him with it once I realized I could use a generic cable.  I look forward to buying more DMR stuff from Jason in the future.

With any luck, I’ll be able to get on the roof this weekend and swap out my 6M ground pole with the dual-band J-pole I’ve had sitting on the window sill in the shack for the last four years.  I’m not doing any 6M FM right now and I’d really like to string up a dipole for that band anyway, so it’s time to make that swap.

Well, I’ll be durned.

I purchased a TYT MD-9600 DMR radio a little while back, and when trying to program it, kind of soft-bricked it because the programming cable that came with it was a piece of crap and kept dropping the connection to the computer.  I thought I had the cable working at one point, and tried sending the code plug to the radio, but it failed in mid-send and the radio just sat there saying “UNPROGRAMMED”.

So I sat on it for a while because I didn’t really have time to fiddle with it.

Then I ran into John Miklor’s review of the radio today, and it caught my eye that the programming cable…

…is just a standard, straight-through USB to mini-USB.

Well, alrighty then.  Grabbed a spare USB cable with a mini-USB end, plugged it in, and voila, I could program the radio no problem at all.

Now I just need to grab the latest Hoosier DMR code plug and throw away that flimsy piece of crap programming cable that came with the radio.