The other thing to try is setting the latency of your USB serial adapter in the driver advanced tab. I have car tuning gear that requires this.
By default the latency setting is a bit high for a lot of USB serial dongles. It increases efficiency at the cost of reduced speed. Akin to the Nagle algorithm in networking maybe?
-Nathan
On Jun 15, 2017 3:26 PM, "Dan Smith via chirp_devel" < chirp_devel@intrepid.danplanet.com> wrote:
+def _rt23_write_block(radio, block_addr, block_size):
- serial = radio.pipe
- cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE)
- data = radio.get_mmap()[block_addr:block_addr + BLOCK_SIZE]
- cs = 0
- for byte in data:
cs += ord(byte)- data += chr(cs & 0xFF)
- LOG.debug("Writing Data:")
- LOG.debug(util.hexprint(cmd + data))
- try:
for j in range(0, len(cmd)):time.sleep(0.002)serial.write(cmd[j])for j in range(0, len(data)):time.sleep(0.002)serial.write(data[j])if serial.read(1) != CMD_ACK:raise Exception("No ACK")This inter-byte delay timing is rather unfortunate. I assume your testing shows that this is the only way the radio will accept the image?
It takes a hair over 1ms to send a single byte at 9600 baud. Sleeping for 2ms in between means you're sending one byte every 3ms, which is crazy slow. Do you see the factory software actually writing one byte at a time in the trace? As we've covered before, doing sleeps at this granularity requires the operating system to schedule you pretty regularly to keep up the stream, which is both wasteful and error-prone of the system is loaded. It also increases the likelihood that the driver will behave differently on Linux, Windows, and with differing serial hardware.
Have you tried doing something like writing 8 bytes at a time, with a sleep in between or something like that?
--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