Get active on 900 MHz (DMR/P25) for about $35

[Mars]

Are you one of the weirdos who has a 900 MHz XTS2500 or XTL2500/5000 (franken-converted) or XPR5580/XPR7580 sitting around, not being used? You bought it "just because" and had intended to use it "some day", but found most of the smelly hams in your area are unmotivated or unwilling to be progressive and move forward and reciprocate with you on any projects? OK, it's just me.

NOTE BEFORE READING FURTHER: The XPR5580e and XPR7580e do not permit out-of-band operation. Firmware lockdown. Ths lockdown is limited to the "e" models only.

I have been active on 900 MHz DMR and P25 for the last couple of weeks. I gave my bastard radios some new life, with a $35 duplex MMDVM "hat" board which attaches to a Raspberry Pi. I had my doubts due to the price point, but it works and is stable. Power output is as-advertised (10 mW) on VHF and UHF. I have found 900 MHz to be about 1mW, but that is all you will need. I'm 35ft away and my RX RSSI (on 7580) is around -77 dBm on average.

First, here's where I got it: https://www.aliexpress.com/item/4000615367339.html

I'm using it with a Raspberry Pi 4B 8GB. TOTAL overkill on the Pi, but it's what I had available.

What sets this board apart from other hammy contraptions is the DUPLEX capability. This means you can run it as a repeater (separate RX and TX frequencies and antenna ports). The advantage of this:

- Dual timeslots on DMR
- The ability to control the hotspot (via RF) and send "4000" commands duplex (drops dynamic talkgroups)

To get operational, here's what you'll need to do:

- Order the board (splurge the extra $2 or $3 and get the OLED display version)
- Get a Pi or repurpose an existing one. I recommend CanaKit as a vendor for North American hams.
- Find a generic case with open top, so you don't short out your Pi board + have access to the hat/RF connectors
- Potentially consider some 900 MHz SMA MALE rubber ducks. I'm using some Moto 900 MHz ducks with SMA male/male adapters. Not critical.
- Download Pi-Star (Free)
- If you do not already have a MicroSDHC memory card, I recommend a high-endurance model. 32GB is more than enough space. (Canadians, change the URL to .ca)

It really is that simple. You will have to hack your XPR7580 codeplug or CPS to allow for 902-928 operation. I am willing to assist with XPR5580/XPR7580 codeplug edits. NOTE: Firmware must be at R02.09.00.0001 or lower (CPS 16) or you will have to downgrade the firmware through certain methods.

P25 radios are much easier to modify (CPS) for out-of-band operation on 900. I believe the CPS edits are posted here on the board.

------------

So how stable are things? Very. But there are some technical things to be aware of:

- First, update the firmware on the duplex-MMDVM when you get it. The seller is claiming "latest firmware" installed, but it's from August 2018. Updating the firmware is very simple. 1) Bridge the solder pad labeled "JP 1" on the duplex-MMDVM board (enables writing). 2) Login to Pi-Star shell. Then execute the following commands:

rpi-rw (allows writing to the file system)
sudo pistar-mmdvmhshatflash hs_dual_hat (executes the firmware upgrade. When complete, reboot the unit). You will now be at 1.5.2 (11-2020). Mine shipped with 1.4.7 (08-2018). Changelog is here: https://github.com/juribeparada/MMDVM_HS/releases

For good measure, log back in to Pi-Star shell, and do the following:

rpi-rw
sudo pistar-update

This updates the OS, binaries, kernel and libraries to latest versions. When done, reboot.

-------------------

- The seller included a note that stated the TXOffset and RXOffset can be set to 0. OK. Maybe for a dumb, lazy ham. In the real world, we are aware oscillator drift needs to be compensated for. Especially way up at 900 MHz. Log in to the shell again, and execute pistar-mmdvmcal. This is a utility which has what you need to set the TX side. The RX side requires some trial and error (observe the BER via the dashboard). It takes a while, but it's worth the effort. I can describe in better detail if anyone gets stuck. My TXOffset is set to +319 Hz, and RXOffset is set to +185 Hz. I also tweaked my RXLevel to 14 (from default of 50) and it seems to have brought my BER down to 0.3%.

I can post more/go over calibration in more detail if anyone actually decides to pursue the board/setup. I don't want to waste too much time on this if no one decides to play. I am confirming it works and is 100% stable. I'm connected via Ethernet (using Wi-Fi on these things leads to packet loss, as everything is UDP streamed) and my buddies tell me I have zero packet loss, as received.

If anyone else follows through, I look forward to hearing about it/assisting/potentially chatting.

-------------------

And I'd be a total assclown if I did not mention the P25 MMDVM Encryption-capable fork. You can use the hardware I have described, and install the software/firmware (instead of Pi-Star) to chat secure P25, with a crowd that's likely much less prone to mouth breathng, than the ones you WILL observe on BrandMeister and what is now the "public" P25 crowd on the dvswitch.org reflector. Please see this thread:

https://communications.support/threads/p25-encryption-capable-mmdvm-fork.18949/

 

[Forts]

So... I'm dumb. Is there a way to buy 2 of these. Link the 1 at location A with location B via internet. Talk.

I know in the past there were ways to setup standalone reflectors/nodes/whatever they called them but it was really convoluted. For the price point it would make a really neat wide area network if it worked.

 

[Mars]

Yes. For DMR, think of brandmeister as a reflector. You can make your own talkgroup, and go from there. Note encryption does not work.

For P25, you can follow the link to the other thread, and start from there. I'm not sure if the guys have linking for the Quantar going yet on a common network so we can talk with these things. It still seems a little confusing, but only because I have not pursued the other project as I gave up trying to talk to my friend who has a Quantar outside of my area.

The dumb fuck hams who wrote whatever is being used for P25, have inadvertently blocked encryption and screwed up a bunch of other things, because they don't know how to re-encode the P25 payload on the other end.

What they did when they created whatever software, was capture something off the air, and cloned that data instead of re-encoding what the source radio is sending. For example, when I am monitoring TG 10200, their stupid software starts the transmission with 10101. There are other quirky things, too. The last time I played with their garbage was a year ago, and when I tested it again last evening, current versions, nothing has changed. I'm not complaining about free software, I'm just saying they are fucking retarded and shouldn't be the ones involved with that project. It is outside of my area of expertise as I am not a coder, but they are clearly not interested in resolving these long-standing bugs. I have no respect for them, as they are the same type of people who coddle the retards with droid-star and other junk functionality who did not come from the time when technically savvy people used P25. They're also unreceptive to suggestions, nor do they take pride in what they put together.

I would love to experiment with what the guys on this site have done, but without the ability to communicate with the Quantar, there's no benefit for me at this point in time. But I have immense appreciation for their contributions.

 

[Astro Spectra]

I'm using the duplex MMDVM hotspot from BI7JTA for 900 MHz local access:

Duplex HotSPOT

www.bi7jta.org

I use it with a compact duplexer and have Pi-Star hardcoded for the two timeslots and talk groups we use on our DMR+ MARC affiliated system, I don't use BM. The vendor answers his email and is passionate about amateur radio. An advantage of hard coding is you don't have to have deal with the whole TG4000, local voice announcements, and timeout kludges it just works like a regular MARC machine.

We do have a local 33cm XPR8400 repeater I installed (with another on the way) but I live in a rural area just out of the repeater's coverage. With the duplex hotspot at home set up on the repeater freqs I don't have to bother to remember to change channels on my XPR7580 when I get back from the commute to stay listening if I want.

Another advantage of the duplex hotspot is that you can listen to traffic on two time lots simultaneously. We have two wide area talkgroups, one on each timeslot. With two handhelds, or one set up for scan, you can keep across the goings on. And you can even talk thru the hotspot like a regular repeater.

As I've said before when discussing 900 MHz DMR radios:

MOTOTRBO 33cm performance measurements

Let me say this first – DMR completely transforms operation on 33cm. Forget everything you’ve experienced with crappy analog voice quality and impaired range on 900 MHz, I’m not talking the small (but worthwhile) improvement Motorola’s HearClear made last century. Instead, DMR makes 33cm work...

communications.support

DMR transforms 900 MHz operations.

 

[TRENT310]

If your friend currently has a Quantar successfully connected to an existing MMDVM network (BM or the like), it should be able to communicate with dvmfne via a bridge running on the dvmfne server. I have not yet tested it, but would be happy to enable it on my dvmfne GW if you want to try it.

Ok, getting back to tech in this thread, what is the software service from the dvmfne project that accepts a STUN connection on port 1994 so it can be networked with far ends that are using STM32 or similar hotspot devices? I've been following that project lightly here too, but it seems its focus is primarily on DVM-attached equipment (as the name implies).

---

The TIA102 specification is part of the story, the other part of the story is actually observing and logging the data being generated by subscriber radios and fixed network equipment running on their own native platforms then comparing with the open source / volunteer developed amateur projects, AND then replicating this observed behaviour as closely as possible on these hobby systems, and then testing and confirming that end-user experience is consistent with as much of a variety of manufacturer's equipment as possible. What does that have anything to do with awaiting direction from some other organization like the ARRL that has really no jurisdiction or authority? Like the XKCD 927 comic, you're never going to come up with a single standard that satisfies all possible scenarios.

So far every amateur P25 linking project I've tried connecting to the Quantar so far via serial wireline has only partially implemented the correct operation of a conventional linked repeater system. DVSwitch/Quantar_Bridge sends a fixed baked-in header for all group calls and doesn't actually pass through the LSD for Soft ID even though it writes the value in its log file, meanwhile P25Link apparently doesn't send any header at all at the beginning of group calls. Meanwhile, when connecting the same setup to an ASTRO TAC using the same synchronous serial / STUN over IP hardware interface, all of the call data is passed correctly right down to headers, ES/MI/KID/ALGID etc. Because this is the native OEM solution - but it proves that this is all addressable at a software level, and has nothing to do with the physical layer and electrical interfacing. Replicating that level of functionality would be a start before getting fancy with linking with other modes or transcoding. So is the issue or hold back due to lack of information, or a reference point for "how things should work", or lack of access to the necessary hardware to test changes with? I want to understand where the community needs help furthering this, or else it's seen as just a lack of care - like everyone's just reached a 'good enough, we can hear each other talk, end of development' point?

So basically, where and why are we losing all the data or throwing it away or substituting it with fixed values that do not pertain to every operating condition?
The wrong TGID used in headers is particularly bad. That talkgroup ID is the minimum required to route the call. Sure, the Soft ID may be fluff, and clearly passing ALGID/KID/ES/MI are disputed topics for whatever reason. And obviously there would be no counterparts to those values for cross-mode bridging or anything involving transcoding, so fine, at that point substitute in ALGID $80 and zero out the KID/ES/MI - but we're talking native protocol linking here to begin with. It's being generated at the SU, it's being repeated at the local FNE repeater, and a copy is sent verbatim via the serial wireline, and then literally getting not handled and lost when it is passed through to the linking software service.

 

[TRENT310]

p.s. BTW, what do "serial wirelines" have to do with amateur radio and why would the typical ham care?

Because it is a method of electrically interfacing with radio transceiver equipment. It would be functionally equivalent to E&M or 4-wire audio/PTT/COR in an analog environment, or DFSI in an IP environment (which is essentially a packet encapsulation wrapper around the same synchronous serial data payload). The physical layer notwithstanding, it serves the purpose to carry the information out of, and in to a radio and the associated transport infrastructure. One of the typical benefits of any digital transmission is to reduce generational degradation as it passes through equipment, and to increase the chances that any copy or transmission of a signal is carried and reproduced as faithfully as possible at the far end(s). This is literally the premise of any telecommunication system is to get information from point A to point B or C without mangling it in the process. So for a project which goal is to connect remote systems by linking them using an IP network, for the software to throw away half the data that is being correctly generated, received, and encapsulated by the local equipment and expected by the remote equipment is not fully accomplishing that task.

As for the rest of your post, I guess that means the constant pursuit of excellence in station operations is dead in your books. Apparently only certified accredited test laboratories working for large sums of money can acquire radio equipment and test them thoroughly, so that's why amateur digital voice must forever languish in incomplete and partial functionality. The peer review of the greater amateur radio community must not be a suitable source of feedback and a driver for further development. And that development cannot continue until the ARRL provides and publishes their recommendations, because apparently they are the final word when it comes to all amateur radio activity. WHAT?

To state "we can do better" should not immediately trigger a retaliatory emotional reaction and a citing of a disclaimer that a project is not fit for every or any purpose. Rather, it should incite curiosity and an interest to explore what is happening, or what is not happening. That often needs no more investment than a positive attitude, time, and interest - it does not always necessarily involve large sums of money.

I'd like to point out that most of the activity on amateur radio spectrum P25 modes is already being done with surplus, end-of-life, end-of-support equipment, which can be acquired at a fraction of the cost that it used to be. In some cases, no more dollar amount than to physically travel to retrieve the equipment otherwise destined for the e-cycling facility.