Smart Bluetooth Forum Discussions

Hello Community

I try to send digital value to iphone with Bluetooth when pio 0 input value change.

And I try to store data to NVRAM when transmission fail, and the stored all data will be sent when transmission success again.

I can send digital data to iphone, but I have no idea about NVRAM programming.

I use BCM20737 and debug with Light Blue app.

I would like to ask 3 questions.

1, When I check if data successfully can be written, I plug off Vcc jumper wire and plug again for power cycling. After power cycling I can't start the service. It doesn't appear on a list like figure 1. Please let me know how to check if  data can be written and keep it in NVRAM after power cycling. I should use another app or ?

2, I can change characteristic's data on iphone screen when pio 0's value change with following code which is refer to hello _sensor. When I watch value of writeNVRAM in bellow code with teraterm, it doesn't change and it's always 1. Please let me know to write value of sum in bellow code into NVRAM. sum's value is count up every change of pio 0's value.

3, I try to store data when transmission fail. There is any command to get callback when transmission fail?

I will really appreciate your help .

Thank you.

ka mi

-------------------------

void hello_sensor_send_message(void)

{

    BLEPROFILE_DB_PDU db_pdu;

    //UINT8 res = gpio_getPinInput(0,0);

    UINT8 res[100];

    UINT8 data = 0;

    UINT8 i;

    count++;

    res[count] = gpio_getPinInput(0,0);

    ble_trace1("count = %d\n",count);

    ble_trace2("res[%d] = %d\n", count, res[count]);

    sum = sum+res[count];

    ble_trace1("sum = %d\n", sum);

    // If client has not registered for indication or notification, do not need to do anything

    if (hello_sensor_hostinfo.characteristic_client_configuration == 0)

        return;

    // Read value of the characteristic to send from the GATT DB.

    bleprofile_ReadHandle(HANDLE_HELLO_SENSOR_VALUE_NOTIFY, &db_pdu);

    db_pdu.pdu[0x00] = (UINT8)sum;

    bleprofile_WriteHandle(HANDLE_HELLO_SENSOR_VALUE_NOTIFY, &db_pdu);

    ble_tracen((char *)db_pdu.pdu, db_pdu.len);

  writeNVRAM = bleprofile_WriteNVRAM(VS_BLE_HOST_LIST-10, sizeof(sum), (UINT8 *)&sum);

  writeNVRAM = bleprofile_ReadNVRAM(VS_BLE_HOST_LIST-10, sizeof(sum), (UINT8 *)&sum);

    ble_trace1("second NVRAM read:%04d\n", writeNVRAM);

-------------------------

Continuation of this thread: More appFineTimer questions...

I saw 12.5 ms in the comment above bleprofile_regTimerCb() function and it confused me.

If I set fine_timer_interval as 12, what will be the actual interval? 12 or 12.5 ms?

If I really want the interval to be 12.5 to make it perfectly fit in every 1 second, how can I config it?

Hi,

I try to evaluate 920737s by using SDK2.2 speed_test example runs with Window peerapp SpeedTest client to figure out what is the max data rate, I notice some posts on the forum has mentioned the data rate can be as fast as 80kps but my finding is far below, please see what I got from the procedure I did below.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

What I got today by running SpeedTest Window client application with speed_test on tag3 board is somewhere around 13.5kbps max.

The limitations that stopped to have better data rate were the SOC itself stopped after data bashing for a little while, I expected it should send and loopback on receive what has been sent infinitely or at least up to me to stop it. It however stop by itself to storm the BT media even I set it for storming forever using forever while loop in firmware.

I wonder what tricks I can have to get it running infinitely (though is not a real use case that no scenario could keep to storm BT media forever in real life, but this test though unrealistic, could show me logic could suck every single bit of juice out of the SOC to serve for data storming and  from the results I can capture in wireshare can show me the theoretical data rate)

Attached is the wireshark  file and a screenshot below.

This performance data rate research is essential for what should be the right candidates.

It did succeed to continue sending data in chunks of 20 bytes (limitation of Android read/write characteristic value size) back to back but it stopped to storm for a little while, this may be due to characteristic configuration setup, or may be related to falling back to low power mode or firmware logic that has exception to exceed the while loop… still not sure and need more debugging.

Max performance data rate record = 13.49kbps.

Hi,

I am new to the SDK2.2 and Broadcom solution on BLTE and I am doing an evaluation on it.

i intend to run speed_test from SDK2.2 by downloading to the tag3 board for a performance data rate test by using the speed_test example provided from the SDK.

i have setup an external sniffer to monitor BLTE traffic from running wireshark, so I can see what data are sent and received and from the timestamps of the capture packets, I can have idea of data rate.

However when I run SpeedTest application from Window peerapps folder,  I see nothing from the wireshark capture of any data sent nor data received from master to slave (master is Window peerapps of SpeedTest, slave is the speed_test run on the tag3 board).

Also I cannot find any document of how to use speed_test for data rate test, And from the speed_test.c comments, it said "configure client configuration descriptor to allow service to send notifications over control characteristics", but how to do it from Window peerapps SpeedTest though?  The SpeedTest applicaton has no such feature to allow me to configure client desccirptor for send notifciation and might be this is the reason why I cannot get any data packet for sent and received in whireshark.

Please advise me how to run the SpeedTest and how to configurate send notification from it, I really have no idea and no document to help me to understand how it works.

I have read thro' the source code of speed_test.c, it looked to me the configuration description changes should be from the

"master" (SpeedTest) side.

Thanks in advance for your help, our team need the data rate performance data in order to consider whether this is the solution we are looking for.

We wanted to start manufacturing our second batch of our product and when placing the order with Anvet we were informed that the current lead time for BCM20732S is 16 weeks!! That's 4 months!!

This is totally unacceptable from a company that wants to the leader of Internet of Things. The market is fast moving and we have outstanding POs to deliver. Has Broadcom discontinued making BCM20732S?

what are customers supposed to do when all of a sudden the lead times change without any sort of prior notice? We are building our businesses on your chips and such abrupt behavior can severely damage our business.

Mehrdad

Hi,

I'm using the following code to send directed advertisments from a 20737S:

void xyz_update_adv_interval(int32_t interval_ms)

{

   int32_t interval = (interval_ms * 1000) / 625;

   uint8_t bdaddr[6]={0xaf,0xfe,0x65,0x46,0xaa,0x5a};

   blecm_setAdvEnable(0);

   blecm_setAdvParam(interval,

                        MPL_ADV_ADV_DIRECT,

                        MPL_ADV_PUBLIC_ADDRESS,

                        MPL_ADV_ADV_CHANNEL_MAP_MASK,

                        MPL_ADV_ADV_FILTER_POLICY_WHITE_LIST_NOT_USED,

                        MPL_ADV_PUBLIC_ADDRESS,

                        bdaddr);

   blecm_setAdvEnable(1);

}

While this works great and I'm able to block connections from nosy Apple devices which we don't have to support, the current draw is a little bit too high during advertisements for a CR2032. I measured 21mA through a 47Ohm resistor. Here is a picture of the voltage after it:

That initial 500ms current draw is a killer. I'm not sure how I could prevent this so if you have a good idea let me know.

The general problem I'm trying to evade is foreign central devices connecting to our peripheral. The thing is that even though I can send advertisements in parallel to open connections to enable permitted devices to access our peripheral, the 4.4 Android Bluetooth stack gets into a non-functioning state by doing so. In the past I resorted to only using advertisements and terminating connections to prevent excessive current draw. Now we have to support a piece of hardware where the Android stack doesn't hand advertisement data over to the user - we only get zeros. For this reason I've thought about going back to connections and limiting the connection of foreign devices by some other means.

If you got any suggestions I would be glad.

Regards,

Kilian

I am trying to simply configure P2 as an external. rising edge interrupt.  I currently have it connected to a simple switch that transitions from high to low.  I have verified that my port mapping is correct by a simple debug loop that outputs traces on the HCI_UART to indicate the state of the pin.  When I run this loop in create(), the correct input state is read via gpio_getPinInput(), this verifies that I have the right pin, and the change in state can be detected.

I have read the following:

How to Write WICED Smart Applications

--> Followed the example code int he GPIO section  - can't get my ISR to run

Re: Wiced Smart Software Runtime -- Lots of Questions

--> As this thread suggested, I tried registering my interrupt callback (ISR) before the bleprofile_Init() call in create(), did not work

interrupt latency

--> This has some interesting points about interrupt priority and such but nothing I can see that can explain what's happening.

Re: how to identify GPIO interrupt source pin?

--> Again, interesting, and this post makes it seem doable, but again, this did not help solve my problem

What I tried, was to check the state of that pin, P2 (PORT 0, PIN 2), using gpio_getPinInput() in the 1 second timer tick.  In that function, regardless the state of my switch controlling the logic level on that pin, the pin is reported as low.   This suggests that perhaps the input is not coming through when I want it to?

I have a trace debug statement in my ISR that would tell me when it is called, and it is NEVER called, regardless how many times I flip the switch.   My code is below, I'm sure I'm doing something wrong, just can't seem to figure out what it is since all the docs and threads make this sound so easy but I can't get it to work at all.

    // dump the database to debug uart.

    legattdb_dumpDb();

    // As per some readings online, it is recommended that you register your interrupt handlers before you call bleprofile_Init()

        UINT16 interrupt_handler_mask[3] = {0, 0, 0};

        interrupt_handler_mask[IRQ_PORT] |= (1 << IRQ_PIN); //IRQ_PORT = 0, IRQ_PIN=2

      // Now register the interrupt handler.

        gpio_registerForInterrupt(interrupt_handler_mask, application_gpio_interrupt_handler, NULL);

        gpio_configurePin(AMS3911_IRQ_PORT, IRQ_PIN,GPIO_INPUT_ENABLE|GPIO_PULL_DOWN|GPIO_EN_INT_RISING_EDGE,GPIO_PIN_OUTPUT_LOW);

      // Clear out any spurious interrupt status..

        gpio_clearPinInterruptStatus(IRQ_PORT, IRQ_PIN);

    bleprofile_Init(bleprofile_p_cfg);

    bleprofile_GPIOInit(bleprofile_gpio_p_cfg);

    // Initialized ROM code which will monitor the battery

    blebat_Init();

...

....

....

What I have observed is that after blecm_SelectAddress() is used to add an entry to the whitelist, that Bluetooth address remains on the whitelist even after I call blecm_SelectAddress() again with the "num" parameter set to 0. According to another post on this forum this should clear the whitelist, but it does not work.

Has anyone out there been able to successfully clear the whitelist after it was set?

Thanks in advance for your help.

I am reading the press release here: http://investor.broadcom.com/releasedetail.cfm?ReleaseID=827044

Where can I find the datasheets for the BCM4771 as well as the BCM4773. If someone can summarize the differences between the two it would be great.

Thanks!

I've been doing some testing recently to determine the severity of packet loss and was wondering if its possible to advertise more than once per interval?

Currently I have one device set to advertise constantly at 100ms intervals and another device set to scan all the time with no sleep (30ms interval with 30ms duration). I've noticed that I still get on average around 6% packet loss and am wondering if sending 3 or 5 packets every 100ms instead of just 1 packet every 100ms would be able to reduce this.

I'm using the "blecm_startAdv()" and "blecm_startScan()" functions.

mwf_mmfae

victorz