The first one can be easily supported in icf.py. The weirdest, when writing the checksum, if the checksum > 249, the checksum becomes two bytes: 0xff, checksum & 0x0f.The bytes coming out of the radio need to be decoded by having their high-order bit flipped (^= 0x80). ![]() The differences I've found so far for the new driver: Status update: I have successfully written to my IC-2730A with Chirp! I am still working on finishing mapping the memory (need to map out skip settings and the two call channels, at least, and see if there's anything else). The Icom Cable is 3 times the price and I want to find something that will likely work with Chirp once someone else, or myself get around to trying to write a driver for it. I will give him a fair shake before, I go down the dispute road. I am waiting to hear back from the cable guy, he mentioned about sending another cable, but I haven't heard from him since Friday. It seems like it is garbling text in one direction. Maybe I will see if I can find an older driver just to see. So it recognized the FTDI chip, but doesn't get farther than that.likely because of the test results above.įrom your post above Rob, I am wondering if it could be a driver issue / counterfeit chip. I get a different error with the generic OPC478 cable, It seems like it tries, but comes back and say that the transceiver is not responding. When I try to connect to it it gives me the error that it cannot connect to that comport, even though it works fine with CoolTerm (yes CoolTerm is closed). I wanted to see if I could breadboard an interface to bypass the cable and rule out the radio using the CP2102, but the Icom software doesn't seem to like that chipset for whatever reason. My guess is there is something either internally wrong with the chip or there is something wrong on the cable side circuitry, perhaps a solder bridge? The CP2102 is validated as working in the above test, It receive it's own loop back on the chip set, but it doesn't seem to get out the cable. Generic OPC478 cable (FTDI) to Silicon Labs CP2102 UART Bridge - TX from CP2102 is received by OPC478 but garbled characters, TX sent from OPC478 is not received by CP2102. ![]() Wouxon/Baofeng Cable (FTDI) to Silicon Labs CP2102 UART Bridge - This has no problems communicating in either direction.I tried some additional test with other interfaces and the OPC478 cable.Ĭomputer to Computer (CoolTerm) - Same port settings I wouldn't think it would do that if it is a half duplex cable. I can get it to do a loop back test on itself and get legit data back, but that is without it plugged in. The weird thing is, it shows up in device manager and gets a port number. Well I did some more testing last night with the cable. Do you have any trick to make it work? Do I need to set my baud rate, parity, stop bits, etc to a certain value? So I am getting 2 different errors from the icom software depending on the converter being used. The comport works just fine in a loop back test. I tried another usb/serial converter (Silicon Labs CP2102) and tried to breadboard an interface, but when I try to communicate with the radio the Icom software tells me that it cannot find find/open the com port. It is suppose to be a half duplex cable I believe, but without the cable plugged in I can do a loop back test on it with a terminal program.which I find weird. ![]() The cable shows up in device manager with a com port number but when I start the Icom software, it lets me select the port, but gives me an error that it cannot communicate with the transceiver. I cannot get the Icom CS-2730 software to work. I don't know if there is issue with the cable or not, I am still trying to work that out with the vendor. Mine has the FTDI chipset in it where I think the one you listed on Amazon has the Prolific chipset. Rob, I just purchased a similar cable from a vendor on eBay that does programming cables.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |