Date   

Re: Pi digital interface for Analog Radio (client)

Steve N4IRS
 

Jim,
Yes, you can mix and match components from a number of different project. The radio you describe would have to pick off the analog audio from the mic, send it through a vocoder and then send the datastream back to the transmitter and on to the DMR repeater. In the receive direction, the radio would have to pick off the the audio from the discriminator, send it to the vocoder. The analog audio would need to be injected back into the radio so the audio could be sent to the speaker. As of this is doable. There is one actual problem. The MMDVM software can look like a DMR repeater transmitter to a subscriber radio. The MMDVM software can look like a simplex signal (DMO) to a subscriber radio. What the MMDVM software can not do, is look like a subscriber radio to a DMR repeater. The same is true for traffic from a DMR repeater to the radio. The MMDVM software can not receive the output of a DMR repeater.

If I were trying to accomplish what you seem to want, I would put my money into the hill top repeater. I would build a high quality analog repeater. The would give you the best mobile coverage. Now couple that repeater with a Digital Voice bridge and you not only get DMR, you get all 5 digital modes plus analog repeater networking. This does assume the hill top repeater has internet access as would a DMR repeater.

Just my take. YMMV
73, Steve N4IRS    

On 11/1/20 3:01 PM, Jim Kusznir wrote:
Hi all:

So, as I reread this and talked to others, it sounded like my request may not have been all that clear, so here's another go, more from application than technical function:

I usually am mobile while on ham radio (VHF/UHF).  I just recently installed an FT-8900.  In my area, due to terrain, 6m is used (and is occasionally the only reliable way to get out).  Cell tower coverage is pretty spotty.

I'm looking to use an existing wide-area DMR repeater transmitting on actual ham bands at "repeater power" located on hilltops with wide range.  I'm looking to do this mobile, where an HT would NOT cut it.  I would rather not have two completely separate radios and antennas in my vehicle, and the only viable mobile I've even considered to this point is the Anytone 578.  Unfortunately, even if I did go the dual-radio route, the Anytone does not allow for separating the control head, and that is required in my vehicle.  So, that leaves me with no ability to use DMR when mobile, which is 90% of my ham radio activity.

What I wanted was a way to do DMR with my existing FT-8900, much like I can do 9600 baud packet with my FT-8900 by plugging in additional equipment to the jack on the back of the radio.  I was hoping to create a "DMR TNC" with its own little display, mic, and speaker, and have it connect to my FT-8900 and use it as a CLIENT on the DMR system, and NOT need any internet in my vehicle (or immediate vicinity).

So, to accomplish this, I see:
1) there ARE software packages that can work with a Pi to connect via IP to the DMR network and run as a client (with a mic/speaker), allowing all talk group access,etc., available on the IP connection you are using.  This is 1/2 of what I was looking for, but no IP connectivity to the DMR network...I want to use my radio.
2) there are solutions for using a Pi to connect to an analog radio and turn it into a hotspot/repeater and connect to the DMR system with IP.  However, I am not looking to be a "repeater" (server) but a user (client).

Ideally, I would like to take parts from both of the above and "mash them together" so that my software frontend will interface with a board (perhaps like the STMDVM, perhaps just an ADC like NWDR's DRAWs hat) which will connect with the analog radio.  Yea, I will likely need something like the ThumbDV or some other AMBE vocoder chip connected via USB....OK.  The missing piece seems to be some sort of software bits to act as an RF client.  I'm also wondering if this hasn't already been done because the analog radio cannot switch its transmitter on/off fast enough to do TDM as a client....If it actually isn't possible for this (or other technical reasons), please let me know!

One more thing: I am NOT limiting options to "ready built systems".  I am a tinkerer, and I am good with linux.  I'm sure I could get a DMR-AllStarLink system going or other such stuff.  I'm not an outright coder, so modding the source code of the client to implement what I'm looking for is beyond me, but I don't require something as neatly packaged as PiStar (but would gladly accept it if it were there!).

Thanks again all!
--Jim, K7LL


Re: Pi digital interface for Analog Radio (client)

Jim Kusznir
 

Hi all:

So, as I reread this and talked to others, it sounded like my request may not have been all that clear, so here's another go, more from application than technical function:

I usually am mobile while on ham radio (VHF/UHF).  I just recently installed an FT-8900.  In my area, due to terrain, 6m is used (and is occasionally the only reliable way to get out).  Cell tower coverage is pretty spotty.

I'm looking to use an existing wide-area DMR repeater transmitting on actual ham bands at "repeater power" located on hilltops with wide range.  I'm looking to do this mobile, where an HT would NOT cut it.  I would rather not have two completely separate radios and antennas in my vehicle, and the only viable mobile I've even considered to this point is the Anytone 578.  Unfortunately, even if I did go the dual-radio route, the Anytone does not allow for separating the control head, and that is required in my vehicle.  So, that leaves me with no ability to use DMR when mobile, which is 90% of my ham radio activity.

What I wanted was a way to do DMR with my existing FT-8900, much like I can do 9600 baud packet with my FT-8900 by plugging in additional equipment to the jack on the back of the radio.  I was hoping to create a "DMR TNC" with its own little display, mic, and speaker, and have it connect to my FT-8900 and use it as a CLIENT on the DMR system, and NOT need any internet in my vehicle (or immediate vicinity).

So, to accomplish this, I see:
1) there ARE software packages that can work with a Pi to connect via IP to the DMR network and run as a client (with a mic/speaker), allowing all talk group access,etc., available on the IP connection you are using.  This is 1/2 of what I was looking for, but no IP connectivity to the DMR network...I want to use my radio.
2) there are solutions for using a Pi to connect to an analog radio and turn it into a hotspot/repeater and connect to the DMR system with IP.  However, I am not looking to be a "repeater" (server) but a user (client).

Ideally, I would like to take parts from both of the above and "mash them together" so that my software frontend will interface with a board (perhaps like the STMDVM, perhaps just an ADC like NWDR's DRAWs hat) which will connect with the analog radio.  Yea, I will likely need something like the ThumbDV or some other AMBE vocoder chip connected via USB....OK.  The missing piece seems to be some sort of software bits to act as an RF client.  I'm also wondering if this hasn't already been done because the analog radio cannot switch its transmitter on/off fast enough to do TDM as a client....If it actually isn't possible for this (or other technical reasons), please let me know!

One more thing: I am NOT limiting options to "ready built systems".  I am a tinkerer, and I am good with linux.  I'm sure I could get a DMR-AllStarLink system going or other such stuff.  I'm not an outright coder, so modding the source code of the client to implement what I'm looking for is beyond me, but I don't require something as neatly packaged as PiStar (but would gladly accept it if it were there!).

Thanks again all!
--Jim, K7LL


Re: DSTAR

k7wby@...
 
Edited

First, Congratulation on your soon to be born new family member..

D-Star is a different animal but not so different that the pieces won't fit if assembled properly. Fortunately DVSwitch Server is an excellent way to bring the pieces together.

To understand D-Star, I highly recommend that you visit ircddb.net to better understand what's going on before you dive in. After you've gone there, head over to D-Star Info
and browse through their info. D-Star Info has plenty of info. As is typical with Ham Radio sites, there are a ton of assumptions made which will send you into at least one if not more guessing games. One of the first things that will mess you up is your D-Star Registration. While it clearly states that you only have to register once to use the reflectors you will soon find that some reflectors require additional registration. For instance REF030 is available to all registered D-Star users but REF014 requires permission from that reflectors owner/operator. It's these little things that can mess you up when you're trying to get things going. To begin with, use a test Reflector and avoid the loss of hair. More importantly, use a test reflector to avoid interfering with live traffic while you're getting it all figured out. 


Pi digital interface for Analog Radio (client)

Jim Kusznir
 

Hello:

I had a recent idea that I was wondering if I'm just crazy, or if this is actually reasonable.

We all know that MMDVM software allows someone to use the internet to create a repeater based on analog radios.  There are also software/hardware packages that allow using a mic and speaker and the internet to connect into DMR as a client (hold conversations, etc).

What about a device/software configuration that wold connect into the 9600 baud data port of an analog radio and a speaker and mic and allow the user to participate in the DMR system as a client through radio (eg, FT-8900 radio, for example)?

I know the STM_DVM board would have the physical connections necessary to interface to the analog radio (it already does that!); I'm not sure if it can act as a client rather than a repeater on the RF port though.

If it can, then the software (Blue DV or one of the equivalents) would need to know how to interface with a radio, or make use of a middle layer (DVSwitch software?)

Finally, is the analog radio able to T/R switch fast enough to do the TDM tx...

Is this doable, or am I just thinking wishfully?

--Jim, K7LL


DSTAR

Aaron Groover
 

Good Morning everyone!

 

First off I hope everyone is doing well. I am currently patiently waiting for my daughter to be born at the hospital. So while I wait lol…… I was looking at setting up DSTAR on the bridge. I know is different and all sorts but wanted to know the correct process as far as where to put i.e REF030C and where I can find the gateway info. Ive had the DMR and also Fusion up for weeks and had QSO’s with no issues.




--

 

Thank You,

 

Aaron Groover

(610) 379 6148

K3ALG@...

 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.


**This message has been composed on a mobile application. Please excuse any grammatical errors**


Re: #mmdvm_bridge #mmdvm_bridge

k7wby@...
 
Edited

Ok, I have some idea of what you're trying to accomplish. Sorry if some of this is redundant but others may want to understand:

Here's my take:
Install DVSwitch from the repository to /opt/ which creates
/opt/Analog_Bridge
/opt/md380-emu
/opt/MMDVM_Bridge
create two new folders in /opt/ 
/opt/mb1
opt/mb2
copy the entire contents of MMDVM_Bridge to mb1 and mb2
delete /opt/MMDVM_Bridge
disable mmdvm_bridge.service
create two new services in /etc/systemd/system based on the original service /etc/systemd/system/multi-user.target.wants/mmdvm_bridge.service
change each of the new .service's so they point to the new locations (/opt/mb1 and /opt/mb2). For instance, the following would be the service definition for the first MB instance I called MB1


[Unit]
Description=MMDVM_Bridge MB1 Service
# Description=Place this file in /lib/systemd/system
# Description=N4IRS 04/20/2018
 
# The device name should point to the
# port the mmdvm is plugged into.
# For USB ports (Arduino Due)
# BindTo=dev-ttyACM0.device
#
# To make the network-online.target available
# systemctl enable systemd-networkd-wait-online.service
 
After=network-online.target syslog.target netcheck.service
Wants=network-online.target
 
[Service]
StandardOutput=null
WorkingDirectory=/opt/MMDVM_Bridge (Change to /opt/MB1)
Environment=DVSwitch=/opt/MB1/DVSwitch.ini (Change to /opt/MB1)
RestartSec=3
ExecStart=/opt/MB1/MMDVM_Bridge /opt/MB1/MMDVM_Bridge.ini (Change to /opt/MB1)
Restart=on-abort
 
[Install]
WantedBy=multi-user.target

Modifiy the second mb service to point to the /opt/mb2/

Now go to /opt/mb2/DVSwitch.ini and modify it to point to a different set of ports than /opt/mb1/DVSwitch.ini. /opt/mb1/DVSwitch.ini can remain as is. If you don't do this you will likely get a "Cannot open port" error when you start the mb2 service and mb2 will fail. 

Finally:
systemctl enable mb1
systemctl start mb1
systemctl status mb1

if it's running then:
systemctl enable mb2
systemctl start mb2
systemctl status mb2

If both of your services start successfully then the problem is no longer with MB and I would look at the ports that are defined in DVSwitch and MB. We can go there next if this doesn't solve your issue.

K7WBY/Steve


Re: DVSwitch Server release date

Steve N4IRS
 


DVSwitch Server release date

Steve N4IRS
 

DVSwitch Server will be available for download at 12:00 UTC today.


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 

 in another way i have a nxdn reflector.he is linked to my ysfreflector and when i use my openspot2 nxdn to ysf they work flawlesly and no crash from mb1 or mb2


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 
Edited

Maybe i can try to change the  in each mb path to start ex mmdvmbridge1 and 2


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 

I create  new .service for each mb .mb1 and mb2 differenf path .in and .ini2


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 

Yes . I stop everything disable them and built my .ini
I already try to change rebuilt purge reinstall  update bimary try many other port . With the same issue. 


Re: #mmdvm_bridge #mmdvm_bridge

k7wby@...
 

You have two instances of MB created in two separate folders. Did you disable the original mmdvm_bridge service and create the two new ones that are needed for the two separate bridges?


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 

i just tried again on the old server and its caused the same problem


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 

Yes but recently mooved the ysfreflector on datacenter. The reason why now we seen this is issue is because  about 2 weeks ago i just close my bridge with brandmeister and all of this users  now pass by the dmr2ysf to reach my network


Re: #mmdvm_bridge #mmdvm_bridge

Steve N4IRS
 

You do not need YSFGateway. Are you saying this has been working over a year with ysf2dmr clients?

On 10/30/20 4:21 PM, swinger72@... wrote:
i point each mbridge directly to the ysfreflector ip .mb2 is local in the same server .my question is it is possible that is because i do not pass by ysfgateway? I have been working this way for 1 year now


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 

i point each mbridge directly to the ysfreflector ip .mb2 is local in the same server .my question is it is possible that is because i do not pass by ysfgateway? I have been working this way for 1 year now


Re: #mmdvm_bridge #mmdvm_bridge

Steve N4IRS
 

OK

On 10/30/2020 2:11 PM, swinger72@... wrote:
No im running in the same server as my ysfreflector


Re: #mmdvm_bridge #mmdvm_bridge

swinger72@...
 

No im running in the same server as my ysfreflector


Re: #mmdvm_bridge #mmdvm_bridge

Steve N4IRS
 

Are you using YSFGateway with mbridge2? I see this:

[System Fusion Network]
Enable=1
LocalAddress=0
LocalPort=3200
GatewayAddress=127.0.0.1
GatewayPort=42000
Debug=1

On 10/30/2020 2:03 PM, swinger72@... wrote:
mbridge2.ini
[General]
Callsign=va2tb
Id=302252804
Timeout=180
Duplex=0

[Info]
RXFrequency=000000000
TXFrequency=000000000
Power=1
Latitude=41.7333
Longitude=-50.3999
Height=0
Location=
Description=MMDVM_Bridge
URL=https:

[Log]
# Logging levels, 0=No logging, 1=Debug, 2=Message, 3=Info, 4=Warning, 5=Error, 6=Fatal
DisplayLevel=1
FileLevel=2
FilePath=/var/log/MMDVM_Bridge2
FileRoot=MMDVM_Bridge

[DMR Id Lookup]
File=/opt/DMRIds.dat
Time=24

[NXDN Id Lookup]
File=/var/lib/mmdvm/NXDN.csv
Time=24

[Modem]
Port=/dev/null
RSSIMappingFile=/dev/null
Trace=0
Debug=0

[D-Star]
Enable=0
Module=B

[DMR]
Enable=0
ColorCode=1
EmbeddedLCOnly=1
DumpTAData=0

[System Fusion]
Enable=1

[P25]
Enable=0
NAC=293

[NXDN]
Enable=0
RAN=1
Id=12345

[D-Star Network]
Enable=0
GatewayAddress=127.0.0.1
GatewayPort=20010
LocalPort=20011
Debug=0

[DMR Network]
Enable=0
Address=hblink.dvswitch.org
Port=62031
Jitter=360
Local=62032
Password=passw0rd
# for DMR+ see https://github.com/DVSwitch/MMDVM_Bridge/blob/master/DOC/DMRplus_startup_options.md
# for XLX the syntax is: Options=XLX:4009
# Options=
Slot1=0
Slot2=1
Debug=0

[System Fusion Network]
Enable=1
LocalAddress=0
LocalPort=3200
GatewayAddress=127.0.0.1
GatewayPort=42000
Debug=1

[P25 Network]
Enable=0
GatewayAddress=127.0.0.1
GatewayPort=42020
LocalPort=32010
Debug=0

[NXDN Network]
Enable=0
#LocalAddress=127.0.0.1
Debug=0
LocalPort=14021
GatewayAddress=127.0.0.1
GatewayPort=14020

Dvswitch
; MMDVM_Bridge export / import configuration file.
;   This file should be placed along side of MMDVM_Bridge or you can supply
;   an absolute path in the DVSWITCH environment variable, e.g:
;   DVSWITCH=/etc/MMDVM_Bridge/DVSwitch.ini
;   before executing MMDVM_Bridge
;
; Another method to set the enviorment variable is to use the systemd unit file
; by adding:
; Environment=DVSWITCH=/etc/MMDVM_Bridge/DVSwitch.ini
; to /lib/systemd/system/mmdvm_bridge.service

; Configure the Quantar Repeater Partner
; Note that the TX and RX ports are already reversed for MMDVM_Bridge <--> Quantar_Bridge
[QUANTAR]
address = 0.0.0.0               ; Address to send IMBE TLV frames to (export)
txPort = 34103                  ; Port to send IMBE TLV frames to (export)
rxPort = 34100                  ; Port to listen for IMBE TLV frames on (import)
quantarPort = 1994              ; HDLC frames To/From the Quantar repeater
debug = 0                       ; Debug 0 = off, 1 = on (adds lots of additional messages)
logLevel = 2                    ; Logging levels, 0=No logging, 1=Debug, 2=Message, 3=Info, 4=Warning, 5=Error, 6=Fatal
logFilePath = /var/log/dvswitch/Quantar_Bridge.log

; Configure the DMR Partner
; Audio format is AMBE 72 bit
[DMR]
address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
txPort = 31100                  ; Port to send AMBE TLV frames to (export)
rxPort = 31103                  ; Port to listen on (import)
slot = 2                        ; Export slot
exportTG = 0                    ; Which TG to export
hangTimerInFrames = 0        ; Use 50 for 3 seconds of hang time (3000 / 60)
talkerAlias = %callsign %location %description ; Get callsign location and description from MMDVM_Bridge.ini

; Configure the D-Star Partner
; Audio format is AMBE 48 bit (DSAMBE)
[DSTAR]
address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
txPort = 32100                  ; Port to send AMBE TLV frames to (export)
rxPort = 32103                  ; Port to listen on (import)
fallbackID = 1234567            ; In case we can not find a valid DMR id in the database, export this one
exportTG = 9                    ; Which TG to export
slot = 2                        ; Export slot
RemotePort = 54321        ; Port to send Gateway commands to
message = %location %description ; Get location and description from MMDVM_Bridge.ini

; Configure the NXDN Partner
; Audio format is AMBE 72 bit
[NXDN]
address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
txPort = 33100                  ; Port to send AMBE TLV frames to (export)
rxPort = 33103                  ; Port to listen on (import)
fallbackID = 1234567            ; In case we can not find a valid DMR id in the database, export this one
nxdnFallbackID  = 12345         ; Use this ID when the input DMR ID is not found in the database
translate = 1234=4321           ; Translate NXDN TG < -- > DMR TG (bidirectional)
slot = 2                        ; Export slot
RemotePort = 6075        ; Port to send Gateway commands to

; Configure the P25 Partner
; Audio format is IMBE 88 bit
[P25]
address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
txPort = 34100                  ; Port to send AMBE TLV frames to (export)
rxPort = 34103                  ; Port to listen on (import)
slot = 2                        ; Export slot
RemotePort = 6074        ; Port to send Gateway commands to

; Configure the Yaesu Fusion Partner
; Audio format is AMBE 72 bit
; Audio format is IMBE 88 bit
[YSF]
address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
txPort = 43500                  ; Port to send AMBE TLV frames to (export)
rxPort = 42500                  ; Port to listen on (import)
txWidePort = 43500        ; Port to send IMBE TLV frames to for YSFw (export)
fallbackID = 1234567            ; In case we can not find a valid DMR id in the database, export this one
exportTG = 1234                    ; Which TG to export
slot = 2                        ; Export slot
RemotePort = 6073        ; Port to send Gateway commands to

2461 - 2480 of 9797