I have increased the delay between two data transmissions up to 5 sec but still not working. Sometimes the BT_status stuck at Disconnecting
whereas device is still connected to the DK as it continue to send data, but sometimes it BT_status just immediately get changed to Disconnected
and once in a blue moon it actually get disconnected. It seems like very random.
... Maybe Nordic have something slightly unconventional (not unusual for them).
I am finally able to disconnect it from the app and this time I changed the way I was connecting. Now I am simply connecting with the selected device from the list view for connection like this.
Disconnection:
I tested this 5 times and every time it disconnected.
I don't know why connecting with a device differently made it work. Because this is the previous connection block when disconnection was not working.
I am not sure how these connection blocks work in the backend code.
Is there any way to get script for these block so that I can have a look at how they execute differently?
Thank you
Doing some more experiments I found that the if I pick one device from the device list and connect using the following method then it works fine for disconnection.
But if do auto selection then disconnections stops working, like by checking conditions contains then set Listview.selctionIndexto Item and then
call.BLE1.connectet Index Listview1.SelectionIndex` then disconnections does not work.
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.
I would expect a microcontroller to have a static MAC address, but increasingly devices are enabled to have dynamic addresses for security reasons.
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)?
will gives error because the full string come with square bracket,
Not if you pick it as a List Item.
No. send(value1); delay(200); send(value2); delay(200);
I thought you had ditched the Clock in favour of registering for values?
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.
No. send(value1); delay(200); send(value2); delay(200);
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