Has anyone managed to make wireless coexistence work on any Tuya modules in OpenBK?

Most Tuya modules have one antenna so there are tricks necessary to make both Bluetooth and WiFi work at the same time. Both N and T Beken (7231) chips have the hardware that is supposed to make it work (wireless arbiter, etc.) but I couldn't find any guides as to what a minimal setup would be. Our little group plans to teach a lab on BLE and reverse engineering this year and we were trying to make some basics to work before we throw it to our unsuspecting students . Any help, hints are appreciated!

Andy

I looked at that briefly when trying to do BT integration into ESP32, it can be done but at a cost... more on that to follow for sure. Maybe @insmod has more to say on the matter?

I assume SDK handles it?
https://github.com/NonPIayerCharacter/beken_f...ver/ble/ble_5_2/platform/7238/entry/ble.h#L44
ble pta is for Bluetooth Low Energy Packet Traffic Arbitration?

>>21847988 Thanks! We were looking at BK7231 series chips (N and T). That SDK has functions for that as well, but it is not clear how to call them or what parameters to set, if any. There is a cost, sure (I am assuming both BLE and WiFi would have to slow down, and the dropped packet rate would go up, but for IoT devices this should be fine). Anyway, thanks again; if anyone knows more, we would appreciate it!

Andy

more discussion here - https://www.elektroda.com/rtvforum/topic4165987.html

>>21850071 This looks really promising, but I am not sure what I am looking at. Am I right to assume that I can build this from the https://github.com/NonPIayerCharacter/OpenBK7231T_App fork? Do I need to specify BK7231N_ALT target? For some reason, none of us here can get the build system to work (I guess it is heavily Windows-biased, which none of us has access to here), so we have to remove most of the scripts first to get to the Makefile, which is why I am asking. Also, any chance this would work on the BK7231T version, since this is what we have for the students to play with? Anyway, thanks, looks great!

@jitsirakowsk

follow that thread I mentioned before, I got a local build system via docker ready that needs to be tested on Linux so you can build it quickly. BT is coexisting and some heavy development and testing is on the way but for now the initial goal is achieved - BT is running on N ( and I think T as well + other platforms as that is the goal of this project ) it works, coexists and with more improvements to follow. Feel free to give feedback and ask questions as this is a huge milestone for our project but we may use it is a different way than you intended it so feel free to engage and we will get it done.

What exactly is the problem with building?
It's Linux only, the only things that are needed to build ALT are make and gcc (best is system arm-none-eabi gcc from ubuntu 22.04 (10.3))
cd to cloned app repo and just type "make OpenBK7231N_ALT VARIANT=btproxy"

Only scan is implemented, no active connections.
Caught advertisements are then passed to Home Assistant via ESPHome API.
Extended advertisements are not supported, as is LE Coded.

BK7231T is not supported (it doesn't support ble 5.x library), only N and 7238. At least for now.

@DeDaMrAz do you think it would be better to use nanopb library, instead of how it's done now?

insmod wrote:

do you think it would be better to use nanopb library, instead of how it's done now?

I am still thinking about that, I have no clear idea how to and what for to use the BT on OBK - direction is lacking in my head. I have to dwell on it a bit more.

>>21853774 Thanks for the tip, we will try this. We were using the shell commands from the root of the repo and they do not seem to work well (I guess bash vs zsh vs sh syntax comes into play), so every time we build we just strip the rest and leave the SDK and the main Makefile and build it this way. I am not sure why such a straightforward project has such a convoluted build system (on the other hand I appreciate the difficulty of supporting a dozen different platforms). Just a clarification: by the app repo, do you mean the platforms/OpenBK7231N directory? There are so many Makefiles floating around between the root and that, I am not sure where the target is. I can always grep for it, I guess...

On the Bluetooth side, we do have the BLE running on T (actually, on N as well but I have not posted it yet), a sample project was posted in this forum. Primitive as it is, it does support advertisements as well as encrypted connections (all you need for the latter is to activate the SM); what we were lacking was the coexistence with WiFi. I am still not sure from looking at your code how it was done. There must be several parameters set up for it to work smoothly (like the delay for the radio reset). Is it all taken care of by the SDK? There is an rf_coex_.. struct somewhere, but all it does is set the policies, no relax times or anything. It must somehow interact with the scan window/interval settings (CEVA manuals for their stack mention some formulas), but where is it done?

Also, you managed to set up active scanning as well. Did you check that it actually sends out scan requests and gets stuff back? There must be a callback that does this upon receiving the advertisement. Is it also done by the SDK code? I did not find it in your code, but I might have missed something. We always wrote the callback by hand (this is all active scanning is, really, just asking when you feel like it ). We do have a bunch of eager students to write code though... Someone currently is working on the HID (over GATT for now) profile, I will tell her you got the coex working, see if she can make a 'wifi keyboard' this way.

Great work!

Andy

No, i meant main app directory (OpenBK7231T_App)
N and T default SDK are from Tuya, and use their makefile. I have problems with it as well on WSL1.
OpenBK723xx_ALT builds fine, but like i said requires specific gcc.
Callback is registered via ble_set_notice_cb
Active scanning works fine, i get BTHome sensor name if it's enabled. Don't know if LE Coded works, it's disabled in SDK and i don't have any device that uses it. Also don't know if extended advertising works.
Coex is achieved via window/interval settings, but it can miss some advertisements that way.

RTL8720C/RTL8720D don't miss advs, they can work when scan window=interval

Pls be aware that i almost know nothing about bluetooth. This is the first time i've done anything with it.

insmod wrote:

Pls be aware that i almost know nothing about bluetooth. This is the first time i've done anything with it.

I want to second this as well, all this is highly experimental and hard WIP!

>>21854686 Thank you for the info. I apologize for a stupid question but I am looking at the code in hal_bt_proxy_bk7231.c (is this the right place?) You said you registered the callback with ble_set_notice_cb so I see a call ble_set_notice_cb(hal_bt_gap_callback), but looking at what hal_bt_gap_callback does I only see the processing of the received advertising data. It does not launch any scan requests. The name of the device, the MAC, etc., would be sent in any advertising packet; there should be no need for active scan. So I wonder what active scan does for you and how the scan requests are sent. Is it done automatically by the stack? I do not have an N device on hand to check but are you getting any advertising info for which info->evt_type&0x7==3 (meaning it is a response to a scan request, not just a standard advertising PDU)?

insmod wrote:

Pls be aware that i almost know nothing about bluetooth. This is the first time i've done anything with it.

This probably works in your favor more than you know We have a bunch of people quite familiar with BLE and they all have a deer-in-the-headlights look when they read Beken's (or, God forbid, Tuya's) BLE code. Thanks for all the help.

Andy

Added after 1 [hours]:

>>21854686

insmod wrote:

Don't know if LE Coded works, it's disabled in SDK

What do you mean by disabled in the SDK? The rf_init function sets the PHY params (in RADIOCNTL2 reg) and it even states in the comment that the PHY is set to support the Coded PHY. Am I looking at the wrong place? The T version, indeed, does not have support for the Coded PHY at all.

>>21855295
Yes, hal_bt_proxy_bk7231.c is the correct file.
hal_bt_gap_callback only processes advertisements, scan must be launched manually with BTStartScan command in OBK, which calls HAL_BTProxy_StartScan. Then scan will just continue until stopped.

I don't think it's in my favor when i want to do more than just receive advertisements.
I tried to implement active connections on RTL8720D, but it's a callback hell there. I barely understand what most functions there do.

To enable scan on LE Coded channels, GAPM_SCAN_PROP_PHY_CODED_BIT must be added here:
https://github.com/NonPIayerCharacter/beken_f...er/ble/ble_5_1/ble_pub/app/src/app_ble.c#L696
And GAPM_SCAN_PROP_ACTIVE_CODED_BIT for active scan.

T doesn't support coded because it doesn't support 5.0.

>>21855646

insmod wrote:

hal_bt_gap_callback only processes advertisements, scan must be launched manually with BTStartScan command in OBK, which calls HAL_BTProxy_StartScan. Then scan will just continue until stopped.

I see. What I meant was if you are doing active scan, you should be getting two responses for each scanned ad: one for the original AD PDU and one in response to your scan request (this was originally introduced to circumvent the 31 byte limit on the AD PDU). If you (or, rather, whoever you are scanning) are using extended advertisements, there is no need for active scan. So there must be a separate callback to launch scan requests. I guess the bits you mentioned are set so that the BLE cell would wait to hop to the next ad channel in order for you to send the scan request. I am just curious if somehow GAPM sends the request by itself, but I do not see where.

insmod wrote:

To enable scan on LE Coded channels, GAPM_SCAN_PROP_PHY_CODED_BIT must be added

I cannot see anywhere in the library that setting this bit does anything. It is an enum, so the debugging info for the library should have a record of it (unless the Beken devs are truly evil), but I cannot see it anywhere in the disassembled sources. There are also a bunch of other _CODED settings; I wonder if they are supposed to be set as well.[

quote="insmod,post=21855646"]it's a callback hell there.

No kidding! I appreciate all your hard work on this. I am also curious why you decided to start with scanning (other than for detection purposes). Setting up connections for peripherals should be a bit easier (we have the code for T, at least and as soon as we get something to test the N code on, we should have that too). The hard work is setting up profiles and handling events, etc. For centrals (the scanning ones) you would have to implement discovery, pairing, etc. Just thinking about it makes me shiver...

Andy