search

travisgoodspeed / md380tools

Python tools and patched firmware for the TYT-MD380
804 stars 245 forks source link

Newer MD380 radios with new vocoder seem to require D13.34 firmware #875

Closed driviera closed 5 years ago

driviera commented 6 years ago

This is not my radio, but I've helped troubleshoot two users in the KD4Z Toolkit group on Facebook, and I can try to get more details once this issue is documented here.

One user reported that digital calls do not disconnect at the end of the call, but linger for several seconds; the other reported that the radio reboots upon RX of a digital call. The only way to obtain a working radio is to revert to the stock D13.34 firmware from TYT. The radio ships with D13.34; MD380Tools appears to be an incompatible downgrade to D13.20.

In July 2017, D13.34 was added to the download list in commit af7b151, but is not yet patched in. Therefore, users who purchase the newest versions of MD380 with the newest vocoders seem to require the D13.34 firmware, and are unable to use MD380Tools. They have tried safe flash environments and various troubleshooting, and the only working method is the stock D13.34 firmware.

I don't know if this user who reported the rebooting radio is a Github user (so he can provide more details about the radio on this issue), but I'd like to let him know one way or another if D13.34 will be supported in the future.

travisgoodspeed commented 6 years ago

Where can a fellow reliably buy a radio that suffers from this problem? It's really hard to diagnose these problems without being able to reproduce them.

driviera commented 6 years ago

I've directed this person on Facebook to this Github issue, and asked if it's UHF or VHF; I realize it's vague at this point, but it's not the first radio that's presented with a vocoder version issue. This issue is here now to gather this information and I'll try to direct the affected users here to provide first-hand information. I'll ask his source as well.

bg4czu commented 6 years ago

My UHF firmware version is D14.044 and also does not support 380tool.

boydjd commented 6 years ago

@travisgoodspeed I bought mine from this seller on Amazon: https://www.amazon.com/gp/product/B01KNZD4ZO/

There is also a D014.004 FW version floating around that I have flashed onto this radio that came with D13.34.

Regardless, I had the same problems with random power cycling and a "quiet" radio.

If there are logs/dumps I can provide, let me know. Or I can just mail you my radio.

travisgoodspeed commented 5 years ago

Howdy y'all,

I bought a radio from @boydjd's link, serial number 1803A007777. It arrived with D13.034 firmware, but when I flashed it with my codeplug and the latest master branch of md380tools, I was unable to reproduce the error condition. Digital calls on 441 Simplex, TG99 correctly terminating when transmitting, and reception did not trigger a reboot.

Perhaps the bug depends upon something in the codeplug?

73 from Knoxville,

--Travis

KD4Z commented 5 years ago

@travisgoodspeed I purchased two fresh MD380's from "letsgetready" on ebay about a month ago and they both came with D014.004 and CP version 1.30 After flashing the current experimental in the 1st one, the "goes silent" issue is easily seen. [serial 1804R00156] (ref https://www.youtube.com/watch?v=qO03_XX--tQ ) When reflashing D014.004, the issue goes away. This radio reports Hardware Version "2.0" by the way. The 2nd radio I purchased is still virgin in the box. Do you want either one of these radios Travis? I'll send it to you.

travisgoodspeed commented 5 years ago

I'm sorry, but I still don't really understand what the symptoms of this bug are or how they might be reproduced. I don't even know if you fine folks are talking about the same bug, or different ones, and I don't know whether the bug is unique to md380tools or comes from the original Tytera firmware.

Could someone please write a detailed description of what the bug is, how to reproduce it in simplex mode, and whether it affects Tytera's firmware in D13.020?

bobbyvan76 commented 5 years ago

I think the issue is the new radios with firmware D13.034 and later (I have one myself) cannot use the MD380tools firmware.

travisgoodspeed commented 5 years ago

Once again:

What exactly doesn't work, and how can I reproduce this problem on my own D13.034 radio? Does the same problem occur in Tytera's D13.020 firmware, and does the problem occur with a clean codeplug?

bobbyvan76 commented 5 years ago

Ok, I want to help. I am fairly new to DMR. Do I need to load Tytera's D13.020 firmware and see if it all works? As well as try all with a clean codeplug? I really liked the features in the MD380tools firmware. I will download the D13.020 and wipe my radio and start from scratch. Will this help?

travisgoodspeed commented 5 years ago

Thanks! We should be able to fix the problem if the following questions are answered, in detailed writing. Most importantly, I need to be able to experiment the problem on in my own lab if I'm to find and patch the responsible code.

bobbyvan76 commented 5 years ago

I will work on this today. I do not have much else to do.

On Wed, Oct 10, 2018, 13:08 Travis Goodspeed notifications@github.com wrote:

Thanks! We should be able to fix the problem if the following questions are answered, in detailed writing. Most importantly, I need to be able to experiment the problem on in my own lab if I'm to find and patch the responsible code.

  • What exactly is the problem?
  • How exactly can I reproduce the problem in simplex mode on my radio that shipped with D13.034?
  • Does the problem also affect Tytera's D13.020 firmware?
  • Does the problem also affect a virgin codeplug?
  • Does anything else in the environment make it easy or hard to reproduce the problem?

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

KD4Z commented 5 years ago

Silent receive bug (the problem)

Given: New radios shipping with D013.034 or higher that are updated to experimental firmware, seem to put the receiver into standby after 5 seconds of inactivity. Any keyboard activity wakes it back up, only to go back to sleep after 5 seconds of inactivity.

Test OEM firmware manifests same issue, without experimental patches. (Short answer Yes)

Is is reproducible in simplex? Yes. Easy Procedure to reproduce below. Is it reproducible with OEM firmware? Yes Is it reproducible with OEM codeplug? Yes Is it reproducible on simplex? Yes

Hardware used: Two recently purchased Tyt MD-380 radios, that came out of box with D014.004 firmware, Codeplug version 1.30 One original, "Tytera" MD-380, approximately 3 years old.

Observed value for Hardware version reports different number after first fw write. When read with CPS 1.37, hardware version reports v05.01 in virgin radio, but v2.0 after that.

Radio #1: Control radio. Still Virgin. Has not been written to in any way. Has OEM as-shipped codeplug.

Radio #2: Test Mule radio. OEM Codeplug for tests, written from codeplug bin obtained from Radio #1

Radio #3: Original MD-380, Old enough to be branded "Tytera", not "Tyt"

OEM Firmware used:

D013.020 from (https://md380.org/firmware/orig/TYT-Vocoder-MD380-D13.20.bin) D014.004 from (https://www.farnsworth.org/dale/md380tools/original_firmware/D014.004.bin)

Tests:

Both radios have same, virgin OEM codeplug, set to channel 1 (Simplex) Radio #1 is used to transmit. md380-dfu is used to write fw and codeplug

Flash Radio #2 with D014.004

Works normally. Able to receive normally, after any time delay. Display is normal orientation. Not suprising, as radio was shipped with this fw.

Flash Radio #2 with D013.020

Display is upside down.
Power On:  Issue manifests 5 seconds after normal radio display is presented.  
Receives normally if RX occurs before 5 seconds.

Press any key (like "up arrow") to wake it up.
Normal operation occurs for 5 more seconds, then issue manifests again.

Display backlight time set for 5 secs.   Changed to other values, but no change in issue is noted.
The Green activity LED also does not illuminate when the issue is manifesting.
Issue also manifests when using repeater offsets.
Issue manifests with experimental firmware as well.

Flash Radio #2 back to D014.004 Normal operation and display resumes.

Flash Radio #3 to D014.004 This was a bust. Radio hangs at opening screen.

Flash Radio #3 to D013.020 This also was a bust! Radio still hung at opening screen.

Fortunately, and weirdly, flashing current experimental brought Radio #3 back into the land of the living. Phew.

d235j commented 5 years ago

@KD4Z can you flash a non-experimental D00x.xxx firmware version to radio #3? My guess is that this will make it functional.

D00x and D01x are different hardware versions — the encryption chip for the vocoder contains a different key. The experimental firmware patches the encryption out.

KD4Z commented 5 years ago

@d235j Sure. I just threw in that last test in to see if TYT had intended on making D014 backward compatible. Obviously not, without help. Since I didn't make note of the original firmware in Radio #3, it is a safe bet it's old hardware.

I just flashed D003.020 (https://md380.org/firmware/orig/TYT-TFT-MD380-D3.20.bin) and the radio seems to operate normally. We can use this radio as a baseline going forward, however it doesn't help resolve the issue we are discussing here!

KD4Z commented 5 years ago

@travisgoodspeed Now something from the "He's only mostly dead" dept. I was curious to see if there was anything useful in the syslog, so I flashed a recent experimental (150c1DE) into Radio "#2", put in my normal hotspot capable codeplug, and enabled USB logging, I then woke up TAC310 and started watching dmesgtail. Turns out, nothing interesting shows up differently than with an older hardware radio.

HOWEVER

After watching dmesg for a while, I realized the issue wasn't occurring, even after long delays. At first I thought it was due to md380_tool.py keeping the radio active...however just having USB logging enabled keeps the radio operational again..mostly. It seems to miss very short key ups, and the Green LED does not illuminate with RX activity, however it doesn't go completely into the dummy state and stay there.

If USB logging is disabled, the radio starts missing RX after 5 seconds again. The issue comes and goes when that option being toggled. Are you intrigued yet?

travisgoodspeed commented 5 years ago

@KD4Z Have you tried your new-hardware radio (number 2) with the official D013.034 firmware?

KD4Z commented 5 years ago

@travisgoodspeed Ok, I just put D013.034 on. It seems to be exhibiting the issue about 50% of the time. First, the LED doesn't illuminate on RX activity at all. Some Rx comes through, some doesn't All of the short kerchunks are missed. I'll leave it in there for a while to see if I can find a pattern, however it isn't hearing 100% that radio #3 hears with experimental fw.

travisgoodspeed commented 5 years ago

Are you receiving in simplex from Radio 1, or from a tower or hotspot on TAC310? If the latter, does the problem still occur in simplex mode?

KD4Z commented 5 years ago

That last pass was from a hotspot on simplex from TAC310. I just changed to a simplex channel and it appears to be approximately the same. It took 5 keys from radio "#1" before radio "#2" (still running D013.034) wakes up and hears the transmission. Then, after waiting 5 seconds it stops hearing again, and then 5-7 keyups later, it opened up again and started receiving. Wash-rinse-repeat.

KD4Z commented 5 years ago

@travisgoodspeed It looks like the c5000 chip isn't being awakened after being put to sleep. A user alerted me to his "fix" by forcing the countdown timer in irq_handlers (MD380_ADDR_DMR_POWER_SAVE_COUNTDOWN) from being allowed to decrement. That effectively keeps the chip from sleeping and DMR decoding works reliably again. You can see this is occurring as the little "s-meter" graphic stays active past 5 seconds with the hack in place.

However, that kills the battery saver routine. Current consumption jumps up from 57-62 ma (no backlight standby) to 130 ma constant. So, I believe the real issue is we aren't getting the signal to wake up the chip again. It seems to be related to why the activity LED doesn't get illuminated too. Do we have a mapping to tickle the chip to wakeup or a way to trace that ?

Neoakb commented 5 years ago

I hope to not bother, but I was wondering if there has been any progress on this issue? I got a md380 for christmas and would really like to be able to use the custom firmware as it has some damn nice features.

travisgoodspeed commented 5 years ago

I purchased a new radio that shipped with D13.034, but I've not been able to reproduce the problem. Does the issue happen on your radio?

Neoakb commented 5 years ago

Yup, I had to reflash to D014.004 (I tried using the custom firmware before seeing this issue had been brought up)

serial 1803AXXXXX (some removed)

travisgoodspeed commented 5 years ago

Can you give a better description of the problem, and the exact versions involved? Is stock D13.034 working or broke for you? Where did you purchase the radio?

-Travis

Neoakb commented 5 years ago

Sure, I received the md380 yesterday and the first thing I did was try to install the latest md380tools firmware. Was able to key my jumbospot with no problem, and I can see myself on the brandmeister net. I have been unable to hear anything though. Tried with a local repeater and the same thing.

Radio was purchased from amazon https://www.amazon.com/gp/product/B01KNZD4ZO/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

I installed D014.004 and while I can see I'm getting something (the led is green and the jumbospot shows someone is talking), I can't hear anything, nor does a name show up on the screen.

I tested analog today and that works just fine. Maybe it's a problem where it can't decode the DMR streams?

I've tried all the FW from here with no luck. Either upside-down screen, or it just doesn't seem to know it should receive. https://md380.org/firmware/bin/

Here's the FW that works best (shows the green LED) also contains my codeplug KE8KUX testing.zip

travisgoodspeed commented 5 years ago

Are you saying that D014.004 is also broken for you?

Neoakb commented 5 years ago

Yes. Analog works fine, but dmr doesn't seem to decode. The led turns green, but nothing happens on screen and no audio is heard.

travisgoodspeed commented 5 years ago

Folks, I wish you all well, but this issue tracker is for new bugs introduced by our patches. It is not a support forum for the MD380, nor a place to lodge complaints against the manufacturer's bugs.

Closing this issue, as I think three or four problems have been confused into a single ticket, and I've had no luck reproducing any of the descriptions after six months and two unnecessary radio purchases.

rich0 commented 5 years ago

FWIW when I had this issue I returned the radio to Amazon and just bought a new one from a different listing. If flashing the manufacturers most recent published firmware kills the radio, then it is defective in my book.

I'm sure they changed the design of the radio and sooner or later it may become impossible to get one that works with the md380tools firmware, but it seems like there are still lots of good ones floating around.

KD4Z commented 5 years ago

Very interesting that you can't reproduce this Travis. As I posted above months ago, all new radios that are shipped with D014.x, are unable to cope with any FW except D014.x With a patch to keep the decoder from going to sleep, they will work with the tools,, but as I previously posted, they consume over 100ma more in standby due to that patch. Analog is not functional however. The symptoms are simple. After about 5 secs, the radio will not detect inbound transmissions-- Analog or Digital. If you rotate an encoder, or tap a keyboard key, it wakes up until the station stops transmitting, then 5 seconds later, it's done. I still have that virgin 380 with D014 I offered to you months ago.

g7ukk commented 5 years ago

Hi, just received my MD380 and flashed with the mod. Code plug uploaded and I can hear traffic sometimes. I beleive I am also affected with the 5 second sleep. To confirm, top left signal symbol shows signal for 5 seconds, then goes to no signal. I press a button and the signal returns for 5 seconds. What do I do ?

travisgoodspeed commented 5 years ago

KD4Z kindly sent me a radio with the 5-second sleep problem. I'll be digging into it this Sunday, and opening a new Github issue for it as soon as I've reproduced it.

Until then, you should probably flash a D014.x firmware from the manufacturer to fix the issue.

Neoakb commented 5 years ago

Was wondering if you had any luck with this in the past few months. KD4Z's VM's tweak for the new version radios makes digital work, but not analog so I was hoping you'd be able to figure it out and I could have a fully functional radio. You and KD4Z seem to know what's what with these.

Thanks for your time and work on this!

jeromekeating commented 5 years ago

can it be something to do with the flashing process? I have the "no receive LED" and "doesn't wake from sleep" problems described above but it doesn't always happen. Radio #1 worked for the last few weeks using the 1.08 flash tool until I re-flashed it with the exact same one last night and it developed these problems. Radio #2 I just got yesterday and it showed the same problem after flashing. Then I tried using the 1.05 flash tool and funny enough Radio #2 seems to like that one, while Radio #1 still shows the same problem.

There's something else that's causing this, either something that randomly goes wrong during the flashing process, or something in the codeplug that's messing it up. Because the same radio that used to work now doesn't work on the same firmware. Wish I could provide better information.

PD0DIB commented 5 years ago

1.05 and 1.08 aren't using Travis code, they are fro Ty Weaver, not open sourced and not supported via Travis' github

==================== met vriendelijke groet | Kind Regards | 73 de PD0DIB, Rob van Rheenen

Op za 6 apr. 2019 19:01 schreef jeromekeating notifications@github.com:

can it be something to do with the flashing process? I have the "no receive LED" and "doesn't wake from sleep" problems described above but it doesn't always happen. Radio #1 https://github.com/travisgoodspeed/md380tools/issues/1 worked for the last few weeks using the 1.08 flash tool until I re-flashed it with the exact same one last night and it developed these problems. Radio #2 https://github.com/travisgoodspeed/md380tools/issues/2 I just got yesterday and it showed the same problem after flashing. Then I tried using the 1.05 flash tool and funny enough Radio #2 https://github.com/travisgoodspeed/md380tools/issues/2 seems to like that one, while Radio #1 https://github.com/travisgoodspeed/md380tools/issues/1 still shows the same problem.

There's something else that's causing this, either something that randomly goes wrong during the flashing process, or something in the codeplug that's messing it up. Because the same radio that used to work now doesn't work on the same firmware. Wish I could provide better information.

— 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/875#issuecomment-480520066, or mute the thread https://github.com/notifications/unsubscribe-auth/AXfxPwQJlZD77taaydVFn2tEK59wUFYPks5veNLigaJpZM4UsDRE .