Wi-Fi Combo Forum Discussions
On the schematic for the BCM9WCDPLUS114, the bluetooth module (BM-GP-BR-65) has a pin labeled "coex-in" It is my understanding that this pin is used to shutdown the bluetooth radio while the wifi radio is transmitting.
However, this pin is shown as being connected to one of the GND pins on the WM-N-BM-14 (SM32F205+BCM43362)! That GND pin (pin 59) is NOT connected to GND.
Is this pin somehow special, or is this connection nonsensical? How is the coex-in pin supposed to be used?
Show LessHello, Broadcom
Our customer has some problem and system layout is as follows,
Embedded System <---- UART ----> WICED(SoftAP) <---- TCP through WiFi ----> PC or Mobile
WICED : SDK 3.x.x and BCM943362WCD4, OS/network : FreeRTOS / LwIP
The first client(PC) is connected to WICED successfully and then uart data received from embedded system are also transferred to PC through tcp(LwIP) communication successfully in created uart_thread.
However, if the second client tries to connect to WICED while uart data are transferred, the second client can't obtain ip address.
Could you let me know why the second client can't obtain ip address? What should I do to fix this problem?
If you need more detailed information, let me know.
Thanks,
Sung-Mok Lee
Show Less[WICED-SDK-2.3.0]
Is there an easy way to have the compiler output a single binary for the bootload, DCT, and application sections of the STM32F2XX each time it is built?
Show LessI have BCM9WCDPLUS114 evk board. I use demo.bt_smartbridge application to verify smartbridge function.
I have three BLE modules, BCM920732_TAG, SensorTag from TI(http://www.ti.com/ww/en/wireless_connectivity/sensortag/index.shtml?INTC=SensorTag&HQS=sensortag) and LightBlue running on iPad. Below is scan and connect webpage:
[ATTACH=CONFIG]181[/ATTACH]
BCM9WCDPLUS114 can get three BLE devices by scan.
BUT, only LightBlue on iPad can connect with BCM9WCDPLUS114. BCM920732_TAG and SensorTag cant connect with BCM9WCDPLUS114, they are always "connecting".
Whats the reason? Paring authentication?
Show LessIs there any plan to see a 802.11ac WiFi product being part of the WiCED offer in the near future?
Issue #1
We are running Linux Kernel 3.15 with BCM43362 (Murata Type ZX) and the opensource driver with the firmware. MMC in the kernel is initialized with the Device Tree. When the driver module is inserted into the kernel and the SDIO is activated, we see the errors below. We are also getting similar errors when we are scanning.
mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
mmc1: queuing unknown CIS tuple 0x80 (6 bytes)
mmc1: new high speed SDIO card at address 0001
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
brcmfmac: brcmf_fil_cmd_data: Failed err=-23
Issue #2
When we scan, there are only 1-2 access points listed. We have a few devices picking up 10-12 APs. The WICED module is performing much better.
Show LessHi, WICED Support Team.
What is the part number of WICED Bridge which used BCM43362+BCM20702.
It deosn't mean EVB. I asked about WICED Bridge Module.
And, is BCM943341WCD1 available now? For use as WICED Bridge.
Thanks
BR, Eric Lim
Show LessThis example demonstrates how to connect multiple ACKme modules running WiConnect, an easy to use front end to WICED, to a network as Wi-Fi clients, and how to configure each module to send messages to one another. The requirements for this kind of application can vary considerably, here's a list of assumptions we made for this particular example.
- Each module has a pre-assigned static IP address. This makes it easy for a module to send a message to another specific module on the network since all modules have pre-assigned addresses
- A message may be sent from one module to one or more modules
- There is no security encryption at the network layer, all modules can read messages from other modules if they choose to do so
- Message delivery is NOT guaranteed. If a message is sent from one module to one or more modules, and the message fails to be received, there are no retries at the network layer (retries at the Wi-Fi layer still work though).
The simplest way to enable modules to send messages to one another on a local network is to send messages in UDP broadcast packets. To receive messages, each module runs a UDP client and listens for messages sent on the UDP broadcast address. While UDP broadcast provides a way to send messages successfully, it lacks the ability to address messages to individual clients.
A Simple Message Protocol
To address messages, a simple application layer message protocol can be used. The requirements of a simple message protocol are listed below.
- Each message must have a sender (the source of the message)
- Each message must have one or more recipients (the destination of the message)
- Each message must have a payload
The message packet structure shown in the following diagram provides everything needed.
where …
- Source Address : Source address of the device sending a message. A 1 byte address provides up to 128 unique addresses, and 128 multicast addresses as explained below.
- Destination Address : Destination address of the recipient of the message. If individual destination addresses are limited to 0 through 127, then addresses 128 through 255 can be used as multicast addresses. If the sender wants to send particular types of messages to a group of clients, the sender uses a multicast address. Devices interested in those types of messages can listen on the particular multicast address of interest, in addition to their own address
- Payload : The message payload
Implementation
This example assumes each Wi-Fi device has a pre-allocated (or static) IP address. There are several ways to achieve this.
- Ensure that each device that joins the Wi-Fi AP uses a static IP address, and that no two clients use the same IP address. You can set a static IP address for your device using the static.ip variable. Note that you will also need to set the static.netmask and static.gateway variables.
For this example, we assume that IP addresses assigned to clients are numbered in the range 192.168.1.100, 192.168.1.101, 192.168.1.102, and so on. We also assume the Wi-Fi AP (which is the network gateway) has an IP address of 192.168.1.1.
The assumed configuration of the network is shown here.
WiConnect Commands for Module M0 | Command Description |
---|---|
|
|
Verify it works
Module 0 | Module 1 |
---|---|
|
|
Other Options?
- TCP client/server. Another option is to run a TCP server and TCP client on each module. Each time a module wants to send a message to another module, it must open a TCP client connection to the module it wishes to message. Each module must also run a separate TCP server to receive messages from other modules. This method provides guaranteed delivery, overcoming the potential for lost messages. Note that each module must solve the address problem described for UDP also.