Connection problem

RE: Connection problem

Hung Bui — Mon, 31 Jul 2017 13:09:20 GMT

I'm also confused. You need to find a better way to describe what you are asking about. It's UART signal or it's BLE packet. Please don't mix them up.

RE: Connection problem

endnode — Fri, 28 Jul 2017 18:54:38 GMT

...(2/2) if your problem is really between BLE_GAP_EVT_CONNECTED event and some subsequent application data exchange over GATT then you probably have too long connection interval and/or do unnecessary long GATT Service Discovery from GATT Client side (I suppose that runs on GAP Central side). Doing simple BLE radio trace would tell you all the details and you would have clarity in few minutes. Just for your information you don't need to settle down with ~250ms for GATT Service discovery, if you use short interval (which is recommended if you want to save power and both sides support it!) and do it properly (= look only for service(es) you need instead of full enumeration) then you can easily discover your custom service + characteristic + enable notifications through CCCD in less then 70ms (with 7.5ms connection interval), maybe even less.

RE: Connection problem

endnode — Fri, 28 Jul 2017 18:49:42 GMT

No no no, we don't understand each other;) These levels on oscilloscope are some wires so the question is how you generate that signal. Is it debug UART or just some GPIO high/low signalling? How you detect radio events and transfer it to these levels (interrupt, PPI, some mixed method e.g. with scheduler...)? That can make single digit up to several dozens of millisecond itself as systematic error. Yes, it doesn't explain full 200-300 delay but it's important to understand what are we looking at. Now if really GAP Central devices starts with Power On Reset event then obviously it needs to boot (so start-up itself and enabling of all modules including Soft Device costs you some time) and HF + LF clock start can take 200~300ms on nRF52 (read the spec!) but... (1/2)

RE: Connection problem

Ken — Fri, 28 Jul 2017 16:59:10 GMT

Hi endnode & Hung Bui, thanks for the reply

1.The yellow line is the central UART receiving the TX signal from the external MCU. 2.The blue line is Central from the peripheral BLE radio to receive the UART TX signal. 3. Pink is the peripheral UART receives the TX signal from the external MCU.

I would like to use the central and peripheral BLE modules as UART to BLE radio bridges, Yes, as described by endnode, I hope that GAP Central will connect and communicate with peripherals immediately after booting and starting scanning. My goal is to turn Central power on -> to exchange messages -> to turn off Central power.

The current difficulty is that the central power supply can really send the message too long, resulting in power consumption too high, thanks to the flood reminders, I think 272ms should be found when the service, there is no way to shorten this time?

RE: Connection problem

Hung Bui — Fri, 28 Jul 2017 14:32:48 GMT

I have same question as endnode, what trigger the toggle on the 3 lines ?

I suspect the first 272ms was the time it take to do service discovery. It would be clearer if you can provide a sniffer trace.

RE: Connection problem

endnode — Fri, 28 Jul 2017 11:44:54 GMT

To be sure what exactly are these 3 colorful lines? How "close" are you to actual processing code on nRF MCU? Also what is your exact set-up and sequence? Is GAP Peripheral running indefinitely and only GAP Central is power on at the beginning of test? And you expect that GAP Central will connect and communicate with Peripheral right after it boots and starts scanning? Also what exactly is happening on BLE radio? That can show you which device is the bottle neck and in which phase...

RE: Connection problem

Ken — Fri, 28 Jul 2017 11:09:07 GMT

thanks, your response. You can refer as below link for the measurement of the waveform,. link text

RE: Connection problem

endnode — Fri, 28 Jul 2017 08:19:15 GMT

OK so this makes it even more confusing;) What is exact configuration of your test system and sequence of steps? Can you take RF trace by some BLE sniffer? Then you can clearly say what part is spent before even GAP Peripheral starts advertising, then how long it takes to GAP Central to pick-up the advertisement and issue CONNECT_REQ and finally how long the LL and GATT procedures take before any meaningful exchange happen on APP layer. Without this you can hardly debug and optimize your set-up. There can be many easy/stupid mistakes or misunderstandings like nRF5x starting with LF crystal takes 200-400ms just there so you need o use internal RC or synth from HF if you require start in <100ms range etc.

RE: Connection problem

Ken — Fri, 28 Jul 2017 01:48:55 GMT

Sorry, I did not describe it clearly, I was not talking about the connection time, We use two nrf52832 modules and use the example ble_central \ ble_app_uart_c With ble_peripheral \ ble_app_uart_c, When the two ends ble module connection is successful, Cental ble module needs 200ms to receive RX message, we use the oscilloscope to measure the signal.

Do we want to have a function that can send messages quickly after power-up, can we recommend features? (Mesh..or etc ...)

RE: Connection problem

endnode — Wed, 26 Jul 2017 21:44:18 GMT

Do you use GATT Client/Server architecture? If so then you are even lucky if you see GATT Server Discovery only 200ms long, usual phones will take 600-1500ms even for the minimal GATT Server configuration. If you have control over both sides of the link (e.g. two nRF5x devices running against each other) then you could debug and optimize (with minimal 7.5ms connection interval and GATT Service Discovery you should still be able to do it within 100ms, probably less). In every case such problems should be always debugged with RF analyzer (sniffer), that will tell you immediately where you are loosing 200ms (it can be on-air procedures and then you can see which side does i and maybe change it or at least understand why, it can be even invisible on radio which signals that one of the sides hangs in higher layers and should be debugged...)