Sluggish response time from modified le_data_channel_server on rpi

24 views
Skip to first unread message

Alec Labadie

unread,
Aug 9, 2021, 10:12:41 AM8/9/21
to btstack-dev
Hi Matthias,

Background:
I am wrapping up my project using le_data_channel_server & client as starting points. I am attempting to send messages with a payload of 19 unsigned chars from an iOS app once every 30ms over L2CAP connection for safety/real-time control purposes. I planned to use a timer running in a pthread and implemented with calls to btstack_run_loop_get_time_ms() to ensure that there is never more than 40ms between each message received while in this critical state. The message contents change depending on button press, state, etc. However, I am noticing 6-10s delays between when the iOS sends a new message and when the pi/server recognizes/responds to the message (either by a printf indicating new message, printf(packet) displaying contents of the message that is recognized as new, or by the existence of the appropriate response message sent from pi over L2CAP as seen on sniffer/iOS side/packet logger). 

Questions: 
1) Is this message rate too high or timing constraint too stringent in theory for the le_data_channel_server/pi? 
      (If it is possible than I am going to assume it is the code I have added that is slowing  things down) 
2) Is there a way I can make note of a message being received in software/interrupt without waiting for the program to get to the "L2CAP_DATA_PACKET" case?
3) Do timestamps for received packets exist and, if so, how might I access them? 
4) In general, do you have any recommendations on how I could speed up the program so that it satisfies timing requirements? 

Thank you for your time, 
Alec 

Matthias Ringwald

unread,
Aug 10, 2021, 1:22:07 PM8/10/21
to btsta...@googlegroups.com
Hi Alec

Thanks for the background. Quick comment on that: btstack is not thread-safe and if you want/need to use it from other threads you need to take create care about synchronisation as you cannot call any API function from a different thread.
As BTstack provides timers via it's run loop (e.g. check example/led_counter.c), you don't need a thread to schedule periodic work. Please use btstack timers and check if your latency problem gets fixed.

- A 19 bytes packet every 30 to iOS should be no problem (assuming the default conn interval of 30 ms).
- All POSIX ports incl the Raspi create a packet log in /tmp/hci_dump.pklg which can be opened in Wireshark and has milliseconds timestamps.

Best
Matthias
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/8cb78895-6765-45d1-98ec-23d111aadfb1n%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages