[chirp_users] "length 0" error DLing from FT-8900
junk07+chirp at boling.us
Mon May 18 13:21:16 PDT 2015
Some more testing, trying to find the source of the problem:
I powered the radio from a battery, instead of my bench supply, just to
make sure there was no weird ground loop or other noise injection going
on. No difference in operation.
Side note: I also discovered something to be careful of (Someone else
may well have discovered and mentioned this elsewhere): If I leave the
programming cable attached to the radio but do NOT have it plugged into
a live USB port, when I turn on the radio, it starts transmitting and
stays key-down. If I start with it plugged in and unplug it, nothing
happens but when I plug it back into the USB port, the radio briefly
I probably shouldn't even share this next section -- I'm afraid that it
will muddy the water and that someone reading this thread will latch
onto in and it will distract the conversation away from the real issue,
which is its behavior on my Linux box -- but, in the interest of
I tried the cable & radio on a different machine, running WinXP.
I installed the Prolific driver from the CD that came with the cable.
Installation went fine.
Hyperterm echoed chars, but I saw nothing appear when I pushed the
button on the radio. I also confirmed that I had the right port by
unplugging the cable and observing that the echo no longer worked.
I installed USBPcap and WireShark. The format of the dump is a bit
different than in Linux (with more "CONTROL" stuff shown). WireShark
showed activity when button pushed, but I didn't see the expected data
in there. It appears that instead of sending the "AH008$.$" string, it
was sending a NUL char for each one of the 8 chars. It looked like the
PC replied back with a 0x06 as it did on Linux, then a few more 0x00
chars came from the radio before the connection was shut down.
CHIRP (20150513) returned this error as soon as I pushed the button:
Error reading echo (Bad cable?)
I installed a trial version of G4HFQ's commercial software to see if it
would give any clues. It gave me this when I pushed the button:
The rig identifier expected was X'414830303824'
but the identifier actually received was X'000000000000'
We cannot continue with the read process.
This agrees with what I saw in WireShark.
Thus, under Windows (on different PC hardware), though the PC is clearly
communicating with the radio, the result is different (and inferior,
with less correct info exchanged) to what I was getting on my Linux
machine. Why the difference?
Here's a wild guess, without thinking it through much: what about an
analog problem, like a signal voltage that's lower than it should be --
right at the threshold of proper operation -- and minor power
differences between the two machines might make a difference of all
zeros vs. correct data in some circumstances but not others? I don't
have a digital storage scope, so even if I opened things up so I could
get a probe pair in there, I'd get only limited info about that.
(After this test, I moved the cable back to the Linux box, and verified
that it still behaved as before.)
More information about the chirp_users