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.