On 3/15/2012 6:49 AM, Dan Smith wrote:

When you used the laptop, was CS-2820 configured for high-speed cloning?

I didn't know there was a configuration option for that! It seemed slow compared to the CHIRP high speed cloning (more like the slow speed cloning before I updated from CHIRP 1.2). I didn't pay that much attention to the speed, so I could be wrong - I'll check tonight when I get home from work.

Even still, I wonder if maybe it's older and slower enough that your regular (presumably fast) machine is going *too* fast in hi-speed mode...

The Windows laptop is old and slow, the Linux desktop is very fast, so that's quite possible. I was seeing the same thing with 1.2, which seemed to be not be using high speed cloning. Not sure if that's a useful data point for you.

Oh - I do have a Ubuntu partition on the laptop that I could test with if that would be helpful.

You could try this to see if it helps:

diff -r 8229eb1649d8 chirp/ic2820.py

Thanks, I'll try that also when I get home (as well as Mike's daily build suggestion - thanks Mike).

Brian

On 3/15/2012 12:50 PM, Dan Smith wrote:

Or just the windows chirp build would be helpful, yeah.

Ok, I'll give that a try (I might try the Linux build on the laptop too just for fun).

Hmm, well, looking back at your mail, I'm not sure it's going to matter. You said that it was failing with 0.1.12 too, right?

Correct. I went looking for a newer version specifically because it wasn't working.

When did it last work for you?

No idea. Like I said, I haven't had a need to do any reprogramming for a while. I can check the timestamp on the image I was using, that should give me an idea, but I can't guarantee I haven't done something to touch it at some point (there's a good chance it may have been touched when installing a new Fedora release).

I've blasted about twenty images into my 2820 today trying to find any sort of issue, but I got nothing.

Ah... bugs that you can't reproduce are no fun to chase. I write code for a living, I know what that's like. I'm happy to do as much debugging as I can if you're willing to do a bit of hand-holding along the way (I don't know Python, and am not terribly experienced with Linux development tools).

The chirp error indicating that the radio didn't ack the last block is harmless, by the way.

The error might be harmless, but the radio hanging sure isn't! ;-) I end up with factory settings (including no programmed memories) when I power cycle it (the only way to recover).

Thanks for the help, I'll pass on my findings this evening.

Brian

On Thu, 2012-03-15 at 13:53 -0700, Dan Smith wrote:

...

Thanks for the help, I'll pass on my findings this evening.

Okay, thanks!

Here's what I've tried, and my results.

On the desktop:

Installed the daily build (chirp-daily_03072012-1.fc16.noarch). Tried low and high speed. Neither worked.

On the laptop:

Windows, CS-2820, low and high speed, both work. Windows, Chirp 0.2.0, low and high speed, both work. Ubuntu, Chirp 0.1.2 (from .deb), works. Ubuntu, Chirp 0.2.0 (from tarball), low and high speed, both work.

Brian

Just wondering if we can narrow this down to something with only the RPM packaged builds.

I really can't imagine why that would be. Brian could test the tarball on the desktop and figure it out pretty quick.

Brian, what kind of serial port are you using on each?

The icom clone (not live) code is identical for all icom radios, and has been rock solid since the very beginning of time. There is so much evidence that it's right that I _have_ to look elsewhere first. I'd believe that any of the yaesu clone operations could use some tweaking, but not the icom stuff...

Just trying eliminate that as a problem.

Sure, I'd love for it to be a problem with the daily build, I just don't have much hope :)

My money is on the bank programming code ;-)

Hmm, I don't think so. Just downloading an image and then uploading it again shouldn't involve any of that stuff (it's different for alive radio like the IC-9x). By the time it's uploading, chirp is locked into a control loop with the radio and it does nothing else. And, he said he was happening with 0.1.12.

Although, it's possible that he has something in his image that the radio doesn't like, which might be what you meant. Entirely possible in that case.

Brian, can you send me your image to see if my 2820 chokes on it?

Ok, one more thing I just tried...

On the desktop, I made the serial port available to a Windows XP virtual machine (using VirtualBox), uploaded my image with Windows CHIRP - and it worked!

Brian

Computer: Dell XPS-1530 laptop (Duo core 2.4 GHz CPU, 4Gb RAM, Prolific USB/RS-232 adapter)

OS: Fedora 16 Linux (kernel V 3.2.9-2.fc16.x86_64)

Same distro and same kernel as me, and a reasonably fast machine as well - thanks for trying that.

Brian, your test results with Windows in a VM are interesting... it makes me wonder if this is not a timing issue of some sort,

I thought the same thing. It does feel like that.

or an issue with the Linux driver for your serial card.

Maybe, but the VM is still using the host machine's driver. That's the part that surprised me the most about it working in the VM.

A test with Fedora 16/i686 running in a VM on that same machine and serial port might prove interesting.

I was already thinking about trying that. I'm downloading a Fedora ISO now right (I don't seem to have one on disk - I think I did a liveupgrade from F15). I'll post back later with the results.

Brian

On Sun, 2012-03-18 at 15:28 -0700, Brian Mury wrote:

CHIRP 0.1.2 and 0.2.0 both work correctly in an F16 guest running on the F16 host (the desktop). Hmmmmmmm.....

One more data point: I used a Fedora 16 live CD both natively and in the VM, in order to get as similar an environment as possible. I followed exactly the same sequence of steps in both cases. It did not work natively but did work with the VM. This should eliminate something having gone wrong with my Fedora installation or configuration.

About the only thing different in the VM is the address and IRQ (it shows up as /dev/ttyS0 in the VM, and it's /dev/ttyS5 when running natively - the serial card is /dev/ttyS4 through /dev/ttyS7).

Since the VM just redirects the virtual serial port to the real serial port on the host OS (/dev/ttyS5) I would expect it to not work in the VM if it was a host OS driver problem or similar. However, I'm no expert and I could be wrong.

Unless someone else has suggestions on other things to try, or on how to debug this, I'm not sure what to do next (other than test with the motherboard's serial port when my cable shows up).

Brian

On Mon, 2012-03-19 at 07:32 -0700, Dan Smith wrote:

I'd be highly interested in the behavior of the onboard connector, as well as that of a USB-to-serial port if you happen to have one you could try.

I won't have the cable for a couple weeks, but I'm also interested in seeing how it works. I don't have a USB-to-serial device, but I can ask around and see if anyone I know has one I can borrow.

We could also try artificially slowing down the Icom programming loop if you want, which might mirror the behavior of the VM. However, I think I'd prefer not to commit that and slow everyone else down,

If you want to send me some modified files to drop in, or even just tell me what to put where, I'll give it a try. No need to commit it. We might want to take that off list.

Out of curiosity, does dmesg indicate that they're 16550A ports, 8250, or what?

It says they're 16550A's - which is correct. Here's the relevant output. I don't know what that "Redundant entry" message means; does it mean anything to you?

[ 1.067248] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled [ 1.087788] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.145348] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 1.153547] serial 0000:04:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 1.153595] 0000:04:00.0: Redundant entry in serial pci_table. [ 1.153595] Please send the output of lspci -vv, this [ 1.153596] message (0x1407,0x0120,0x0000,0x0000), the [ 1.153596] manufacturer and name of serial board or [ 1.153597] modem board to rmk+serial@arm.linux.org.uk. [ 1.174489] 0000:04:00.0: ttyS4 at I/O 0xeff8 (irq = 18) is a 16550A [ 1.205374] 0000:04:00.0: ttyS5 at I/O 0xeff0 (irq = 18) is a 16550A [ 1.213472] serial 0000:04:00.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 1.213519] 0000:04:00.1: Redundant entry in serial pci_table. [ 1.213520] Please send the output of lspci -vv, this [ 1.213520] message (0x1407,0x0121,0x0000,0x0000), the [ 1.213521] manufacturer and name of serial board or [ 1.213521] modem board to rmk+serial@arm.linux.org.uk. [ 1.234413] 0000:04:00.1: ttyS6 at I/O 0xefe8 (irq = 18) is a 16550A [ 1.264308] 0000:04:00.1: ttyS7 at I/O 0xefe0 (irq = 18) is a 16550A

Brian

Maybe, but the VM is still using the host machine's driver. That's the part that surprised me the most about it working in the VM.

That's true, but it also adds a significant amount of latency and some additional buffering, so it's really hard to say. However, it doesn't surprise me.