if you run debug traces, shouldn't it show you the disconnect reason? then you can match it with the BLE spec sheet.
how do I set-up debug traces, I'm using a bcm20736s and I'm programming it via an FTDI?
It is most likely that hello_sensor is the one that disconnects. Client, your phone, won't really disconnect unless it sends a disconnect request or gets out of the range.
As far as I know, there are two reasons why hello_sensor will disconnect.
Either hello_sensor will disconnect because of the connection idle timeout or because of the pending SMP request(pairing).
Are you pairing with hello_sensor? If not, disconnection probably occurs because of the latter reason.
In connection_up function:
lesmp_pinfo->pairingParam.AuthReq |= LESMP_AUTH_FLAG_BONDING;
Either try pairing with hello_sensor or try commenting out these two lines if you want to prevent disconnections.
If you've changed this variable hello_sensor_stay_connected to be 0, then hello_sensor will disconnect after .con_idle_timeout (seconds) defined in the app configuration. The default value of hello_sensor_stay_connected is 1 and so unless you've changed this value, you really won't get disconnected from the connection idle timeout.
If you think your application is disconnecting because of the connection idle timeout, you can either put 0 for .con_idle_timeout in the configuration or call a function like bleprofile_StopConnIdleTimer. This is a function defined in the hello_sensor. You can define your own function similar to this and call it somewhere in your app.
I'm guessing your phone is not pairing with hello_sensor properly, hence the disconnection.
Let us know if this helps.
I already have that enabled and when I do monitor the trace I don't get any error codes except those I put put in such as connection down. I've seen the term air trace over the forums, does this require extra hardware i.e. a packet sniffer or is it a matter of enabling it ?
I do pair with hello_sensor and I've had the connection up for over a 1000 seconds and no disconnections and in some cases connection is down within 100. hello_sensor_stay_connected is set to 0 but I've also set con_idle_timeout to 0. Take it the sensor can't terminate a connection on it own?
I had some more questions about pairing if you don't mind, I've not changed anything with regards to pairing from the example and I was wandering if it' possible to have pairing require a key so that when the phone requests to pair it's then prompted to enter a key/code sort of like classic Bluetooth?
on the topic of debugging my module will sometimes restart randomly for example after successfully flashing new code I remove the TX line and then restart the module to view the trace the module will restart sometimes for as much as 4 times before operating normally. I also have a button that triggers an interrupt, this is pulled down by an external 10k resistor, and I've noticed every now and again this interrupt will cause a restart and I was wandering if there was a way to see what caused the restart even is it's a varible that I can maybe write to nvram and then read on my next restart?
Try changing hello_sensor_stay_connected back to 1. I believe you are right in that if you change .con_idle_timeout to 0, there will be no disconnection at least from the connection idle timeout. However since we don't know the source of disconnection, lets try to reduce the number of variables. See if disconnection still occurs even after you changed hello_sensor_stay_connected back to 1. If it does, then it is most likely either pairing or your interrupt that is causing the disconnections.
Now to eliminate the pairing as the cause of disconnection, try commenting out
lesmp_pinfo->pairingParam.AuthReq |= LESMP_AUTH_FLAG_BONDING;
in connection_up function. If disconnection still happens, it is probably your interrupt that is the root cause unless you made other changes to hello_sensor.
In that case: What are you doing in the interrupt function? Which pin are you using for the button interrupt?
Your phone isn't likely causing the disconnection, but just curious which model are you using?
To answer your question about requiring key in pairing, there's something called passkey pairing.
Hello_sensor has everything set up for passkey pairing. You just need to uncomment the line that defines PASSKEY_PAIRING.
There is a little instruction for setting it up at the top of hello_sensor.c. The line that you need to uncomment appears right after the includes.
If you upload your code with indications to your changes to the original hello_sensor, I'll be happy to test it with various mobile devices here.
The interrupt function increments a value every time it' called, I had to do a software debounce with an if statement as the interrupt is called twice instead of just on the rising edge, this is a temp fix that works just now, it also starts high adv if connection is down and read the variable from nvram before is increments and write it back to nvram. I thought maybe it had something to do with nvram, so I tried commenting this out and this still happened.
I have a customs app running on a LG G2, I thought it was maybe the app but the app was tested using the Hello_Sensor example with no disconnections at all so it can't be that unless if LG's BLE chip has some disconnection parameters such a if connection is idle for x time disconnect, just guessing here.
I noticed something odd earlier, with regards to reboots at start, the app is will attempt ti reconnect to the module if connection is lost, so this means after a random reboot the app will try to reconnect, is it possible that the phone attempting to reconnect will cause issues if say the module is halfway through the create function?
while using an arduino I while back I had random reboots because I was running out of ram could this also be happening here, if so that wouldn't explain reboots at the start or when a reboot is followed by a series of subsequent reboots?
Thanks for the help with passkey, I'll start work on that just now and update you as to how that goes, I've also attached my code as you asked, thank you for all your help
dose_counter.zip 16.1 K
I tried your dose counter.
It seems like it works fine. I don't have any problems with disconnections after a proper pairing.
But I've only tested when the device is idling.
I didn't know how to interact with dose_counter so I couldn't do anything else.
Can you tell me more about how to use the app?
My only guesses as to why you are having disconnection issues are pairing and MAYBE LG G2.
When you pair, do you see the BLE device as a paired device when you go to Bluetooth Setting?
Because when I paired with the device, I was able to stay connected without any disruptions.
Since Android devices have a wide range of hardware implementations, it can be your phone that is disconnecting. (but I doubt this is the problem)
But maybe LG's implementation of BLE stack is different from ours. I'm not sure about this one.
Have you tested your app on a different Android device?
As for the "reboots", I didn't experience this either.
I don't know how you are programming your Android app, but you can make it so that the app doesn't autoconnect after connection is lost unless this is one of your app's feature. However, I don't think this will cause any problems. I think it might be just ignored since the BLE device is not ready.
I was just skimming through your code (I'll take closer look later) but I did noticed that you never reset some of the variables you are using. (correct me if I'm wrong).
You've defined some variables to be UINT32 and it will take a very long time to reach the maximum values, but it can eventually create an overflow bug.
It might not be the biggest concern right now, but I thought it was something to fix later.
Dose counter measure the dose a user enters via the button using an interrupt connected to button and if the interrupt doesn't fire for 2 seconds this dose is then transmitted to the app if paired, if it's not paired the dose is saved in nvram. so all you need to do is pair with the device and register for either notifications or indication and you should get a number corresponding to your button presses. did you by any chance have a loop at the interrupt set up and see why it fires on both edges?
The module does pair with the device and does show up under paired devices. I'll be able to get another device next week I agree it's unlikely this is the cause, can I ask what you used for your testing?
The reboots are however my biggest issue atm, I was wandering if it's at all possible to to find out what caused the reboot, maybe a flag in a register somewhere?
these variables are used to hold time from the seconds timer and figured since I'm making use of deep sleep and the module under normal operation shouldn't be awake for more than a few minutes when I go to sleep they would all get reset but I'll start patchin this just in case, thank you. I was curious if you how an overflow would affect the module?
I used Nexus 7, 9, and iphone 5.
I've talked to few other FAE's about your issues.
For firing interrupts on both edges, it might be because of the switch bouncing.(but seems like you fixed this problem in your code)
But when I scoped the signal, it seemed to be clean. You might want to scope it yourself.
For the reboot problem, it might be crystal warmup issue(?) if you using a SIP design.
These are just conjectures; I'm sorry I can't answer your questions definitively.
As for the integer overflow, the value might loop around causing a logic error somewhere.
I don't think it will cause a major problem like shutting down the app.
I'll ask the developers if there are any flags indicating what caused the reboot.
According to the developers, there are no such reboot flags unfortunately. Sorry.
Are you still having issues with the reboot?
If you are, can you elaborate more on that?
Do you think the random reboots are the cause of the disconnections?
Are there random reboots only when you are trying to view traces?
previously you said:
" on the topic of debugging my module will sometimes restart randomly for example after successfully flashing new code I remove the TX line and then restart the module to view the trace the module will restart sometimes for as much as 4 times before operating normally. "
It's hard to understand the bug, because when I run your code on Tag 3, I don't run into any problems.
Are you using SIP design?