Bug #3791
Updated by Bernhard Hailer almost 4 years ago
CHIRP Daily 20160702, also in older versions. After successfully reading the radio: DTCS for TX is Correct DTCS for RX reads 023N vs Programmed 065N (written by TYT Software Version 1.0.8) "CrossMode" DTCS becomes Tone->Tone, should be DTCS. Subsequent Read/Write of Radio to/From TYT Software was verified correct with a handheld TX. Changing the 023N in CHIRP to 065N and crossmode to ->DTCS then writing to the radio, reading from TYT it is correct. It seams to be a GUI Display issue with CHIRP for this Model. The GUI Display also appends subsequent characters behind channel label blocks that are not used, as in short names. *This bug was basically accidently stumbled upon* Thank You, Rich Davis W4NMH EMT ARRL Life Member, Instructor Official Emergency Station (OES) Official Relay Station (ORS) Technical Specialist (TS) Volunteer Examiner (VE) http://www.Norfolk-ARES.org _(removed irrelevant text [AE6YN])_ *Effective Bug Reporting* Effective reporting of a bug or feature is critical to getting the issue resolved in a timely manner. If bug descriptions are difficult to understand or reproduce, they are less likely to receive attention. When you are crafting your bug report, try to answer the following questions: 1. What is the behavior you are seeing? 2. What is the behavior you were expecting? 3. Can you reproduce the problem all the time? 4. What are the steps required to reproduce the problem? 5. Is this specific to a certain radio model (driver) or something that you can reproduce with another radio? In most cases, it is important to attach an image of your radio to the bug so that a developer can look at the exact state and determine what the problem is. It is often helpful describe what you expect to see in a given memory location, as well as what you actually see. If relevant or difficult to describe what you are seeing, attaching a screenshot of the behavior may also be helpful. For more information about how to file an effective bug report, please see Eric S. Raymond's How to ask questions the smart way *Getting your debug log* If you are expecting something to happen (such as importing from a file, or setting a memory) and CHIRP appears to ignore the request, you probably should include your debug.log. If you are getting an error message, you should definitely include the log. The debug log is cleared every time you start chirp, so the procedure for getting a usable log is: 1. Start chirp 2. Reproduce the failure or bug 3. Close chirp 4. Copy and send the debug.log before starting chirp again Here are some tips for getting to it on the various platforms: Windows Go to Start->Run and type "%APPDATA%\CHIRP". Your debug.log file will be in the folder that opens.