To automate, save the ListView Selection, not the index.
This block only accept the index not the selection that is why I must pass the Selection Index
There is something that is making disconnection work in-between auto selection and manual picking of the list item.
Although the following two blocks look same as in the lower block selection is done manually by tapping on the device I want to connect and disconnection work fine, whereas in the upper block selection is done automatically but disconnection doesn't work.
Which early-on (post #44) I said you should use but you reported that it failed?
Post#44 is about connecting automatically by selecting the device that contains the particular device name.
The point is still uncleared how connecting with picking a device manually is ok but picking automatically to connect make disconnect stop working.
Didn't you try picking automatically with a chunk of the address string? It would probably work with the whole of the address string.
No. When you pick automatically one device with particular name then using connect.withaddress will gives error because the full string come with square bracket[ ], MAC adddress, device name and power.
I also tried to just show one device with desired device name in the listview and then pick it manully and connect to that device and surprisingly it never connects.
So conclusion is to just stay away from changing or manipulating devices in listview and use the standard way that is show all devices in the list view pick one and connect to the selection index.
I would expect a microcontroller to have a static MAC address, but increasingly devices are enabled to have dynamic addresses for security reasons.
New issue. This time I am sending data from DK to the app periodically every 200ms and I send two different values. If I increase the app clock time interval more than 400ms like 500ms in the app than clock will start to behave differently the clock will stop getting timer ticks regularly every 500ms instead it will tick randomly tick maybe after 3sec or 7 sec or maybe 1 minute.
Well the MAC is same all the time only difference is if you simply use BLE.DeviceList every thing will be fine but if you manipulate it by put this into a different list and do operations like getting a particular device then it will not work. I am not sure if the problem is in BLE extension or the way BLE extension and other things list or listview communicate with eachother.
... I thought you had ditched the Clock in favour of registering for values? Also, are the two values sent as a single stream (e.g. Val1|Val2)?
Not if you pick it as a List Item.
No. send(value1); delay(200); send(value2); delay(200);
I have skipped the timer in the app that was used to read value I am only using timer if one of the value increases by a certain number than timer will start and record the time. But as you suggested to not use 1ms delay instead use 1000ms and I found it does not work at time interval greater than 400ms.
Don't do that - send it as a single package and separate at the delimiter in the App. If these are sensor values, delay() should not be used, instead use elapsed milliseconds.
I'm away from my desk now, going for a Covid jab. Back in the evening UK time.
I caught your post in the last community newsletter/ forum summary email.
In these cases you also need to check your firmware on the nRF52833 board. The default behaviour within the nRF52 SDK or nRFConnect library is to complete all tasks before disconnecting and sending the acknowledgement back to your app.
What you have been doing is bombarding your nRF52833 with read requests every 200ms which does not leave much time for the nRF52833 firmware to respond to each read request. What happens is that it sends back a value even if it is not a new value or if you are waiting for a read request to then calculate a new value, it has to do so and then return the value within 200ms. I suspect you are locking things up.
This is why it is regarded as better practice to rely of the notify attribute. Then your nRF52833 will notify the central device of a new value. This reduces wireless traffic. As such, as has been suggested, it is better to the "registerfor" methods to obtain fresh data within in your App Inventor app and get rid of that timer altogether.
You will then find that you can disconnect without problem.
Hi @Gerriko_io
I appreciate your effort in going through this topic and giving your suggestion.
I changed my nRF52DK firmware so that now nRF52DK is sending notifications and my android app is receiving this data using (RegisterFor). Even I tried to increase the interval of notifying data up to 1 Sec but still disconnect is not working as it should be.
So, doing different experiments I found that if I use the normal way of connecting to nRF52DK then disconnect will work all the time. By normal way I mean the following:
But if I try to automate the connecting process (Select a specific device automatically and connect to it) OR (just display the device with a name that I want to connect) then disconnect will not work.
I automated it using two different ways shown in the following picture:
**----------------------------------------------------------------------------------------------------------------------------------- **
**----------------------------------------------------------------------------------------------------------------------------------- **
Means if I try to automate the device selection process or connection process then disconnect will not work.
Thank you
Hi @androidz
Thanks for the personalised update. Hmmm, ok. I think I can see where your problem is with your automated process.
It's a guess as I'm not to able to test but I would suggest you try inserting a "BluetoothLE1.StopScanning" method once you have found your match and make sure it is used before the "call BluetoothLE1.Connect" method and see if that makes a difference.
Hope that helps. Best of luck with your project.
2 Likes
Wow, it is working now.
But can you please explain how calling BluetoothLE1.StopScanning before calling BluetoothLE1.Connect.Index is making disconnect work.
Thank you
I do not know specifically, it's always done that way in examples as best practice (including in my sample template files).
... it's possible that another device is found and added to the address list, which will then potentially change the address indexes as the list is auto-sorted.
It is better that the code performs logically and is not continually running a function when it is no longer required, the App scan could clash with the Arduino send for example.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.