Thesis Pte Ltd

icon

One thesis

Copyright © 

2025

 Thesis Pte. Ltd. All Rights Reserved

OFFICE

34 Boon Leat Terrace #04-09A Singapore 119866

GET IN TOUCH

One thesis

Copyright © 

2025

 Thesis Pte. Ltd. All Rights Reserved

Categories
News Tech bites

Bluetooth Low Energy – iBeacon basics

iBeacon is a protocol developed by Apple Inc. in 2013. In short, iBeacon technology allows mobile applications to understand their position on a micro-local scale, and deliver location-specific contextual content to users based on their proximity. The underlying communication technology is Bluetooth Low Energy (BLE). The protocol takes advantage of the BLE technology to bring about very low-powered broadcasting devices that could alert users of its presence. By adding certain parameters to the advertising data packet, the broadcasting device can be used to transmit location specific information. The most common use case of such iBeacon devices would be in the brick and mortar shops, where business owners want to transmit location-specific promotions or to track their shoppers who have their shop-specific app installed on their smartphones. Of course, privacy is always a running concern for the user tracking implementation but with the latest mobile OS, users can prevent their privacy from being breached. The caveat is that the users have to be tech-savvy enough to know how to do that.

Several development projects that we’ve been involved in are requests for iBeacon-like attributes – implementing similar protocol but with varying levels of modifications. The good news is that you can implement the iBeacon on your own. There will be another article released soon, where we talk about EddystoneTM – Google’s latest beacon protocol. Stay tuned for that.

For those really curious about the type of projects we have done using iBeacon and other Beacon protocols, I will just say that there are various combinations but mostly it boils down to users’ behavioural monitoring based on location. We focused on product development, so our clients could remain focused on their customer’s buy-in and marketing.

iBeacon advertising protocol

iBeacon is a one-way transmitting protocol. You have to set the device to be non-connectable and always stay in advertising mode. The reason for non-connectable should be a no-brainer because if you are connected, BLE will not advertise. To save power, you will want to broadcast in a longer time interval. You can try a 100ms broadcasting interval and slowly fine-tune it from there.

ibeacon-bytes

The above illustration describes the iBeacon protocol in the simplest way possible. All BLE SDKs should have provision to modify the advertising data, so make sure to arrange your advertising data as per the protocol or the iBeacon will not work. To officially work with iBeacon, you will need to license the technology from Apple. You can read Apple’s beginner document for more information (source).

Moving on to the more technical aspect.

The 4 most important components of this protocol are:

1. Proximity UUID
2. Major
3. Minor
4. Measured power

Proximity UUID

This is the unique identifier that separates your device from the hundreds or thousands of iBeacon devices out there. Your app will have to white-list your UUIDs in order to prevent reading from the wrong device. By whitelisting, I mean your app should only read from devices with your authorized UUID. There are multiple avenues to generate UUID but one of the most common sources can be found here.

If you are just testing out iBeacon using the AirLocate sample code located on the Apple Developer site (https://developer.apple.com/ibeacon/), you will need to use their predefined UUIDs

1. E2C56DB5-DFFB-48D2-B060-D0F5A71096E0

2. 5A4BCFCE-174E-4BAC-A814-092E77F6B7E5

3. 74278BDA-B644-4520-8F0C-720EAF059935

4. 112ebb9d-b8c9-4abd-9eb3-43578bf86a41

5. 22a17b43-552a-4482-865f-597d4c10bacc

6. 33d8e127-4e58-485b-bee7-266526d8ecb2

7. 44f506a4-b778-4c4e-8522-157aac0efabd

8. 552452fe-f374-47c4-bfad-9ea4165e1bd9

Major/Minor

To define the location of the device, you declare the major and minor values. An example usage would be in a multi-storied departmental store, you will use major to define the level and minor to define the particular section within the level. Since it is a 2 bytes parameter for each value, you can define up to 65536 unique major locations and 65536 unique minor locations. If you do the sum, that’s a lot of unique locations.

Measured power

Another aspect of the iBeacon is that it can tell how far the user is away from the iBeacon device. However, to achieve that, you need to calibrate the device. The way to calibrate is fairly straightforward. You need a mobile app that can measure RSSI, and you use that to measure the RSSI at a 1m distance from your device. I would also recommend you to do the calibration in multiple directions and compute the average as the measured power. Bear in mind that the measurement is in dBm.

The best time to calibrate is on actual deployment. Laboratory or factory calibration will usually net the best results but it doesn’t reflect your actual environment as there are many factors to consider when it comes to RF, e.g. Fresnel zone, Dead zone and etc…

Surprise

A little surprise to some but you can actually indicate the device’s battery life in the advertising protocol. It is a little more advanced so I wouldn’t recommend it to beginners. The reason why you can do that is that Apple protocol does not use up all of the available advertising bytes for BLE; you can squeeze in 1 more byte right after measured power. However, since it’s only 0-15, you will need to include custom firmware code within your device to digitize the battery level into 16 levels.

Go forth and code away!

Categories
News Tech bites

BLE introduction: Notify or Indicate

What are the differences between Notify and Indicate?

The short answer is that they both basically do the same thing, except Indicate requires acknowledgement, while Notify does not. For the longer answer, please read the rest of my post.

By default, you cannot push data to your remote client whenever your Bluetooth low energy (BLE) device has new data to publish. If you read my previous post, you will know that you need to enable the proper permission and include a “Client Characteristic Configuration Descriptor” (CCCD) for that to happen. Not forgetting, your remote client must subscribe to the attribute via the CCCD to receive the pushed data.

Typically, people push data when they want their remote client to asynchronously receive updates whenever their BLE device has new data. While you can perform a periodic polling, the method wouldn’t be very energy efficient and you will not get the quickest update (this depends on your polling rate). Also your BLE device might get updates in an aperiodic fashion, so periodic polling is an utter waste of energy. Furthermore, polling requires two-way communication and Notify is one way, so you will save on radio airtime which would lead to further energy reduction. However, because Notify is unacknowledged, it is unreliable since you will not know whether your remote client has received the data.

To rectify that, let me introduce the Indicate feature. It is almost the same as Notify, except it supports acknowledgment. Your remote client will have to send an acknowledgement if it has received the data. However, such reliability comes at the expense of speed since your BLE device will wait for the acknowledgement until it has timed out.

Conclusion

pro-con-notify-vs-indicate

For most use cases, I would recommend you start with Notify until you find out in your test environment that data is dropping out, then you move into Indicate. In any case, Indicate might take up additional airtime, but it shouldn’t drastically affect your use case. If the communication speed of Indicate is bordering your requirement, then perhaps you should be looking at alternative wireless technologies because BLE is not meant for high-speed communication.

Categories
News Tech bites

GATT it man

Hey folks, I am back with another article on Bluetooth Low Energy (BLE). In my previous article, I addressed some common misconceptions between classic Bluetooth and BLE. This time, I will be talking about one of the most commonly used profiles for a BLE device – the GATT, also known as the Generic Attribute Profile.
Before I begin, let’s start with a good ol’ history lesson. You may ask why. Simply because I love history, and I promise it’s a short one.
BLE was not always known as Bluetooth Low Energy. It was first conceived by Nokia in 2006 as Wibree. Then, it was touted to be a competitor to Bluetooth and there were articles on how Wibree might replace Bluetooth in some use cases. However, as we all know by now, that didn’t happen because Bluetooth SIG absorbed Wibree in 2010 into its current Bluetooth v4.0 specifications and BLE was born. As always, we have to thank Nokia for laying the foundation of many good wireless technologies that we have come to enjoy today. Nokia 3210, I will always love you for being my first… mobile phone.
With the history lesson behind us, let’s move on with the introduction of BLE profiles and protocols.
For BLE, you will use one of the following profiles or protocols:

  1. GATT-based profiles
  2. BR/EDR profiles
  3. BR/EDR protocols

I will focus on GATT-based profiles as they are  the most commonly used profiles in data-transfer applications.

GATT Profiles

When one looks deeper into the GATT-based profiles, one will quickly discover that Bluetooth SIG has defined many profiles for generic IoT usage. Of course, you can also design a custom profile if none of them suits your use case.  However, there are reasons that Bluetooth SIG has a predefined profile.
First, a predefined profile is kind of like a “plug and play” element in your design. Most BLE-chip software development kits (SDKs) would support some of such profiles and all you have to do is to enable them. This saves a lot of time for developers.
Second, the predefined profile uses the 16-bit universally unique identifier (UUID) because it has been approved by Bluetooth SIG. A custom profile needs to use a 128-bit UUID to prevent collision with an existing UUID (if any) and for future-proofing the design.
Having said so, a predefined profile will not be flexible when you need to transmit information that is not in the predefined list. When that happens, you will need a custom profile. At this junction, I know that some of you guys may have the tendency to “retrofit” a predefined profile for your use case, but I will not recommend that. It is better to define a custom one from scratch.

gattitman-pros-and-cons-table
Pros-and-cons summary table

GATT Structure

As much I wish to go into great detail on the deep, deep abyss of BLE, I will give only an overview to get you chaps started. Ok, maybe it’s not that deep of an abyss and maybe it’s a shiny piece of heaven to some of you chaps. I will give only an overview. For those who wish to learn more about BLE, do read this.
The best way to get started is to have a graphical representation of the GATT profile.

gatt-structure
Figure Credit.

When it comes to designing a profile, there are three attributes that must be taken care of – namely service, characteristic and descriptor. Each attribute is demarcated by a handler number which is usually enumerated automatically by your Bluetooth chip SDK. If your SDK does not take care of that, I will just say “have fun enumerating”. So to prevent making a mess out of your code, it’s better to design and reiterate before you jump into your code, you code monkeys.
One good note when it comes to designing a profile is that it’s not necessary for a characteristic to hold a descriptor, but it’s mandatory for a service to hold at least one characteristic.

Service

There are two types of services – primary and secondary. Usually, developers will use only the primary service because the secondary service can exist only under the primary service, which makes it a little tricky to use. Within a profile, you may find multiple primary services. For example, a standard heart-rate tracker will have the following services:

  • Device information service
  • Battery information service
  • Heart-rate service

Note that all of them are predefined services. You are encouraged to create your own service if none of the standard services fits your usage, modification to the service may yield unexpected results and it’s recommended that you write your own service characteristics.
So if you look at the above graphic, you can think of service as a container for all your characteristics. During device advertising, you would usually include the UUID of the key primary services so your remote client will discover the right device.

Characteristic

A characteristic is a data container for the information that your device wishes to transmit to your remote client. For example, a heart-rate service will have a Heart-Rate Measurement characteristic to hold the heart rate that your device has detected.
When declaring a characteristic, you will also determine the permission level for the characteristic:

  • Read
  • Write
  • Write with response
  • Signed write
  • Notify
  • Indicate
  • Writable Auxiliaries
  • Broadcast

The most common permissions would be read and write. One a side note, if you wish to push your data to your remote client, you will need to enable the notify permission. However, enabling the notify permission is not enough, you will also need to include the notify switch descriptor, also known as Client Characteristic Configuration Descriptor or CCCD.

Descriptor

As mentioned previously, it is not entirely necessary for a characteristic to be accompanied by a descriptor. A question that a reader might ask is, under what circumstance would you include a descriptor? That would be when you wish to describe a characteristic (like its name or function) or to include a notify switch. For the former, you would include a “Characteristic User Description” and for the latter, you would include a “Client Characteristic Configuration Descriptor”.

In Summary

In a nutshell, you use a predefined profile if the standard profile is good enough for you, and a custom one if you know what you are doing.
For a firmware designer, you have to take note that the BLE GATT profile is by no mean persistent. You will need some form of non-volatile memory to hold your default values or previously captured data and instantiate your GATT profile during each device restart or power up.
Now go forth and code away!
Build the future.

Categories
News Tear downs

Teardown of the low-cost No.1 Sun 2 smartwatch

Overview

We have already done a teardown on the LG watch R, and today, we will tear down the Sun S2 to see what lessons we can glean from this low-cost smartwatch from China. A review on the watch has already been done, and we are not making a head-on comparison with the LG watch R.

It will be interesting to learn the design and manufacturing differences between the two that brought about such a big price difference. We will look at the following:

  1. The Charging Plate and base cover
  2. Audio Speakers
  3. Battery and microphone
  4. Mainboard PCB
  5. The Display and touchscreen controller
  6. Comparison
  7. Conclusion

Introduction

Tech circles were recently abuzz with announcements of new smartwatch releases, such as the new Samsung Gear S2 and Huawei’s Watch. Each smartwatch had its features benchmarked against the famous Apple watch.

However exciting the new smartwatches are, consumers often forget that the bulk of global electronics manufacturing is still centred in China, with massive manufacturing infrastructures capable of producing electronic wearable clones en masse.

Although the Huaqiangbei district in Shenzhen, Guangdong province, is notorious for counterfeit versions of leading electronics brands, we increasingly see products with additional features not found in the original devices. The parts are – of course – targeted at the growing segment of cost-conscious and tech-savvy consumers.

Apple watches knock-offs were available for sale the following day after the timepiece was unveiled. It is a fresh reminder that Chinese engineers and factories are more than capable of churning out cheaper alternatives and producing fakes at turn-around times measured in weeks instead of months. These are propelled by consumers’ insatiable appetite for the latest technologies.

The market has seen trends where consumers do not necessarily desire the best or latest gadgets but what’s more accessible to them in terms of affordability and availability. Such trends explain Xiaomi’s meteoric rise in the market of wearables and smartphones, surging past incumbent market leaders such as Fitbit and HTC.


In our usual trawl for the latest gadget bites, we chanced upon the No.1 Sun S2 smartwatch (above). The No.1 Sun S2 smartwatch is much like the LG Watch R as they both have round screens, but the similarity ends there. The Sun S2 costs S$80 (US$55), about one-fifth the cost of an LG Watch R, which initially retailed at S$399. That’s five No.1 Sun S2 smartwatches for the price of one LG Watch R.

The Charging Plate and base cover

A very nicely constructed magnetic charging base that even features a speaker duct!

No surprises here, the base came off quickly, revealing the expected optical photoplethysmograph (PPG) heart-rate sensor from Taiwanese PixArt PAH8001 featuring an integrated pixel array plus a green LED sensor in a 3 x 5mm SMD package with a low power consumption of 1.5mA. The complete datasheet is available here.

Not included in the LG watch R is an onboard camera! The specifications state a 0.3 megapix0.3-megapixels place where a usual adjustment crown would have been in a typical mechanically-winded watch. A possible inspiration from the Samsung Gear 2’s camera? Still a bona fide spy watch!

The microphone port is found on the left side of the watch, with the speaker placed on the opposite right, a well-thought layout, so the microphone will not pick up feedback from the speaker.

The designers went through the trouble of designing a clear window separator into the base cover for the heart-rate sensor and a cover mesh grill for the speaker, no shoddy slap-together work here.

Audio Speakers

The orange arrows in the above picture show the design of the acoustic channel.

The plastic brace was pried away to reveal a hefty speaker driver indeed! Not your typical piezoelectric buzzers found in a watch but a driven membrane speaker. The plastic housing appears to have machined-milled markings typical of a Computer Numerical Control (CNCed)-finish. Could this piece have been a piece of moulded plastic that went through machining post-moulding? The housing also contains a nicely designed acoustic channel that speeds the sound away from the speaker to the watch’s exterior—a charming engineering design.

Battery and Microphone


With the plastic brace out of the way, a standard 350mAh lithium polymer battery pack is soldered directly to the main printed circuit board (PCB). It appears that JST footprints were designed for attaching batteries. Still, they opted to solder the battery onto bare pads instead, a labour-intensive manufacturing process but one which saves the cost of an additional two components (male and female connectors) and allows generic battery leads to be used.

We couldn’t find information on the “XA2D 1516” markings of the microphone; it is likely another low-cost analogue microphone that you can easily replace with alternative components. What was more interesting was the little rubber duct that ducts the microphone’s channel to the watch casing’s exterior. It’s a custom-moulded part to add water resistance to the watch. It seems that the design of this watch isn’t the stereotypical shoddiness of Chinese engineering, which was pleasant and unexpected.

Mainboard PCB

The main PCB is connected to the screen via two flexible Hirose mezzanine connectors, likely for the touchscreen controller and the graphics interface to the screen itself.

The freed flex PCB houses the PixArt PAH8001 heart-rate sensor can now be studied. It’s not unexpected exposed pads for USB connectivity (GND, Data+, Data- and VCHG) that will be connected to the exterior of the base cover via the pogo pins, accompanied by the usual passive decoupling capacitors and a metal stiffener for the 30-pin a Hirose DF37B-30DS-0.4V mezzanine 0.4mm pitch receptacle.

Curiously, over half the connector of the 30-pin is not connected, so design-wise, a smaller connector could have been used to save real estate; such an approach could be to future-proof the design and allow more peripherals to be connected.

With the main PCB free, we can see that a large portion of real estate is entirely unpopulated; the silkscreen to indicates that it’s version 1.0. A likely explanation is that future models of this watch will be populated with other components – GPS? GSM-phone calling features? – To add additional functionality. The design of the PCB certainly seems capable of doing so.

We can now appreciate the layout, how scarcely populated the entire PCB is and how capable the central MCU, which is a Mediatek  MT6260 SoC 32-bit microcontroller, is. The central MCU has the following features:

  • Based on the ARM7EJ-S core
  • FM radio 76-108Mhz
  • Bluetooth 3.0 + EDR
  • LCD or WiFi interface
  • MPEG-4/H.263 codec encoder for video recording
  • HE-AAC audio codec with PCM playback and recording
  • GSM/GPRS/EDGE connectivity
  • Built-in Li-ion battery charger and 14 LDOs for various onboard peripherals

This is one full-featured MCU with built-in power management, WiFi/Bluetooth and GSM, and audio/video capabilities! WiFi and GSM are not featured in this model, but there’s no doubt that future models will use the same MCU and PCB layout. Populated with the necessary support components, those features will become available in the later models.

The most significant component is the MT6260 SoC MCU, flanked by a Gigadevice Flash Memory 25LQ128YIG chip, a 128 Mbit 133Mhz NOR flash memory (datasheet here) and a TXC T260 crystal series from TXC Corp. Impressive, just four components on the top layer!

We also found a PT116 SOT23-6 charging chip, possibly a current protection regulator for the battery. The routing from the battery to the PT116 certainly appears to fulfil that function since the Mediatek MT6260 has a built-in lithium-ion battery charge controller. An unknown “CM4U VV3” chip is also observed, which is likely the accelerometer sensor.

A quick schematic of the PT116 battery charger/protector.

Moving onto the bottom layer. Besides the camera, membrane button as well as an Eccentric Rotating Mass (ERM) vibrator and a microphone, there are no other components populating the bottom of the PCB.

The camera module is a YUV422-format type 22-pin that is soldered directly onto the PCB with a resolution of 640×480 pixels (0.3 megapixels). The YUV colour encoding scheme assigns both brightness and colour values to each pixel. In ‘YUV,’ ‘Y’ represents the brightness or ‘luma’ value; and ‘UV’ represents the colour or ‘chroma’ values. In contrast, the values of the RGB encoding scheme represent the intensities of red, green and blue channels in each pixel.

The YUV422 format cameras usually use 14 to 20-pin assignments and it’s common to see such VGA-resolution camera modules support YUV422 or RGB565 data output formats. This module is no different; read more about YUV-type formats here and here. Space is saved by soldering the module directly to the PCB at the cost of ease of replacement.


One of the other two spaces on the PCB appears to be the footprint of a microSD card socket. We found that it fits a microSD card very nicely could it be expansion-able memory storage? Adjacent to the space is likely space for a SIM card for GSM-enabled models of this watch.

The Display and touchscreen controller


From our tests, the screen is satisfactorily responsive and the graphics are crisp and sharp. The BL-RL-IPS122H001A-3 screen appears to be a Hyundai SW122DC IPS screen from Hong Kong that was manufactured on the 12th of June 2015. Specifications include:

  • 262K colours
  • Resolution: 240(H) X 204(V)
  • 1:1000 contrast ratio
  • 0.7mm thick Corning glass cover
  • Interface: SPI 4 wire via a Hirose DF37B-24DS-0.4V Mezzanine 0.4mm pitch 24-way receptacle

The capacitive touch controller is a Mstar Semiconductor MSG22S that supports screen sizes up to 3.2″ and an X, Y resolution of up to 2048×2048 pixels.

The uQFN-32 chip on the flex PCB has an operating voltage of 2.8V ~ 3.3V and appears to have embedded flash memory & SRAM via an I2C slave interface. It is able to transfer data at up to 400Kb/s through the 0.4mm 10-way connector. The MSG22S also has a built-in 1.2V LDO with programmable interrupt (INT) levels: 1.2V, 1.5V, 1.8V, and VDD.

This beefy little chip also touts automatic background capacitance tracking with a 14-bit Analog-To-Digital Converter (ADC) with a 120Hz update rate! That allows it to support wet-finger tracking with enhanced immunity to RF interference and AC charger noise which plagues many other capacitive touch controllers. Several useful articles on EMI-rejection methods in touchscreen designs are discussed here and here.

Up until 2011, US companies – including Atmel, STMicroelectronics, Synaptics, and Cypress – had dominated the capacitive touch controller IC market. But as the global demand for smartphones and tablet PCs soars, Asian companies such as FocalTech, Elotouch, Goodix and MStar Semiconductor from China and Taiwan,  while Melfas, Zinitix and Imagis Technology are emerging as the leading vendors in South Korea. More options are now available to developers!

Goodix, formally known as Shenzhen Huiding Technology, provides touchscreen controllers to major clients include Samsung Display Corp, JDI, Huawei, Toshiba, Asus, Lenovo, Acer, Nokia and many other giants in the tech industry and has even recently challenged Synaptics’ touchscreen controller patents! Juicier reading here.

Comparison


If you compare these two smartwatches it becomes clear that the winner based on specifications would be the LG Watch R. But at one-fifth the cost, the No.1 Sun S2 watch does give consumers a fully featured smartwatch that meets most expectations with similar specifications and functions. Considerable cost advantage and availability is a major contributing factors when it comes to consumer purchase decisions.

Conclusion

What have we learnt?

The system is obviously designed to be more capable but possibly crippled or designed for future upgradability so that an inexpensive model in the manufacturer’s line is first introduced to gain market traction before the full-featured flagship model is released to the market.

This is a good business strategy in terms of engineering and marketing – such an approach reduces the number of component variants and allows different models to be released based on the same hardware. The need to retool a manufacturing line or procure new components for a separate model is reduced whilst giving consumers the illusion of choice. Yet, between sales of thousands of units versus Apple’s millions, Chinese brands will need to improve their standing amongst consumers if a major global market share is to be captured.

The No.1 Sun S2 watch is packed with Chinese silicon. The MCU, memory, sensors and controllers can be manufactured at a fraction of the cost of its Western equivalent components, and with the Chinese capable of producing tens of thousands of such devices, consumer choices may well soon be skewed in the other direction of low-cost, functional and relatively fashionable wearable devices, a business direction that has enabled certain Chinese companies to enjoy massive growth in recent years.

Have a platform you want to learn about? We have IPC-CID+ and electronics professionals on our team and we provide in-depth teardown and investigative report services.

Build the Future!

Categories
News Tech bites

Bluetooth: should you go low energy?

Bluetooth today is understood by many as a convenient connectivity solution. Yet there are limitations regarding its flexibility and this entry serves to discuss some misconceptions about Bluetooth Low Energy (BLE or Bluetooth Smart) and classic Bluetooth.

We often receive projects that involve Bluetooth communication, yet many of our clients specify “BLE” without understanding the technology sufficiently. Many assume that BLE is simply classic Bluetooth or Bluetooth v2.x, but with much lower energy consumption. I don’t blame them for the misconception, since our latest mobile devices, e.g. mobile phones and tablets have been touting BLE as if it is a replacement for classic Bluetooth. Furthermore, the name – Bluetooth Low Energy – isn’t much of a help in undoing the misconception. Hence, I have decided to contribute this article and, hopefully, it can be of help to some of you who are reading this.

Before I begin, I would like to say that this is not an extensive article. It will be about the top most common misconceptions that I have often encountered. For the benefit of those who aren’t familiar with BLE, do read these pages for a good introduction (here and here).

Misconceptions

1. Using BLE to perform high-rate data streaming

At this junction, if you have read enough about BLE, you should have an inkling that it was chiefly designed for low-rate of data applications, e.g. Internet of Things (IoT) sensor nodes and Human Interface Devices (HID). Unlike classic Bluetooth, BLE has very low data throughput. This is because of the optimizations made to the Bluetooth profiles and Logical Link Control and Adaptation (L2CAP) to achieve low energy consumption.

bluetooth

(source)

To give a sense on how low is low data throughput, I will put forth a scenario. However, before that you have to understand that data in Bluetooth is split into packets and exchanged through one of 79 designated Bluetooth channels. The scenario that I will be putting forth will be based on a Generic Attribute Profile (GATT) structure that most BLE devices utilize with the following settings:

• ARM M0+ chip (operating frequency of 48MHz)

• Connection Interval of 7.5ms, which is the lowest setting (I will explain more later but typically, shorter connection interval results in higher throughput)

• Default Maximum Transmission Unit (MTU) of 23bytes per packet

Connection interval (CI) in BLE is defined as the time period before the radio jumps to another channel. A shorter CI will result in a lesser amount of packets being sent before the radio switches channel. Since swapping channels will result in downtime, you may begin to think that the CI should be as long as possible so more packets can be sent through one channel. The idea of having a longer CI to reduce downtime and hoping it will result in higher data transmission rate does sound feasible. However, life is often not that straight–forward, especially when it comes to Radio Frequencies (RF). A longer CI will also create more opportunities for RF interference to set in, and corrupt your transmission and connection event. Thus, it leads to an even lower data transmission rate.

Under the aforementioned settings, I typically get around 1 packet per connection event (7.5ms). In 1 second, I will get 133 packets transmitted and with an MTU of 23 bytes, my data throughput is 3059 bytes per second. However, take note that the L2CAP profile on BLE devices takes 3 bytes for the notification process. As a result, only the remaining 20 bytes will contain the actual data that you desire, if you spec-ed it for the notification process.

I hope that it is clear to you now that BLE is not cut out for high-rate data streaming. If you wish to perform high-rate data streaming like file transfers, please stick to classic Bluetooth.

2. BLE doesn’t auto-connect like classic Bluetooth

Very often I am asked, “Why doesn’t the BLE device auto-connect when I turn it on, even after pairing?” The answer is very simple. BLE devices don’t auto-connect like a classic Bluetooth device because it wasn’t designed to do so.

Natively, only classic Bluetooth like Bluetooth v2.x + EDR has native reconnect functions. However, all is not lost; you can simulate the reconnect feature by writing the feature into your software. The only problem is that your software must be running in the background for that to work. Therefore, if you are working on a device that requires constant connection, make sure you write a “ping-pong” feature to support “auto-connect”.

Thank you for reading this article. Hope you find it useful and do remember to share our article. Feel free to comment below.

Categories
News Uncategorized

When USB lights get too hot

USB powered lights are convenient for reading, off-center lighting for mobile photo-taking and the like and on the market are some low-cost and simple USB-powered reading lights such as the S$2 Xiaomi Mi LED light.

Unfortunately, we found that the light output is not sufficient for certain conditions. A quick tear-down revealed a SAM semiconductor S8101 LED driver and what looks to be a row of six PLCC-2 3020 Package LEDs. The Mi LED light is rated at 1.2W and draws about 240mA @ 5V, that gives about 40mA/200mW power dissipation per LED.

While low-cost, the flexible-neck USB light puts out a measly light. Inspired, it was time to quickly hack our own.

We found another low-cost LED-powered lamp, rated at 5W and 450lumens on the packaging, which is supposed to be four times brighter. It has ten 5730 COB LEDs. The 5730s are rated to output more light than a 3020 module (~45 vs 5.4 lumens), see comparison here. The 5730 LED module also has a greater efficiency than the 3020 (90 vs 80 lumens/watt), however, note that lumen brightness varies greatly for different colour temperatures and LED binning, and this is just a simple gauge.

We removed the LED-PCB from its plastic housing and, with a little sawing (literally), soldered it to a flexible-neck USB extender and voila! We’ve now got our 450-lumen flexible USB-LED light. It’s blazingly bright, looks good and performs well!

Until we touched it to remove it from the USB port and YIKES! IT WAS HOT. It wasn’t warm, but HOT.

The thermal camera showed the LEDs and the schottky diodes heating up to a blazing 105°C. Insane!

Not to worry, we had a couple of cooling fans meant for cooling PC motherboard northbridges lying around. Those fans usually run at 12V from a motherboard fan header. USB voltage is rated at 5V and adding a 5V to 12V step-up converter is neither practical nor a 5-minute solution. So instead, we got a small 5V 40x40x10mm cooling fan from the hardware room and swapped out the 12V 40mm fan with a 5V one. No fuss!

Fortunately, the mounting holes of the northbridge cooler and the LED PCB were conveniently aligned! So with some thermal paste and trusty cable ties, the heatsink fan assembly nestled nicely onto the PCB and the fan wires were soldered to the 5V and USB ground. The assembly runs at a cool 34.7°C now!

A quick measurement with the light-meter shows 115.7 kLux of brightness, (converting that over 60mm2 or 0.0036m2 area to lumens is 416.52 lumens, close to the rated 450 lumens of the product.

It also seems to be drawing 960mA, or 4.82watts at 5.03 volts, which is expected.

A note of caution: a standard USB2.0 port on your computer is capable of delivering up to 500mA (0.5A); with USB 3.0, it moves up to 900mA (0.9A), so this guy isn’t exactly USB-hub friendly, but plugging it into a standard powerbank or a dedicated USB wall-adapter isn’t an issue since they can provide upwards of 1A.

With that, now we have a 416lumen USB-powered flexible lamp for various uses in the lab. This project took a little less than a lunch break to hack together, we hope you like it!

Build the future.