[chirp_devel] Supporting Yaesu FT857 radios with Chirp
Hello Chrip-devel,
I've been recently emailing Dan Smith and he recommended to join this group about this:
I've heard that code is being developed for supporting the FT817 and FT857. This is something I asked for some time ago and it seems like it's about to happen! I'll be happy to do testing here.
Before I go there, I have a related question I need to get answers before I can do any testing. Specifically, I have an RT Systems CT-62B cable here that came with their Windows software for a FT857 but Linux 2.6.32 doesn't recognize it:
usb 2-1.3: new full speed USB device using ehci_hcd and address 12 usb 2-1.3: New USB device found, idVendor=2100, idProduct=9e56 usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1.3: Product: CT-62B Radio Cable usb 2-1.3: Manufacturer: RT Systems usb 2-1.3: SerialNumber: RTTFPERY usb 2-1.3: configuration #1 chosen from 1 choice
Question #1 - Does anyone know if these RT System USB cables Prolific or FTDI based?
Question #2 - If FTDI based, it seems it's only a matter of getting it initially supported with a "/sbin/modprobe ftdi_sio vendor=0x2100 product=0x9e56". If Prolifici based, the pl2303 module doesn't support this syntax. Instead, the Prolific driver seems to want this at the higher level with "/sbin/modprobe usbserial vendor=0x2100 product=0x9e56". What I don't understand is if the RT Systems cable is Prolific based, how will the USB system know to associate the device with the Prolific vs. FTDI driver? Why? Because I already have other FDTI and Prolific USB devices on the machine!
Statement #1 - I've successfully submitted Linux kernel for the FTDI driver to support the US Interface Navigator USB IDs (think of it as a big brother to a Signalink device). So, once I have this tested and working, I'll submit the patch to the kernel folk. If other people have RT Systems device IDs (shown in "lsusb -v"), I'll add that into my patch.
Anyway... please let me know when the FT897 code is ready for testing and I'll give it a try!
--David KI6ZHD
-------- Original Message -------- Subject: Re: [Fwd: [chirp_users] New Daily Build] Date: Wed, 18 Jan 2012 09:18:38 -0800 From: Dan Smith dsmith@danplanet.com To: David A. Ranch References: 4F159FBD.4000904@trinnet.net 4F15A065.3070802@danplanet.com 4F16FE33.7020604@trinnet.net
Ok.. I'll try to add myself to that list.
Marco says he does in fact have an 857, and that we should expect support for it to show up soon. Being on the devel list would let you help test that ahead of time, which would be good.
Quick question.. I have an official RT-Systems USB cable for the FT857 but it's not recognized by the Linux 2.6.32 kernel. I want to say these are Prolific based devices but maybe they are FTDI? I already submitted kernel patches that were accepted to add US Interface Navigator support so maybe I can do the same for these serial devices.
Yeah, these devices are not setup to provide a VCP by default, and I think they are in fact FTDI. I don't have any, so I haven't gone through the process of trying to fix the vendor IDs, but Robert Terzi has. Ask on the devel list and I think he can get you set right up.
On 1/18/2012 3:18 PM, David Ranch wrote:
Question #1 - Does anyone know if these RT System USB cables Prolific or FTDI based?
The RT Systems cable for the VX-8 is FTDI based and has the same vendor id 0x2100. The product id for the VX-8 cable 0x9e50.
this works for me. I run it from a udev rule. /sbin/modprobe ftdi_sio vendor=0x2100 product=0x9e50
Note: if you try that by hand, it won't work if ftdi_sio is already loaded, you need to rmmod first.
On 18/01/2012 21:18, David Ranch wrote:
Hello Chrip-devel,
I've been recently emailing Dan Smith and he recommended to join this group about this:
I've heard that code is being developed for supporting the FT817 and FT857. This is something I asked for some time ago and it seems like it's about to happen! I'll be happy to do testing here.
[... cut ...]
Anyway... please let me know when the FT897 code is ready for testing and I'll give it a try!
--David KI6ZHD
Hi David the code for 817 has been already merged in the repository and now I'm working on 857. My plans are to publish 857 code not later then next monday asking all you out there to stress the code to point out any bug.
As of today the status is: - 817 (nd and not nd) is supposed to work, i have uncommitted changes in the code mainly to be able to reuse it for 857 - 857 (non nd) code can clone in and out, set most memories details but more investigation on odd split settings is needed
Someone told me that 897 is bit to bit compatible with 857, can you confirm? I mean is it really possible to clone from 857 to 897 and viceversa?
73 de IZ3GME Marco
Hello Marco, Robert,
Thanks for the replies..
the code for 817 has been already merged in the repository and now I'm working on 857.
Fantastic news!
As of today the status is:
- 817 (nd and not nd) is supposed to work, i have uncommitted changes in
the code mainly to be able to reuse it for 857
I'm curious, will this code only do memories or will it also record/restore other radio configurations as well?
Someone told me that 897 is bit to bit compatible with 857, can you confirm? I mean is it really possible to clone from 857 to 897 and viceversa?
As I understand it.. the boards in th 817, 857, and 897 are all electrically the same. The changes are only in the finals (817 is only 5W), chassis (897 has a larger display, VFO knob, internal support for battery packs). Beyond that, I think they are all the same but by no means am I an expert.
According to RT System's website, the 897, 857, and 817 all use the same cable number - USB-62:
897 / 857 - http://www.rtsystemsinc.com/yaesu_Template.cfm?yaesupage=ADMS4B
The 817 software DOES have a different part number and I'm not sure why (maybe they are programmed differently) but again, it uses the same USB-62 cable: http://www.rtsystemsinc.com/yaesu_Template.cfm?yaesupage=ADMS4A
--David
On 19/01/2012 18:13, David Ranch wrote:
I'm curious, will this code only do memories or will it also record/restore other radio configurations as well?
It simply clone in, modify memories and clone back. So the answer is that it saves/restores every thing that is included in clone operation. It seems that the whole internal storage of the radio is copied but I investigated only the memories area.
The 817 software DOES have a different part number and I'm not sure why (maybe they are programmed differently) but again, it uses the same USB-62 cable:
from a software point of view 817 != 817ND != 857 and i'm sure as we had to change the code between models. More, already the clone protocol is different. About cables as you say they are identical.
73 de IZ3GME Marco
participants (4)
-
David Ranch -
IZ3GME Marco -
Marco Filippi IZ3GME
-
Robert Terzi