Bug #125
closedFT-8800 Invalid Frequencies
0%
Description
I followed your instructions to install CHIRP on my iMac running Snow Leopard (10.6.8). I successfully installed KK7DS_Python_Runtime_R10.pkg, then unzipped the Chirp zip file and tried to run CHIRP without success. I rebooted my machine and tried again, but still without success. Not sure what the problem could be. I have collected the console.log from both operations. There is no debug.log (see the attached ChirpProblem.pdf file). The log results are identical each time I try to run Chirp, i.e. I get a permission denied and the app exits with error 1. I have tried changing the user and the group to admin and to root with the same result. I tried moving the app to /Applications and changing the user and group similarly with the same results. I have run out of options that I can think of, so help is needed.
Files
| ChirpProblem.pdf (244 KB) ChirpProblem.pdf | Log and directory information | ||
| WindowImage.jpg (12.8 KB) WindowImage.jpg | |||
| debug.log (2.73 KB) debug.log | |||
| NoChannelsFound.jpg (6.06 KB) NoChannelsFound.jpg | |||
| ADMS-2I-Export.csv (581 Bytes) ADMS-2I-Export.csv | |||
| debug.log (17.7 KB) debug.log | |||
| debug.log (9.73 KB) debug.log | |||
| ChucksRadio.img (21.7 KB) ChucksRadio.img |
Updated by Dan Smith over 12 years ago
- Status changed from New to In Progress
Can you try the latest daily version to see if that works? I see something in your log that looks wrong, so we'll need to get 0.2.2 fixed for sure, but if you could check the latest daily build for MacOS, that would help:
http://trac.chirp.danplanet.com/chirp_daily
Thanks!
Updated by Chuck Burton over 12 years ago
- File WindowImage.jpg WindowImage.jpg added
- File debug.log debug.log added
The daily build app did not crash on start-up now, but comes up with a blank screen (see WindowImage.jpg). The console.log shows the following messages:
4/18/12 9:20:28 AM [0x0-0x92092].com.danplanet.chirp[1428] ** (chirpw:1428): WARNING **: Invalid borders specified for theme pixmap:
4/18/12 9:20:28 AM [0x0-0x92092].com.danplanet.chirp[1428] /opt/kk7ds/share/themes/OSX-theme/gtk-2.0/Buttons/button-default.png,
4/18/12 9:20:28 AM [0x0-0x92092].com.danplanet.chirp[1428] borders don't fit within the image
I have included the debug.log from the run. Hope that helps.
Updated by Dan Smith over 12 years ago
- Subject changed from CHIRP will not run on my iMac. to MacOS Package broken for 0.2.2
- Assignee set to Dan Smith
- Target version set to 0.2.3
Your screenshot looks like it's fine to me. Try going to File->New, or Radio->Download to get started.
I'll mark this as a bug in the 0.2.2 Mac package.
Thanks!
Updated by Chuck Burton over 12 years ago
- File NoChannelsFound.jpg NoChannelsFound.jpg added
- File ADMS-2I-Export.csv ADMS-2I-Export.csv added
- File debug.log debug.log added
Did as you said (File/New followed by File/Import). The import was a CSV file that was exported by ADMS-2I (the RT Systems/Yeasu app for Windows to manage the FT-8800). CHIRP produced a No Channels Found error (see NoChannelsFound.jpg). I have included a scaled down version of the exported file (see ADMS-2I-Export) and the debug.log.
Regards
Updated by Dan Smith over 12 years ago
Yep, that's expected. CSV is a format, not a specification. Lots of applications store data in CSV format, but that doesn't mean that they're compatible. Adding support for the ADMS format is something that could be added to CHIRP in the future, but it's not currently supported. It sounds like chirp is running correctly now though, which is good.
Try downloading from your 8800 directly.
Updated by Chuck Burton over 12 years ago
One more thing I forgot, I was unable to Quit Python. Quitting did nothing. I had to Force Quit to get it to close. I'll try downloading from the 8800 tonight or tomorrow and let you know. The connection to the Mac is a USB connection, so will give that a shot.
Updated by Dan Smith over 12 years ago
Yep, that's a known problem, and it lies in the Python MacOS platform support package (not directly in chirp).
Just click the red x button at the top left of the main chirp window to gracefully quit, or choose quit from the file menu.
Updated by Chuck Burton over 12 years ago
I was able to download FT-8800 data using the RT Systems CT29B Radio Cable. I received 2 tabs of data. I assume one is the Right Transceiver and one is the Left transceiver (looking at Columns did indicate which was which). In addition, the transceiver can transmit and receive on different frequencies, but only one frequency is shown. The offset seems to indicate the transmit frequencies or offset. It is not clear to me how an Rx/Tx with an offset is handled. However, at least two channels have receive and transmit frequencies (159.225, 153.785 and 151.625, 151.625), but they seem to show an in valid frequency (8153.780000) rather than the actual transmit frequency. Both are labeled as split Duplex, but there are a couple of others that seem to show split and correct transmit frequency.
Apparently Chirp does not capture the Banks or the Skip HM data memory information. Is that information thrown on the floor?
I have provided the debug.log file for your review.
Updated by Dan Smith over 12 years ago
- Subject changed from MacOS Package broken for 0.2.2 to FT-8800 Invalid Frequencies
- Chirp Version changed from 0.2.2 to daily
- Model affected changed from Mac OSX 10.6.8 to FT-8800
I'm changing the name of this bug again, because (a) I've checked and the 0.2.2 MacOS package seems to be fine to me and (b) you have unrelated issues. In the future, please create a new issue for each actual issue.
CHIRP supports split TX/RX memories by indicating a duplex of "split" and showing the TX frequency in the offset field. It sounds like that's what you're seeing. Most amateur radios (the FT-8800 included) default to a single frequency with a duplex and offset, which is how CHIRP natively shows it. Normally you would have a frequency of something like 146.900, a duplex of "-" and an offset of 0.600MHz.
Please attach your .img file with the broken frequencies in it and I'll take a look.
CHIRP does not support the hyper memory functions of these radios. The information is not "dropped on the floor", it's just ignored. Editing your memory image with CHIRP will not erase this data, and it will still be present when you upload back to the radio.
Please direct any future discussion on how to use CHIRP to the mailing list.
Thanks!
Updated by Chuck Burton over 12 years ago
- File ChucksRadio.img ChucksRadio.img added
Not sure, do you want me to start a new problem report for this information or should I put the IMG file here. I am assuming you want it here. Sorry, I did not create separate problem report for each issue. I assumed that one led to the other, but I guess they didn't really go one after the next.
0.2.2 may work on your machine, but it still will not start on mine - same problem as initially stated with the same console.log entries. Your call.
The IMG file is attached. Channels 19 and 98 have the problem.
Updated by Dan Smith over 12 years ago
- Status changed from In Progress to Closed
Got it, thanks for the image. This is fixed for tomorrow's daily build.
Regarding the 0.2.2 package, I've tested it on a couple machines without any trouble, but am also hoping to get some confirmation from a more MacOS-y person than myself. I'll follow up on it and open a new issue if we find something wrong.
Thanks!