[chirp_devel] [PATCH] [New Model] Support for the BTECH Mobile Radios, update 1 for #3015

[M.Sc. Pavel Milanes Costa]

El 27/03/16 a las 17:42, Dan Smith via chirp_devel escribió:
>>   def _rawrecv(radio, amount):
>> >-    """Raw read from the radio device, new approach, this time a byte at
>> >-    a time as the original driver, the receive data has to be atomic"""
>> >+    """Raw read from the radio device, less intensive way"""
>> >+
>> >      data = ""
>> >  
>> >      try:
>> >-        tdiff = 0
>> >-        start = time.time()
>> >-        maxtime = amount * 0.020
>> >-
>> >-        while len(data) < amount and tdiff < maxtime:
>> >-            d = radio.pipe.read(1)
>> >-            if len(d) == 1:
>> >-                data += d
>> >-
>> >-            # Delta time
>> >-            tdiff = time.time() - start
>> >-
>> >-            # DEBUG
>> >-            if debug is True:
>> >-                LOG.debug("time diff %.04f maxtime %.04f, data: %d" %
>> >-                          (tdiff, maxtime, len(data)))
>> >+        # Getting the data with a dynamic timeout in the serial deppending on
>> >+        # the amount of data we need
>> >+        timeout = amount * 0.06
> This really doesn't make any sense: the value of timeout doesn't need to
> be greater if you're reading more data. The select() call that pyserial
> is making doesn't know how much data you're asking for, it only reports
> whether there is*any*  data to be read from the descriptor. Further,
> pyserial cuts down the timeout each time through the read loop, if it
> has to go again. That means that if you're a little late on the first
> read loop, your timeout is cut down even further in the second and
> subsequent loops. Eventually that will end up cutting your timeout down
> to very small (i.e. less than a byte interval) value, which will make
> this unreliable. It might be good to review the implementation of
> pyserial's read code:
>
> https://github.com/pyserial/pyserial/blob/master/serial/serialposix.py#L470-L516
>
> This is why you need to be processing incoming data into a queue if
> you're having trouble with the timing bits. Relying on the timeouts like
> you are is only going to work in lucky situations where you start your
> read with enough timeout remaining to process the full block.
>

Good to know about the shrinking of the timeout by using this. I will 
review the pyserial code now to better understand the issue.

Can you point me to a example of the queue schema you mention here?

73
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160327/fbeb9635/attachment-0001.html