[chirp_devel] Initial Yaesu FT-857 testing

[Dan Smith]

> Is that information saved into the saved .img file itself?

Everything the radio dumps to us is stored in the .img file. If the 
radio sent us identifying information, then it is, yeah. Run "hexdump 
-C" on one of the VX-X images in the tests/ directory for an example.

> Hmmm.. bummer. That's the only real complaint I've heard with Python
> over the years... it's threading isn't all that hot.

It's only a problem because I was lazy and didn't implement something 
better in the read loops within the drivers and depended on this 
working. IMHO, Python's threading support is about as good as most. 
You're probably thinking of the fact that the interpreter isn't 
multi-threaded, nor reentrant, which really isn't related to this problem.

> No, that's not what I meant to say. What I did mean is that it seems
> this current tip of tree that I applied the FT857 patches to seems to
> have broken the support for my other radios.

Hmm, well, I've not heard such reports. It would be very helpful if you 
could do a little bisection to determine where you think things broke. 
If you clone the actual source tree, then you can move through the 
changesets pretty easily in a single directory without downloading a 
bunch of tarballs.

> Ok.. fair enough but when I tried with my Kenwood FH-F6A, all the
> downloaded memories showed the memory text field as "ERROR" and it
> downloaded all 400 memories as "error"

Understand, but CHIRP won't push error'd memories back to the radio. It 
can't. Kenwood radios are the pinnacle of obsessive verification. If you 
send a memory (they're sent to the radio one at a time in text format) 
that doesn't meet spec, it will outright reject it.

Please grab the console output and post it here so I can see. Hopefully 
that will provide some insight into what's going on. I recently made 
some fixes for the TH-F7A, which could have broken the F6, I suppose, 
but I usually hear about those fairly quickly.

> I'll look at that but I think the numeric keypad works everywhere else.

Okay, well, the default on my 11.10 machine is to use the numeric pad 
for mouse keys. With that disabled, the numeric pad works fine in chirp 
for me.

> Anyway... I think at this stage, it would be safe to add the FT857 code
> into the repository though it would be good to hear what Kurt finds with
> his FT817.

Yeah, I just talked to him and he's going to try it in the next day or 
so. I'll hang on for that.

-- 
Dan Smith
www.danplanet.com
KK7DS