There’s also a chance that some of it is due to missing a critical packet. The protocol in K40 Whisperer is somewhat bugged. It sends a packet, then sends “hello”, then reads status and deals with the status. But, there’s some chance that between packet send and “hello” that the state has changed. For example, if it’s busy, the packet is ignored. Then Whisperer sends “hello”, and read the state, but the state is now OK. – It will wrongly assume the initial packet sent correctly.
There are some packet gaps that could actually cause it to fail to respond, if it lost some important commands. For example sending “NSE…NSE” without the S1E command between them will sometimes often lock it up. Also, there’s no wait time on a busy signal it just starts hammering the board with data as fast as it can, that might not be optimal. So it gets hammered with hello packets far faster than it should ever need to be. That might actually be able to Denial of Service the board.
There’s redundancies in both the USB protocol and the subprotocol within the Nano’s protocols, it should actually survive channel noise. When I worked through the Whisperer code for K40Nano, I pegged this as a likely problem. And added a
time.sleep(0.1) to avoid it.