Closed M6NBP closed 6 years ago
Just to check, have you tried any other DMR radio (MD380, GD77, Motorola, Hytera)?. When you work with a MMDVM board modems and analog radios, several things could produce problems, specially deviation or RX calibration, bad wiring (not proper shielding or long cables), RF interference, bad duplexer adjustments, etc.
Hi All work. But saying that, reports of Hytera after the last firmware update having the same issue. This is happening to many and not just me. This is why I posted
Duplex boards
Very difficult DMR activation ("repeater fail" error): disable mode scanning, select just DMR mode. Not DMR activation ("repeater fail" error) with MD380, Ailunce HD1 or some other radios: increase DMR deviation to 55 % or 60 %. RX timeout: this is due to TX and RX clock differences, which does not have easy solution. Be sure your firmware version is >= 1.4.7, which minimizes this problem. https://github.com/juribeparada/MMDVM_HS
Sorry but that "Know issue" is ONLY for MMDVM_HS devices that uses ADF7021. MMDVM board like STM32_DVM_PiHat V3 does not have that problem.
Well am sorry to tell you that the Anytone 868 with the STM32_DVM_PiHat V3 (BLUE) Board on Pi-Star and Firmware MMDVM 2018023 does have an issue.
I have it setup and I stand by my first post
I contacted Steve Zingman and it was he that said I should post in this group
I only said that because the issue that you mention about MMDVM_HS duplex board (ADF7021) has nothing to do with MMDVM, because they use a complete different hardware. However, the "repeater fail" error is a very common problem, and can be produced for different sources, then is easy to confuse the real cause. I have also a Anytone 868 and I don't have any repeater activation problem with my MMDVM repeater (with ZUM MMMDVM-Pi board, STM32F446). That's why my suggestion to check your hardware setup/calibration first.
All has been tested. Like I said others have been reporting the same issues with there Anytones and accessing repeaters using the same boards .
If I leave around a 5 second pause before I TX then I have a better chance of getting in.
But I should not have to do that.
I have also been told the Hytera 857 after the latest firmware was loaded in the radio had the same issue. The person I talked with fixed the issue by rolling the firmware back a version.
Then it looks more a Anytone firmware issue. I need to see my radio firmware version, probably I am not using the latest one.
The fact that it is happening to other radios as well as the Aaytone is an issue. Antone say they can not replicate. But saying that I bet they do not have the repeater Hardware to even try and find the issue.
Others now posting on this group
(https://groups.yahoo.com/neo/groups/mmdvm/conversations/topics/17718)
I can't also replicate: I tested again now, several PTTs, no pauses (and also some with pause, just in case), with Anytone 868UV with latest firmware (2.32, http://www.connectsystems.com/software/software%20D868UV.htm), and works fine, I couldn't get a single handshake error, after several minutes of testing. Using always my MMDVM repeater (duplex mode) with ZUM MMDVM-Pi modem board (STM32F446, like STM32_DVM_PiHat V3). After this, I really don't think we have a MMDVM's firmware problem, and also we don't have a radio firmware problem in this case.
The fact that we now have a report of Motorola radios doing the same says the issue is real. Copy from a post and a very Repeatable person as well
"THis problem has existed for quite some time. My Motorola's have always had this problem talking to HomeBrew repeaters.
Corey N3FE"
A post from Alan M0AQC https://groups.yahoo.com/neo/groups/mmdvm/conversations/topics/17747
juribeparada You have to do it after you have received someone talking.
If you just PTT TX it will connect most times. But as sure as you want to talk it is that time it has not.
We might have a fix TX Hang time is 4 Been told to change to 10 They say this should sort it out
I will test tomorrow and let you all know if it works
I had the same problem with my Anytone and my MD380 and seem to have solved it by changing the DMR TX Hang time in the expert mode to 3 second or less. It was originally set at 3 seconds and I changed it to 4 seconds for some reason (I think I just wanted a longer hand time), I don't remember why for sure or when. Anyway, I changed it to 1 second 5 days ago and it's been working fine since the change.
TX Hang time at 10 is working if I follow someone. But I am finding if I have not TXed for a while I am not getting back in on the 1st PTT
I will try the 1 second and see if that makes any difference
VK4TUX posted this on another group to me Years ago ~2015/2016 on duplex (repeater) mmdvm use I discovered a DMR 10s TX hangtime combined with 10s mode hangtime was the optimum setup, with no dmr key issues between overs, as it was already txing, waiting for the rx to fill empty slots. This is why a mmdvm repeater used for DMR should have a 100% duty rating/setup on the transmitter setup. Transmit may last for many minutes or hours on a busy system on both time slots. I still use these settings today. Heatsinks may be useful on the TX 7021 chip if too hot to the touch (around ~55 deg C > threshold of pain)
So far I can TX in every time with the Anytone and it seams to be working. I will test it out all day and let you know how it goes
I have been using for a few days now and it seams to be working 99.99% of the time.
VK4TUX settings is the best so far :)
See below (Only change the ones he has marked)
In pistar you can do via ssh login > rpi-rw > sudo nano /etc/mmdvmhost
to ;
[General] Callsign=xxxxxxxx Id=xxxxxxx Timeout=600 Duplex=1 ModeHang=10 <<< added, This acts for all modes not otherwise defined below ;
Display=None Daemon=1
[D-Star] Enable=1 Module=B SelfOnly=0 AckReply=1 AckTime=750 ErrorReply=1 RemoteGateway=0
[DMR] Enable=1 Beacons=0 BeaconInterval=60 BeaconDuration=3 ColorCode=1 SelfOnly=0 EmbeddedLCOnly=1 DumpTAData=0 CallHang=0 TXHang=10
[System Fusion] Enable=1 LowDeviation=0 SelfOnly=0 TXHang=4 RemoteGateway=0
[P25] Enable=1 NAC=293 SelfOnly=0 OverrideUIDCheck=0 RemoteGateway=0
[NXDN] Enable=1 RAN=1 RemoteGateway=0 SelfOnly=0
[D-Star Network] Enable=1 GatewayAddress=127.0.0.1 GatewayPort=20010 LocalPort=20011 Debug=0
[DMR Network] Enable=1 Address=127.0.0.1 Port=62031 Local=62032 Jitter=360 Password="none" Slot1=0 Slot2=1 Debug=0
[System Fusion Network] Enable=1 LocalAddress=127.0.0.1 LocalPort=3200 GatewayAddress=127.0.0.1 GatewayPort=4200 Debug=0
[P25 Network] Enable=1 GatewayAddress=127.0.0.1 GatewayPort=42020 LocalPort=32010 Debug=0
[NXDN Network] Enable=1 LocalAddress=127.0.0.1 LocalPort=14021 GatewayAddress=127.0.0.1 GatewayPort=14020 Debug=0
You appear to be operating out of band! Just an observation.
Dom G7NPW
On 13 Oct 2018, at 12:55 pm, M6NBP notifications@github.com wrote:
I have been using for a few days now and it seams to be working 99.99% of the time.
VK4TUX settings is the best the so far :)
See below
*In pistar you can do via ssh login > rpi-rw > sudo nano /etc/mmdvmhost
to ;
[General] Callsign=M6NBP Id=xxxxxxx Timeout=600 Duplex=1 ModeHang=10 <<< added, This acts for all modes not otherwise defined below ;
RFModeHang=300 <<< disabled with
NetModeHang=300 <<< disabled with
Display=None Daemon=1
[Info] RXFrequency=445000000 TXFrequency=440000000 Power=1 Latitude=00.00 Longitude=00.00 Height=0 Location="LV" Description="" URL=http://www.qrz.com/db/M6NBP
[Log] DisplayLevel=0 FileLevel=2 FilePath=/var/log/pi-star FileRoot=MMDVM
[CW Id] Enable=0 Time=10
[DMR Id Lookup] File=/usr/local/etc/DMRIds.dat Time=24
[NXDN Id Lookup] File=/usr/local/etc/NXDN.csv Time=24
[Modem] Port=/dev/ttyACM0 TXInvert=1 RXInvert=0 PTTInvert=0 TXDelay=100 RXOffset=0 TXOffset=0 DMRDelay=0 RXLevel=50 TXLevel=50 RXDCOffset=0 TXDCOffset=0 RFLevel=100 CWIdTXLevel=50 D-StarTXLevel=50 DMRTXLevel=50 YSFTXLevel=50 P25TXLevel=50 NXDNTXLevel=50 RSSIMappingFile=/usr/local/etc/RSSI.dat Trace=0 Debug=0
[Transparent Data] Enable=0 RemoteAddress=127.0.0.1 RemotePort=40094 LocalPort=40095
[UMP] Enable=0 Port=/dev/ttyACM1
[D-Star] Enable=1 Module=B SelfOnly=0 AckReply=1 AckTime=750 ErrorReply=1 RemoteGateway=0
ModeHang=20 <<<< disabled
[DMR] Enable=1 Beacons=0 BeaconInterval=60 BeaconDuration=3 ColorCode=1 SelfOnly=0 EmbeddedLCOnly=1 DumpTAData=0 CallHang=0 TXHang=10
ModeHang=20 <<<< disabled
[System Fusion] Enable=1 LowDeviation=0 SelfOnly=0 TXHang=4 RemoteGateway=0
ModeHang=20 <<<< disabled
[P25] Enable=1 NAC=293 SelfOnly=0 OverrideUIDCheck=0 RemoteGateway=0
ModeHang=20 <<<< disabled
[NXDN] Enable=1 RAN=1 RemoteGateway=0 SelfOnly=0
ModeHang=20 <<<< disabled
[D-Star Network] Enable=1 GatewayAddress=127.0.0.1 GatewayPort=20010 LocalPort=20011 Debug=0
ModeHang=10 <<<< disabled
[DMR Network] Enable=1 Address=127.0.0.1 Port=62031 Local=62032 Jitter=360 Password="none" Slot1=0 Slot2=1 Debug=0
ModeHang=20 <<<< disabled
[System Fusion Network] Enable=1 LocalAddress=127.0.0.1 LocalPort=3200 GatewayAddress=127.0.0.1 GatewayPort=4200 Debug=0
ModeHang=20 <<<< disabled
[P25 Network] Enable=1 GatewayAddress=127.0.0.1 GatewayPort=42020 LocalPort=32010 Debug=0
ModeHang=20 <<<< disabled
[NXDN Network] Enable=1 LocalAddress=127.0.0.1 LocalPort=14021 GatewayAddress=127.0.0.1 GatewayPort=14020 Debug=0
ModeHang=20 <<<< disabled
[TFT Serial] Port=/dev/ttyAMA0 Brightness=50
[HD44780] Rows=2 Columns=16 Pins=11,10,0,1,2,3 I2CAddress=0x20 PWM=0 PWMPin=21 PWMBright=100 PWMDim=16 DisplayClock=1 UTC=0
[Nextion] Port=/dev/ttyAMA0 Brightness=50 DisplayClock=1 UTC=0 ScreenLayout=0 IdleBrightness=20
[OLED] Type=3 Brightness=0 Invert=0 Scroll=0
[LCDproc] Address=localhost Port=13666 DimOnIdle=0 DisplayClock=1 UTC=0
[POCSAG] Enable=0 Frequency=439987500
[POCSAG Network] Enable=0 LocalAddress=127.0.0.1 LocalPort=3800 GatewayAddress=127.0.0.1 GatewayPort=4800 ModeHang=5 Debug=0 *
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
It was just an example I have now edited the document down and only showing relevant parts
Hi Not sure if this is the correct place to post this, but will give it a try.
STM32_DVM_PiHat V3 (BLUE) Board on Pi-Star Anytone 868 radios having issues with timing and not getting into the repeater. This was first seen by myself on the Duplex Hotspots and was finally fixed with a new firmware update a few months back. ( Firmware HS_Hat V 1.4.8 ) Also on the Duplex board it would drop a TX at around 60sec. I have not had a chance to fully test this on this board.
With the radio you have to key up a few times to get in. Leaving a long pause 3 to 5 seconds always seam to help
This issue has been talked about over the last few days in the UK on Tg2350 Ref4400 and this is why I am posting this to see if it can be fixed.