We are using a DA14580 in an external processor application as a central, and after a scanning procedure, our second DA14580 (a peripheral) is discovered.
Worth noting is also the fact that the scanning procedure returns 0x45 after 10 seconds (TIMEOUT), which is according to documentation expected.
app_set_mode() for central is implemented like inhttp://pastebin.com/FdkrJv5s
连接程序app_connect (charx) is implemented like inhttp://pastebin.com/WHUMmqbF
The problem is: After calling the app_connect() with the indx of the discovered device, no response is received from the
DA14580 central. Peripheral DA14580 does not receive any connect request.
msg->peers[0].addr contains the correct peripheral address, namely {0x51, 0x39, 0x2, 0x98, 0x80, 0x0}
As for the peripheral, it was tested and works (with Android, our custom Windows App with BLED112 dongle)..
P.S. After the scanning procedure is finished (0x45 error received), trying to scan again fails, i.e. no response is
received.
Looking forward to suggestions.
Hi irfansehic,
As far as i can tell the code that you ve pasted is taken from the proximity monitor for the windows application, i ve tested the parameters with the proximity monitor application and i was able to connect to a proximity reporter application (although i wasn't able to you use your parameter as a latency since you use a #define). What you can do is to check with a sniffer if the CONNECTION INDICATION is getting through the air when the app_connect() function is getting invoked.
Regarding the fact that the scanning fails, as you said the 0x45 is normal since the scanning has a timeout, are you able to track other devices that are advertising at the moment, perhaps the peripheral device stalls when a connection indication occurs and its not advertising anymore.
Thanks MT_dialog
Hi!
Thank you for the answer.
You are correct, that is the proximity monitor example from SDK5.
We don't have a sniffer so that might make things harder.
The peripheral does not communicate with other devices, and surely keeps on advertising.
Latency is 0.
Hi irfansehic,
You will have to check if the command is on the air in order to debug this and to eliminate possibilities, assuming that the message doesn't leave the air you will have to get a GAPM_CMP_EVT with operation GAPM_CONNECTION_DIRECT and somekind of status, can you check if you are able to get that response ?
Also after the first scan finishes and you try to re-scan and you dont get an advertising indication are you able to get the timeout from the second scanning, just to verify that even if you dont get any advertising indication the device is scanning indeed.
Thanks MT_dialog