[chirp_devel] Pipe Isochronous Transfers
How do I set my radio.pipe.mode to Iscochronous (no handshake) for read? I am working on a driver for the R/S PRO-649 scanner, and it responds to the dump command with a continuous transfer of 4096 bytes.
Are you sure you want/need ischronous mode?
Isochronous (e.g. in USB or 1934/Firewire) type pipes are typically only used for constant bit rate audio or video streams.
Chirp deals in serial ports.
Perhaps you want to turn off serial port handshaking?
It is off, by default unless the class sets HARDWARE_FLOW class variable.
If you want to double check the flow control settings, you can look at:
radio.pipe.rtscts radio.pipe.dsrdtr radio.pipe.xonxoff
-ch
On Sun, Feb 11, 2018 at 11:18 AM, Rick DeWitt via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
How do I set my radio.pipe.mode to Iscochronous (no handshake) for read? I am working on a driver for the R/S PRO-649 scanner, and it responds to the dump command with a continuous transfer of 4096 bytes.
-- Rick DeWitt AA0RD Sequim, Washington, USA 360-681-3494
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
It appears I need the isochronous mode. I've tried all possible combos of xonxof, rtscts and the unused dsrdtr. I've got the baudrate, parity, bytesize and stopbits set so that my dump command is properly sent and echoed. At that point the radio begins an un-synched dump of all memory; which the port buffer ignores. I've tried single and multiple byte reads, repeating the dump command, etc. I use the same port settings for the upload, which is 1-byte at a time, and they work fine.
The original programming s/w (ScanCatLite) also has this problem! It trips a timeout after commanding the download. I have tried some obvious non-dump download command strings, but no joy yet.
FYI: The download/dump mode is intended to allow you to clone from one radio to another.
Rick DeWitt
AA0RD Sequim, Washington, USA 360-681-3494
On 2/11/2018 4:04 PM, Christopher Hoover wrote:
Are you sure you want/need ischronous mode?
Isochronous (e.g. in USB or 1934/Firewire) type pipes are typically only used for constant bit rate audio or video streams.
Chirp deals in serial ports.
Perhaps you want to turn off serial port handshaking?
It is off, by default unless the class sets HARDWARE_FLOW class variable.
If you want to double check the flow control settings, you can look at:
radio.pipe.rtscts radio.pipe.dsrdtr radio.pipe.xonxoff
-ch
On Sun, Feb 11, 2018 at 11:18 AM, Rick DeWitt via chirp_devel <chirp_devel@intrepid.danplanet.com mailto:chirp_devel@intrepid.danplanet.com> wrote:
How do I set my radio.pipe.mode to Iscochronous (no handshake) for read? I am working on a driver for the R/S PRO-649 scanner, and it responds to the dump command with a continuous transfer of 4096 bytes. -- Rick DeWitt AA0RD Sequim, Washington, USA 360-681-3494 <tel:360-681-3494> _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com <mailto:chirp_devel@intrepid.danplanet.com> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel <http://intrepid.danplanet.com/mailman/listinfo/chirp_devel> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers <http://chirp.danplanet.com/projects/chirp/wiki/Developers>
It appears I need the isochronous mode.
There is no such thing in standard serial mode that I know of. There is an isochronous mode in the raw USB protocol, but we don't have access to it from the serial layer, nor do we need to as it's purely a detail of how the line discipline and driver talk to the actual device.
I've tried all possible combos of xonxof, rtscts and the unused dsrdtr. I've got the baudrate, parity, bytesize and stopbits set so that my dump command is properly sent and echoed. At that point the radio begins an un-synched dump of all memory; which the port buffer ignores.
I'm not sure what "port buffer ignores" means. We have drivers for lots of radios that dump lots of information all at once, which works fine. If the device is really kicking over to some weird mode and not sending the data in a way that the standard serial emulation driver can receive then I'm not sure there's much we can do about that.
I've tried single and multiple byte reads, repeating the dump command, etc. I use the same port settings for the upload, which is 1-byte at a time, and they work fine.
All of these are a long ways up the stack from what you're describing and don't really have much effect on the transport of data from the device to the kernel, where it is buffered (almost indefinitely) until you read it.
The original programming s/w (ScanCatLite) also has this problem! It trips a timeout after commanding the download. I have tried some obvious non-dump download command strings, but no joy yet.
FYI: The download/dump mode is intended to allow you to clone from one radio to another.
Over regular RS-232 serial right? If so, then there's no special mode for this. RS-232 is really (really) simple and doesn't have multiple methods of transport like USB does. I assume you're using a USB to serial adapter to talk to the actual scanner right? If so, I'd try a different one.
--Dan
Thanks for the info. I'm now pretty sure that there is an alternative, non-dump download mode for this device. Upload is working great. Hacking various download commands is in-work....
Rick DeWitt AA0RD Sequim, Washington, USA 360-681-3494
On 2/12/2018 8:06 AM, Dan Smith via chirp_devel wrote:
It appears I need the isochronous mode.
There is no such thing in standard serial mode that I know of. There is an isochronous mode in the raw USB protocol, but we don't have access to it from the serial layer, nor do we need to as it's purely a detail of how the line discipline and driver talk to the actual device.
I've tried all possible combos of xonxof, rtscts and the unused dsrdtr. I've got the baudrate, parity, bytesize and stopbits set so that my dump command is properly sent and echoed. At that point the radio begins an un-synched dump of all memory; which the port buffer ignores.
I'm not sure what "port buffer ignores" means. We have drivers for lots of radios that dump lots of information all at once, which works fine. If the device is really kicking over to some weird mode and not sending the data in a way that the standard serial emulation driver can receive then I'm not sure there's much we can do about that.
I've tried single and multiple byte reads, repeating the dump command, etc. I use the same port settings for the upload, which is 1-byte at a time, and they work fine.
All of these are a long ways up the stack from what you're describing and don't really have much effect on the transport of data from the device to the kernel, where it is buffered (almost indefinitely) until you read it.
The original programming s/w (ScanCatLite) also has this problem! It trips a timeout after commanding the download. I have tried some obvious non-dump download command strings, but no joy yet.
FYI: The download/dump mode is intended to allow you to clone from one radio to another.
Over regular RS-232 serial right? If so, then there's no special mode for this. RS-232 is really (really) simple and doesn't have multiple methods of transport like USB does. I assume you're using a USB to serial adapter to talk to the actual scanner right? If so, I'd try a different one.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (3)
-
Christopher Hoover -
Dan Smith -
Rick DeWitt