Wi-Fi Combo Forum Discussions

Hi all,

When I am testing the maximum tcp speed through the iperf example in WICED, for 5 GHz (80 Mhz bandwidth), it gives me around 75 Mbps, however the TCP_CLEINT example is way slower than that and it barely reaches to 2 Mbps. I tried to remove the echo back from the server and reduce the delay time between each transmission and also increase the length of "tx_data" but when it is more than 1500 characters, the module resets multiple times during the tcp connection and does not start the communication.

By the way, I don't see any speed difference when I'm changing the TCP_PACKET_MAX_DATA_LENGTH which is strange. In the iperf example, by increasing the tcp window size up to a certain point, the speed also increases which it makes sense. In the TCP_CLEINT example, the packet length can't go above 65535 characters which I guess there is no such a limit in the iperf example...

Is there any benchmark on the tcp_client example? How to push up the speed to 75 Mbps in the TCP_CLIENT example? I need to repeat the iperf speed results on my own data through the tcp connection!

Kind regards,

Hamid.

Hi,

My original post got locked and marked as answered, even though it is not solved.
Link to the original post:

Pairing two BLE devices to one phone.

The problem is still there even if we set different device addresses using function:

void wiced_bt_set_local_bdaddr( wiced_bt_device_address_t  bd_addr );

As mentioned in the post, this issue is only while using BLE. For BLE we are also using random address refreshing.

Apparently there is something very similar in the pairing data, that makes the iOS consider these devices same and/or somehow rejects the pairing data.

Is the address the only parameter that is used for pairing data? Or is there something else that is part of the pairing data?

At the moment we limit the user to use only one of our devices with one phone, however we would like to be able to have multiple devices connected to one phone.

Regards,
Erik

Hi:

     We are developing a WIFI/BLE adapter board based BCM43438 to our RISC-V chip.  The BCM43438 board schematic reference iMX7 development board design and be posted below. After we produced a fully new board, I want use PC to send UART command for test. I first send RESET command (0x01 0x14 0x0C 0x00) to BT with both hardware flow control and without, but none has response. All power are OK, the board use a 26mhz external crystal and a 32.768k LPO. Do I lost some  procedure cause no response?

A little over a year ago we designed in the Cypress 4343W across the SPI interface. At that time, it was well documented on how to connect SPI.

In the H rev of the documentation, SPI interface was removed. I do not want to change our design or lose the speed advantage of using SPI over 1 bit SDIO.

Can I still use the SPI interface?

The issue is observed fairly consistently with the code below on non-debug builds, but debug builds work well. It looks like wwd_management_set_event_handler() in wwd_wifi_stop_ap() is called too early (perhaps because wwd_wifi_sleep_flag semaphore wasn't cleared at some step before when initializing). wwd_wifi_start_ap() also fails with "Error: Soft AP or Wi-Fi Direct group owner already up" error after failed stopping.

I found a very similar issue here IOCTL times out during wwd_wifi_stop_ap()​ .

The board is BCM943362WCD4. SDK 5.1.0.

void application_start(void)
{
    wiced_init();
    wiced_ssid_t ssid;
    memset(&ssid, 0, sizeof(ssid));
    strncpy((char *) ssid.value, "11", 2);
    ssid.length = 2;
    wwd_result_t wwd_res = wwd_wifi_start_ap(&ssid, WICED_SECURITY_OPEN, NULL, 0,1);
    wiced_rtos_delay_milliseconds(1000);
    if (wwd_wifi_stop_ap())
    {
        printf("fail\n");
    }
    wwd_res = wwd_wifi_start_ap(&ssid, WICED_SECURITY_OPEN, NULL, 0,1);
    if (wwd_res)
    {
        printf("start fail\n");
    }
}

Hello,

I have some old BCM4319 boards that I wanted to use in a project,and I read in another part of this forum that the last version of the SDK that supports those boards is 1.3. I looked here and the earliest version I could see available is 2.x. Does anyone know where I could find the 1.3 SDK?