Run an update / upgrade or two to bring you up to RC6. Where A fair few bugs and patches were implemented.
Andrew M1DNS, (Mod)
YSF2DMR Issue
Re: YSF2DMR Issue
Andrew M1DNS.
Pi-star Admin Team.
Pi-star Admin Team.
Re: YSF2DMR Issue
I can confirm for myself that the issue is now resolved. I had been following this thread for a while and just updated to RC6 and it now passes the RX audio to my FT2DR while using the YSF2DMR mode. Thanks for the update.
Rob
Rob
Re: YSF2DMR Issue
Still dealing with the audio out issue. And a real Newbie to this stuff. (Read - "clueless") - but trying....
I actually have two Zumspots - both running Pi-Star 3.4.17.
Both say "ZUMspot RPi" - one is the Nextion 2.4 and the other is the OLED 1.3 (Both from HRO.)
My first question is - is there any significant difference in the hardware? Obviously the displays are different, but what about the basic motherboard? I can't figure out any way to even identify the hardware?
To continue
I'm using an FT2DR
I have Pi-Star setup for both YSF and YSF2DMR modes.
Second question - if I TX on my HT - what am I sending out over the Zumspot - YSF or YSF2DMR? Or Both? (The latter seems unlikely.)
And, of course, the third question - why am I not hearing any audio on the FT2?
I've seen 2 conflicting posts - one indicated he had updated to 4.x RC6 and it wasn't working - another indicated that fixed the problem?
If updating truly is the fix - how is that done - I assume there are some instructions out there somewhere?
Thanks in advance,
John, N6JCB
I actually have two Zumspots - both running Pi-Star 3.4.17.
Both say "ZUMspot RPi" - one is the Nextion 2.4 and the other is the OLED 1.3 (Both from HRO.)
My first question is - is there any significant difference in the hardware? Obviously the displays are different, but what about the basic motherboard? I can't figure out any way to even identify the hardware?
To continue
I'm using an FT2DR
I have Pi-Star setup for both YSF and YSF2DMR modes.
Second question - if I TX on my HT - what am I sending out over the Zumspot - YSF or YSF2DMR? Or Both? (The latter seems unlikely.)
And, of course, the third question - why am I not hearing any audio on the FT2?
I've seen 2 conflicting posts - one indicated he had updated to 4.x RC6 and it wasn't working - another indicated that fixed the problem?
If updating truly is the fix - how is that done - I assume there are some instructions out there somewhere?
Thanks in advance,
John, N6JCB
Re: YSF2DMR Issue
If your running two installations both using the same id connecting to the same server, that will cause you issues. Set them up using SSID's. Your id +01 02 03 04 etc. added to create a 9digit Id.
Also use a 2nd seperate id+ SSID in the id field in the YSF2DMR config panel.
1: no real difference, only the type of attached screens
2: You talk to YSF2DMR by selecting it. As you do any YSF reflector using the radios wires X link feature. When you select YSF2DMR you are talking YSF to the installation then the crossmode feature of MMDVM routes you to the DMR TG you have set in the config.
If you want to talk YSF to any other YSF reflector. Agn using the wires X link feature select the YSF reflector you want to link with, it'll connect there and you'll no longer be connected with the DMR TG.
You are calling the YSF2DMR, YSF2NXDN, or YSF2P25 cross modes the same way as calling a connection to a YSF reflector. When connected, your traffic is passed to the DMR / NXDN / P25 TG you have setup in the appropriate YSF2 config panel as 1s and 0s to the associated network. The RF path between radio and installation will always be YSF, C4FM.
3: Ensure your radio is set with the DGID of 00. Or have no other digital squelch set. Probably best to set the mode as DN and not have the radio choose the mode. (With obvious exception YSF2P25, as that requires the mode be set as VW)
Before working with cross modes it might be wise to ensure the radio/ installation works correctly with a simple YSF reflector. Ensuring you have any TX or Rx freq. offsets set correctly to ensure a reasonable (below 1.0% BER) or any such needed config setup to ensure both radio and install are working as one.
Andrew M1DNS, (Mod)
Also use a 2nd seperate id+ SSID in the id field in the YSF2DMR config panel.
1: no real difference, only the type of attached screens
2: You talk to YSF2DMR by selecting it. As you do any YSF reflector using the radios wires X link feature. When you select YSF2DMR you are talking YSF to the installation then the crossmode feature of MMDVM routes you to the DMR TG you have set in the config.
If you want to talk YSF to any other YSF reflector. Agn using the wires X link feature select the YSF reflector you want to link with, it'll connect there and you'll no longer be connected with the DMR TG.
You are calling the YSF2DMR, YSF2NXDN, or YSF2P25 cross modes the same way as calling a connection to a YSF reflector. When connected, your traffic is passed to the DMR / NXDN / P25 TG you have setup in the appropriate YSF2 config panel as 1s and 0s to the associated network. The RF path between radio and installation will always be YSF, C4FM.
3: Ensure your radio is set with the DGID of 00. Or have no other digital squelch set. Probably best to set the mode as DN and not have the radio choose the mode. (With obvious exception YSF2P25, as that requires the mode be set as VW)
Before working with cross modes it might be wise to ensure the radio/ installation works correctly with a simple YSF reflector. Ensuring you have any TX or Rx freq. offsets set correctly to ensure a reasonable (below 1.0% BER) or any such needed config setup to ensure both radio and install are working as one.
Andrew M1DNS, (Mod)
Andrew M1DNS.
Pi-star Admin Team.
Pi-star Admin Team.
Re: YSF2DMR Issue
I installed a bridge using ysf2dmr on 4.1.0.rc6. It is located about 5 miles from a Fusion Repeater. The RF frequencies are opposite to the repeater such that the hotspot sees the repeater as a mobile/portable radio. This system works fine as intended for local repeater users.
However, when a reflector is connected to the repeater, the hotspot(YSF2DMR) no longer sends packets to the intended dmr talk group, but instead sends them out to a tg number equivalent to the reflector ID, and sometimes not even the programmed server. If a net is in progress on this reflector, this bridge becomes a cause of interference. I have had to take it down pending an appropriate fix.
I see multiple reports on this forum that the they don't hear return traffic but see the light on the radio. This is a clear symptom of the traffic being redirected to another TG. If you have promiscuous mode, or digital monitor, you can find the actual TG the traffic is on.
Is this module YSF2DMR still a work in progress. The last revision on the YSF2DMR code was 9 months ago.
If there is someone working with this code, please let me know. I modified the DMRGateway to add Network 4, and 5 and added isolation to only allow one network to be active at any given time. I am willing to dive into this project as well, but only if no one else is in the mood to do so.
Phil VE3RD
However, when a reflector is connected to the repeater, the hotspot(YSF2DMR) no longer sends packets to the intended dmr talk group, but instead sends them out to a tg number equivalent to the reflector ID, and sometimes not even the programmed server. If a net is in progress on this reflector, this bridge becomes a cause of interference. I have had to take it down pending an appropriate fix.
I see multiple reports on this forum that the they don't hear return traffic but see the light on the radio. This is a clear symptom of the traffic being redirected to another TG. If you have promiscuous mode, or digital monitor, you can find the actual TG the traffic is on.
Is this module YSF2DMR still a work in progress. The last revision on the YSF2DMR code was 9 months ago.
If there is someone working with this code, please let me know. I modified the DMRGateway to add Network 4, and 5 and added isolation to only allow one network to be active at any given time. I am willing to dive into this project as well, but only if no one else is in the mood to do so.
Phil VE3RD
Re: YSF2DMR Issue
I have been looking at the YSF2DMR code. I have not figured it all out yet but have made some guesses as to what is happening.
If WiresX is enabled and there are three toggles involved in the .ini files, then wiresx has control of your hotspot setting the server and talk group. In my case the server was ok, but the TG ID was the same as the wiresX reflector that was in use. Luckily that TG was not assigned on the server
ie if your radio is set to DMR TG310 and wiresx has set return data to 21080, the your green light will indicate incoming traffic but you won't hear it until you tune to TG21080 or whatever TG wiresX is using.
In my application I need to stop incoming RF from going back out via RF. If some one could help and save me some time, I would really appreciate it.
My application is a bridge. I have a duplex hotspot on a cheap chinese duplexer into an X-50 vertical at 30 feet (5 Miles from the Fusion Repeater) The signal path is good.
RF to and from my repeater is translated to a fixed DMR Server and fixed talk group. I have all the toggles off to lock DMR to the designated sever/TG. The idea is that incoming net data goes out RF and incoming RF data goes out to the NET. No return data packets to be sent out on the incoming mode.
However the received YSF RF data packet is being sent back out RF causing looping on the repeater. I need to stop this and am currently trying to hack the YSF2DMR.cpp code to stop this. Any assistance would be greatly appreciated. Given enough time I will figure it out.
Phil VE3RD
[email protected]
If WiresX is enabled and there are three toggles involved in the .ini files, then wiresx has control of your hotspot setting the server and talk group. In my case the server was ok, but the TG ID was the same as the wiresX reflector that was in use. Luckily that TG was not assigned on the server
ie if your radio is set to DMR TG310 and wiresx has set return data to 21080, the your green light will indicate incoming traffic but you won't hear it until you tune to TG21080 or whatever TG wiresX is using.
In my application I need to stop incoming RF from going back out via RF. If some one could help and save me some time, I would really appreciate it.
My application is a bridge. I have a duplex hotspot on a cheap chinese duplexer into an X-50 vertical at 30 feet (5 Miles from the Fusion Repeater) The signal path is good.
RF to and from my repeater is translated to a fixed DMR Server and fixed talk group. I have all the toggles off to lock DMR to the designated sever/TG. The idea is that incoming net data goes out RF and incoming RF data goes out to the NET. No return data packets to be sent out on the incoming mode.
However the received YSF RF data packet is being sent back out RF causing looping on the repeater. I need to stop this and am currently trying to hack the YSF2DMR.cpp code to stop this. Any assistance would be greatly appreciated. Given enough time I will figure it out.
Phil VE3RD
[email protected]
Re: YSF2DMR Issue
what is the fix for the no audio in ysftodmr bug I am using 4.1.0 rc7 and can see activity but can't hear it
Re: YSF2DMR Issue
出现这种情况是因为4.1.0 有bug，固件换成3.4.17后就没有这个问题，已经通过测试。