Yes, prefix mode.
I am communicating with an AVR Microcontroller. Asyncstreams prefix isnt an issue as its pretty solid.
But if the packet drops a byte or so from radio interference, or something of that nature, it will not fire the asyncstreams error, it just crashes the app instead.
If there is an extra byte in the packet, the Asyncstreams_error will fire and terminate the transaction. But if the packet comes up short, it crashes. Also if there is an extra byte in the prefix header by some unknown reason, it also, crashes.
In a 2.4Ghz noisy environment, This situation is inevitable. So far, 90% of the time I dont have a problem. But the problem I do have is that 1 packet every 1000 is malformed in a way that there is a byte missing, or corrupt prefix header, the whole app crashes, and of course the current progress while the app is running is lost. That sucks.
The packet going from the phone to the AVR if its corrupted, my firmware in the AVR will toss it out. it has its own checksum check. But the AVR replying back to the phone implements the "prefix" packet mode. My packet is encapsulated in the Async prefix so when the phone gets it, it will decode it properly and buffer it like normal using the normal asyncstream methods, and its waiting for my app to handle the UTF8 response.
its that return path from the AVR to the phone where the issue occurs of the app crashing. Not transmission from phone to AVR, as the AVR is programmed to know how to deal with it.
