Maybe I should reboot my PC or clear the cache like tech support always tells people even though that's never related to the issue or solves the problem. I've worked in IT for a very long time - reboot/clear the cache - reboot/clear the cache - reboot/clear the cache - a million bajillion times.
So here's some interesting info. Note that the apk code itself (after I decompile it) is looking for Bluetooth admin permissions. Not an allowed permissions option on the phone.
Here's some other interesting security stuff for those who may be interested. That's what I do for a living - cyber security. Not exactly ideal that it has weak security and allows accessing activity and can read/write/delete files in storage and cleartext storage of sensitive info (ie email address, MIT AI account) in the code. Also weak hash codes.
From the blocks you've posted, I see that you use a clock to verify whether the BT is connected , or not. If this clock is automatically started by the design page, this could lead to a problem.
If it fires before the BT connection has succeded, it creates the error. In other words: tthe connection block is a "blocking" block ( ) and until the connection has been successfully obtained, or the internal timeout has elapsed, the block stays there. When it has finished its job it exits with a boolean : true if success or false if timeout.
My suggestion is therefore to remove at all the clock. On the opposite you shall activate a fast clock (typically I use a 10 milliseconds one) after a successfully connection, to poll the BT client so to catch incoming BT data in 'real time', if any.
At last, if you want to still use a clock as a watchdog (allowing in any case a long period of many seconds), you can do that, but you shall start it only after the BT has been successfully obtained.
Best wishes.
you can remove rhat check completely, because once bluetooth is connected, that property will always return true no matter if the connection will get lost later
as the bluetooth protocol was designed, there is no way to detect, if a connection still is alive, therefore you have to send regularly (i.e. poll) some data to the device. And if you get an error, then you know, that the connection was lost...
Ah, ooops I didn't remember that detail, thanks @Taifun for highlighting..
So please @Gwen_Ceylon forget that suggestion (that kind of watchdog).
In effect I do my BT watchdog as follows:
every 30 seconds (or even more, with a clock) I do a handshake: i.e. the App sends one character (typically I send a '$' ) and waits for the echo from the Server (or the opposite, it is irrelevant to the scope). No echo means that the communication has ceased, therefore I popup a warning and I retry a new connection.
In @ABG 's FAQ you can find this:
The rest of my previous post (i.e. the initial clock probably too early) remains valid. Please give it a sight.
Nope.
I mean: I've always (i.e. in tenths of Arduino applications) followed the rule of the standard documentation, so why would I have used the reversed configuration (Tx instead of Rx) ?
So let me ask again where have you found that info ?
EDIT: a comon error is, instead, to forget to cross the wires (Tx to Rx) between Arduino CPU board and the BT shield, but as far as I can see in the snapshot of the wiring, this is not the case.
Yep, as I've said, according to your snapshot, they are correctly wired (and with SBT the Arduino side is working).
Have you removed the clock ?
Cheers.
) and until the connection has been successfully obtained, or the internal timeout has elapsed, the block stays there. When it has finished its job it exits with a boolean : true if success or false if timeout.
) and waits for the echo from the Server (or the opposite, it is irrelevant to the scope). No echo means that the communication has ceased, therefore I popup a warning and I retry a new connection.
