From reading the spec for Device::SerialPort and looking at the CAT manual for the FTDX-1200, I figure that haukex has it right -> all you need to do is write_settings to send all of the device settings to the device before starting to use the serial port. Evidently statements like $port->parity("none"); set some parameter in a data structure, but the method does not actually send that info onto the actual device.
For testing, I would put a sleep(x seconds) after: $port->write("FA21050000;");. If the VFO-A command doesn't work, the fancier command for VFO-B probably won't work either! I didn't see any timing restrictions in the CAT manual, but for testing, I would pause and just look at the radio display to see what, if anything, happens on the display before immediately sending (or trying to send) another command to the radio.
I don't know the reliability that you expect from your application. You are controlling a piece of hardware. Hardware makes mistakes for a variety of reasons. The idea of send command, e.g. "FB;" and then wait with a read() until exactly 11 bytes have been returned, will work virtually all of the time, but not all of the time. This detail may not matter for your application. But best practice would be to "timeout" a blocking input request like that so that your program does not "hang". A perhaps contrived example: radio is powered off after 5 of 11 bytes have been sent to you. Radio is powered back on. It will not send anymore bytes, but you will still be waiting to read some bytes which will never come. In that example, what is the probability of this happening? Very, very low. But, there are other reasons why this same sort of thing could happen. In general, if it can happen, it will happen. It is just a matter of "how often".
I am curious as to your actual application and whether or not you have to co-exist with some other application?
My friend has two apps which want to talk to the same radio serial port. You can't just willy-nilly "y" the cables from 2 different serial ports together. That actually will work a lot of the time, but not all of time! What is desired is a "man in the middle" box. This box talks to the single "real serial port", but looks like two separate virtual ports to 2 different applications. If App A sends "FB;", it gets the response to that command before sequencing in perhaps an "FA;" command from App B. This man-in-the-middle is the "traffic cop" so that the radio only "hears one single voice" and is completely unaware that there are two end user apps out there.
I see how to to talk to the USB->Serial Port. But I am unsure how to make my software look like a serial port (COM port) to other applications?
My traffic cop app will be Windows based.
In reply to Re: Cannot write to, or read from, the SerialPort
by Marshall
in thread Cannot write to, or read from, the SerialPort
by macdev
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |