Send the packet from peripheral to central, why see the current pulse about 1000ms later

RE: Send the packet from peripheral to central, why see the current pulse about 1000ms later

Einar Thorsrud — Mon, 17 Feb 2025 09:52:57 GMT

Hi,

I am not sure I understand how to read the latency from these current measuremetns. Can you elaborate mor on how you test? At which points in the code do you consider the data sent and received, and can you toggle GPIO's on those and meaure with a logic analyze or similar?

[quote user="James168"]2) Is there a simpler sample than peripheral_uart and central_uart to just send the packet periodically, I can check if it has unexpected current pulse or not.[/quote]

The central /periphearl UART (NUS) samples are probably the simpest samples for exchagning data in a connection.

RE: Send the packet from peripheral to central, why see the current pulse about 1000ms later

James168 — Mon, 17 Feb 2025 09:45:55 GMT

Hi,

1) The long connection interval is clear to identify the TX and unknown current pulses, otherwise they may overlay with empty PDU current pulses. Using the shorter connection interval parameters still have unknown current pulse 1000ms later. The settings are as the following,

CONFIG_BT_PERIPHERAL_PREF_LATENCY=0

CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=400

CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

2) Is there a simpler sample than peripheral_uart and central_uart to just send the packet periodically, I can check if it has unexpected current pulse or not.

RE: Send the packet from peripheral to central, why see the current pulse about 1000ms later

Einar Thorsrud — Fri, 14 Feb 2025 12:44:34 GMT

Hi,

I am not sure exactly how you measure this other than looking at the current draw, but looking at the sniffer trace it seems the connection interval is about 1.8 seconds, so I would seg a high latency is expected here. If you need a short(er) latency, you need to reduce the connection interval.