I have an application running, with i2c.

With BLE 160-140 the on-time in the soft-timer (script-language) is about 20 milliseconds.

I tried the Update to BLE 180-143. Now the on-time is about 50 milliseconds.

It is ic2-interface, wich causes the problems. Is there any possibility, to configure the i2c interface to works faster, like in old version?

 

 Hello Guys, 
    
   I am working on the NCP system environment. The watchdog has been implemented in the NCP target and it works as per the requirement. 
    Using the reset management unit, whether the system was reset by watchdog or not. It would be good if this information can be sent from NCP target to NCP host. 
    To send this information from target to host, using the User messaging module. 
    So following this blog(https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/11/23/custom_communication-1aq3), 
    have implemented the following. Below I have steps that I followed to implement the communication between NCP host and target. 
    
1. Sending a message from NCP host to the target    
    //Whenever the NCP target started following command is sent to target
    gecko_cmd_user_message_to_target(data_len, &target_value);
    
    //Which triggers the handle_user_command on NCP target, after the data from host received on the target.
    handle_user_command()
    
    
    //Further response is triggered to host from NCP target
    //I have implemented the following code in the NCP host, to receive response from NCP target
    void user_rsp_handler(void)
    {
        static uint8_t rsp_result;
        uint8array rsp_data;
        static uint8_t rsp_array_data[255];
        struct gecko_msg_user_message_to_target_rsp_t temp;

        rsp_result = temp.result;
        if(rsp_result)
        {
            rsp_data =  temp.data;
            rsp_array_data[0] = rsp_data.len;
            rsp_array_data[1] = rsp_data.data[0];
        }
    }
    
    In the debug mode, I can see untill the data can be received on the NCP target and it triggers response, but I don't see the response received on the host (checked in debug mode).
    I am not sure about the last step to read the response from the target on the host, is this the correct way of implementation to read the response?
    
    Further this sequence of event happens only once, when I intentionally stop the watchdog counter from being reset,  NCP target will reboot itself. 
    gecko_cmd_user_message_to_target(data_len, &target_value) command is sent to target, but handle_user_command() doesn't get triggered.
    Is there some kind of changes that needs to be done, so that handle_user_command to be triggered again?
    
    
    
    
    
2. Using the hardware soft timer, I was trying to Sending a message from target to NCP host
    
    //    Using the following function, from NCP target, data is sent from target to host
    gecko_send_evt_user_message_to_host(host_msg_len, &host_msg_data);
    
    
    //gecko_evt_user_message_to_host_id Event gets triggered on the NCP host
    //using the following code, try to get the data from the response as follows
    uint8array host_data1;
    static uint8_t host_data_array1[255] = {0};

    switch(evt_id)
    {
    case gecko_evt_user_message_to_host_id:
    {
        struct gecko_msg_user_message_to_host_evt_t temp1;
        host_data1 = temp1.data;
        host_data_array1[0] = (host_data1.data[0]);
        host_data_array1[1] = (host_data1.data[1]);

    }
    break;
    default:
    break;
    }
    }    
    
    Data received isn't correct, the way data is read isn't correct. 
    Is this a way to read the response on NCP host?  Could someone guide me on how to proceed with this further?
    
    Thanks and best regards,
    Chetan

Hi,

 

I have seen quite a lot of questions regarding bonding failures when one of both ends does not have bonding information anymore. However, none of them seem to solve the problem when the BGM111 (as slave) has removed the bonding information (because oldest bonding data is removed when max has reached) while the master (LightBlue on iPhone or MAC OS Siera) still has the bonding information. So, I'm posting a new request.

 

The situation is as follows: I have BGM111 module (stack version 2.3.3, build: 2346) set up in bondable mode and encryption/MITM enabled:

 

// Delete all bonding keys for test purpose, bonding data of test device will eventually be removed anyway // when the max number of bonding entries has been reached.

gecko_cmd_sm_delete_bondings();

gecko_cmd_sm_set_bondable_mode(1);

gecko_cmd_sm_configure(0x03, sm_io_capability_displayonly)

 

// Setup fixed key for now

gecko_cmd_sm_set_passkey(123456);

 

Now, when both devices don't have bonding information this will work fine: I receive a request to enter the passkey when I try to access my bonded_read/bonded_write protected characteristic. However, when I reboot the BGM111, which will remove bonding information on the module site, I cannot establish a bonded connection anymore with the module. I'm receiving the following bonding_failed error codes:

 

- 0xC / 0x18 (0xC when trying to access characteristic from Light Blue on Mac OS, 0x18 from iPhone 6)

followed by:

- 0x206 // Pairing failed because of missing PIN, or authentication failed because of missing Key

 

I have tried to force the bonding process by invoking sm_increase_security in both

le_connection_bt5_opened and le_connection_parameters events without success. The command sm_enable_encryption seems not to be available anymore.

 

So, my question is: What does the (undocumented?) error code 0xC/0x18 mean? And most important: What can I do to get a bonded connection after the bonding data is removed from the module without manually removing the module from the phone/laptop.

 

Thanks!

 

Regards,

Bram

Hi

An issue has just surfaced in my application whereby the stack stops reporting Indications to my application. I have just updated my application to use Bluetooth stack 2.13.0. I am sending a ~60k file from my PC using indications. A few things of interest:

This worked without issue on Bluetooth stack 2.11.2.

Now with 2.13.0 it stops after between 10k and 20k is received.

The Bluetooth heap is set to 32k in both versions of application code.

If I REDUCE Bluetooth heap size to 8k on the 2.13.0 version it works.

If I set stack size to 16k I receive a bit more (25 - 35k) before it fails.

If I add a 25ms delay in between sending Indications from PC it works on 2.13.0 stack.

When it fails the PC seems to think it has sent the complete file and doesn't complain about not getting an acknowledge.

The connection is still alive and I can read characteristics from the application.

EDIT: Further test shows that if I keep trying to resend the file the stack DOES report indications again, but stops at around 10-20k received again. It just needs a rest!

Now I'm pretty sure that Windows Bluetooth API is not handling Indication properly. It doesn't seem to care if it gets an acknowledge which is maybe causing an issue. However, I'm not sure why decreasing the stack memory on the device helps.

 

Any ideas?

Thanks

 

Hi,

I am using ncp_btmesh_empty_target and bgtool to test api commands.

If I am passing commands, few are working but few are not working. for example start_advertising works but gecko_cmd_mesh_node_start_unprov_beaconing is not working. Is there any dependencies or any modifications needed in code?

Hello Guys, 

Could someone please tell me how to solve this error, which started appearing all of a sudden?  

Error :  Field 'sleepCallback' could not be resolved 

Here is the screenshot for your reference 

 

Thanks and regards,

Chetan

I am trying to use a BLED112 dongle to write characteristic on a remote BLE device. The characteristic is 500 bytes long.

Using BGLIB, I see the 'prepare_write' and 'execute_write' commands allow you to queue up 18 bytes at a time with 'prepare_write' and at the end send the 'execute_write' command.

However, it appears that I get an error 0409 - prepare write queue full when queueing up more that 5 prepare writes, in order words trying to write more than 90 bytes (18 * 5) to the characteristic.

How can I use the BLED to write to this long characteristic?  Is there a version of firmware for the dongle that has a larger prepare write queue size? 

Hi,

is there an easy way to hook up playsound command to an event like connect (in iwrap 6.2)?

 

Thank you,

Hynek

I started a project based on soc-empty. I added the SWO terminal code and the code to read the battery. This is a custom PCB - but no peripherials. So, it's a module, a couple of caps, and a debug connector.

Without starting advertisements, and just spinning on the gecko_wait event() after calling gecko_init(), the average current is around 9 uA. There is a spike happening about every 140 ms. When zoomed out, this spike looks to be about 10 uA, but when zoomed in it looks more like 75-100 uA. This happens without the RTCC enabled.

I understand the we should be in EM2 during the gecko_wait event(). So I think the question is what is happening every 140 ms?

 

 

Hello,

1. Can the Bluegiga WT32i stream music to a Bluetooth 5 headset, given that the Bluegiga WT32i uses BT Classic v3.0 and the headset uses BT/BLE v5.0?

2. Furthermore, can the Bluegiga WT32i stream Stereo aptX music to a Bluetooth 5 headset?

3. Last, can the Bluegiga WT32i stream aptX HD music to a Bluetooth 5 headset?

FYI, we are using a QCC3034-based headset, see below:
https://www.qualcomm.com/products/qcc3034

Thanks,
Peyman

I have just completed a simple project with the BGX13P firmware version 1.2.2045.0 and noticed something strange.  When conducting some range tests, we allow the device to naturally disconnect, then try to re-connect...  Data can be sent to the device from the app, but nothing can be received.  The UART connecting into the module seems to be dead?  A power cycle resolves this, but we can see the module switch from command to stream mode, but no commands or anything is acknowledged from the module.  Even the reboot command is ignored.  Unfortunately a power switch is not an option for this device, so hopefully there is some solution for this.  

Hi,

I have a project developed with BGM13P22 part and following sdk version:

Name: Gecko SDK Suite: Bluetooth 2.9.2.0
Version: 2.3.1
Location: C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\

I want to migrate my project to bluetooth 5. Which sdk must I use ? Any advice or guide to help doing that ?

Ones the project works with bluetooth 5, will it works also with previous bluetooth 4.x smartphones ? 

My goal is the BGM13P22's aplication can works with bluetooth 5 with smartphones that admites it and also it works with 4.x with old smartphones which have not bluetooth 5 yet.
Any helping will be apreciated,

Asier,

 

 

 

Hello,

   https://silabs-prod.adobecqms.net/documents/public/application-notes/AN981.pdf   

  points to iOS cable replacement apps. Several forum posts point to source code for this app, but the links seem invalid. Please point me to this app and source code for interfacing iOs to BLE113 using cable replacement profile.

 

With best regards,

Faizal.

 

 

 

 

I was looking at the API notes for 2.13.0.0 and saw cmd_le_connection_read_channel_map() has been added.  I was a little confused about what the return value means.  If a channel is marked as Used, what exactly does that mean in this context?  Does it mean the AFH algorithm is avoiding that channel as per KBA BT 0406? 

Additionally, what is the bit order for the output in the 5-byte return? 

Thanks!

Hi,

In my project I would like to be able to put my MCU in deep sleep mode for a long period of time (about 1 day). In this mode the BLE loop is not even called. I am making use of the function :

gecko_peek_event()

So, after a certain amount of time, I call this script :

CORE_DECLARE_IRQ_STATE;
CORE_ENTER_ATOMIC(); // Disable interrupts
time_ms = gecko_can_sleep_ms();
gecko_sleep_for_ms(time_ms);
CORE_EXIT_ATOMIC(); // Enable interrupts

This is the result :

- Whenever I ask for how long I can sleep, I always end up having "131071999" which is 0x7cfffff.

- The time which is actually slept is always smaller than 131072 ms = 0x20000.

- The time actually slept is modulo 131072 ms. For example : if I want to sleep 131073 ms, it will sleep for only 1 ms. If I want to sleep 131071 ms, I will sleep for 131071. If I want to sleep (y*131072)+x, it will always sleep x ms.

 

Is it the normal behavior ? I have not seen anything regarding the "maximum" time the stack can sleep in the datasheets. Is it intentional or is it a bug from my program ?

Thanks.