forum.pistar.uk

Sorry if I am being daft, but I would appreciate so guidance from those of you more knowlegable in this area. Newly back to amateur radio after about 30 years digital modes and hotspots seem a confusing game.

Most boards seem to be stated as MMDVM boards, some it seems don't have rf (I could be wrong) a lot seem to have 70cms. I've not seen one on 2m.

Next most self assembly item seem to pair up with a Raspberry Pi zero w or bigger.

So my questions are;

1. Are they pretty much the same device? as I can't see specific manufacturers except commercial pre built.

2. Is the digital mode they support dependent upon the Pi-Star firmware installed in the Raspberry Pi or is there a specific MMDVM hardware dependance for D-star, DMR and YSF?

Here's hoping that somebody can help clarify these points.
Thank you.
Phil.

Hi Jason,

Thank you for the kind reply. Sorry if I wasn't clear in how I set out my questions.

Most of the single antenna MMDVM boards I have found look the same or 'generic' and are listed via Ebay from China. I can't say that I have found Amateur Radio dealers that helpful or knowledgeable. Certainly there are no dealers local to me that I can go to and discuss options so using the internet seems the only way.

The link to the S55AL hotspot was interesting and different to the ones I have looked at that fit over a Pi Zero. As far as I could make out that was a build from scratch item as I could not see any selling information showing. The following link shows the items I've seen most of and as I say they all tend to look the same and I doubt there will be any documentation. Some show differing digital modes, for example the following don't list YSF operation. https://www.ebay.co.uk/itm/2Pieces-MMDV ... Swn~JeFXwI

KE7FNS Said - I'm not clear on what exactly you are asking. Are you wanting to know about the MMDVM device, or the RPi device?

In answer to that question, the reason given above is why I asked if there is some form of firmware or hardware embedded on the MMDVM boards to support the different digital formats which Pi-Star which runs on the Raspberry Pi uses to handle the different digital formats.

Or is your statement

KE7FNS Said -MMDVMHost (the software that does all the behind the scenes work) supports D-Star, DMR, P25 Phase 1, NXDN, System Fusion, and POCSAG paging on the MMDVM.

actually saying that there is firmware on the MMDVM board that the Raspberry Pi Star software uses.

Thank you very much for your kind reply
Phil

Hi Jason
Many thanks for your comprehensive reply. I think the key message I get from your response is that the MMDVM board has it own dedicated firmware and, if I am correct, it is that that facilitates the specific digital mode encoding\decoding that the hotspot can provide.

The Pi-star software on the Raspberry pi provides a control panel to configure internet data sources be they YSF,DMR or D-star that will be passed via the MMDVM board.

The question then is if the MMDVM firmware supports the digital mode in use and requested by the pi-star config. The boards I gave a link to don't list YSF so it is possible that they don't support that digital mode and 'may' require a firmware update, if indeed they are compatible with any updated firmware. And as you say, some makers change the components then I suspect this is a rats nest of potential problems as although they 'look the same they aren't'.

I have a D-star transceiver and the chap I am working on things with has Yaesu (C4FM/Wires-x) so we have a potential problem that the boards won't handle YSF and that is before we even think about trying to find a 'bridge' between the two modes.

The MMDVM firmware site link you gave, looks to be the source code to compile the firmware and a whole order of magnitude more complexity again if we had to compile it then only to find it isn't compatible with the MMDVM boards we have and that assumes we find out how to install the updated firmware onto the MMDVM board.

To me this is starting to sound like we are headed into a black hole and me especially, as I am the computer head in our little project. Maybe I have to concede defeat to my friend and forget digital as a wasted side of our transceivers. We only have one digital repeater on hand in our area that we can access for C4FM on 70cms that is heavily used making a personal hotspot essential for D-star if I am to use anything and highly desirable for my friend with Yaesu kit not to 'hog' the repeater he can access.

Please excuse me when I say I feel deflated and lost. It is so easy to spend ages hunting the internet to find so much data that is misleading that then perpetuates further lost time.

We'll see what turns up maybe they will operate YSF and it'll be ok or maybe they drop in the bin and we try to forget it as a bad experience.

Thank you so very much for your help.
Phil

Hi Jason,

Thank you again for your support, technical and moral.

I am in the position that the fellow radio amateur I am helping has already ordered the two kits whilst I was doing research, he was being kind and trying to say thank you for the help I have given him in not just this areas but others like FT8 and PC configuration etc. Like you I looked at the sellers 'other items' and thought that they may not know much about with these kits are.

So your

KE7FNS Said - Well, technically both MMDVMHost and the MMDVM have to have the ability in the software/firmware to be able to communicate for a specific digital mode.

I take as the MMDVMHost is an internet data streaming source, the format of that source is dependent upon whatever the user has configured the Raspberry Pi to access using the Pi-star software.

KE7FNS said - For example, in DMR there are specific DMR packets that MMDVMHost sends to the MMDVM and vice versa, for YSF they are completely different packets, but similar in design.

So the pi-star needs to connect to data sources that our radio primarily is capable of (D-star/YSF etc.) those sources can be connected repeaters or other user hotspots and possibly internet based 'bridge' locations or nodes that facilitate D-star to YSF and vice versa ( I could be wrong).

Anyway I am buoyed up by your kind help and will persevere and see how we go hoping that I don't need to try and change the MMDVM embedded firmware. Thank you though for the 'Sudo instruction' to do this, which I assume is done from the Raspberry Pi command Line console.

Don't knock your own clear and helpful support Jason. I will read the other links you have offered up but without your help I would be far less certain. By the way, this is the 5th time of trying to post a reply as the forum seems to bomb each time I try and post losing everything I typed so this doesn't carry all I had originally set out to say (probably just as well Hi).

Most importantly I hope that eventually it will work and we can use one of the hotspots to say direct thankyou.

Kind regards
Phil.

Well Jason,

I can let you know that you were spot on. The boards arrived, they weren't as shown in the pictures so definitely clone boards without markings. The build quality wasn't that great either but they work and I have tested both boards on a single Pi Zero (can't buy them here at the moment for ready cash). The boards also cover YSF too so that's ok.

I have hooked one up and set it up with the IC-9700 and worked through a reflector, more by luck that design so have had a test report from N8XOL (Ron in Michigan) so I'm glad I got that far. The settings and navigating d-star are all a bit of a maze. Setting the [DR] screen from to the Hotspot and then the [To] to Linking to a Reflector REF001C , 030C or 067C all seems to work. Quite where I go from here is a bit of a mystery trying to get to grips with Reflectors vs Repeaters and then how to find a link between D-star and Wires-x which others around here predominantly use as there is a fusion repeater.

When we get another Pi zero I have to build the one for my friend here. With current situation we may have to hand over at a distance and me remote into his pc and setup as he is in a vulnerable group for this Covid-19 virus. With any luck we may have another Pi later this week but we aren't counting on it.

Thank you for your encouragement and help.
73's Phil.

Hi Jason,

Ok on the performance differences on the various Pi devices, that is a major difference.

I have pre configured an sd card ready to with wifi settings but as we are both in high risk group for this virus we can't go out or meet. I don't know if the pi uses the Wpa_Supplicant settings file on first boot when Pi-star unpacks itselt or if I can use my wpa_supplicant file then replace it with his. Secondly I am not familiar enought to know how to configure more than 1 wifi connection on the linux platform.

I have somebody who an leave the hotspot once built in a place where Nigel can get it safely - fully wiped down with medical wipes for extra safety, or we may have to leave it until we can do more. The rest of config I can do by remote computer support unless it comes to putting settings directly into his transciever and even that maybe possible.

Hope things are all ok for you and your family and that you stay safe.

Hopefully we'll speak sometime through these systems.

Kindest regards to you and yours.
Phil

Possibly a daft question Jason so forgive me if so.

Could I use my wpa-supplicant file, go on the hotspot and configure it for Nigel then simply replace the Wpa_supplicant file with one setup for his ssid and password?

I've got both versions of supplicant file and can see the SSiD nd Password entries as #ssis= and I note the same again as Hexadecimal values for ssid under ssid=Hex

However the psk=hex string doesn't match with the password character hex values so isn't generated the same way.

If I can config Nigels callsign etc then I could do that and then swap the wpa_supplicant file on the sd card before hading over.

I got a might confused with the way you suggested, perhaps silly but I'm being honest here.

On the virus front things are ramping up steadily, getting supplies in is getting problematic, we're ok for the moment but we are also in early stages of thing ramping up. 12 weeks to go, before we can possibly start to integrate again, then review they say so maybe not then.

As long as we stay well, then having the amateur radio setup is a good thing. Given your last comments on using the mmdvm hotspot I'm guessing you are not on dstar.

kind regards
Phil

This whole thread is interesting because I suspect that many hams that would love to experiment with digital radio like DMR, YSF, D-Star, P-25 etc are frustrated by the complexity that various products, write-ups, forums and products expose.

It's hard to "get" the big picture of where each component of the overall system fits in.

Once you start working with the technology and become familiar with it, it is almost "magic" how powerful it is. I've been helping with one of the projects (OpenGD77) and the authors and testing community regularly get together via ham radio in spite of world-wide geographic distance (Australia and France for some of the principle authors).

The magic is based on digital voice switching network technology implemented over the Internet. This voice switching works on very highly compressed low data rate digital packets of voice data and the meta data needed to route it from user to user. These voice switching networks support both private contacts and one to many / many to many group contacts.

There are more than one DMR ham voice switching networks. My preference is one that is built with open source software and almost completely self configured and maintained by users - Brandmeister, but there are others. https://brandmeister.network/

It all started out with Motorola's DMR IP Site Connect technology. The Motorola products are proprietary technology, and defined the actual behavior of the voice switching technology which eventually was standardised by an organization in Europe. The amateur DMR-MARC voice infrastructure is an extended version of Motorola's technology, and was one of the first to become widespread. https://www.dmr-marc.net/

You'll also see other DMR voice switching networks. TGIF comes to mind. http://tgif.network/

D-Star has it's own voice switching network, as does Yaesu YSF. These are deployed with proprietary technology in the voice network servers.

Through a series of bridges and gateways between these voice infrastructures, users of the different over the air digital technologies can communicate with each other. There are differences between how the private conversations and group conversations are structured ("Rooms" in YSF versus "TalkGroups" in DMR, for example) but techniques have emerged for getting them to work together.

A system like Brandmeister is particularly powerful, which is why it's become popular for DMR users. It is really a second generation approach to building and maintaining one of these voice infrastructures.

So how do the different components fit in? First, Pi-Star

PiStar does a couple of things. It connects your installation to the Internet, switches voice packets between the Internet and local radio equipment (duplex repeaters or simplex hot spots) and displays a dashboard full of status messages and indicators about the state of conversations it's working on.

This is all built in layers. I've just discussed some of the voice switching layers. Below that is the component that provides an interface between users and the Voice Over Internet (VOIP) networks. The VOIP networks that directly attach to your device are radio technology specific. Yaesu products only connect to YSF compatible servers and use a closed proprietary technology. The behavior of that technology has been analyzed and cloned, and this allowed open versions to be built as gateways between VOIP networks. D-Star is a different closed proprietary technology that has been analyzed and cloned too.

DMR is a standards based technology that was first implemented in a proprietary product family by Motorola. It has been analyzed and cloned like the others, but the work on this has been much more deeply explored. There are components within Pi-Star that talk directly with DMR VOIP networks via the Internet using Motorola's standardized IP Site Connect protocols. The VOIP networks themselves support various functional capacities deployed by Motorola. For example, DMR-MARC is built partially out of Motorola components, and it supports the Remote Management technologies for Motorola repeaters. Brandmeister makes limited use of the Remote Management protocols, and doesn't expose them to users.

The various bridges and gateways in the VOIP infrastructures allow connection to other VOIP connection managers. In the case of Brandmeister, you connect to a "Master" from your home PiStar Raspberry Pi computer via IP, and the masters connect to each other worldwide. They take care of switching your voice packets to others, and their voice packets to you. The masters can switch voice packets to other masters which then connect other networks of the same radio technology (DMR to DMR for example) or gateways to networks of other technologies (DMR to YSF for examlple).

PiStar does some of it's magic by being able to connect to local radio devices to create local repeaters and hot-spots. The MMDVMHOST component of PiStar runs inside the Raspberry Pi and knows how to talk to local radios in several radio technologies. That's what the "MM" stands for "Multi-Mode". It can handle voice packets and control meta data in DMR. It can do it in YSF. It can do it in D-Star. It can do it in P.25 (a public safety protocol) and it can do it in NXDN (Kenwood's version of digital radio).

The Raspberry Pi runs Linux and the software is executed on it's ARM 32 bit processor. There are several versions of these single board computers. Even the smallest Raspberry Pi Zero W has enough power and storage to run PiStar efficiently.

MMDVM

MMDVM is the firmware that controls a local device (sometimes packaged as a "hat" that plugs directly into a Raspberry Pi board's connector pins) that implements the radio controller and often a low power software defined radio chip.

Several products have been produced that run MMDVM, the Multi Mode Digital Voice Modem. It's completely open source - the hardware and firmware that implements the radio modem and MMDVMHOST software that runs in the Raspberry Pi, and is being continuously improved.

There are a number of products that run MMDVM or it's equivalent. Open projects like the MMDVM Hotspot Hat "JumboSpot" board project have commercial competitors like the similar ZumSpot hat board, DVMega, OpenSpot products and others. These boards and hats either provide the modem and radio or interface to radios, and can even also include the VOIP interface too (OpenSpot).

Firmware has to be written to interface between PiStar's MMDVM Host and the software defined radio components that put voice packets out over the air and receive them. This firmware, that knows how to actually transmit packets through various technologies, is specialized for controlling the radio chip on devices like the "MMDVM" Board. This separate circuit board has a controller that prepares the voice packet transmissions, deals with receiving incoming packets and turns the radio chip on and off. It's implemented in boards like the "JumboSpot HotSpot Hat" in a self contained processor. From the description:

"It runs on the Arduino Due, the ST-Micro STM32F1xxx, STM32F4xxx and STM32F7xxx processors, as well as the Teensy 3.1/3.2/3.5/3.6. What these platforms have in common is the use of an ARM Cortex-M3 or M4 processor with a clock speed greater than 70 MHz, and access to at least one analogue to digital converter and one digital to analogue converter."

Here's the Analog Devices ADF7021 chip, a high quality RF transciever:

https://www.analog.com/media/en/technic ... DF7021.pdf

This processor is used to control the radio chip. On the MMDVM Hotspot Hat board it is a ADF7021 (or RF7021SE module) radio transciever chip. The duplex version of this board has two of them. This chip implements the radio receiver and transmitter on those boards. Other boards used with external radios don't have this chip since they send and receive signals through the external radio. This software defined radio operates at one of two clock speeds, and the quality and precision of the clock chip has a lot to do with the quality of an individual board. A high quality clock chip will be stable and accurate. A cheap one will probably not be.

This radio transciever chip generates a very low power signal that is directly transmitted by the hotspot hat board through a small antenna. A few milliwatts, it's suitable for local use within a few hundred to thousand feet.

Together the firmware, Arduino Due microprocessor, A to D and D to A converter and ADF7021 transciever chip are a software defined radio with the flexibility to transmit and receive all the major digital mobile radio technologies. DMR, D-Star, YSF, NXDN and P-25. Very inexpensive and pretty neat.

By using these low cost components and the free open source software, the open source hardware JumboSpot HotSpot Radio Hats (simplex and duplex) are both powerful and affordable. Unfortunately, there are a couple of issues to be aware of. Most digital mobile radio modulation technologies require fairly precise frequency centering for transmission and reception. Every radio varies a few cycles to few hundred cycles based on component tolerances. This means that one portable handheld radio may be a few hundred cycles off the exact center RF frequency. In more expensive radio implementations, receivers include "Automatic Frequency Control" that will steer the receiver dynamically to center the incoming frequency. On the low cost JumboSpot, the ADF7021 processor controlled by MMDVM does not implement AFC. This means that when the signal it's receiving is off a bit, it will generate "Bit Error Rate" errors. There is an expert setting for MMDVMHost on PiStar that lets you adjust both a receive "RXOffset" and transmit "TXOffset" to minimize these errors with a specific radio. With adjustment, you can get the BER below 1%. There is a "MMDVMCAL" utility for doing this within PiStar.

The packaging and implementation of these components varies from different designers and different manufacturers. Most that implement MMDVM can communicate in all the technologies supported by the MMDVMHOST software. There are a couple of projects that don't. I've been working on the OpenGD77 project. This is DMR only since the radios it run on only communicate via DMR protocols. So far, this project has implemented the DMR hotspot portion of MMDVM within Radioddity GD-77, GD-77, and Baofeng DM-1801 radios on their internal processors. This is in addition to providing a much more amateur radio friendly firmware for these radios. These have the advantage of operating with higher power, and being implemented on radios that include automatic frequency control, which deal with bit demodulation errors on receive. In this project, the PiStar running MMDVMHOST plugs directly into the portable handheld radio via USB (the same attachment used to program the radios). Thanks to the 50 percent RF duty cycle of DMR, it even appears that these can run long periods of time at moderate power output (adjustable from 1 watt to 5 watts). These are ideal for creating event hotspots with some range.

I hope that this overview can help you understand the relationship between all the components and new unfamiliar names you encounter when first working with digital mobile amateur radio.

Jason,

As ever thank you so much for your kind help. We ramped up another notch on the isolation factor yesterday so progress on this may cease as we may not be able to exchange necessary parts if a delivery doesn't arrive. Already we cannot meet, or be within 2m of each other and any surfaces we touch would have to be disinfected. So with thoughts in mind to protect and care for each other we probably have to postpone.

I sincerely hope that at some point and if I can get my head around the extensive information regarding the range digital voice modes that Marc added to the thread maybe we will be able to get to speak d-star to your dmr (its still a way off for me).

A google map satellite view into where you are shrunk the world and somehow made your posts so much more personal, so with that in mind I will wish you and family well through these times.

Marc,

This thread all started because I was totally confused having been out of amateur radio so long (as has Nigel my friend) but now have a d-star transceiver IC-9700 and Nigel an FT991a. The digital voice ham radio stuff is still taking some learning and at the same time things are developing all the time behind the scenes, versions of AMBE codec and linking etc are all a boggle. I will have to take a lot more time looking at your post and the links within it to follow what you are saying.

One day I hope to be able to get a way of 'bridging' from d-star to wires-x. Not that Nigel and I need it as we can use simplex fm, but to share in things more. I have read a bit about XLX reflectors and that they can link the various digital modes but that may be where Jason is saying I may need to update the MMDVM firmware too. With clone hardware that we have that may not be as simple and may require a better supported commercial HAT board. Only time will tell.

Thank you for your comments pointers to the additional reading material, I could have some time to read it in the weeks ahead, but I think Jason has given me more than enough to cope with for the minute.

Wishing you well and thank you again.
73s Phil.

Hi Phil,

Yes - I read through the thread from the beginning.

The voice encoding "VoCoder", sometimes known by the brand name AMBE, is a proprietary firmware based processor that is inside the radios themselves, often implemented in a dedicated chip processor for that specific task. It's not within PiStar or the hotspot device. Those are devices that basically receive/transmit, store and forward voice packets that the radios themselves have encoded or will decode from and to audio. The audio conversion to compact packets of digital bits takes place in the radios.

The gateway interfaces between different digital modes (DMR / YSF / D-Star / NXDN / P-25) do have to unwrap the packets and sometimes return them to audio to be re-encoded for the other mode they are forwarding to.

Marc