Open yevgenb opened 10 years ago
Yes, when a stream errors you need to re-open it and do any app-level handling of the interrupted transfer. I think this is consistent with most other node.js streams.
Do you mind elaborating on your use case a bit? The easiest way to avoid this, if you're not doing TCP-like streaming, is to set autoAck:false
in your stream options.
The use case is simple sending sensor data - do not need 100% reliability so will try to set autoAck to false. What is the best way to re-open stream - radio.begin()?
To re-open a stream, you should just need to radio.openPipe()
. Unfortunately due to #13 you might run out of "slots" quickly if errors are frequent — in light of this, I'll try fix that one soon. In the meantime, unless you turn off autoAck you'd need to nrf.end()
and then go all the way back to nrf.connect
and create a new radio instance :-(
I'm realizing that in some situations you might want a sort of "retrying UDP" mode where the radio hardware looks for ack and retries if it doesn't get it, but if has to give up it's not an error at the stream level. I've got some other improvements I want to make to .openStream()
(#14) so this should fit in there.
Thanks for your patience!
I have tested simple "pong" test with arduino sending sensor data. It runs until first error occurred than stops. Is there anything I miss? What is the proper way of handling errors?
and console: 89340852 received at 6/6/2014, 8:20:43 AM Message Received: 89340852 89374608 received at 6/6/2014, 8:21:19 AM Message Received: 89374608 89408112 received at 6/6/2014, 8:21:54 AM Message Received: 89408112 89441900 received at 6/6/2014, 8:22:30 AM Message Received: 89441900 89476088 received at 6/6/2014, 8:23:05 AM Message Received: 89476088 Error sending reply. [Error: Packet timeout, transmit queue flushed.]