[chirp_users] New Daily Build
Greetings,
A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location:
http://trac.chirp.danplanet.com/chirp_daily/daily-01212012/
A list of the changes included in this build (since the last daily) follows:
changeset: 1263:7b748c5c5f65 tag: tip user: Dan Smith dsmith@danplanet.com date: Fri Jan 20 18:59:00 2012 -0800 files: tests/run_tests description: [tests] Add a very simple cross mode tone test, run if the radio supports it
changeset: 1262:4b820fc47c04 user: Dan Smith dsmith@danplanet.com date: Fri Jan 20 18:51:41 2012 -0800 files: tests/run_tests description: [tests] Don't choke on radios that support cross-mode tones
changeset: 1261:410445300fff user: Dan Smith dsmith@danplanet.com date: Fri Jan 20 10:08:53 2012 -0800 files: chirpui/mainapp.py chirpw description: Add a simple language override in the View menu that allows you to choose one of the supported languages if you aren't able to set it via your operating system.
On Jan 21, 2012, at 6:01 AM, Dan Smith dsmith@danplanet.com wrote:
Greetings,
A new daily build of CHIRP is available. This includes changes made directly to the tree yesterday, and may include additional features, bug fixes, and/or bugs. If you are interested in trying it, grab it from the following location:
All,
Linux Fedora RPMs for the latest chirp-daily build are now available in the KK7DS Ham-Apps yum repository.
To add the repository as a software source, please follow these instructions: http://www.d-rats.com/component/content/article/30-d-rats-yum-repository/
I know it says d-rats, the chirp files are in the same repository
After setting up the repository, open the "Add/Remove Software" tool and go to "software sources" under the system menu. Make sure the "KK7DS Ham Apps Beta Software" line is checked (enabled).
For some reason, the Fedora package manager likes the beta versions better that the daily builds, so you may not see the daily release in the list the first time you update. If you don't see it, open a terminal window and enter: yum update chirp-daily_01212012 Or: yum update chirp-daily_01212012-1.fc16
That should install the latest daily build.
Happy Testing, Mike, N0SO
Hi, Can anyone direct me to the howto for the 817? I tried putting my ND in clone mode as the source and clicked on chirp to read from but get a com error. I tried a rate of 38400 and 4800 on the ND with error indications from chirp. Used a data cable that works for Ham Radio Deluxe and FT-817 Commander. I'll take a pointer to the instructions if that's simpler to post. Kurt KC9LDH
Can anyone direct me to the howto for the 817? I tried putting my ND in clone mode as the source and clicked on chirp to read from but get a com error. I tried a rate of 38400 and 4800 on the ND with error indications from chirp.
You need to put the radio into clone mode, then go to Radio->Download, choose Yaesu, FT-817ND, and then hit okay. Once CHIRP is waiting, then hit the A key on the radio to start the transfer. I believe if you do this sequence properly, it should work. I didn't write the driver, but I've had no problems with it downloading.
O.K.
That worked. Modified the .img and did the reverse. Got chirp ready to transfer the modified img file and hit the C button on the 817 and then did an upload to the 817. Both units showed a progression during the transfer but there was no beep or any indication the transfer was successful. Restarted the 817 and the rig was reset to the baseline. Fortunately, I didn't have but 3 frequencies in it but all the parameters I had set are gone. I had the thing download from the rig just fine and I saved the .img file but it won't write to the 817.
Kurt KC9LDH
--- On Sun, 1/22/12, Dan Smith dsmith@danplanet.com wrote:
From: Dan Smith dsmith@danplanet.com Subject: Re: [chirp_users] FT-817ND Howto? To: "Discussion of CHIRP" chirp_users@intrepid.danplanet.com Date: Sunday, January 22, 2012, 2:07 PM
Can anyone direct me to the howto for the 817? I tried putting my ND in clone mode as the source and clicked on chirp to read from but get a com error. I tried a rate of 38400 and 4800 on the ND with error indications from chirp.
You need to put the radio into clone mode, then go to Radio->Download, choose Yaesu, FT-817ND, and then hit okay. Once CHIRP is waiting, then hit the A key on the radio to start the transfer. I believe if you do this sequence properly, it should work. I didn't write the driver, but I've had no problems with it downloading.
Well,
Though my 817ND seemed to be reset by attempting to write a memory file to it, I was able to recover the frequencies by using FT-817 Commander. The old frequencies were still in the 817 but had to be turned on!!?? I did a fresh install of the 817 Commander on another computer and it showed they were "in there" but I had to activate them and rewrite the memory using the 817 Commander. Anybody else have any problems with writing to an 817ND with chirp? To recap, I place the 817ND into clone mode, hit the C button and tell Chirp to upload the .img file to the rig. After the write progression bar disappears, the rig just sits there. During the write process, the 1/8 notes go across the screen of the 817ND but a complete indication is never seen/heard. I'd caution people who are working with an 817 when trying to do writes with Chirp. If you have FT-817 commander, use that to make a memory backup. Scroll down on this link to get to a download of the old FT-817 Commander: http://forums.hrdsoftwarellc.com/showthread.php?23307-FT-817-Commander-Downl... Kurt KC9LDH
--- On Sun, 1/22/12, Kurt Savegnago ksaves2@sbcglobal.net wrote:
From: Kurt Savegnago ksaves2@sbcglobal.net Subject: Re: [chirp_users] FT-817ND Howto? To: "Discussion of CHIRP" chirp_users@intrepid.danplanet.com Date: Sunday, January 22, 2012, 4:57 PM
O.K.
That worked. Modified the .img and did the reverse. Got chirp ready to transfer the modified img file and hit the C button on the 817 and then did an upload to the 817. Both units showed a progression during the transfer but there was no beep or any indication the transfer was successful. Restarted the 817 and the rig was reset to the baseline. Fortunately, I didn't have but 3 frequencies in it but all the parameters I had set are gone. I had the thing download from the rig just fine and I saved the .img file but it won't write to the 817.
Kurt KC9LDH
--- On Sun, 1/22/12, Dan Smith dsmith@danplanet.com wrote:
From: Dan Smith dsmith@danplanet.com Subject: Re: [chirp_users] FT-817ND Howto? To: "Discussion of CHIRP" chirp_users@intrepid.danplanet.com Date: Sunday, January 22, 2012, 2:07 PM
Can anyone direct me to the howto for the 817? I tried putting my ND in clone mode as the source and clicked on chirp to read from but get a com error. I tried a rate of 38400 and 4800 on the ND
with error indications
from chirp.
You need to put the radio into clone mode, then go to Radio->Download, choose Yaesu, FT-817ND, and then hit okay. Once CHIRP is waiting, then hit the A key on the radio to start the transfer. I believe if you do this sequence properly, it should work. I didn't write the driver, but I've had no problems with it downloading.
Though my 817ND seemed to be reset by attempting to write a memory file to it, I was able to recover the frequencies by using FT-817 Commander. The old frequencies were still in the 817 but had to be turned on!!?? I did a fresh install of the 817 Commander on another computer and it showed they were "in there" but I had to activate them and rewrite the memory using the 817 Commander.
Yep, that's because (a) the clone didn't seem to finish and the radio will reset itself to recover and (b) Yaesu's definition of "reset" is "mark the memories as unused".
Anybody else have any problems with writing to an 817ND with chirp?
I've programmed my non-ND 817 over ten times since Marco wrote the code. The code for the ND version differs by precisely two digits in a block number. What platform are you on and what kind of cable setup are you using?
Using a commercial cable that works fine with HRD and FT-817 Commander. Is a USB cable. Working in a Linux and an XP operating systems. Like I mentioned, Chirp read the 817ND memory into an .img file without any problem. I let the program sit for awhile during the write back into the 817ND but it just sat there. Restarting goes to the default like you say and gives that awful dark violet screen color on the ND's display. I usually have it set to orange.
Oh, the data cable is a PL2303 converter that works with the 817 ND just fine ordinarily. Me suspects it might just be a simple code issue? :-)
Kurt KC9LDH
--- On Sun, 1/22/12, Dan Smith dsmith@danplanet.com wrote:
From: Dan Smith dsmith@danplanet.com Subject: Re: [chirp_users] FT-817ND Writing problem To: "Discussion of CHIRP" chirp_users@intrepid.danplanet.com Date: Sunday, January 22, 2012, 6:56 PM
Though my 817ND seemed to be reset by attempting to write a memory file to it, I was able to recover the frequencies by using FT-817 Commander. The old frequencies were still in the 817 but had to be turned on!!?? I did a fresh install of the 817 Commander on another computer and it showed they were "in there" but I had to activate them and rewrite the memory using the 817 Commander.
Yep, that's because (a) the clone didn't seem to finish and the radio will reset itself to recover and (b) Yaesu's definition of "reset" is "mark the memories as unused".
Anybody else have any problems with writing to an 817ND with chirp?
I've programmed my non-ND 817 over ten times since Marco wrote the code. The code for the ND version differs by precisely two digits in a block number. What platform are you on and what kind of cable setup are you using?
Me suspects it might just be a simple code issue? :-)
Can't say, as it works 100% for me. Patches are gladly accepted.
You might increase the delay on line 86 of ft817.py from 0.01 to 0.1 and see if that helps. Yaesu radios are really bad about timing between blocks and their lack of buffering/flow control.
Tried the change to ft817.py and no dice. Perhaps someone else with an ND can try. I think the cable is fine because it works with HRD. Tried both Linux and Windows versions of Chirp. Weird because it reads the 817ND's memory just fine. No joy when it writes. The same cable with the 817 Commander works and is actually what I used to restore the memories while trying to troubleshoot Chirp. Perhaps someone else with an 817ND can give it a go but be sure to use 817 Commander to backup your memories if you have alot of places occupied. Kurt KC9LDH
--- On Sun, 1/22/12, Dan Smith dsmith@danplanet.com wrote:
From: Dan Smith dsmith@danplanet.com Subject: Re: [chirp_users] FT-817ND Writing problem To: "Discussion of CHIRP" chirp_users@intrepid.danplanet.com Date: Sunday, January 22, 2012, 8:22 PM
Me suspects it might just be a simple code issue? :-)
Can't say, as it works 100% for me. Patches are gladly accepted.
You might increase the delay on line 86 of ft817.py from 0.01 to 0.1 and see if that helps. Yaesu radios are really bad about timing between blocks and their lack of buffering/flow control.
I think the cable is fine because it works with HRD. Tried both Linux and Windows versions of Chirp. Weird because it reads the 817ND's memory just fine. No joy when it writes.
Hmm, strange. Try running with CHIRP_DEBUG and grabbing the console output to send to us. On linux:
# CHIRP_DEBUG=y ./chirpw 2>&1 | tee debug.log
Maybe Marco has an idea?
On 26/01/2012 04:25, Dan Smith wrote:
I think the cable is fine because it works with HRD. Tried both Linux and Windows versions of Chirp. Weird because it reads the 817ND's memory just fine. No joy when it writes.
Hmm, strange. Try running with CHIRP_DEBUG and grabbing the console output to send to us. On linux:
# CHIRP_DEBUG=y ./chirpw 2>&1 | tee debug.log
Maybe Marco has an idea?
Yes please, the debug output should help. Please do the clone out immediately after the clone in so we are sure that there are no other variables playing.
I suspect a timing problem as Dan has already suggested but what is really strange is that the radio should say if the clone operation was completed or not ... BTW I developed the driver on my 817nd and never had to face such a deep reset.
73 de IZ3GME Marco
O.K.
I'll give it another try tonight with the linux version. I think I have another cable and will give it a go too. I will say that after I have Chirp read the ND, there is a delay, then a beep and then the screen on the ND says ERROR. Thing is, even with this funky read process, all of the memories are appropriately read and displayed on the computer screen in chirp. I'll see what a different cable does and try the write process from chirp to the ND with the debug command.
Kurt KC9LDH
--- On Thu, 1/26/12, Marco IZ3GME iz3gme.marco@gmail.com wrote:
From: Marco IZ3GME iz3gme.marco@gmail.com Subject: Re: [chirp_users] FT-817ND Writing problem To: chirp_users@intrepid.danplanet.com Date: Thursday, January 26, 2012, 4:55 AM On 26/01/2012 04:25, Dan Smith wrote:
I think the cable is fine because it works with
HRD. Tried both Linux
and Windows versions of Chirp. Weird because it
reads the 817ND's
memory just fine. No joy when it writes.
Hmm, strange. Try running with CHIRP_DEBUG and grabbing
the console
output to send to us. On linux:
# CHIRP_DEBUG=y ./chirpw 2>&1 | tee debug.log
Maybe Marco has an idea?
Yes please, the debug output should help. Please do the clone out immediately after the clone in so we are sure that there are no other variables playing.
I suspect a timing problem as Dan has already suggested but what is really strange is that the radio should say if the clone operation was completed or not ... BTW I developed the driver on my 817nd and never had to face such a deep reset.
73 de IZ3GME Marco _______________________________________________ chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
Hi Kurt
I'll give it another try tonight with the linux version. I think I have another cable and will give it a go too. I will say that after I have Chirp read the ND, there is a delay, then a beep and then the screen on the ND says ERROR.
I feel pretty sure is not a cable problem, it is a protocol problem! Good to know that the 817 raise an error. At the end of the clone in operation the radio is expected to play a "happy beep" and go back to the clone menu.
Please keep in mind this golden rule: if the clone operation from radio is not perfect don't even think to clone back!
Thing is, even with this funky read process, all of the memories are appropriately read and displayed on the computer screen in chirp.
This is because chirp didn't saw any problem in the clone operation, may be the radio sends a packet more than expected.
I'm going to investigate the log you sent, will let you know. Thanks
73 de IZ3GME Marco
Hi Kurt
I'll give it another try tonight with the linux version. I think I have another cable and will give it a go too. I will say that after I have Chirp read the ND, there is a delay, then a beep and then the screen on the ND says ERROR. Thing is, even with this funky read process, all of the memories are appropriately read and displayed on the computer screen in chirp. I'll see what a different cable does and try the write process from chirp to the ND with the debug command.
Could you please run in linux the attached script and send me the output: - copy the file to your chirp-devel directory in the chirp subdir (the same where the ft817.py file is) - cd to that dir - prepare the radio for the clone operation - run it with python ./dump817nd.py /dev/ttydeviceofyour817 2>&1 >/tmp/817dump - start radio clone tx wait for the clone to complete, the radio should complain "as usual" and the program should take a few seconds to finish after the actual data transfer is ended. Send the generated /tmp/817dump file. Plese send also an image of the white label on the radio (the one with model, serial number etc): we have to find not only the protocol details but also a way to recognize the various radio sub models.
Thank for your help
73 de IZ3GME Marco
Here is the script .... sorry ...
73 de IZ3GME Marco
participants (4)
-
Dan Smith -
Kurt Savegnago -
Marco IZ3GME -
Mike Heitmann