Page 2 of 2

Re: Which MMDVM Board?

Posted: Thu Mar 19, 2020 10:32 am
by G0KDT
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

Re: Which MMDVM Board?

Posted: Thu Mar 19, 2020 8:34 pm
by KE7FNS
G0KDT wrote:
Thu Mar 19, 2020 10:32 am
Ok on the performance differences on the various Pi devices, that is a major difference.
Yes, however the only real benefit to that performance is the time it takes to boot and become a usable system is reduced dramatically. In other words MMDVMHost only uses 1-2% of the CPU utilization on my 3B+ setup so the daily functions of the hotspot don't really benefit all that much.
G0KDT wrote:
Thu Mar 19, 2020 10:32 am
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.
It unpacks it on every boot if detects that the file exists on the /boot directory of the SD card. Once it loads the settings from the file the settings are written to a different location on the filesystem (/etc/wpa_supplicant/wpa_supplicant.conf) for all future bootings.

You should be able to configure the hotspot to your likings, and then use the backup procedure on the dashboard to save those settings so that you can upload them to a fresh image on a SD card or clone the SD card using a cloner like win32diskimager.

Then you can insert that clone SD card and boot his hotspot which at that point is an exact copy of yours and change a few settings like DMR ID, location etc, and then finally load his wifi settings and it should be good to go ready for him to plug it in. That is a similar setup I use for maintaining multiple hotspots.

To handle multiple networks in the wpa_supplicant file you just specify multiple network structures.

Code: Select all

network={
ssid="FirstSSID"
psk="password"
key_mgmt=WPA-PSK
id_str="0"
priority=100
}

network={
ssid="SecondSSID"
psk="password"
key_mgmt=WPA-PSK
id_str="1"
priority=99
}
It will search for the first one and if it detects it, it will connect to it, if it doesn't it'll go to the second and try it.
G0KDT wrote:
Thu Mar 19, 2020 10:32 am
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.
Sounds like a safe plan to me. It is amazing what you can do with software like Teamviewer.
G0KDT wrote:
Thu Mar 19, 2020 10:32 am
Hope things are all ok for you and your family and that you stay safe.
Just kinda taking things day by day and waiting to see how this whole thing pans out. I hope all is well for your friends and family also.

Re: Which MMDVM Board?

Posted: Fri Mar 20, 2020 3:25 pm
by G0KDT
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

Re: Which MMDVM Board?

Posted: Fri Mar 20, 2020 6:32 pm
by KE7FNS
G0KDT wrote:
Fri Mar 20, 2020 3:25 pm
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?
Yes. Whatever wpa_supplicant file that is loaded on the SD card before being booted is what will be configured during the boot, when you copy a new wpa_supplicant file to the /boot directory the older settings are overwritten and replaced with the new one.
G0KDT wrote:
Fri Mar 20, 2020 3:25 pm
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.
Yeah, that is normal. What you are seeing is the Pre-Shared Key (PSK). How that PSK is generated is with a program called wpa_passphrase, you can run it from the command line.

Code: Select all

wpa_passphrase [ ssid ] [ passphrase ]
G0KDT wrote:
Fri Mar 20, 2020 3:25 pm
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.
Yes, however what I would do is add both yours and Nigel's network settings (so you would have duplicate network={ } sections) from the wifi builder into one file, and then make yours priority 100 and his priority 99, and then you should be able to power his up and test it for the time being. Then when you are ready to hand it over, use the wifi builder to create a file with just his network and copy it on the SD card and let him power it up.
G0KDT wrote:
Fri Mar 20, 2020 3:25 pm
I got a might confused with the way you suggested, perhaps silly but I'm being honest here.
No problem, there are built in means to easily backup and restore the settings in pi-star. So you can get your hotspot fully configured, back it up, and then if you ever need to rebuild it, you just restore from a backup. It is much easier than starting from scratch.

All I was trying to explain is basically two ways to produce 2 identical hotspots. One is using the backup procedure on the dashboard on hotspot 1, and restoring it onto hotspot 2. Or using a PC to clone the SD card from hotspot 1 onto the SD card for hotspot 2. Either way you will end up with 2 identical hotspots with only half the amount of work.

Then you just need to go in a change a few settings, and it will be setup for your friend.
G0KDT wrote:
Fri Mar 20, 2020 3:25 pm
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.
Yeah, it is crazy to see images on the news where they show the streets in New York or Los Angeles completely empty of people and cars.

I only have DMR capabilities at the moment.

Re: Which MMDVM Board?

Posted: Tue Mar 24, 2020 5:48 pm
by kd2lh
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.

Re: Which MMDVM Board?

Posted: Tue Mar 24, 2020 8:24 pm
by G0KDT
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 :D for the minute.

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

Re: Which MMDVM Board?

Posted: Tue Mar 24, 2020 10:33 pm
by kd2lh
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

Re: Which MMDVM Board?

Posted: Wed Mar 25, 2020 7:45 pm
by KE7FNS
G0KDT wrote:
Tue Mar 24, 2020 8:24 pm
As ever thank you so much for your kind help.
Hey, no problem, I enjoy the interaction on the forum, actually more than talking on a radio. It seems that so many other forum users only post when they have a major problem and then disappear never to be heard from again. Sometimes they don't even come back to tell you if your suggestion you made in their post worked or not.
G0KDT wrote:
Tue Mar 24, 2020 8:24 pm
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.
Yeah, that seems like the best thing to do at this time. I hope that everything is well and goes well for you, your friends and your family and you are able to find some way for you and your family to get the things you need to survive during this situation.
G0KDT wrote:
Tue Mar 24, 2020 8:24 pm
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).
Yeah, that was a bit of information overload. I suggest when you find you have some free time you might try browsing Toshens website that I linked earlier, I think his way of technical writing really makes it easy to understand and grasp the concepts. He has some paragraphs on that crossover stuff you are interested in, but I have never experimented with it. Even when I was reading the info that KD2LH posted I couldn't stay focused and wandered off and skipped over most of it. I did see a few things that could be addressed. One of them was RPi's being only 32 bit processors when actually ever since the RPi 2 1.2 released in October 2016 they are 64 bit processors except the RPi Zero and Zero W variants. Raspbian has remained on a 32 bit version, but there has been some progress to bump it up to 64 Bit. I eagerly await that moment it becomes the norm.
G0KDT wrote:
Tue Mar 24, 2020 8:24 pm
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.
Yeah, honestly I don't think this is the best place to be when faced with what is going on. There are 4 million people in a 15,000 sq mile area I share the same volume of air with. Right now there are 401 confirmed positive cases of COVID-19, yesterday there were 152. Every day that number is going to get larger and larger. I think it is only a matter of time until it will be unavoidable.

Re: Which MMDVM Board?

Posted: Wed May 27, 2020 8:20 am
by G0KDT
Hi Jason,

It's been a while. I hope you and your family are all ok this virus thing has dealt out quite a nasty pounding on people and I feel for the many that have lost loved ones and are suffering.

Our Uk spike in cases increased until for such a small chunk of the earths surface we have a had a high number of cases, nothing like the figures we read for the USA but still too high. And still we aren't clear, whilst lockdown relaxations are kicking in and people are being asked to travel and more importantly 'go home' at the end of their day out, many are not and the region in which NIgel and I are in moved to the second highest rate of infection in the country. Not so good, and I feel certain that we'll see a second spike, already the hospital in the next county up is turning patients away so tricky times.

As to the Hotspots, we got them all working, well for D-Star we did and great for Rx on Fusion but TX on Fusion has been totally hit and miss. Nigels FT991a simply will NOT connect to the hotspot when we (He) use's the 'X' button (I have had to do all I can diagnostics wise by remote login.... yeah right, that's been fun when you want to press a button the radio :roll: ). Somewhat insanely (in my view) Nigel bought an FT3D which did hook up to the Hotspot albeit not consistently, and that did get the FT991a to connect...?? but then he has sold the FT3D... (hence comment)because it was not loud enough to hear.... I've posted questions for the YSF Pi-Star gurus to try and find a way through but I think we're on a hiding to nothing.

SO as I say, hope all is well and thanks for the help you gave it was very very helpful and appreciated.
Phil

Re: Which MMDVM Board?

Posted: Fri May 29, 2020 7:20 pm
by KE7FNS
G0KDT wrote:
Wed May 27, 2020 8:20 am
As to the Hotspots, we got them all working, well for D-Star we did and great for Rx on Fusion but TX on Fusion has been totally hit and miss. Nigels FT991a simply will NOT connect to the hotspot when we (He) use's the 'X' button (I have had to do all I can diagnostics wise by remote login.... yeah right, that's been fun when you want to press a button the radio :roll: ). Somewhat insanely (in my view) Nigel bought an FT3D which did hook up to the Hotspot albeit not consistently, and that did get the FT991a to connect...?? but then he has sold the FT3D... (hence comment)because it was not loud enough to hear.... I've posted questions for the YSF Pi-Star gurus to try and find a way through but I think we're on a hiding to nothing.
Unfortunately I don't have any experience with those two radios or fusion in general, all my Yaesu radios are ancient. Hopefully someone out there will respond with either a fix or some way to solve your issues.

Glad to hear that you two are still doing well. Keep doing what you have been doing and hopefully we all can put this behind us.