CC Blog Design Solutions Research & Design Hub

InPlay’s NanoBeacon

FIGURE 1 This is the IN100 development kit supplied by InPlay. Note that it comes with a programmer and three IN100 modules.
Written by Brian Millier

An Ultra-Low Power BLE Beacon That Needs Almost No Programming Effort

If you need to design a Bluetooth Low Energy (BLE) beacon with the ability to read sensors, the IN100 is a new, ultra-low power device that may fit the bill. While not as versatile as a BLE-enabled microcontroller (MCU), it is much less expensive and requires virtually no coding.

  • What should I use when designing a BLE beacon that can read sensors?
  • What is the IN100 NanoBeacon from InPlay?
  • What is a good ultra-low power BLE beacon?
  • IN100 NanoBeacon from InPlay

Of the many projects that I’ve built using ESP32 microcontrollers (MCUs), several of them have used Apple’s iBeacon Bluetooth Low Energy (BLE) protocol to send sensor readings and alarm statuses to a central hub. This hub can then send email alert messages, SMS messages, or just post sensor data to an MQTT server. The ESP32 is good at doing both the sensor end and the central hub. Both Espressif’s IDF toolchain and the Arduino IDE have decent BLE libraries to handle this wireless protocol, so writing the necessary program isn’t too much of an effort.

The only real limitations with the ESP32 might be its price and the fact that its power consumption is rather high if you are planning on powering the remote sensor units from a battery. While you can drastically reduce the ESP32’s power consumption by putting it into a “deep-sleep” mode, that results in it powering back up via a full hardware reset. This takes a bit of time, and variables that have to persist between sleep cycles must be stored in RTC RAM. Also, the ESP32 will draw up to 350mA while it’s transmitting RF packets, although BLE beacons will be much shorter than a normal Wi-Fi packet.

Recently, I discovered the IN100 NanoBeacon device, manufactured by InPlay (headquartered in California). These devices provide BLE beacon capability and the ability to monitor various forms of sensors. The IN100 has three main claims to fame:

  • It consumes an extremely low amount of power, especially in its “sleep” mode.
  • It is tiny—2.5 x 2.5 mm in DFN8 or 3 x 3 mm in QFN18. (The newly announced version also comes in an even smaller WLCSP package.)
  • It requires no discrete programming and instead can be configured completely using InPlay’s NanoBeacon Config Tool (a PC application running under Windows, Linux, or Mac OS).

The IN100 in the larger QFN18 package costs about $1.30 USD, and about $1.00 USD in the smaller 8-pin package (which has less I/O capabilities). Both quoted values are for a quantity of one. If you’re familiar with the projects I write about in my columns, you’ll know that I can’t handle/mount such small devices. Therefore, I wouldn’t be trying out these devices unless suitable breakout/development boards were available. Luckily, both InPlay and Sparkfun provide such boards at reasonable prices. Let’s first take a look at both offerings.

IN100 DEVELOPMENT BOARDS

Even in their largest package (QFN18), the IN100 is a tiny device, and when starting from scratch, the best way to go is by obtaining InPlay’s own IN100 Development board. Referring to Figure 1, you can see that it is made up of two parts: the IN100 NanoBeacon board itself and a matching programmer for the device. This development kit costs only $30.00 USD and comes with one programmer board and three NanoBeacon boards. You might think that InPlay is being overly generous in supplying three NanoBeacon boards. However, the IN100 devices are one-time programmable (OTP), which is somewhat of a disadvantage, in my mind. Having three NanoBeacon boards to experiment with gives you some room for error in case you don’t get the configuration right the first time. There is a workaround for this—running your configuration in the IN100’s internal RAM, which I’ll explain in more detail later in the article.

FIGURE 1
This is the IN100 development kit supplied by InPlay. Note that it comes with a programmer and three IN100 modules.
FIGURE 1
This is the IN100 development kit supplied by InPlay. Note that it comes with a programmer and three IN100 modules.

The first thing you’ll probably notice is that the NanoBeacon board contains an SMA socket for the antenna, rather than the common PC board trace antenna found on ESP32s and other RF MCU modules. This was done for a couple of reasons:

  • During development, you might want to monitor the RF power/waveforms with a ‘scope or VNA, and this would be impossible if only a trace antenna were provided.
  • You can try out various types of whip/stub antennas to determine the normal range of each antenna.

At this point, I’d like to point out that the IN100 Development board’s SMA socket is a “regular” SMA socket—not the RP-SMA (reverse polarity) socket that is commonly used on Wi-Fi routers and such. That is, the IN100 Development board’s socket has a female inner connector. The antennas used with Wi-Fi routers usually come with RP-SMA plugs that also have a female inner contact. If you’re like me, you have several old Wi-Fi routers stuffed in a drawer. Therefore, I didn’t bother to order an antenna for the NanoBeacon development kit. If you do plug in a Wi-fi router antenna, it will mate up fine physically and is designed for the correct frequency. But you are plugging a female jack into a female socket. So, such an antenna won’t work with the NanoBeacon board. During early testing on my bench, this lack of a functioning antenna didn’t stop me from receiving the IN100’s beacon signal on my phone—a few feet away. However, I received a rude awakening when I started testing the range—it was horrible! I then tried out an antenna from an nRF24L01 module I had in my parts drawers. It worked well, and I quickly noticed that the nRF24L01 antenna contained a regular SMA jack, and its male inner pin mated properly with the female inner pin on the IN100 board. Lesson learned. DigiKey sells an adapter that will overcome this issue—the ADP-SMAFRP-SMAF—but it makes sense to get an antenna with a normal SMA plug on it.

The programmer board contains a Micro-USB port for connection to your computer, for both programming and powering the IN100 board itself. There is a CH340 USB-Serial bridge chip on the programmer board which provides a TTL-level bidirectional serial interface to the IN100. The CH340 USB bridge is now used on many ESP32 boards, so the PC driver for it was already present on my computer. However, InPlay provides a link to the proper CH340 driver on their website.

All interaction between the NanoBeacon Config Tool PC application and the IN100, including the actual flashing of the IN100’s OTP memory, is done via this serial link. Therefore, lacking this programmer board, you could also program IN100 devices (and/or interact with them using the NanoBeacon Config Tool) via either:

  • A USB-TTL Serial cable (with 3.3V logic levels)
  • A USB-TTL Serial adapter module (also with 3.3V logic levels)

The IN100 programmer board contains a 3.3V LDO regulator powered by the PC’s USB port. This normally powers the IN100, but there is a switch on the programmer that can disconnect this 3.3V power source from the IN100 board. While not visible in Figure 1, the backside of the IN100 board contains a socket for a CR1220 coin cell which can power the IN100 board, whether or not it’s connected to the programmer board (via the 10-pin header connector). You can run the InPlay IN100 development board without its matching programmer board by using one of the USB-Serial adapters mentioned above, but you will likely find that such cables/adapters provide 5V on their power lead—not 3.3V. So, you’ll have to provide 3.3V for the IN100 development board some other way. While I haven’t tried it, I believe the CR1220 coin cell would work OK, but possibly not for the actual Flashing operation.

The IN100 board contains J8—a 2-pin socket/jumper which can be used to patch in a current monitoring device to monitor the actual power used during a beacon transmission (as well as the idle current during sleep). I’ll cover this in more detail later in the article.

While I got started with the IN100 using the InPlay development kit described above, I was also interested in the Sparkfun IN100 boards. They weren’t in stock at DigiKey when I obtained the InPlay development kit, but I ordered a few of them later on.

Figure 2 shows the Sparkfun IN100 development board. They cost $5.95 USD and come in two similar models, of which one has pin headers attached. The other one comes without attached pin headers but contains an additional reset switch and power LED. Both versions contain the common Qwiic connector for attaching external I2C sensors. Unlike the InPlay development boards, the Sparkfun models contain a trace antenna (invisible in the photo). The Sparkfun boards contain a CR1225 socket whereas the InPlay development board has a CR1220 socket. I bought a 10-pack of CR1220 coin cells, as these slightly thinner cells work fine with both boards.

FIGURE 2
This is Sparkfun’s IN100 breakout board. This particular model comes with header pins, but no reset switch or power LED.
FIGURE 2
This is Sparkfun’s IN100 breakout board. This particular model comes with header pins, but no reset switch or power LED.

Both InPlay’s and Sparkfun’s IN100 boards contain 0.1” headers which bring out all the necessary IN100 power and I/O pins. Being an “old hand” at designing breakout boards, Sparkfun spaced the two rows of pins at a distance of 0.9” apart, so they mount on Vector and protoboards nicely. Unfortunately, InPlay’s PCB designers didn’t think of this, and their headers are spaced at 0.924” (23.5 mm), so they don’t mount properly on either Vector boards or protoboards. This is why I decided to get the Sparkfun boards later. I used a USB-Serial cable to interface the Sparkfun boards to the NanoBeacon Config Tool running on my PC. This works OK, but isn’t as convenient as using the InPlay IN100 development board/programmer board combination.

The model of Sparkfun board that I ordered came with header pins but no reset switch. Note that when the IN100 is running a program from RAM, the only way to reload a program is to reset the IN100. You would think that this would merely involve turning off the VDD power to the board, but this doesn’t work. The reason is that the serial Rx and Tx pins are still connected, and they supply enough “phantom” power to keep the IN100 running. So, for the Sparkfun boards, doing a reset involves both removing VDD power and disconnecting the USB-serial bridge cable. While that is readily done by unplugging the USB cable from your PC’s USB port, this will kill the USB cable’s COM port in Windows. So, you will have to use the Config Tool’s Probe command again and reconnect to the proper COM port. The lesson here is to get the model of Sparkfun board with the reset switch and solder on the missing header pins yourself.

IN100 NANOBEACON FUNCTIONALITY

Let’s look at what the IN100 device can do. At its core, it contains a BLE RF transmitter and associated modulator. Unlike Nordic, ESP32, and Infineon AIROC BLE-enabled MCU modules, the IN100 doesn’t attempt to implement the full BLE protocol stack. If you’ve worked with BLE, you’ll know that BLE is a complex protocol, requiring a large software stack to fully implement. Instead, the IN100 implements just the BLE Beacon protocol, which is a one-way communication and is therefore what is termed “connection-less.” That is, Beacons don’t “connect” to a remote device and exchange data back and forth (optionally with some form of message acknowledgment). Instead, they just broadcast their message to however many remote devices are within range, and they have to assume that the intended remote device actually got the message. There are many applications where this lack of an acknowledgment of a sent message would be a deal-breaker, but there are plenty of cases where this beacon protocol is sufficient. To bolster this connectionless protocol, Beacon messages are generally sent several times on different RF channels to maximize the chance that they will be received by the targeted device.

BLE Beacon transmitters generally operate at a lower RF power than you would normally expect for Wi-Fi packet transmissions. Generally, a 5dBm (or less) RF power level would be used for BLE packets, since the “LE” in BLE stands for low energy, and a battery is normally the power source. The IN100’s RF transmit power is programmable in 1dBm steps between -54 and +5dBm. Obviously, at the -54dBm extreme, you would get great battery life, but the range would be limited.

Beyond the BLE Beacon RF core, the IN100 contains a state machine (a rudimentary MCU) to coordinate timing and to monitor the GPIO pins and various sensors (both internal and external). The internal OTP ROM memory configures how this state machine operates. How the state machine is configured is handled quite seamlessly by the NanoBeacon Config Tool application which runs on your PC.

It’s been decades since I worked with MCUs whose non-volatile program memory could only be erased using UV light (when reprogramming was called for). I’ve never worked with MCUs that contained OTP program memory that can only be programmed once. So, I was somewhat wary of the IN100’s OTP program memory—I don’t mind admitting that I almost never get a program 100% right the first time. Of course, the $6 USD Sparkfun development boards are inexpensive enough that you can afford to throw them away until you get your configuration 100% correct. However, I don’t like wasting parts, so I was glad to hear that, in most cases, you can test out your IN100 configuration program by running the IN100 in a “run from RAM” mode. In this mode, you can experiment all you want until you get it right, and only then burn the configuration to the IN100’s OTP memory. Of course, “run from RAM” only runs so long as power to the IN100 remains present, but both the InPlay and Sparkfun boards have battery sockets, so you can run the board under battery power.

Besides the state machine, the IN100 device also contains the following peripheral blocks:

  • UART device—This is used by the Config Tool for programming/testing, but also can optionally be interfaced with an external MCU when running an actual application.
  • I2C port to connect to external I2C sensors, and so forth (which run in remote mode)—The I2C port is the only IN100 function that cannot be tested in the “run from RAM” mode. You must burn your configuration to OTP ROM if the I2C function is used.
  • Pulse Count Interface—This is a fairly limited pulse counter which can be used to interface to certain sensors that provide a compatible pulse output.
  • ADC—This is an 11-bit, fast ADC that is multiplexed between an internal temperature sensor, VCC monitor and four GPIO pins (specifically the MGPIO pins).
  • Programmable load switch—This comprises two FET switches that can be programmed to connect/disconnect an external load to the VDD and VSS bus. There are some significant limitations to this feature, which I’ll get into later.
  • GPIO pins—Depending upon the package chosen, there are up to eight GPIO pins available—four of which are useable as analog inputs to the ADC.
  • Sleep Timer—This block can place the IN100 in a deep-sleep mode between measurements/beacon transmissions.
  • Timer(s)—These can be used to “timestamp” the Beacon transmissions.
  • Encryption—There is AES-128 based encryption for data and AES-128 based authentication (both optional).

Given the above functionality, typical applications of the IN100 are retail beacons, wireless sensors, asset tracking, alarm systems, and fitness applications.

THE NANOBEACON CONFIG TOOL

During the development process, the IN100 devices are configured by the NanoBeacon Config Tool application which runs on a PC under Windows, Linux, or Mac OS. This is a fairly straightforward application which you can see in Figure 3. The IN100 development kit’s Programmer board boards connect to the PC using a USB serial port, as I covered in the Development Board section. To the right of the Config Tool screen is the UART window: when you click on the Probe button, it will populate the Port list directly below it with the active COM ports. There is no way to know in advance which COM port corresponds to your InPlay IN100 Programmer board (or USB-Serial cable in the case of the Sparkfun board)—unless you happen to have no other USB serial ports connected at the time. You would just try each one until you see a notification window indicating that the IN100 device has connected. If you plug the IN100 programmer board into a different USB socket, it will enumerate as a different COM port. I happened to have my desktop PC’s Bluetooth port configured for Serial Port Profile (SPP). This shows up as COM9, and if I select it by mistake in the Config Tool, it completely crashes the Config Tool and only a full PC reboot will allow the Config Tool to work again.

FIGURE 3
This is a screen capture of the main page of the NanoBeacon Config Tool application that runs on a PC under Windows, Linux, or Mac OS.
FIGURE 3
This is a screen capture of the main page of the NanoBeacon Config Tool application that runs on a PC under Windows, Linux, or Mac OS.

The middle of the screen displays the three different Advertising Sets that the IN100 can handle. Once you enable a particular set, you then click on the Edit button and configure that Advertising Set. First, you would select what type of beacon you wish to implement:

  • iBeacon—Apple’s beacon standard. This has a 128-bit UUID field plus two 16-bit user fields and one 8-bit user field.
  • Eddystone—Google’s beacon standard. This also has a 128-bit UID frame (in two sections) as well as an EID Identity frame and a TLM frame which can be used to send sensor data, and so on.
  • Custom Beacon—With this selection, you can define your own completely unique beacon, or you can use the Custom Beacon setting to emulate either the iBeacon or Eddystone beacon—but while allowing it to contain sensor values and such of your own choosing. These can replace the pre-defined frames in either of those beacon types.

Once you’ve defined your Beacon type, you select the Advertising Parameters tab and enter such parameters as Advertising Interval, Channel, PHY selection (data rate, basically), and Bluetooth Device Address. If you are deploying several IN100s at a specific location, all of which are identical Beacon types and have the same Advertising Interval, you can select among several Random Advertising Delays, to prevent collisions. Selecting more than one Advertising (RF) Channel can also maximize the chance that the Beacon transmissions will get through.

The last and probably most versatile configuration is found in the Advertising Mode tab. This is where you specify whether you want your Beacon packets to be sent out continuously at the chosen Advertising Interval, or whether they must be triggered by some event. There are many choices here:

  • Sensors, such as the on-board ADC (four channels), external I2C sensors, or what InPlay calls a “One-Wire Sensor”
  • The state (or change of state) of various IN100 GPIO lines

Note that in the Advertising Mode tab, you can select from the various functional blocks mentioned above, but they each have to be enabled and configured separately. This is done by clicking on the various tabs along the left side of the screen—just below the Advertising tab.

The One-Wire Sensor doesn’t refer to 1-Wire devices that were first manufactured by Dallas Semiconductor (now Analog Devices). These devices communicated using a timing-critical protocol, and that signal could coexist with the positive power rail. The IN100 is not able to handle this timing-critical protocol, and the One-Wire Sensor instead refers to TI’s LMT01 high-accuracy temperature sensor. The LMT01 sends out its temperature readings in a short pulse train, and the number of pulses sent can be used to determine temperature. There may be other One-Wire devices, but I have not encountered them myself.

The One-Wire Sensor function actually makes use of the IN100’s Pulse Counter block. This is a 16-bit counter which is used to measure the LMT01’s pulse train. The IN100’s Pulse Counter seems to have been designed to work specifically with the LMT01. It must be used in conjunction with the IN100’s Power Switch circuit because the Pulse Counter doesn’t have the ability to decide when to start counting pulses. This gating is accomplished by having the Power Switch turn on the LMT01 when a beacon is programmed to be sent. In this case, the LMT01 pulses won’t start until after the unit is powered up and the internal temperature measurement is taken.

There is a field labeled “Total time of Pulse Sequence (ms)” that must be filled in by the user. This tells the Pulse Counter to stop counting and report the total number of pulses after that time has elapsed. There is also a field titled “Max Gap between pulses (µs)“ that must be filled in and that will dictate how low a pulse frequency can be measured. InPlay provides a good video on how to interface with the LMT01, the link to which you can find on Circuit Cellar’s Article Materials and Resources webpage [1].

That link has about a dozen videos covering the configuration of most of the IN100’s internal function blocks. These videos are well-done, and I encourage you to view them before doing too much experimenting with the IN100.

I had envisioned using both the IN100’s Power Switch and One-Wire Sensor (Pulse Counter) functions for purposes other than the LMT01 sensor interface. However, there are some significant limitations to these functions which aren’t noted in either the IN100 datasheet or the videos mentioned above. What I discovered is:

  • The maximum Pulse sequence Time is 255ms. This means that whatever you hook up to the IN100’s Pulse Counter GPIO pin must be able to wake up from a power-off condition, perform the measurement, and send out the pulse train in less than 255ms.
  • The Maximum Gap between Pulses is 511µs. The Config Tool will warn you if you go beyond 512, stating that 512 is the maximum. However, nothing works if you enter 512—you must limit this reading to a maximum of 511. This means you can’t theoretically measure pulse trains with a frequency of less than 1,957Hz.
  • The Power Switches have significantly higher RDS(on) values than you might expect from a MOSFET (even one in a tiny SMD package). The SW0 (high-side) switch has a resistance of 18Ω and SW0 (low-side) has a resistance of 8Ω. You can’t draw any significant amount of power through these switches without incurring a significant voltage drop.

There is another IN100 function that uses an internal Pulse Counter: the GPIO Edge Count function. While this function does not have the Pulse Sequence Time and Maximum Gap time limitations discussed above, it has no gating function. Therefore, it can only be used to report a running total of the pulses received at the chosen GPIO pin, at each advertising beacon interval. It is, however, a 24-bit counter, so I guess you could determine a signal frequency by taking the difference in readings from one beacon to the next and dividing by the advertising interval. However, unlike the One-Wire Sensor Pulse Counter, I found that this counter would not handle pulses above about 750Hz.

After configuring the Advertising configuration and setting up any necessary IN100 internal function blocks (GPIO, ADC, and so on), you may or may not have to select the “Global Trigger Settings,” and/or the Global Settings buttons, to perform somewhat more advanced configurations. Finally, you would next click on the “Run from Ram” button and watch as the program is uploaded to the IN100 device connected to the Programmer board (or USB-serial cable). The IN100 should then start sending out Beacon messages at the prescribed interval. As mentioned earlier, you must reset the IN100 to reprogram the device.

One thing that I tried successfully was to use the Custom Beacon configuration and populate the beacon frame with the bytes defined by Apple for an iBeacon. In place of the Major, Minor, and Tx Power fields, I was able to substitute variable values being monitored by various IN100 I/O function blocks, such as the ADC. This came in handy because my Particle Argon host (hub) device that was receiving the beacon packets had an available library for the Apple iBeacon protocol. I doubt I would be able to write a BLE custom beacon driver for the Particle Argon board (Nordic nRF52840 MCU).

Whatever configuration you design, you can save and load it to a PC disk file using the appropriate buttons in the Configuration window. This window also contains a QR code button. If you select this, the program will display a large QR code on the screen. When you run the IN100 cell phone apps (iOS or Android), these apps can read this QR code (using the phone’s camera) and configure the cell phone app to reflect the way that the IN100 has been configured. Let’s look at these cell phone apps next.

IN100 CELL PHONE UTILITY APPS

The NanoBeacon cell phone utility app is provided for free by InPlay. The iOS version is available on the Apple App Store, and the Android version on the Google Play Store. I have both an iPhone/iPad and an Android phone available, so I tried them both out.

I am an iOS fan, using both my iPhone and my iPad daily. But I found the IN100 NanoBeacon app on both of my iOS devices to be unreliable. Specifically, when the IN100 was sending out continuous (that is, non-triggered) beacons at a one-second interval, for example, I would often fail to see them reported by the iOS app. However, the Android app, running on a phone sitting right next to my iOS device, would report them properly. This iOS issue was somewhat random, but serious enough that I gave up on using either my iPhone or iPad Air for testing and used an Android phone instead. I did run into a few “bugs” with the Android version of the NanoBeacon app, but after reporting them to InPlay, they were corrected in a later software version.

Since Beacons consist of small, simple packets, the NanoBeacon app doesn’t have a lot to report. However, even in my single-family home which has no close neighbors, there are a number of my own devices that are sending out BLE packets of one type or another, which makes spotting the NanoBeacon a bit more difficult.

This is where filtering comes in. In both versions of the NanoBeacon app, there are numerous ways to filter out extraneous BLE devices. In the Scanner window, there is an icon that looks like a group of three sliders that takes you to the Filter screen. You can see this in Figure 4, and some of the available filters are:

  • By Beacon Type
  • By Beacon Name or Bluetooth address
  • By minimum signal strength (RSSI)

More useful is the ability of this app to read the QR code that is generated by the NanoBeacon Config Tool application—after a user configuration has been defined and uploaded to the IN100. This QR function is contained in a separate Configuration Screen, as seen in Figure 5. The blue icon, right above the trash can icon, is the one that activates the phone’s camera, after which you point it at the large QR code that’s displayed in the PC Config Tool application. All the relevant user configuration details are then populated on this screen. You can choose to filter on this configuration data, after which time the Scan screen will only display beacon packets arriving from any IN100s that are configured exactly this way (including identical UUID and Bluetooth addresses).

I explained why I didn’t use my iOS devices to run the NanoBeacon app. However, I did note that the camera on both of my iOS devices had no trouble recognizing the QR codes. My Android phone is a low-end Motorola cell phone (bought mainly for testing Android apps) and I had to be quite deliberate and steady-handed before it would recognize the QR code.

When an IN100 is operating in the iBeacon mode and set to filter on the configuration supplied by the QR code, the scanner will display a screen as shown in Figure 6 and will update at the beacon interval you selected. If you define your own Custom configuration, and embed some ADC readings and so on in the Beacon packet, when you filter using the appropriate QR code you will see a display that lists those readings by name and updates their values as beacons come in.

Note however that if you use the Custom advertising format and tailor it to emulate the iBeacon frame format (but with sensor data substituted for any of the Major, Minor, or Tx Power parameters), it will NOT display in the NanoBeacon app as an iBeacon (with the sensor data filling in the Major, Minor, Tx Power parameters). Instead, as shown in Figure 7, it just shows up as an unspecified Beacon (matching the QR configuration), and you must look at the Raw Data to determine the value of these variables. Even if it doesn’t show up as an (Apple) iBeacon, it still displays the manufacturer as Apple, as the manufacturer is defined in a beacon field of its own.

FIGURE 4 This is the Scanner Filter screen of the NanoBeacon cell phone app running under Android. Here you can select filters to eliminate other beacons from showing up in the app—apart from the NanoBeacon you are actually testing.
FIGURE 4
This is the Scanner Filter screen of the NanoBeacon cell phone app running under Android. Here you can select filters to eliminate other beacons from showing up in the app—apart from the NanoBeacon you are actually testing.
FIGURE 5
This is the Configuration screen. Clicking the upper blue icon (at the bottom of the screen to the right), you can then scan the QR code displayed on the NanoBeacon Config Tool’s screen of your PC.
FIGURE 5
This is the Configuration screen. Clicking the upper blue icon (at the bottom of the screen to the right), you can then scan the QR code displayed on the NanoBeacon Config Tool’s screen of your PC.
FIGURE 6
After you read the QR configuration code provided by the NanoBeacon Config Tool, you will see all the IN100’s configuration parameters, including Bluetooth address, advertising interval, and so forth.
FIGURE 6
After you read the QR configuration code provided by the NanoBeacon Config Tool, you will see all the IN100’s configuration parameters, including Bluetooth address, advertising interval, and so forth.
FIGURE 6
After you read the QR configuration code provided by the NanoBeacon Config Tool, you will see all the IN100’s configuration parameters, including Bluetooth address, advertising interval, and so forth.
FIGURE 6
After you read the QR configuration code provided by the NanoBeacon Config Tool, you will see all the IN100’s configuration parameters, including Bluetooth address, advertising interval, and so forth.
IN100 POWER CONSUMPTION

The IN100 is promoted as an ultra-low power Beacon device, thanks in part to its ability to enter a low-current sleep state between beacon transmissions. During our email exchanges, InPlay’s FAE sent me a power profile graph for a typical beacon transmission. This can be seen in Figure 8. Just prior to becoming involved with the IN100s, I had spent some time trying out Jetperch’s Joulescope JS220 for a review in Circuit Cellar issue #393 (“Joulescope JS220: A Precision DC Energy Analyzer,” Circuit Cellar 393, April 2023) [2]. The JS220 instrument is ideally suited for such low-power measurements, so I connected it up to an IN100 board and ran my own test. My measurements, shown in Figure 9, basically confirmed those supplied by InPlay:

— ADVERTISMENT—

Advertise Here

  • Sleep current is 588.196nA.
  • Maximum current during RF transmission (at 5dBm) is 8mA.
  • Total transmission time for three beacons (chan. 37,38,39) is about 1.4ms (plus a lesser current is drawn for a few milliseconds during wake-up/calculations).
  • Power consumption for one complete wake-up, measurement and 3-beacon transmission cycle is 3.056nAh.
FIGURE 8
This is a screen capture of a Power Analysis tool as sent to me by InPlay.
FIGURE 8
This is a screen capture of a Power Analysis tool as sent to me by InPlay.
FIGURE 9
This is a screen capture of the Joulescope JS220 measurements that I personally performed.
FIGURE 9
This is a screen capture of the Joulescope JS220 measurements that I personally performed.

Let’s look at the above from a battery life perspective. Assuming that you were using the CR1225 coin cell that the Sparkfun board uses, it has a 50mAh (0.05Ah) capacity. Each Beacon cycle, as measured above, uses 3.056nAh. Let’s assume one Beacon is sent per minute. The power used per minute would be 3.056nAh for the Beacon transmission + 588nA sleep current x 1/60th of an hour (assuming that the IN100 is in deep sleep for the full minute—it’s actually a bit less due to about 8ms for wake-up/Beacon transmission), so the total power per minute is (3.05 + 9.8) or 12.85nAh.

I must admit I scratched my head for a while after getting such a long battery life from such a small coin cell. Of course, I have not added in any power for any type of sensor, and that could have a much larger contribution to power consumption than the IN100 itself, in some cases. Also, the coin cell itself would exhibit some self-discharge, which would be meaningful over the above length of time.

IN100 BEACON RANGE

I don’t have the specialized equipment needed to perform comprehensive RF testing. Instead, I did some range experimentation using both the InPlay IN100 modules and the Sparkfun IN100 modules. To give the modules “a fighting chance,” I set the Tx Power at maximum (5dBm) and ran both modules on 3.3V. I used my Motorola cell phone, running the NanoBeacon app, as my receiver. The IN100 modules were in a fixed location in my second-floor office, in a wood-frame house. I walked around outdoors on my lot to see how long a distance the modules could cover.

I tested the InPlay IN100 module with a 4” whip antenna that came with an nRF24L01 module which I had on hand. I didn’t have specs on it, but similar ones have between 3 and 8dBi gain (where the “i” designates the gain over an isotropic antenna which radiates in all directions). Because the IN100 uses an SMA and not an RP-SMA socket, the field of useable antennas is limited, but the Linx Technologies ANT-W63WS5-SMA would be a good candidate. I consistently got 100’ of range with this setup before the RSSI values dropped below -95 and readings became sporadic. This matches closely with the BLE range I get using ESP32 MCUs with their integrated trace antenna.

The Sparkfun boards were a different matter. They incorporate a trace antenna, so one would expect the range to be somewhat less than that obtained with the InPlay IN100 board/whip antenna. However, the Sparkfun boards were barely able to reach a range of 20’ indoors, with no obstructions in the RF path. When I reported this to my FAE contact at InPlay, I don’t think that he believed me—at first, anyway. Later, after InPlay contacted Sparkfun, I got a message saying that the poor range is due to the fact that the IN100 has three settings (in the XO tab of the NanoBeacon Config Tool) that must be changed for the Sparkfun boards. The default capacitor code of 8 (= 4.0pF), while optimal for the InPlay IN100 development board, is not correct for the Sparkfun board, with its integral trace antenna. The correct code for the internal capacitor, as well as two other relevant settings, are shown in Figure 10.

FIGURE 10
This is the NanoBeacon Config Tool screen where you can enter custom parameters for matching the installed crystal.
FIGURE 10
This is the NanoBeacon Config Tool screen where you can enter custom parameters for matching the installed crystal.
I2C PERIPHERAL OPERATION WITH THE IN100

If your Beacon application requires measurements that can’t be implemented using IN100 GPIO state, IN100 ADC readings, IN100 internal temperature, or the TI LMT01 temperature sensor, then you will have to find a sensor with an I2C interface and configure the IN100 to operate it.

This is more involved than adding an appropriate driver library to your MCU’s “C” program and calling initialization and measurement routines. The IN100 is implemented as a state machine, not a true MCU. As mentioned earlier, you cannot test the IN100’s I2C interface using the “Run From RAM” mode. Nor can you directly use an MCU “C” driver library written for that sensor.

InPlay has anticipated this stumbling block in the development process by providing IN100 configuration files for the following common I2C sensors:

  • Analog Devices ADXL367 MEMS Accelerometer
  • Bosch BMA400 very-low power Accelerometer
  • Bosch BME280 Pressure, Temperature, and Humidity sensors
  • Sensirion SHT4X Humidity/Temperature sensors
  • Sensirion SGP40 Indoor Air Quality sensor
  • TI TMP102 Low-Power Temperature sensor
  • Sparkfun breakout boards with BMA400, BME280 sensors

These configuration files are available on InPlay’s GitHub site [3]. They can be directly loaded into the NanoBeacon Config Tool application using the Load button. Next, you would use the Burn Program button to write the IN100’s OTP ROM.

If you want to interface a different sensor, it’s a bit more work. To start with, I’d recommend viewing InPlay’s I2C Configuration tutorial video [4].

If you load one of InPlay’s I2C Configuration files, you can click on the I2C tab on the left side of the Config Tool screen. Select the I2C remote #1 box, click Edit and then I2C Commands. You will then see a window like that in Figure 11. You can see that the IN100 expects a series of pseudocodes to define the various I2C read/write commands needed to initialize and measure from your selected I2C sensor. Besides reads/writes, you can also define delays (in µs) between commands using the “i2c wait” pseudocode. These are often needed for sensors that take a significant amount of time to report a measurement after one has been requested. One last feature of the I2C programming method is the ability to define when any given I2C pseudocode is executed:

  • When the IN100 is first powered up (cold boot)
  • When the IN100 wakes up (either periodically or when triggered) and takes a measurement/sends out a Beacon.
  • Both of the above
FIGURE 11
This is the NanoBeacon Config Tool screen where you define the series of pseudocodes needed to interface to the I2C sensor you are using.
FIGURE 11
This is the NanoBeacon Config Tool screen where you define the series of pseudocodes needed to interface to the I2C sensor you are using.

Your choice out of these three options will be reflected by the first number after the pseudocode. It will be a 3 if both are selected, a 0 if only cold boot is chosen, and a 1 if warm boot is selected. For some reason, InPlay decided to flag only the cold boot option with an additional “# cold boot” comment.

Because the IN100 implements a state machine rather than an MCU, you will note that the IN100 contains no I2C commands that can perform loops or any other type of conditional command. Therefore, there is no way to poll a sensor register and wait until the measurement is complete. This can only be emulated using the delay command (i2c_wait). So, you either have to take a close look at your sensor’s datasheet, or try out the sensor using an MCU you are experienced with and check out how that MCU and the associated driver library work.

Most of the I2C sensors that I would use have Arduino driver libraries written for them. If you use these libraries, you really don’t know what I2C commands are sent/received for either the sensor initialization, configuration, or measurement functions. So, adapting a working program utilizing a specific I2C sensor to a working IN100 configuration isn’t trivial.

The I2C sensor libraries from Adafruit and Sparkfun are well-written and contain internal (Private) functions for I2C read and I2C write. Any interaction with the I2C sensor will be routed through these two routines. It occurred to me that it would be easy to add a few lines of code to each routine to report what bytes had been sent or received. Before sending this data out the Serial port, I first sent out a “timestamp” which was derived from the Arduino millis() function, which returns the number of milliseconds since the MCU was booted up. This would give you a good idea of when the IN100 i2c_delay would be needed, and how much delay time was required. Listing 1 and Listing 2 show the I2C read and I2C write routines from a Sparkfun BMA400 library. The lines I added are in red. Using this method, I believe you can derive the necessary IN100 pseudocode commands, for a given I2C sensor/configuration, to allow you to achieve a working IN100 solution—while “burning” as few IN100 devices as possible getting there.

LISTING 1
This is an I2C read routine from a Sparkfun BMA400 sensor driver that I have modified to provide I2C read information to help configure the IN100’s I2C port.

BMA400_INTF_RET_TYPE BMA400::readRegistersI2C(uint8_t regAddress, uint8_t* dataBuffer, uint32_t numBytes, BMA400_InterfaceData* interfaceData)
{
    // Jump to desired register address
    interfaceData->i2cPort->beginTransmission(interfaceData->i2cAddress);
    interfaceData->i2cPort->write(regAddress);
Serial.print(millis());
Serial.print(“---I2C Write REG Address= “);
Serial.print(regAddress, HEX);
Serial.print(“—I2C Read= “);
    if(interfaceData->i2cPort->endTransmission())
    {
        return BMA400_E_COM_FAIL;
    }

    // Read bytes from these registers
    interfaceData->i2cPort->requestFrom(interfaceData->i2cAddress, numBytes);

    // Store all requested bytes
    for(uint32_t i = 0; i < numBytes && interfaceData->i2cPort->available(); i++)
    {
        dataBuffer[i] = interfaceData->i2cPort->read();
       Serial.print(dataBuffer[i],HEX);
    }
  Serial.println(“”);
    return BMA400_OK;
}
LISTING 2
This is the same as Listing 1 except it is for the I2C write routine.
	
BMA400_INTF_RET_TYPE BMA400::writeRegistersI2C(uint8_t regAddress, const uint8_t* dataBuffer, uint32_t numBytes, BMA400_InterfaceData* interfaceData)
{
    // Begin transmission
    interfaceData->i2cPort->beginTransmission(interfaceData->i2cAddress);
    Serial.print(millis());
    Serial.print(“---I2C Write REG Address= “);
    // Write the address
    interfaceData->i2cPort->write(regAddress);
    Serial.print(regAddress, HEX);
    Serial.print(“--”);
    // Write all the data
    for(uint32_t i = 0; i < numBytes; i++)
    {
        interfaceData->i2cPort->write(dataBuffer[i]);
        Serial.print(dataBuffer[i], HEX);
    }

    // End transmission
    if(interfaceData->i2cPort->endTransmission())
    {
        return BMA400_E_COM_FAIL;
    }
    Serial.println(“”);
    return BMA400_OK;
}
CONCLUSIONS

I didn’t cover all the IN100’s features in this article. For example, when you are using triggered Beacon messages, there are Low and High Thresholds that you can define for readings such as those from the internal ADC, One-Wire Sensor, and so on. You can also define how many advertising beacons you want sent out per trigger event, or alternately you can specify that you want only one burst of advertising beacons to be sent out regardless of whether the trigger condition persists or later gets re-triggered.

There will still be times when you must spring for a more expensive/power-hungry MCU (with BLE functions) to handle a specific IoT use case. But many times, the IN100 will hit the “sweet spot” in terms of its functionality, size, price, and ultra-low power consumption.

I’d like to thank Aidan Martens, an FAE at InPlay, for his assistance while I was investigating the IN100. Some issues that I found/reported were addressed by InPlay quickly, so I didn’t feel it worthwhile to include them in the article. 

REFERENCES
[1] InPlay video on how to interface with the LMT01: https://inplay-tech.com/nanobeacon-config-tool
[2] Millier, Brian: Joulescope JS220: A Precision DC Energy Analyzer. Circuit Cellar, Issue 393, April 2023, p. 4-13.
[3] IN100 configuration files for common I2C sensors: https://github.com/NanoBeacon/config-files
[4] I2C Configuration tutorial video: https://inplay-tech.com/nanobeacon-config-tool

RESOURCES
InPlay | inplay-tech.com

SOURCES
IN100 devices and development boards:
https://inplay-tech.com/in100
Sparkfun IN100 breakout boards:
https://www.sparkfun.com/products/21293

— ADVERTISMENT—

Advertise Here

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • SEPTEMBER 2023 #398 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.


Note: We’ve made the Dec 2022 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article
+ posts

Brian Millier runs Computer Interface Consultants. He was an instrumentation engineer in the Department of Chemistry at Dalhousie University (Halifax, NS, Canada) for 29 years.

Supporting Companies

Upcoming Events


Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2024 KCK Media Corp.

InPlay’s NanoBeacon

by Brian Millier time to read: 30 min