g4klx / MMDVM

The firmware for the MMDVM (Multi-Mode Digital Voice Modem)
GNU General Public License v2.0
473 stars 189 forks source link

Anytone 868 Handshake #196

Closed M6NBP closed 6 years ago

M6NBP commented 6 years ago

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.

juribeparada commented 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.

M6NBP commented 6 years ago

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

M6NBP commented 6 years ago

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

juribeparada commented 6 years ago

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.

M6NBP commented 6 years ago

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

M6NBP commented 6 years ago

I contacted Steve Zingman and it was he that said I should post in this group

juribeparada commented 6 years ago

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.

M6NBP commented 6 years ago

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.

M6NBP commented 6 years ago

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.

juribeparada commented 6 years ago

Then it looks more a Anytone firmware issue. I need to see my radio firmware version, probably I am not using the latest one.

M6NBP commented 6 years ago

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.

M6NBP commented 6 years ago

Others now posting on this group

(https://groups.yahoo.com/neo/groups/mmdvm/conversations/topics/17718)

juribeparada commented 6 years ago

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.

M6NBP commented 6 years ago

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"

M6NBP commented 6 years ago

A post from Alan M0AQC https://groups.yahoo.com/neo/groups/mmdvm/conversations/topics/17747

M6NBP commented 6 years ago

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.

M6NBP commented 6 years ago

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

WB8GRS commented 6 years ago

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.

M6NBP commented 6 years ago

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

M6NBP commented 6 years ago

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

M6NBP commented 6 years ago

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 ;

RFModeHang=300 <<< disabled with #

NetModeHang=300 <<< disabled with #

Display=None Daemon=1

[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

g7npw commented 6 years ago

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.

M6NBP commented 6 years ago

It was just an example I have now edited the document down and only showing relevant parts