You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
-
Oh, ok - well that's expected I think. It's not really a crash.
nice, yes that is was I understood was happening, I was overdoing it, was gettting greedy because I was playing with your tiny dash and it was fun :)
thanks, sory for not making my self clear, it is not a problem for me, I actually swiched to running NRF.updateServices 16 times per 1 sec, one variable after the other, and only send the ones I want to be instant every 100ms, while running all the rest of the code for the toilet empty cycle, and your amazing software is not breaking a sweat on the dsd6 :)
https://github.com/enaon/sCat-a/blob/9109221dd977e7d7467cf9cbc1442445a11c7e53/app/main.js#L16
enaon
@Gordon
Oh, ok - well that's expected I think. It's not really a crash.
What's happening is you're writing a bunch of data, but because the signal strength is bad it's not able to send all of that data quickly, so at some point you call
Bluetooth.printlnand rather than lose data it waits patiently until enough other data has been sent that it can fit the text in the buffer.Put another way, if you did
Bluetooth.printlnwith 10,000 characters of data, you'd hope that you would receive all that data - even though it wouldn't fit in the output buffer and theBluetooth.printlnfunction might take a while to complete. It's the same sort of thing.Probably using raw characteristics fixes it for you because if you try and write when too much data is backed up, it just throws an exception and carries on (rather than waiting)