Hose Line — If your browser fails to produce audio, try another browser. My situation? Chrome fails, but Opera works on Win7 and DuckDuckGo works on Android. It makes no sense.
— If no browser produces audio it is very likely that the Hose Line server software has failed. The only solution? Check back in the days following. I have never seen a webpage announcement one way or the other.
— Some links below to lesser known talkgroups are simply to see if there is activity, and may not remain here. So many unused talkgroups, yet more are added each month. Ridiculous. Sigh…
Dealers — A select list of dealers, based upon conversations with persons whose opinions I and friends trust, selling DMR radios. The list is not comprehensive. Links are not endorsements. Buyer beware. Your mileage may vary.
Codeplugs; Sample… — Codeplugs are enigmas. Whereas it is best to learn to build your own codeplug, looking at samples can help. These repositories may be helpful. Third-party codeplug editors (below) can convert file formats and make global changes. — If using a sample codeplug, you may have to change the hotspot simplex frequency to conform to your area's bandplan, cf. USA & Canadian Frequency Coordinators.
Codeplug Editors — FYI. I haven't evaluated or thoroughly tested all editors. See my notes below. Back up your codeplug file(s) before using an editor. I like, use and support N0GSG's software; recommended.
The MD-UV380 is a mid-2018 dual-band variant of the popular MD-380. Web searches do not yield much information about the radio. In my opinion, the manual could be improved. The following items are notes and observations made since purchasing the radio in July 2018. My radio firmware version is 16.006 and the CPS software is version 1.03. I haven't perceived a need to upgrade either, and I don't recommend upgrading either the firmware or software unless there is a need. At introduction the radio cost ~$140; in late–2019 the price has dropped to ~$80.
The charger is not a rapid-charging unit. It takes 6-8 hours to charge a dead battery. I bought a second battery at the outset.
When unboxing your new radio and loading the TYT CPS (Customer Programming Software) onto your computer, the very first thing to do is READ the radio, and save the initial file elsewhere as a 'do not touch' safety valve backup just in case. I name files in the the format of 'uv380-yyyymmddhhmm.rdt'—facilitates sequential file sorting—so I can revert to previous versions.
An MD380 codeplug will not directly load into a MD-UV380. Let's leave it at that. If you seek a MD-380 codeplug (as a sample, starter or to study) in lieu of building your own, in my opinion the easiest solution is to use the N0GSG DMR Contact Manager to read in an MD380 codeplug and write it out in the UV380 format. (If you are a new user of the N0GSG software, I strongly recommend first reading the PDF user manual.)
As an aside, there are a few "tools" software packages for tweaking the MD-380 firmware. Note these will not work on the MD-UV380. There are no MD-UV380 "tools" packages, nor do I expect there ever will be.
The dual VFOs are not ganged. When one has UHF and VHF repeaters and simplex frequencies in the same zone list, you can listen to traffic on both receivers simultaneously. VFO A audio has priority over VFO B if both receivers are active.
If scanning a zone list with analog FM frequencies and the scan stops, the radio will continue to check for other activity approximately every 3 seconds. A momentary "blip" interrupts the audio.
The MD-UV380 has 3—H, M, L—power levels; page 51 of the manual states only there are only two. I like to have a quick button programmed to change same. To conserve the battery, I program repeaters at M and step to H if needed. Program one of the buttons on the left side of the radio.
If implementing the Pi-Star Remote commands—these should be set up as private, not public, calls—on your radio for use with your hotspot, KE0FHS has a good explanation on how to set up the reboot, shutdown and other commands. For the reboot and shutdown commands, there is one more step to be done. The reboot and shutdown command fails unless you uncheck the "Private Call Confirmed" checkbox on the codeplug's "reboot" and "shutdown" Channel Information sheets. Otherwise, on the hotspot, the DMR logo just shows up on the OLED screen over the rolling MMDVM logo.
For each zone list with hotspot talkgroups (Brandmeister, in my case), VFO B entries are (1) Unlink 4000, (2) Remote's Reboot—enables waking up a hotspot that dropped a WiFi connection—and (3) Remote's Shutdown. Shutdown can be helpful. It lets me quickly turn off the car's hotspot as I pull in the driveway so I am not additionally transmitting through the house's hotspot; I don't have to reach to pull the car's 12vdc plug.
For me, the MD-UV380 has been a bulletproof radio. (Your mileage may vary.) In my opinion, the dual-band MD-UV380 is akin to the classic single-bandMD-380. Compared to the expensive and complicated (more settings to sort through) Anytone AT-D878UV radio, the MD-UV380 is a "plain Jane" radio with a simpler, less complicated, screen and easier CPS programming. For me, simpler is better. Think about it. In the end, it is just a conversation. I would buy another MD-UV380 without hesitation.
For what it is worth, I use a hotspot virtually all the time. I don't set static talkgroups or use the digital monitor mode (promiscuous). The latter seems obtuse to me. Look for the CPS' "group call match" to explore promiscuous for yourself.
Some persons complain about the digital audio quality. The audio quality is fine. Digital audio is communications quality, not high fidelity, and sounds different than analog FM. Some persons may need to adjust the radio's microphone gain, using the CPS, but that's no surprise.
A few notes on the MD-UV380 codeplug manipulation…
Early first impressions is the DMR CPS Programmer by DL5MCC is more difficult to use. There seems to be more dependency on CSV files. The advantage is more or different DMR radios are supported. That said, I haven't yet attempted to delete records using the DL5MCC program while sorting out the TYT software (v1.03).problems. Editcp by WJ2O does not seem to work with the UV380. The first attempt produced a string of frequency 'out of range' errors. After checking the test file with both the TYT and N0GSG software, Editcp won't recognize the 'rdt' file format.
28 Jan 2020: In my opinion, there is a deletion logic error in the TYT CPS software when attempting to remove Brandmeister talkgroups. (I would expect the same logic problem may occur in other editors.) Attempts to delete a talkgroup digital contact and a channel—removal of the zone list entry > the channel entry > the contact—unhooks the relation between digital contacts and channels. I have to correct the channel records, adjusting the contact name, to fix the misalignment. In my opinion it is easier to make the corrections with the N0GSG DMR Contact Manager.
After another foray into deleting unwanted Brandmeister groups from the MD-UV380 codeplug with experimentation—using numerous interim backups—and studying Figure 15 in the N0GSG documentation, an answer appears to be working. The channels file is central. Using the N0GSG DMR Contact Manager software, I first deleted the channels sheet and second the digital contacts entry. I did this doing one Brandmeister talkgroup at a time. The relationships on the remaining channel sheets were unchanged. The entries automatically disappeared from the zone and scan lists.
Note the following.
These steps work on talkgroup entries for hotspot use; I haven't experimented with repeater entries.
These steps work on the MD-UV380 codeplug. My guess this works on other TYT radio models. It may work with other radios using the rdt file format.
Regardless of your radio, I strongly recommend testing and making liberal use of interim backup files as your deletions editing proceeds. Your mileage may vary.
I ran into a problem sharing a codeplug as a Gmail attachment. The recipient of the file reported it was corrupted. The solution was to upload the codeplug file to my Dropbox account and then email a link to share it. Other cloud services—Box, OneDrive et al—should work too.
… from among the following possibilities. See what you think.
0000FF — Blue
0000CD — Blue 3
00008B — Blue 4
B22222 — Firebrick
8B0000 — Red 4
228B22 — Forest Green
36648B — Steel Blue 4
8B4726 — Sienna 4
282828 — Sgiverydarkgrey
Remember to "Apply Changes" to see results. (To return one or a few colors to a default value see this list of default colors.) At the page bottom there is a safety "reset values" to all default colors should your total schema wanders off the rails. Do make a record of your CSS changes as the Pi-Star Configuration > Backup/Restore > Download Configuration ZIP file does not include the color values.
After upgrading and updating Pi-Star on one hotspot's SD card, I made a second SD card for a second hotspot. The first hotspot worked. The second failed to work. It made no sense; I assumed the SD card was the problem. The solution? (Tip of the hat to WB3EHB for suggesting a solution.) Using two Windows SD utilities:
Use the Disk Imager program to read the first good SD card. Name the file, including the drive letter (and path if desired) and adding the "img" extension. Note the location of the (~15gb) file written to the fixed disk. When done, remove the good SD card and put it back in the hotspot.
Use the SD… Formatter program, format the second SD card.
Use the Disk Imager program to write the file, created in step 1, to the SD card.
Remove the completed SD card and put it in the second hotspot. Power on the second hotspot and open the Dashboard…
Adjust, if necessary, the BER values with the Configuration > Expert > MMDVMHost > Modem > RXOffset/TXOffset menus.
Make a Pi-Star Configuration > Backup/Restore > Download Configuration backup. Save it with a different name to differentiate the files.
A fringe benefit of this exercise? Making a full SD card image includes all settings and configurations, including those items not saved in a Configuration ZIP file. If you make additional cards for one hotspot, skip step 4.
Updating Pi-Star may involve two steps. Moving from version 4.0 to version 4.1 requires downloading a new image file. With 4.1 installed, new release candidate versions—it is always good to run the Update first and Upgrade second—are installed with the Dashboard commands…
Configuration > Expert > Update
Configuration > Expert > Upgrade
The date at the upper right of the Dashboard changes only when there is a significant Pi-Star Update (per KEOFHS: "changes to the Pi-Star dashboard app"). The version number changes whenever there is a Pi-Star Upgrade (per KEOFHS: "operating system-level changes to the system and packages required to support new features").
Pi-Star's scrolling logo, by default, is turned off as of version 4.1.0 rc7 / 20191220. The calls et al continue to be displayed when the talkgroup is active. In the Configuration>Expert>MMDVM Host>OLED section, the default values are now "Type | 3" and the remaining fields are zeros (0's). To turn the scrolling logo back on, change "LogoScreensaver" from 0 to 1. Thanks to Rex, WD0AJG, for sorting out these changes and alerting us to same in the Colorado HD Telegram group.
Lose your connection to a Brandmeister master server? Too many quick keyups may be the cause. In response to a question in the Telegram Brandmeister General Support (English) forum, W7XM posted the official explanation.
"More than 4 keyups, with 2 seconds or less transmission within 1 Minute is banned for 1 hour on the master the hotspot is connected to."
W7XM continues "…so to clarify it only triggers when using devices (jotspots) like OpenSpot (1,2,3), MMDVM's (simplex mode), DVMega, etc. So some repeaters are using other software and then linking back to Brandmeister. So in that case it sees it as a hotspot and the rules apply."
Pi-Star's SSH Access provides Linux access to controlling the device. The APT (Advanced Package Tool) is a command-line utility to interact with the packaging system. Read Using APT Commands in Linux for the how-to.
13 Jan 2020: Interesting situation late night with a simplex hotspot. Talking to friends, at times communications was lost for a few minutes. i looked at the speed, ping and traceroute to see if we could isolate the cause. I opted to use the Pi-Star Configuration to change USA Brandmeister servers from 3103 to 3101.
The simplex RPi0 Jumbo hotspot was running Pi-Star v4.1.0 rc7 with rng-tools.
My default Brandmeister settings
Hotspot Security: password installed, active since its implementation.
Selfcare settings: in place, no static groups set, and hotspot security password entered.
No Brandmeister static groups have ever been set since I got onto DMR.
The hotspot is on 24/7 excepting power outages and preparing a new card.
When I mentioned the wierdness in the Telegram group, KE0FHS wrote "I think a lot of what you experienced and described is probably one-off… I think the most important point lost in these details is that that SelfCare settings are saved per server." That was a nuance I wasn't aware of or didn't remember.
The server change of 3103 to 3101 cleared the Pi-Star's modem setting and wiped out the hotspot security password. I reselected the GPIO modem, applied the change, reentered the security password and applied the change to reconnect to friends in our local talkgroup (tg).
In the morning I found the Pi-Star Dashboard loaded with tg91 and Thai tg52002 traffic. (In 2019 I probably have turned to tg91 ~6 times, and no Thai tg has ever been installed in my codeplug.) I turned on the radio; still on my home talkgroup, and it was receiving traffic (the green light was mostly on) but no audio.
Changing to the zone with the busy tg91, I did a call to tg4000. I went to BM Selfcare and hotspot settings. The static talkgroups section showed radio buttons for my home tg, tg91 and tg52002 but no radio button was selected. I dropped all dynamic groups.
I rejoined (key-up) my home tg, and and soon saw tg91 reappear on the Dashboard. A repeat of the previous foray into Brandmeister Selfcare cleared it up.
I have no idea what happened. AC2F wrote "Different master? Each one saves your own set of talkgroups. There are odd things with OS when it switches to 'backup master' you are getting different settings (which you've probably set a month ago on backup master)." I thought my 3103 and 3101 Selfcare settings were alike, but who knows? I know I deliberately never set any static groups. N1AJW wrote "A while back, a year or two, everyone had tg91 as static suddlenly. Same thing, they never put it on." W7XM jokingly says "solar flares…" I tend to believe W7XM's explanation. 🙂
Moral of the story: keep detailed notes on your Pi-Star software and Brandmeister website settings. If you use different servers, keep separate Selfcare notes for each server. And check through your Pi-Star's Configuration for unexpected changes before going back to the Dashboard.