[chirp_users] "length 0" error DLing from FT-8900
Hi, longtime CHiRP user for Icom,Yeasu,Wouxun,Baofeng here. I just got a Yeasu FT-8900R (and a USB programming cable) and am having difficulty getting it to download.
I'm running CHiRP 0.4.0 on Python 2.7.8 under Ubuntu 14.10.
I put the radio in clone mode, have CHiRP waiting for the data, and as soon as I press the V/M button to send the data, I get the error: "ord() expected a character, but string of length 0 found" and the radio shows a clone error.
I read the recent (May 4) thread on this list between Dan & Benjamin entitled "Chirp IndexError" that describes the same error. In his case, Benjamin wasn't getting anything from the radio, and it proved to be a loose cable. Not so with me.
In my case, here's what I know:
I can connect a terminal program (PuTTY) to the correct port and get echo. I also receive data from the radio when pressing the V/M button that looks right. Specifically, the radio sends this string, viewed in PuTTY: AH008$.$ ("." is non-ASCII char) I captured it to a file and this is the exact data stream in hex: 41 48 30 30 38 24 80 24
The correct data stream only appears at 9600 baud, which is what ft7800.py says it should be fixed at. AH008 is the model that the code shows for the FT8900.
Here's the terminal output from the failure: ... User selected Yaesu FT-8900 on port /dev/ttyUSB1 Clone thread started Download finished in 1 seconds -- Exception: -- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/chirpui/clone.py", line 227, in run self.__radio.sync_in() File "/usr/lib/python2.7/dist-packages/chirp/ft7800.py", line 320, in sync_in self.check_checksums() File "/usr/lib/python2.7/dist-packages/chirp/yaesu_clone.py", line 209, in check_checksums if checksum.get_existing(self._mmap) != \ File "/usr/lib/python2.7/dist-packages/chirp/yaesu_clone.py", line 156, in get_existing return ord(mmap[self._address]) TypeError: ord() expected a character, but string of length 0 found ------ Clone failed: ord() expected a character, but string of length 0 found Clone thread ended --- Exception Dialog: ord() expected a character, but string of length 0 found --- None ----------------------------
Any ideas?
if you are getting the same issue as a fella with a a cable issue I would bet that your cable doesn't have the right driver installed. Tell us more about the cable.
On Tue, May 12, 2015 at 6:56 PM, Charles Boling junk07+chirp@boling.us wrote:
I didn't figure there had been any major changes to that part
Not bothering to verify w/ a newer version before posting to the list *was* lazy, though, and you were right to call me on it. :-)
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
On 05/12/2015 07:20 PM, Ryan Tourge wrote:
if you are getting the same issue as a fella with a a cable issue I would bet that your cable doesn't have the right driver installed. Tell us more about the cable.
It's Linux, so it doesn't have the mess of driver issues that the Prolific chipsets (and clones) have on Windows.
The fact that, unlike Ben, I do get the expected text from the radio is encouraging. Of course, it doesn't tell me that anything sent *to* the radio is getting there, but at least we know something's [at least mostly] working in one direction.
The cable was bought from KAWAMALL on eBay. lsusb shows: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Today's build (20150513) shows this run:
======================================================================= charles@charles:~$ chirpw
(process:7774): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/chirp/ui/clone.py", line 238, in run self.__radio.sync_in() File "/usr/lib/pymodules/python2.7/chirp/drivers/ft7800.py", line 327, in sync_in self.check_checksums() File "/usr/lib/pymodules/python2.7/chirp/drivers/yaesu_clone.py", line 222, in check_checksums if checksum.get_existing(self._mmap) != \ File "/usr/lib/pymodules/python2.7/chirp/drivers/yaesu_clone.py", line 168, in get_existing return ord(mmap[self._address]) TypeError: ord() expected a character, but string of length 0 found
ERROR: ---------------- ERROR: Clone failed: ord() expected a character, but string of length 0 found ERROR: --- Exception Dialog: ord() expected a character, but string of length 0 found --- ERROR: None
ERROR: ---------------------------- charles@charles:~$ =======================================================================
On Wed, May 13, 2015 at 9:52 AM, Charles Boling junk07+chirp@boling.us wrote:
On 05/12/2015 07:20 PM, Ryan Tourge wrote:
if you are getting the same issue as a fella with a a cable issue I would bet that your cable doesn't have the right driver installed. Tell us more about the cable.
It's Linux, so it doesn't have the mess of driver issues that the Prolific chipsets (and clones) have on Windows.
The fact that, unlike Ben, I do get the expected text from the radio is encouraging. Of course, it doesn't tell me that anything sent *to* the radio is getting there, but at least we know something's [at least mostly] working in one direction.
Your loopback test proves it's not a driver issue.
It's possible there's another issue with the cable, but I'd bet there's something funky in the code. At the very least, Chirp's error handling is lacking because here we're seeing a low-level Python error, not a Chirp application error.
I don't have time to look into this now, but I'd start by viewing the history on ft7800.py in the repo.
Tom KD7LXL
I'd start by viewing the history on ft7800.py in the repo.
Note that the same problem exists with both the current daily and 0.4.0 from over a year ago. (Surely another FT-8900 owner would've reported a regression by now were it a universal problem! Are there any 8900 owners reading this that can confirm that CHIRP works okay with their rig?)
The repo shows 3 changes (Mar 3/4/5 2015) including the one that created the "drivers" directory and moved all the radio files there out of the main dir. The next change ("Fix style issues" -- mostly adding spaces) doesn't appear to have done anything nasty to the code. The most recent change ("Use logging in drivers") just changed 3 instances of "print" to "LOG.info".
I dropped back to the main chirp in the repo's web interface, but didn't see a way to show any entries before March 3rd. (It showed a page of entries, with no "older" or similar button.) The most recent tag was the 0.4.0 release, which took me back another year to March 2014, so I don't know how to view changes between 3/2014-3/2015. Please forgive my ignorance there.
I had a problem with an FT-8800 that I could not copy and paste from left side to right side. Had to use RT Systems then go back to CHIRP.
Jardy Dawson WA7JRD Ham Radio
Message relayed through SETI (Search for Extra-Terrestrial Intelligence, although no terrestrial intelligence has been found yet, either)
On May 13, 2015, at 12:00, Charles Boling junk07+chirp@boling.us wrote:
I'd start by viewing the history on ft7800.py in the repo.
Note that the same problem exists with both the current daily and 0.4.0 from over a year ago. (Surely another FT-8900 owner would've reported a regression by now were it a universal problem! Are there any 8900 owners reading this that can confirm that CHIRP works okay with their rig?)
The repo shows 3 changes (Mar 3/4/5 2015) including the one that created the "drivers" directory and moved all the radio files there out of the main dir. The next change ("Fix style issues" -- mostly adding spaces) doesn't appear to have done anything nasty to the code. The most recent change ("Use logging in drivers") just changed 3 instances of "print" to "LOG.info".
I dropped back to the main chirp in the repo's web interface, but didn't see a way to show any entries before March 3rd. (It showed a page of entries, with no "older" or similar button.) The most recent tag was the 0.4.0 release, which took me back another year to March 2014, so I don't know how to view changes between 3/2014-3/2015. Please forgive my ignorance there.
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
More info:
I used Wireshark to do a raw capture USB. I am NOT a USB expert, but here's what I saw in 3 different tests:
#1:
I first examined a successful CHIRP session w/ a Wouxun radio.
After the initial GET DESCRIPTOR for the device and about 10 URB_CONTROL packets, I saw lots of URB_BULK packets exchanging the data with the radio.
#2
I then tried it with PuTTY connected to the FT-8900.
As soon as I started the capture, I saw the GET DESCRIPTOR request/response.
When I pressed the button on the radio to send the data, I then saw 16 "URB_BULK in" packets, the 1st one being from the radio to the PC, the 2nd being the other direction, etc. Each of the 8 packets from the radio contained one of 8 chars of the "AH008$.$" string.
#3
I then monitored a session w/ CHIRP and the FT-8900.
Note: I'm going to prefix some of my comments w/ WireShark packet numbers, just so I can keep track of where I am in the dump and go back and reference it later if needed.
The serial port was USB device #12. lsusb shows these endpoints defined for the device: EP 1 IN EP 2 OUT EP 3 IN
1) As soon as I started the capture, I saw the GET DESCRIPTOR request/response (to/from 12.0).
409) When I started CHIRP listening, I saw two "URB_CONTROL out" packets (PC-->radio & response) to/from 12.0.
417) When I pressed the button on the radio to send the data, I saw the same "URB_BULK in" packets as in #2. These 1st 16 packets were from/to 12.3 and contained the same "AH008$.$" string.
Each of these bulk packets seem to contain 64 bytes plus whatever the data payload is. The recipient always replies with a 64-bit packet w/ no data. I won't bother to mention these confirmation packets anymore.
433) I then saw a reply from the host ("URB_BULK out") to 12.2 containing a single data byte (0x06). 435) The radio (12.3) replied with a 0x06. 439) Then the same exchange happened again (host sent 0x06, radio replied).
443) Then the host sent a "URB_CONTROL out" tp 12/-
445) The radio (12.3) sent an empty (64 bytes, no data) "URB_BULK in" packet to the PC. 446) The radio sent another one -- without a confirmation packet from the PC. I'll take a wild guess that the previous packet killed CHIRP. 447) 12.1 sent a "URB_INTERRUPT in" packet.
That was the end of the session.
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 transmits.
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 completeness...
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: FTB8900 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.)
It appears that the USB/RS-232 converter in the programming cable just can't get along with the USB ports on one particular computer (unfortunately, it's my main workstation, newer than all the others.)
I brought my radio and cable over to a fellow ham's house who had an FT-8800 & the same Kawamall cable. It worked fine w/ his cable attached to his PC. It then worked fine w/ my cable! We then plugged it into one of my notebooks (not previously tested with) and it worked fine there. Actually, on both machines it had an error or two, but the rest of the runs were fine.
It made me wonder if maybe there was a connection problem at the radio, that repeated pluggings fixed. It couldn't be merely a loose/unreliable connection, for the results at home had been consistent every run; it must be something more along the lines of a ground pin that wasn't connecting at all, but there was still enough signal coming through the shell or something that it worked under certain conditions.
Back home, I plugged it in and found that the situation hadn't changed -- it still refused to work on my PC but worked on other computers. Time to verify that it wasn't a software problem!
I used Live CDs (1st the Chirp LiveCD based on Ubuntu 12.04, then a Ubuntu 14.04 LiveCD, after the other misbehaved with my nVidia video card) to ensure that the entire software stack was the same on 4 machines that I was testing on, and that it wasn't a different kernel that was making it work/not. As expected, different versions of CHIRP made no difference.
3 computers worked fine, but the 4th did not. (All of my other cables/radios work fine on it!)
Oddly enough, I *could* get it to work on the 4th computer in one circumstance: Run the LiveCD in a VMWare Virtual Machine, plug the radio into the 2nd USB port on the top of the box (a 3.0 port) *and* ensure that a hub with other things was plugged into the 3rd USB port (a 2.0 port). Is that weird, or what!?
The need to be in a particular what's-plugged-in-where config lent credibility to the notion that it was a voltage issue, but that I was actually able to get it to work in VMWare in one configuration made me wonder if it was more of some weird signal timing problem. It would be interesting to know with more certainty the true details of the problem, but I feel that lack the knowledge, equipment, and/or large amounts of time required for me to determining that....
I think I will ask to borrow the other ham's cable, and try it on my PC. If it works normally, I will probably take a chance and buy another cable. If it doesn't, I will shrug my shoulders and plan on using other machines to program that radio.
What operating system are you using? If Windows, see if yourcable is a Prolific. If it is, roll back the driver to 3.2.0.0.
Jardy Dawson WA7JRD Ham Radio
Message relayed through SETI (Search for Extra-Terrestrial Intelligence, although no terrestrial intelligence has been found yet, either)
On Jun 11, 2015, at 06:51, Charles Boling junk07+chirp@boling.us wrote:
It appears that the USB/RS-232 converter in the programming cable just can't get along with the USB ports on one particular computer (unfortunately, it's my main workstation, newer than all the others.)
I brought my radio and cable over to a fellow ham's house who had an FT-8800 & the same Kawamall cable. It worked fine w/ his cable attached to his PC. It then worked fine w/ my cable! We then plugged it into one of my notebooks (not previously tested with) and it worked fine there. Actually, on both machines it had an error or two, but the rest of the runs were fine.
It made me wonder if maybe there was a connection problem at the radio, that repeated pluggings fixed. It couldn't be merely a loose/unreliable connection, for the results at home had been consistent every run; it must be something more along the lines of a ground pin that wasn't connecting at all, but there was still enough signal coming through the shell or something that it worked under certain conditions.
Back home, I plugged it in and found that the situation hadn't changed -- it still refused to work on my PC but worked on other computers. Time to verify that it wasn't a software problem!
I used Live CDs (1st the Chirp LiveCD based on Ubuntu 12.04, then a Ubuntu 14.04 LiveCD, after the other misbehaved with my nVidia video card) to ensure that the entire software stack was the same on 4 machines that I was testing on, and that it wasn't a different kernel that was making it work/not. As expected, different versions of CHIRP made no difference.
3 computers worked fine, but the 4th did not. (All of my other cables/radios work fine on it!)
Oddly enough, I *could* get it to work on the 4th computer in one circumstance: Run the LiveCD in a VMWare Virtual Machine, plug the radio into the 2nd USB port on the top of the box (a 3.0 port) *and* ensure that a hub with other things was plugged into the 3rd USB port (a 2.0 port). Is that weird, or what!?
The need to be in a particular what's-plugged-in-where config lent credibility to the notion that it was a voltage issue, but that I was actually able to get it to work in VMWare in one configuration made me wonder if it was more of some weird signal timing problem. It would be interesting to know with more certainty the true details of the problem, but I feel that lack the knowledge, equipment, and/or large amounts of time required for me to determining that....
I think I will ask to borrow the other ham's cable, and try it on my PC. If it works normally, I will probably take a chance and buy another cable. If it doesn't, I will shrug my shoulders and plan on using other machines to program that radio.
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users To unsubscribe, send an email to chirp_users-unsubscribe@intrepid.danplanet.com
Not to be rude, but the writers of the last couple of replies didn't put much effort into reading the msg they replied to, much less reviewing any of the rest of the thread. It's NOT a Windows driver problem on one machine because (a.) I'm not running Windows and (b.) running from the same CD ensured that it's the identical software stack from the application level down to the Linux kernel; the only software difference would be in the BIOS. Thus I declare that it's basically a hardware problem.
I'll post the results of my tests with the other cable tomorrow night or Saturday. At this point my posts are pretty much informational, rather than help-seeking. Thanks, everyone!
A final (at least for now) report on this:
I tried the another cable, and it likewise exhibited the problem on the one machine but not the others. Just for grins, I installed the appropriate Windows driver (which, also worked fine on other hardware) in a VM with the device connected to it (as a raw USB device, not as a COM port) and observed the same malfunction there, which assured me that it wasn't an issue that was common between the PL2303 driver in all versions of the Linux kernel and that particular chip on that particular motherboard.). The only thing I haven't done software-wise is try a bare-metal install of Windows on that machine to disprove any general problem specific to the kernel's generic USB driver (that only shows up with this kind of cable, and not any of the other half-dozen other kinds of Prolific cables & adapters I have, nor with the dozens of other kinds of USB devices I've used with it).
So, for now I'm just going to have to use another machine to talk to the radio. If I *really* want to program on this machine, I might buy an RS-232 cable, and try it with one of the USB/RS-232 converters I've used w/ this box, and see if I have any better luck with that. And if I happen to get my hands on a digital storage scope, I'd love to record the communication at the radio port and compare the signals.
participants (6)
-
Charles Boling -
Charles Boling (AD7UF)
-
Jardy Dawson -
Jim Unroe -
Ryan Tourge -
Tom Hayward