Bug #305
closedHangs on upload to ID-880H
Added by Bill Atkinson over 11 years ago. Updated almost 8 years ago.
0%
Description
OS X 10.7.4
GTK 2.24.10
PyGTK 2.22.0
Python 2.7.2
I was able to read the radio without issue. After adding a few new channels, I attempting to upload the changed. I noticed that it appears to hang approximately 10% in. Rebooting the radio results in all memories being erased. Assuming that it was a change I'd made that was causing the issue, I downloaded the radio again and without making any changes, immediately attempted the upload. Same result. Please let me know what further information I can provide.
Files
| id880h-original.img (61.5 KB) id880h-original.img | Bill Atkinson, 09/15/2012 02:39 PM | ||
| debug-hispeed.log (5.39 KB) debug-hispeed.log | Bill Atkinson, 09/16/2012 02:10 PM | ||
| debug-nohispeed.log (4.86 KB) debug-nohispeed.log | Bill Atkinson, 09/16/2012 02:10 PM |
Updated by Dan Smith over 11 years ago
- Assignee set to Dan Smith
- Target version set to 0.3.0
Hi Bill,
Are you really testing with 0.2.3 or the latest daily. If the former, can you try the latter, just for comparison's sake? The daily builds are available at the bottom of the download page.
This sounds like it might be related to the hi-speed clone mode. Right now, there's no "switch" to flip to turn that off, but it sounds like maybe there should be, at least for debugging purposes.
I'll try to get something pushed into a daily build asap to let you flip that switch.
Updated by Bill Atkinson over 11 years ago
Confirmed behavior in version CHIRP daily-20120912.
I believe you may be correct in your assumption regarding the hi-speed clone mode. In watching the progress meter, the Mac gets to the hanging point and then the radio's progress meter catches up a couple of seconds later. At that point no further progress is made.
Updated by Dan Smith over 11 years ago
Hey Bill,
I've pushed a change up that will add a "Settings" tab on the left side. This will have a check box inside that will let you enable or disable hispeed cloning with your radio. This change will be in tomorrow's daily build. If you could test it and let me know what you find, I'd appreciate it.
Thanks!
Updated by Bill Atkinson over 11 years ago
Using CHIRP daily-20120915, I unchecked the box for the hi-speed clone after reading the radio. I made a small change in one of the memories and attempted an upload to the radio. It still freezes and the progress bar in Chirp is about 1/5 of way to the former freezing point. Not sure how that correlates to turning off the high speed. After canceling the upload and resetting the radio, I'm once again left with an empty radio.
After resetting the radio, I downloaded again now having the hi-speed mode turned off, since it's only exposed after a download. Upon attempting an upload I'm met with the same result. I was wondering if perhaps the hi-speed was corrupting the download somehow, but that does not appear to be the case.
All of the other radio settings remain intact, I only lose the memories.
Updated by Dan Smith over 11 years ago
Okay, do you have a windows or linux machine you can use to upload your image back to your radio so that you don't lose anything?
If it's choking even on the non-hispeed clone, then I expect driver issues (as are usually the problem on MacOS). Can you attach your debug log here for examination? Also, please attach one of your .img files and I'll try it on my 880 here.
Updated by Bill Atkinson over 11 years ago
- File id880h-original.img id880h-original.img added
This radio is devoted strictly to DSTAR, so when it gets blanked I only lose two memories. I do however have another one coming for mobile use that will have more channels.
I've attached my .img file for your review. Would you like logs of the download or upload or both? And with or without the hi-speed option turned on?
Updated by Dan Smith over 11 years ago
Actually, separate logs of both would be good. It sounds like hispeed or not, it doesn't really matter. I expect the problem is actually the quantity of data filling the buffer and not the speed at which it's happening.
Also, are you using the 1529 (or equivalent) or the OPC-478 (or equivalent) cable? What USB adapter are you using (if separate from the cable)?
Updated by Bill Atkinson over 11 years ago
- File debug-hispeed.log debug-hispeed.log added
- File debug-nohispeed.log debug-nohispeed.log added
I'm using an original ICOM OPC-478 cable with a DB9 connector. The USB-Serial adapter is using an FTDI chipset/driver. I currently have two of them on this particular Mac Mini. One controls my FT-950 and the other I'm using for CHIRP. I've tried various USB-Serial adapters an have found this particular one to be the most reliable across multiple platforms.
I've attached two logs:
debug-hispeed.log - A download/upload attempt with hi-speed enabled.
debug-nohispeed.log - A download with hi-speed enabled (since the setting isn't exposed until a download takes place) and then an upload with hi-speed disabled.
I'll let you examine the logs, but my cursory examination shows both upload attempts terminate with an error 9: bad file descriptor.
Updated by Dan Smith over 11 years ago
Ah, here we go. In the debug log, during upload, you can see it fails here:
RadioError: Failed to communicate with the radio: write failed: [Errno 9] Bad file descriptor
This means that the file descriptor (in this case, the serial port) we're writing to suddenly becomes "bad". This usually means that it gets closed by the application and then written to (which isn't happening here) or something similar. The most common situation I've seen for this is that the driver barfs, the USB line experiences a hiccup, something transmits nearby and interrupts things, etc. You might check your system log (specifically dmesg) to see if it sees the USB adapter become disconnected and then reconnected during the communication around the time of the failure.
Updated by Bill Atkinson over 11 years ago
Checking /var/log/system.log for the time period I attempted the uploads, I see the following:
Sep 16 16:54:41 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: ** (chirpw:22651): WARNING *: Invalid borders specified for theme pixmap:
Sep 16 16:54:41 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: /opt/kk7ds/share/themes/OSX-theme/gtk-2.0/Buttons/button-default.png,
Sep 16 16:54:41 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: borders don't fit within the image
Sep 16 16:55:38 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: * (chirpw:22651): WARNING *: Invalid borders specified for theme pixmap:
Sep 16 16:55:38 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: /opt/kk7ds/share/themes/OSX-theme/gtk-2.0/Tabs/notebook_top_flat.png,
Sep 16 16:55:38 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: borders don't fit within the image
Sep 16 16:56:07 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: * (chirpw:22651): WARNING *: Invalid borders specified for theme pixmap:
Sep 16 16:56:07 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: /opt/kk7ds/share/themes/OSX-theme/gtk-2.0/Frame-Gap/frame1.png,
Sep 16 16:56:07 Bills-Mac-mini [0x0-0xad5ad5].com.danplanet.chirp[22651]: borders don't fit within the image
Sep 16 17:04:27 Bills-Mac-mini [0x0-0xadcadc].com.danplanet.chirp[22683]: ln: /Users/bill/Downloads/chirp-daily-20120915.app/Contents/MacOS/../CHIRP: File exists
Sep 16 17:04:34 Bills-Mac-mini [0x0-0xadcadc].com.danplanet.chirp[22683]: * (chirpw:22683): WARNING *: Invalid borders specified for theme pixmap:
Sep 16 17:04:34 Bills-Mac-mini [0x0-0xadcadc].com.danplanet.chirp[22683]: /opt/kk7ds/share/themes/OSX-theme/gtk-2.0/Buttons/button-default.png,
Sep 16 17:04:34 Bills-Mac-mini [0x0-0xadcadc].com.danplanet.chirp[22683]: borders don't fit within the image
Sep 16 17:05:28 Bills-Mac-mini [0x0-0xadcadc].com.danplanet.chirp[22683]: * (chirpw:22683): WARNING **: Invalid borders specified for theme pixmap:
Sep 16 17:05:28 Bills-Mac-mini [0x0-0xadcadc].com.danplanet.chirp[22683]: /opt/kk7ds/share/themes/OSX-theme/gtk-2.0/Tabs/notebook_top_flat.png,
Sep 16 17:05:28 Bills-Mac-mini [0x0-0xadcadc].com.danplanet.chirp[22683]: borders don't fit within the image
Nothing at all in dmesg besides some google chrome related messages. I checked throughout the failed upload process.
Updated by Dan Smith about 11 years ago
- Status changed from New to Rejected
I'm going to close this as "rejected" since it's clearly the serial adapter going offline and there has been no activity for a long time.
Updated by Danny White almost 8 years ago
Dan Smith wrote:
I'm going to close this as "rejected" since it's clearly the serial adapter going offline and there has been no activity for a long time.
Was this issue ever resolved? I'm having the same problem.