Hi all for your info last night I started working on support for FT817ND in chirp. Even though this is my first time with Python I was able to start a new module, write and test the "clone receive" and checksum routines before to go to bed ;) Today I'll finish beautify the receive code and probably will also write the send routine.
At a first look memories in the dump seams to be in the same format as described in http://www.ka7oei.com/ft817_meow.html but i'll start working on this later on. If some one has more info please notify me: every bit of information can help.
... and naturally if there are volunteer betatesters I'll be happy to send the source and share the effort
best 73 de IZ3GME Marco
for your info last night I started working on support for FT817ND in chirp. Even though this is my first time with Python I was able to start a new module, write and test the "clone receive" and checksum routines before to go to bed ;) Today I'll finish beautify the receive code and probably will also write the send routine.
Great! I was thinking of doing this myself recently, but I'm glad you're doing it for me! :)
... and naturally if there are volunteer betatesters I'll be happy to send the source and share the effort
I'm currently separated from my 817 at the moment, but should be able to help test in a week or so.
Thanks!
On 13/01/2012 01:07, Dan Smith wrote:
BTW Have you got an ND or old one?
It is an original/old/non-ND one.
Let's hope they didn't change the clone protocol between sub models ...
Good news are I'm looking at my ft817 _ND_ memories in chirp :)
Please Dan, there are two things I don't know how to arrange: - seems that "PKT" mode is not in common.MODES, may I add it? - radio has different valid steps for FM, AM, SSB; how I can arrange for them to set valid_tuning_steps in get_features?
73 de IZ3GME Marco
Good news are I'm looking at my ft817 _ND_ memories in chirp :)
Nice!
Please Dan, there are two things I don't know how to arrange: - seems that "PKT" mode is not in common.MODES, may I add it?
So, you're bumping up against something that has needed some maintenance for some time. When CHIRP started out, it was rather ICOM-specific and so several of those drivers still index directly into the global definitions of the modes to convert something like "0x3" to "FM". If we change those then they will break.
The short answer is: if you add "PKT" to the end of the list then you should be safe for now. However, we need to move to radios declaring their modes in valid_modes and indexing into *that* list instead.
The tuning steps have the same problem, of course. You can see that I recently added 9.0 to the end of that list as well when hitting the same sort of problem.
- radio has different valid steps for FM, AM, SSB; how I can arrange
for them to set valid_tuning_steps in get_features?
I think you'll need to declare all of the steps that the radio supports in valid_tuning_steps and then check in your set_memory() handler to make sure they're using a valid combination.
I wouldn't be opposed to changing valid_tuning_steps to look something like this:
valid_tuning_steps = {"FM" : [5.0, 10.0, ...], "AM" : [5.0, 9.0, ...], ... }
However, that gives us the same problem of needing to update all the old drivers as well. If we can agree on these changes, then I can go through and manually update the drivers, but I don't want to do that more than once if I can help it :)
On 13/01/2012 01:24, Dan Smith wrote:
The short answer is: if you add "PKT" to the end of the list then you should be safe for now. However, we need to move to radios declaring their modes in valid_modes and indexing into *that* list instead.
Good, I will add it.
I wouldn't be opposed to changing valid_tuning_steps to look something like this:
valid_tuning_steps = {"FM" : [5.0, 10.0, ...], "AM" : [5.0, 9.0, ...], ... }However, that gives us the same problem of needing to update all the old drivers as well. If we can agree on these changes, then I can go through and manually update the drivers, but I don't want to do that more than once if I can help it :)
Too much work at this time. Let's stay on the easy way: I will add steps if needed and comment the 817 sources to remember that it can be improved.
BTW I'll send the sources to the list a soon as I know there is someone that can do tests.
73 de IZ3GME Marco
Let's stay on the easy way: I will add steps if needed and comment the 817 sources to remember that it can be improved.
Sure.
BTW I'll send the sources to the list a soon as I know there is someone that can do tests.
Well, I'll surely have some comments about the code, and having code to test and no way to test it will push me to make a cable. So, I say: send what you have now so we can take a look! :)
On 13/01/2012 17:30, Dan Smith wrote:
Well, I'll surely have some comments about the code, and having code to test and no way to test it will push me to make a cable. So, I say: send what you have now so we can take a look! :)
Ok ok ... here is the code :)
Add ft817nd in directory.py and you are done
I don't have time to work on it today ... Please note: - flags structure has to be investigated, it seems there are two copies in memory - clone_in is supposed to work - get_memory is supposed to work but need to support more details (eg. the narrow modes) - clone_out, set_memory and validate_memory has not been done yet
73 de IZ3GME Marco
Add ft817nd in directory.py and you are done
Nice, looks pretty trim!
# Copyright 2010 Dan Smithdsmith@danplanet.com
Be sure to put *your* copyright on it! :)
If I have time tonight I may cook up a cable and give it a shot. Thanks!
Add ft817nd in directory.py and you are done
Got pretty close to the end and then hit this:
File "/home/dan/chirp/chirp/ft817nd.py", line 37, in ft817_read raise Exception("Unable to read block %02X expected %i got %i" % (blocknum, block, len(data))) Exception: Unable to read block 31 expected 132 got 120
Clone failed: Unable to read block 31 expected 132 got 120 Clone thread ended --- Exception Dialog: Unable to read block 31 expected 132 got 120 --- None
--- Exception Dialog: Unable to read block 31 expected 132 got 120 ---
I changed the last block size to 120 instead of 132. Not sure if that's a difference between the regular and -ND model or not. If so, then we just need a subclass in the ft817.py file (I think it should be named ft817.py not ft817nd.py, FWIW).
A quick sniff test showed the first two channels I have stored, with names and frequencies. Excellent start, thanks!
On 14/01/2012 04:28, Dan Smith wrote:
--- Exception Dialog: Unable to read block 31 expected 132 got 120 ---
I changed the last block size to 120 instead of 132. Not sure if that's a difference between the regular and -ND model or not. If so, then we just need a subclass in the ft817.py file (I think it should be named ft817.py not ft817nd.py, FWIW).
We can rename it as soon as we know all needs to support the non nd model, it's up to you as I don't have it ;)
A quick sniff test showed the first two channels I have stored, with names and frequencies. Excellent start, thanks!
That's good :D
73 de IZ3GME Marco
On 13/01/2012 01:24, Dan Smith wrote:
The tuning steps have the same problem, of course. You can see that I recently added 9.0 to the end of that list as well when hitting the same sort of problem.
I see no 9.0 step, sure you have added it later than 0.1.12 version I'm working on Will have to merge sorces ...
73 de IZ3GME Marco
I see no 9.0 step, sure you have added it later than 0.1.12 version I'm working on Will have to merge sorces ...
Yeah, you should be using a snapshot of the tree at least, or even better, cloned with mercurial so you can generate proper diffs:
You can click the "gz" link on the left to get a tarball snapshot of the tree.
Thanks!
On 14/01/2012 15:01, Dan Smith wrote:
Yeah, you should be using a snapshot of the tree at least, or even better, cloned with mercurial so you can generate proper diffs:
http://d-rats.com/hg/chirp.hg
Gone with mercurial and attached you can find an updated diff.
I have done some changes in memory structure and completed set_memory and clone_out. I've also corrected a "development" bug in vx7.py If you change the block_lengths to test with ft817 please note that I changed the meaning of values not counting block number and checksum so your last block has to be 118 now
Now that I can clone in and out, I will go deep investigating the memory structure: it is different than expected!! If someone out there wants to help this are the only elements that have been tested and are supposed to fully work: - tag_on_off - tag_default - mode - duplex - is_duplex - skip - freq - offset - name
and finally tmode is not working for sure.
Now is the time for others to help :)
73 de IZ3GME Marco
On Mon, January 16, 2012 09:07, Marco Filippi IZ3GME wrote:
On 14/01/2012 15:01, Dan Smith wrote: Now is the time for others to help :)
I'm supposed to be working on VX2r, but I am on vacation and away from the hardware. I do have everything I need to make an interface cable for the FT817ND (including an FT817ND), so I will help with testing when I get back.
73,
Andrew ZL3AME
Gone with mercurial and attached you can find an updated diff.
Thanks!
I have done some changes in memory structure and completed set_memory and clone_out. I've also corrected a "development" bug in vx7.py If you change the block_lengths to test with ft817 please note that I changed the meaning of values not counting block number and checksum so your last block has to be 118 now
Okay, attached is a revised version of your patch to add in the regular 817. It downloads for me, but does not upload yet. I will look into this. I also integrated your vx7 changes into the repository.
The diff *from* your other patch is included below, but I would recommend you just take the attached patch and work forward from that.
Now is the time for others to help :)
I'll be glad to jump in and work on this a bit. I do worry about having too many people making changes and only communicating by sending patches. If it gets confusing, it may be best to create a branch in the tree for this sort of development, but we'll see how it goes.
Thanks!
It downloads for me, but does not upload yet. I will look into this.
The change below makes the upload work for me, as well as tone modes. Yaesu radios are really bad about not being able to process data at the full baudrate and thus you have to delay a bit between writes to make sure they don't choke. This extra 0.01 sleep seems to be enough and doesn't make a measurable difference in upload time for me.
diff -r 9c56a812bf70 chirp/ft817nd.py --- a/chirp/ft817nd.py Mon Jan 16 08:46:08 2012 -0800 +++ b/chirp/ft817nd.py Mon Jan 16 10:57:40 2012 -0800 @@ -83,6 +83,7 @@ else: repeat = 1 for i in range(0, repeat): + time.sleep(0.01) checksum = yaesu_clone.YaesuChecksum(pos, pos+block-1) if os.getenv("CHIRP_DEBUG"): print "Block %i - will send from %i to %i byte " % (blocks, pos @@ -130,12 +131,13 @@ unknown3:1, ipo:1, att:1, - unknown2:2, - tmode:2; + unknown2:4; u8 ssb_step:2, am_step:3, fm_step:3; - u8 unknown4[2]; + u8 unknown7:6, + tmode:2; + u8 unknown4; u8 unknown5:3, tone:5; u8 unknown6:1,
On 16/01/2012 17:45, Dan Smith wrote:
I'll be glad to jump in and work on this a bit. I do worry about having too many people making changes and only communicating by sending patches. If it gets confusing, it may be best to create a branch in the tree for this sort of development, but we'll see how it goes.
Well ... I made many changes today, mainly to the memory structure, and have merged with repository.
I have taken a look to your diff and I think is better you to manually reproduce it because the changes I made to the structure would break your code.
With my radio I have all working to a good level, apart of a few TODO in the code it works smoothly: I read back, changed and reprogrammed more than 100 memories with many different combinations of splits, modes etc etc and it really seem to do the job :)
For test purpose I used the well known ftcommander and it shows up that there must be differences in the memory structures between old and new 817 models.
My opinion is that now is time to put in non nd model and then pull initial support to the repository. I'll spend my time doing something else in this while ... may be I'll have a look in ft859 ... This way we will not overlap on the same source with me doing "beta testing" and you developing at the same time.
73 de IZ3GME Marco
I have taken a look to your diff and I think is better you to manually reproduce it because the changes I made to the structure would break your code.
Okay.
With my radio I have all working to a good level, apart of a few TODO in the code it works smoothly: I read back, changed and reprogrammed more than 100 memories with many different combinations of splits, modes etc etc and it really seem to do the job :)
Okay, I'll apply my non-ND changes and do some more testing and then if everything looks good, I'll push to the repository.
By the way, there is somewhat of a testsuite in the tests/ directory. I ran it on your first version and it failed. I'll commit a base image for the non-ND radio so that we can run those tests. If you can send me an image for the ND then I'll put that in there as well. I can also start looking at the failures and try to get them fixed up.
I'll spend my time doing something else in this while ... may be I'll have a look in ft859 ...
That would be great, thanks!
On Thu, Jan 12, 2012 at 10:02, IZ3GME Marco iz3gme.marco@gmail.com wrote:
Hi all for your info last night I started working on support for FT817ND in chirp.
I promised to do this a few months ago, and never started. Thanks!
... and naturally if there are volunteer betatesters I'll be happy to send the source and share the effort
I have an early FT-817 I can test (not the ND model). If they've changed the memory mapping slightly, I should be able to modify your code enough to get it working for both models.
Tom KD7LXL
On 12/01/2012 18:57, Tom Hayward wrote:
I have an early FT-817 I can test (not the ND model). If they've changed the memory mapping slightly, I should be able to modify your code enough to get it working for both models.
Good! You can start dumping your radio using the (quick and dirty) attached file and see if at least the clone protocol is the same.
How to: - prepare your radio for in clome mode - start dump.py - start radio clone tx (fn-a) - look at the beautiful data on standard output and hope the radio does not say "Error" ;)
73 de IZ3GME Marco
On Thu, Jan 12, 2012 at 12:17, Marco Filippi IZ3GME iz3gme.marco@gmail.com wrote:
On 12/01/2012 18:57, Tom Hayward wrote:
I have an early FT-817 I can test (not the ND model). If they've changed the memory mapping slightly, I should be able to modify your code enough to get it working for both models.
Good! You can start dumping your radio using the (quick and dirty) attached file and see if at least the clone protocol is the same.
I can't find my '817 cable anywhere. Dan, it sounds like you have the same version. Can you dump your memory for Marco?
Tom KD7LXL
I can't find my '817 cable anywhere. Dan, it sounds like you have the same version. Can you dump your memory for Marco?
I actually don't have a cable for mine, so I'll have to cook one up. By the time I'm reunited, I imagine that Marco will have posted a version of the real code for us to test, so I'll surely participate however he needs :)
participants (5)
-
Andrew Errington -
Dan Smith -
IZ3GME Marco -
Marco Filippi IZ3GME
-
Tom Hayward