Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Project 1 Wrap-Up

Project 1 Wrap-Up

250 likes received 100 likes received 50 likes received

Project 1 Wrap-Up

Back to main page: Leveraging TAG4 to better understand the WICED Smart Programming Environment

          In order to transmit sensor data via BLE notification, all we’re going to do is combine the preceding two sample applications and alter a few details. We’re going to slightly alter our GATT database to accommodate for the volume of data we’ll be sending. Additionally, our transmission process will be altered to accommodate for data larger than one byte.

          For the sake of accuracy, when we send data from the HTS221, we multiply the decimal values by 10 (our platform doesn’t support decimal, float values). These scaled-up numbers will often exceed one byte, but we must send those values one byte at a time.

          As a result, in the sample firmware, the length of the GATT characteristic has been extended from 1 byte to 5: 2 bytes for humidity, 2 for temperature, and one as a gap between the two values (for readability).




                                  LEGATTDB_PERM_NONE, 5),

               'D','a','t','a',' ','T','x',

          When working with this many values, it’s easier to weed out any discrepancies by zeroing all values out in between your read and write. For that reason, you’ll see a block of code within the transmission function doing just that.

  //clear out the previous values
  db_pdu.pdu[0x00] = 0;
  db_pdu.pdu[0x01] = 0;
  db_pdu.pdu[0x02] = 0;
  db_pdu.pdu[0x03] = 0;
  db_pdu.pdu[0x04] = 0;

          Additionally, we need to deal with the issue of sensor data exceeding one byte. If you try to put more than one byte of data into a one byte slot, you’ll be transmitting only the value that exceeds the one bye. For instance, one byte is equal to 256. If we try to fill it with the value 257, we’ll end up transmitting the value 1.

          With that said, you’ll find in the sample app a logic block within the transmit function that allows the data to carry over into the next byte if it exceeds one byte. This is, again, for the sake of readability and it isn’t necessary to dissect the logic. In your own apps, you can adapt the data transmission any way you’d like. And it's likely a better choice to just send changes in the data, which will likely never exceed a single byte.

          if (humidity < 255) {

            db_pdu.pdu[0x04] = humidity;

          }else if(humidity < 65535){

            db_pdu.pdu[0x03] = (humidity / 255);

            db_pdu.pdu[0x04] = humidity;


---------------------------------------------------------SAMPLE FIRMWARE STEP-BY-STEP----------------------------------------------------

The following list is a combination of the preceding 2 posts and it will allow us to successfully transmit data to our LightBlue app:

    1. Power up the sensor
    2. Initialize the sensor
    3. On a loop:
      1. Start measurements of sensor
      2. Read data from sensor to a buffer
      3. Read the GATT characteristic
      4. Write the sensor buffer to the GATT characteristic
      5. Send the notification

Run the app on your WICED device and find it on your LightBlue app. Upon connection, you’ll receive a stream of notifications of the current temperature and humidity in hex format separated by a zeroed one byte margin for readability. Again, breathe on your board and watch the values sharply increase.

Being able to stream values to your LightBlue app is more than just the end goal. Rather, the ability to stream these values is an incredibly powerful tool in the design process. Consider the case that you’ve just designed your own board using a WICED BLE chip, but you don’t have the ability to run traces on the board. You now have the power to receive data from your chip and figure out where your code is failing.

Jacob W. Torres

Back to main page: Leveraging TAG4 to better understand the WICED Smart Programming Environment