Hello Marco,
First off, thanks for taking the time to troubleshoot this and I'm sure that many people will love to have FT support in Chirp!
BTW it would be MUCH better having yaesu make a robust and public protocol.
Yeah... I don't think that will happen. I get the impression that the protocol that Kenwood is much more flexible but I don't know if it's open per se. Curious, have you ever spoke to some of the other programming tool people out there such as G4HFQ with his FT programs? http://www.g4hfq.co.uk/mmohelp/mmohelp.htm All of those are very nice but being Windows only, they won't work for me.
This is what I suppose even if I didn't had a look at the rest of the data (yet), the clone operation should replicate all setting of the radio. Having a full backup of the radio is one of the reasons for which I decided to use the clone protocol instead of peeking and poking in memory.
Right.. ok. That's good. What would be SLICK is that, (if ever) that Chirp could download three FT857 radios and save the main binary blobs for the primary radio settings as say radio A, B, C. When programming in back the main memories, ask the user if they want to substitute in the correct radio's main menu settings with those memories. It seems this would be possible considering that Chirp already knows where the memories go w/o disturbing the main radio settings.
Send the generated /tmp/857dump file.
Will send in another email directly to you.
--David