Here is what I’ve found so far:

1) Audio quality is excellent both inbound and outbound.

2) Does not do Brandmeister “officially” – more on that later.

3) You can connect to both DSTAR and DMR at the same time however it will not play both at the same time – whichever one keys up first you’ll hear.

4) On busy DSTAR reflectors the main display will crash after 10-15 minutes and the entire thing will be in an unusable state.

5) On busy DMR reflectors when not connected to a DSTAR reflector as well, eventually the main screen will stop displaying call signs and information. The green RX LED will also go solid. When it’s in this state DMR still works, you can still transmit/receive however after about 10-15 hours in this state it will eventually stop working entirely.

6) The buttons on the handmic do nothing, just the PTT switch.

7) The rotary encoder is jittery – spin the knob “too fast”, i.e. at any rate other than “dog slow” and it’s either non-responsive or the counter starts going in the opposite direction.

8) The speaker in the box itself is only “OK”. You’re going to want to use to an external speaker. I use an old Kenwood comms speaker I had laying around.

9) On the web page interface the “unlink” option in the DCS menu doesn’t work. The only way to unlink from a DMR reflector is to link to a different reflector. There is no “4000” option to hard unlink entirely.

10) No way to hard-reset the box back to factory defaults that I can find if you screw up entering your callsign and DMR ID so make sure you NEVER, EVER screw up the initial setup web page process.

Now for some internal discovery.
This box runs both an SSH server as well as a mini-httpd webserver.
The web server runs the webpages that allow you to connect to different reflectors.

Over the weekend I was able to guess the root SSH password and login to the box. What I found is:
SPECS: 128MB of RAM and 4GB of internal flash storage.
I haven’t opened the box to see if the flash is chip-based or card-based.
There is also an internal 2-port USB hub. One USB port for the DV4mini and the other obvious port on the back for a future wifi USB adapter I guess.
CPU is an ARM926EJ-S rev. 5 (ARMv5TEJ), all info taken from DMESG.

1) DV_SERIAL. That’s right. Our old friend dv_serial makes an appearance!
When you plug in a DV4mini and power up the box, after the main process “sees” the DV4mini is plugged in it launches dv_serial and you control it using software on the desktop. There’s no way to control it from the device itself neither from the front panel nor the built-in webserver that I can find. Same thing as if you had it plugged into a Raspberry Pi. DV_SERIAL does NOT control the rest of the box, just the DV4mini if you have it plugged in. This is the same dv_serial program that the Linux DV4mini software uses on the Raspberry Pi.

2) OLED – oled is the main process that controls the entire box, not just what is displayed on the screen. Upon power-on after the Debian Linux OS has booted up the oled program is launched and it launches two other additional programs – DCS and DMR. But the OLED program has a bit of a problem – it crashes with a segmentation fault after 10-15 of listening to a busy DSTAR reflector because it seems to not be able to handle corrupted DSTAR packets very well. The OLED program also doesn’t handle the display very well leading to corrupted characters on-screen after a while when connected to a DSTAR reflector.

3) DMR – DMR is the program that handles DMR reflectors. It’s rock-solid except for one tiny issue – upon every transmission it receives it spawns local UDP ports that it never closes. Over time on a busy DMR reflector it will eventually spawn hundreds and hundreds (thousands?) of open UDP ports that never close and eventually ties up all the RAM causing the entire box to be non-responsive and stop working forcing you to power-cycle the box. On boot up it spawns 3 DMR processes.

4) DCS – DCS is the program it uses to connect to DSTAR reflectors. There seems to be conflict with the DCS program and the OLED program that initially calls it since on busy reflectors the DCS program causes the OLED program/process to crash out entirely leaving the control panel and display in an unresponsive state. Unlike the DMR process, the DCS process does not spawn a lot of UPD ports. Upon bootup 6 DCS processes are spawned and it keeps to that number over time.

5) DV4AMBE_1 and DV4AMBE_2. These two programs control the audio decoding/encoding. As you can see, there are two of them indicating there really are two AMBE chips in this thing. That’s actually pretty cool.

5) LINK – Link is the program called by the user interface webpages that connects both DMR and DCS reflectors. you basically call “/media/data/system/link LG4369” and it will connect the DMR program to reflector 4369. “/media/data/system/link REF030C” will connect DCS to the famous reflector 30 Charlie. On the DMR side the link program is hard-coded to only be able to use 4-digits. More on that issue later.

6) USER – user is the program the initial setup webpage uses to populate the config.cfg file located in /media/data/system with your callsign and DMR ID. If you screwed up this setting in the beginning configuration page there’s no way to edit this short of SSH’ing into the box and editing it using nano. Possibly by browsing directly to the config web page as well but I haven’t tried that yet.

7) config.cfg – this file is located in /media/data/system and contains your callsign and DMR ID. It also contains the DMR_MASTER configuration, i.e. this is where it’s setup to connect to a particular DMR_MASTER server located in Florida. It is possible to change this to point to a Brandmeister master server and I currently have mine pointing to the BM Dev server where it’s working fine…well, as fine as the DMR and OLED and link programs allow.

I found a slew of leftover debugging and testing web files and other oddities while looking around in the box indicating the developer did not do proper cleanup prior to releasing the software.

Also, the link program itself is hard-coded to only use 4-digits meaning that after connecting it to a Brandmeister master server you can’t go to a 5-digit talkgroup – at least as far as I’ve been able to find. Decompiling the link program itself didn’t give me any clues either.

I find it very, very odd that they made the OLED program the main program that controls everything including the display. I feel the display controls should have been split out into a separate program entirely.

There is also no watchdog process in place to monitor the state of the running DMR, DCS, and OLED processes and re-start them if they crash. Once they crash – and the OLED process crashes a lot – you have to reboot/power-cycle the device to get it working again.

There is no real internal logging done on this device at all that I can see.

There are a few main things that really bug me about this box:

1) Every few minutes the device pings Google for one ping – and one ping only. This is probably a way to do some sort of poor man’s network connectivity test. But if your DNS servers ever go down for any reason, not sure what will happen when it tries this single ping to Google.

2) Upon bootup (really upon startup of the OLED main program) it connects to and pulls down and saves the list of Brandmeister master servers. It also contains a list of Brandmeister reflectors/talkgroups. It does not use these in any way whatsoever during operation so not sure why it does this unless it’s leftover code from the Linux version DV4mini control program being used in the OLED program. Also finding traces of DVRPTR-NET all over the place including the hostname itself.

3) Compiler tools are already installed on the device to include git. I was able to successfully git clone and compile the MMDVMHost software even if it was very slow to compile.

4) If something happens to the Linux OS inside the box there is no way for a user to reflash the OS to it that I can find. I’m sure there’s some sort of undocumented process to do so but we’re not being told what that process is.

My bottom-line review of this device is that while the hardware itself has potential, the software is very poorly developed and very buggy. From my limited research on the matter it seems code that was on past hardware DG1HT has worked on has been repurposed for this box as well. That would be fine if not for the fact that the code is buggy and prone to memory leaks (DMR UDP ports) and seg faults (OLED/DCS not handling corrupted DSTAR data properly). Again, these issues are all software-based and fixable by the developer.

Until they fix these issues I would advise against anyone buying a DV4home at this time.