[chirp_devel] Pipe Isochronous Transfers

[Dan Smith]

> 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