travisgoodspeed / md380tools

Python tools and patched firmware for the TYT-MD380
805 stars 244 forks source link

Admit criteria not respected #120

Open ae5au opened 8 years ago

ae5au commented 8 years ago

The factory firmware doesn't seem to respect admit criteria selections (at least for DMR channels).

Admit criteria of "Always" should always allow transmit. This selection works properly.

"Color Code" should only allow transmit if there isn't another signal being received on the color code and time slot that the radio has programmed for that channel. In my testing (and that of others), it seems to behave just like "Always". This is the largest problem as it allows you to transmit on a talk group that is free while there is traffic on another talk group that uses the same time slot.

"Channel Free" should not allow transmit if there is any other signal on the channel. I'm not sure if this should require the signal to be on the same time slot as programmed or not, but I would think that it should inhibit if any signal is being received...analog or digital. In my limited testing, it does inhibit transmit if there is activity on analog or a different color code, but NOT if there is traffic on the same color code.

dg9vh commented 8 years ago

I can confirm this issue and firmware behavior. @travisgoodspeed I think it should be tagged as enhancement.

m0ivq commented 8 years ago

2.034 and earlier stock firmware has this issue. Haven't yet tested on 3.008

travisgoodspeed commented 8 years ago

Any word on whether this has been fixed in the 3.x series?

dg9vh commented 8 years ago

@travisgoodspeed I just tried plain unpatched stock D003.008.bin - the issue is still existing, it is still not respecting admit-criteria color code... I can transmit over others...

xSmurf commented 7 years ago

So I most definitely remember this working from my MD390G pre flashing. But I've now reverted back to both s13.020 and s13.012 and the politeness feature is still gone. I've now talked to at least four OMs who say they have noticed the same thing. I've replicated this in both simplex and repeater mode, and with the Admit Criteria both as Color Code and Channel Free. I've tried multiple code plugs as well, including a completely fresh one from the latest official MD390G CPS.

I'm at a loss, I swear it worked with the radio OOTB.

dg9vh commented 7 years ago

Be sure: admit criteria never worked correctly. 100% Kim DG9VH Am 18.10.2016 05:23 schrieb xSmurf notifications@github.com:So I most definitely remember this working from my MD390G pre flashing. But I've now reverted back to both s13.020 and s13.012 and the politeness feature is still gone. I've now talked to at least four OMs who say they have noticed the same thing. I've replicated this in both simplex and repeater mode, and with the Admit Criteria both as Color Code and Channel Free. I've tried multiple code plugs as well, including a completely fresh one from the latest official MD390G CPS.

I'm at a loss, I swear it worked with the radio OOTB.

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

i2NDT commented 7 years ago

any news on the "admit criteria" issue?

travisgoodspeed commented 7 years ago

No news, but pull requests are always welcome.

i2NDT commented 7 years ago

tnx Travis for the answer. but it sounds strange to me that the admit criteria doesn't work! isn't it one of the mandatory features a dmr radio must fulfill to be accepted as DMR?

Randy-W0RDR commented 7 years ago

My user group (about 41 people in Colorado) has noticed that the issue seems worse with the "tools" FW that it was on the original factory. It's there on both. We also noticed it was much worse on a MMDVM-Based repeater than on a genuine MotoTRBO (XPR 8300) - not sure if this helps with diagnosis...

ghost commented 7 years ago

Without a properly working admit criteria, sending periodic GPS frames will create interference on repeaters. This bug should be prioritary.

IZ4HUF commented 7 years ago

Now there is a new firmware update from Tytera to solve the Admit Criteria, the new version is 013.34. Please visit: http://www.tyt888.com/?mod=download ( find "MD-380 SOFTWARE 0321")

nivex commented 6 years ago

On my radio the Admit Criteria is being respected w.r.t. a call in progress on another talkgroup. That is if I'm on Local and someone else is chatting away on TAC 310 (both on the same timeslot), I will get bonked when I try to key up.

Where this fails is if there is a call on my talkgroup with audio actively being processed, I can still key up right on top of it.

Of potential note: I just upgraded to CPS version 1.34 and there is a new channel setting In Call Criteria with options:

I have set this on an active channel here and sadly I was still able to key up over top of an ongoing call. My guess is it still needs some bits from the newer firmware mentioned by IZ4HUF.

For reference my MD380Tools version is 2017-06-11.

PD0DIB commented 6 years ago

Think it 8s not custom Firmware related, that feature is handled by the CPS.. I'm using CPS 1.37 and have in the Admin creteria Channel free and the other is follow admin creteria. That's working ok 73 PD0DIB , Rob

==================== met vriendelijke groet | Kind Regards, Rob van Rheenen

Op 29 nov. 2017 12:21 a.m. schreef "Kevin Otte" notifications@github.com:

On my radio the Admit Criteria is being respected w.r.t. a call in progress on another talkgroup. That is if I'm on Local and someone else is chatting away on TAC 310 (both on the same timeslot), I will get bonked when I try to key up.

Where this fails is if there is a call on my talkgroup with audio actively being processed, I can still key up right on top of it.

Of potential note: I just upgraded to CPS version 1.34 and there is a new channel setting In Call Criteria with options:

  • Always
  • Follow Admit Criteria

I have set this on an active channel here and sadly I was still able to key up over top of an ongoing call. My guess is it still needs some bits from the newer firmware mentioned by IZ4HUF.

For reference my MD380Tools version is 2017-06-11.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/travisgoodspeed/md380tools/issues/120#issuecomment-347697779, or mute the thread https://github.com/notifications/unsubscribe-auth/AXfxPzfiE8wYbJCQa9r38m62ih1I6t_Fks5s7JVxgaJpZM4Ifvtp .

tristantech commented 6 years ago

D013.34 is for MD380 models with the new vocoder (and seems to work for me), but does anybody have firmware for an old-vocoder MD380 that has the admit criteria fix?

i2NDT commented 6 years ago

I am interested as well!!! 

 i2NDT's Web Site i2NDT's Grabber Compendium

Il Martedì 24 Luglio 2018 23:07, Tristan Honscheid <notifications@github.com> ha scritto:

D013.34 is for MD380 models with the new vocoder (and seems to work for me), but does anybody have firmware for an old-vocoder MD380 that has the admit criteria fix?— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

JSB2000 commented 5 years ago

What's the fix status on this issue? My MD380 was respecting the admit criteria setting on past updates of the firmware but just noticed that it was no longer doing so on recent versions.

Currently running e0e885a CP ver 1.34 as pulled/installed with glv/glvflash on tytV4 virtualbox. No idea what "Dxxx.xx" version that's supposed to equate to.