<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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? <div dir="auto"><br></div><div dir="auto">-Nathan</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jun 15, 2017 3:26 PM, "Dan Smith via chirp_devel" <<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> +def _rt23_write_block(radio, block_addr, block_size):<br>
> + serial = radio.pipe<br>
> +<br>
> + cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE)<br>
> + data = radio.get_mmap()[block_addr:<wbr>block_addr + BLOCK_SIZE]<br>
> + cs = 0<br>
> + for byte in data:<br>
> + cs += ord(byte)<br>
> + data += chr(cs & 0xFF)<br>
> +<br>
> + LOG.debug("Writing Data:")<br>
> + LOG.debug(util.hexprint(cmd + data))<br>
> +<br>
> + try:<br>
> + for j in range(0, len(cmd)):<br>
> + time.sleep(0.002)<br>
> + serial.write(cmd[j])<br>
> + for j in range(0, len(data)):<br>
> + time.sleep(0.002)<br>
> + serial.write(data[j])<br>
> + if serial.read(1) != CMD_ACK:<br>
> + raise Exception("No ACK")<br>
<br>
This inter-byte delay timing is rather unfortunate. I assume your<br>
testing shows that this is the only way the radio will accept the image?<br>
<br>
It takes a hair over 1ms to send a single byte at 9600 baud. Sleeping<br>
for 2ms in between means you're sending one byte every 3ms, which is<br>
crazy slow. Do you see the factory software actually writing one byte at<br>
a time in the trace? As we've covered before, doing sleeps at this<br>
granularity requires the operating system to schedule you pretty<br>
regularly to keep up the stream, which is both wasteful and error-prone<br>
of the system is loaded. It also increases the likelihood that the<br>
driver will behave differently on Linux, Windows, and with differing<br>
serial hardware.<br>
<br>
Have you tried doing something like writing 8 bytes at a time, with a<br>
sleep in between or something like that?<br>
<br>
--Dan<br>
______________________________<wbr>_________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.<wbr>danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/<wbr>mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/<wbr>projects/chirp/wiki/Developers</a><br>
</blockquote></div></div>