The Project board is for sharing projects based on Silicon Labs' component with other community members. View Projects Guidelines ›

Projects

    Publish
     
      • Bluetooth in Action 7 - Variables and Timers

        jlangbridge | 05/146/2016 | 08:15 PM

        Hi everyone,

         

        In this episode of my Bluetooth in Action series, we’ll continue on our first application. The Power/connection LED needs some work to make the device more energy efficient and easier to use, so let's concentrate on that.

         

         

        Our application shows promise, but we aren't new millionaires yet, this project is still unsellable in it's current state. Two things have to be done. One, we can't rely solely on the connection LED, we need to add another output. I want to use an output on the expansion header to be able to put a buzzer on a breadboard, but until that happens, we'll use the expansion board that came with the WSTK. It has two LEDs, so we will still have the visibility we need.

         

        Secondly, the power/connection LED isn't very useful. If no connection is made, the LED is off, making users think the device is off, when it isn't. Leaving the LED on all the time during a connection isn't energy efficient. Remember, Silicon Labs spent a long time making this device as energy efficient as possible, but it is only as efficient as the developer is clever. Leaving even a small LED constantly on for no reason will decrease battery life. To remedy this, the LED will blink; one second on, one second off when no connection is made, and 1/10th of a second on, one second off when a connection is made.

         

        To be able to do this, we will need two elements; timers, and variables. A timer is a small alarm clock that is programmed to create an alarm after a given amount of time, and the alarm is captured by a system event. Using variables, we can keep track on where we are; is the LED on, and what situation are we in?

         

        Finally, a quick test is in order to see how our application is doing.

         

        I hope you enjoy the episode, and I look forward to seeing you next time! Bye bye!

      • Bluetooth in Action 6 - First Application, part 2

        jlangbridge | 05/134/2016 | 12:07 PM

        Hi everyone,BLE-rocket-1.jpg

         

        In this episode of my Bluetooth in Action series, we’ll finally be creating our first program. In the previous episode, we had a look at BGScript, and how to write, compile and flash BGScript applications. Today, we’ll be creating a real-world application.

         

        So we've written our first application. The next step is to compile it, and to flash it to the BGM111 module, before testing it out. To do that, you have the choice between two tools. One of them is command line, the other is a graphical interface. Compiling is simple; just indicate the .bjproj file that was created, and it does the rest for you. If you made a mistake, it will stop, and indicate the error, the type of error, and the line number where the error was encountered.

         

        Next, we need to flash. The command line tool can compile and flash directly, and there is no need to specify the COM port, it will find it automatically. The graphical interface is slightly different; it has a different section to enter the flash file, and it will automatically fill in the binary filed when the compilation is complete.

         

        Both systems have another trick up their sleeves. Remember we saw there was an Ethernet port on the board? Let's flash using that. If the device is not found on any USB port, the applications will ask if you want to flash via Ethernet, and ask for an IP address. This allows for some very interesting properties; you can reflash a device that is already in test condition, in another room, or potentially in another building. You can reset the device, flash it and reboot it remotely.

         

        FInally, it is time to have a look at our application, and see it running. Silicon Labs has a great application for connecting to a Bluetooth device, and it shows a list of services proposed by the board, we'll check that the name of our application, and the services provided correspond to what we programmed.

         

        Our application works, but it remains limited. For the time being, we turn an LED on if a connection is made, and we turn it off when the connection is terminated. In the next episode, we'll change that, and add an alarm, as well as fix a potential problem with the LED remaining on all the time. Remember, power efficiency!

         

        Don't hesitate to drop me a comment, I'll answer it as soon as I can. See you next time!

      • Bluetooth in Action 5 - First Application, part 1

        jlangbridge | 05/124/2016 | 03:58 PM

        Hi everyone,

         

        In this episode of my Bluetooth in Action series, we’ll finally be creating our first program. In the previous episode, we had a look at BGScript, and how to write, compile and flash BGScript applications. Today, we’ll be creating a real-world application.

         

         

        So, what can we write? I can think of one application that might be useful. I used to travel quite a bit before, and while I love to travel, there was one part that I hated – the thought of luggage being stolen. Your precious laptop and tablet gone, not the kind of thing you want before a trans-Atlantic flight, where you’ve already seen all the films on your previous trip, leaving you 8 hours to think about what happened.

         

        Let’s think of an application that could help us out, using Bluetooth Smart. What if we created an application that allowed a mobile telephone to connect, but triggered an alarm once the link was broken? If your suitcase is out of range of your mobile telephone, then a buzzer starts beeping, or something to attract the attention of people around. Well, this is easy enough to do in BGScript, so let’s try that out. We’ll be creating a new application, not one based on the examples delivered with the SDK. That being said, I will copy an existing BGPROJ file from an example.

         

        To write this application, we are going to need two things. First of all, the BGM111 API Reference Manual that we saw earlier on in this series. We’ll need this to know what functions are available, and how to use them. We will also need the BGM111 Wireless Starter Kit User Guide. We only need one piece of information from here; the GPIO for the LED. The BGM111 API Reference Manual will be used extensively to know what BGScript functions are available, and how to call them. We'll be creating functions to handle connections, disconnections, and advertising.

         

        You can compile this and flash it to test it out if you want, or you can wait until the next episode where I’ll show you how to compile and flash our application, and give it a spin. In the meantime, feel free to drop me a comment, I’ll answer it as soon as I can.

         

      • Smart Solar-Powered Bamboo

        mapleleafs | 05/124/2016 | 12:35 AM

        This project comes in installments, and involves housing the Silabs EFR12 Bluetooth part inside of shoots of bamboo. You plant these shoots in the ground, in your yard or garden, and solar power them, where they serve as soft garden lights at night. During the day, they monitor your soil moisture and plant lighting. Additionally, because they have light sensors anyway, I enable them to control your landscape lighting simply by pointing a laser pointer at them. This landscape lighting can optionally be UV light, designed to help grow your plants when they are not getting enough sunlight. The end result is an environment-friendly biodegradable means to high-tech and IoT your yard.

         

        The Bluetooth bamboo stakes all pair with a single web server in a star configuration, served by a Raspberry Pi 3. The Pi aggregates the soil moisture and periodic lighting information, bridges the Bluetooth to Wifi, and serves your garden with its own web page, showing you the status of your garden. Additionally, the Pi 3 drives the relays which run the landscape lighting (they are remote-controlled by the bamboo, but they are driven by the Pi). Because the Pi runs off of the same wall power as the landscape lighting, there is no need for the Pi to run low-power. The bamboo stakes, however, absolutely require low power; and thus, the Silabs parts.

         

      • EFR32WG Range Test

        operator | 05/123/2016 | 06:08 AM

        Below are the conditions and results of some range tests performed with a pair of BRD4151A +19.5 dBm EFR32MG WSTK boards.

        Tests were performed in the most glorious of non-scientific manner befitting of real-world conditions.

         

        The range test application was flashed to the boards and I verified that it was working properly:

        image1.JPG

         

        Next, a bit of data from the BRD4151A Reference Manual is required:

        3.3.4 Inverted-F Antenna

        The BRD4151A Radio Board includes a printed Inverted-F antenna (IFA) tuned to have close to 50 Ohm impedance at the 2.4 GHz band.

        3.3.5 UFL Connector

        To be able to perform conducted measurements Silicon Labs added an UFL connector (P/N: U.FL-R-SMT-1) to the Radio Board. The connector allows an external 50 Ohm cable or antenna to be connected during design verification or testing.

        Note: By default the output of the matching network is connected to the printed Inverted-F antenna by a series component. It can be connected to the UFL connector as well through a series 0 Ohm resistor which is not mounted by default. For conducted measurements through the UFL connector the series component to the antenna should be removed and the 0 Ohm resistor should be mounted (see Chapter 4.2 Schematic of the RF Matching Network for further details).

         

        The inverted-F antenna is actually quite great but I felt like going for something a bit more excessive.

         

        For starters, we need to modify things a little.

        Here is the 0 Ohm resistor mentioned above under a scope:

        0 Ohm Default

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

         

        This resistor must be rotated 90 degrees anti-clockwise to the trace leading to the U.FL connector:

        0 Ohm modified

        (It looks messy but it's just a couple square millimeters of flux reflecting light from the scope)

         

        Two, 2.4GHz antennas were chosen (because they were what I had lying around and because both happen to have the aforementioned requisite 50 Ohms of impedance).

         

        For the transmit side, an 8 dBi omni-directional antenna:

        Omni

         

        And for the receive side... a 24 dBi parabolic directional grid, which I'm sure everyone has in their junk drawer at home:

        Parabolic Grid

         

        The pigtails and coax cable likely introduce a non-negligible amount of insertion loss but it was decided that I would just see how it worked out in lieu of a bunch of math.

         

        A suitable location was required with significant distance of unobstructed line of sight which proved very difficult to find in my locale.

        (The local airport was very confused about exactly why I wanted access to their runway and hung up on me.)

         

        Fortunately, water is pretty flat and a nearby lake had a 535 meter clear path:

        Lake

         

        Cables were connected:

        Cables

         

        I managed to con my significant other into standing on the opposite side of the lake holding the omni-directional antenna and pressing the start button on the transmitter side.

         

        Antennas were approximately 1.5 meters above ground level and were aligned optically (I pretty much just took a best guess).

        Boards were configured to use the minimum data rate and maximum receive sensitivity.

        FCC regulations were complied with to the best of my ability and understanding.

         

        Results were quite positive and very consistent.

        RX

        All transmitted packets were received!

         

        A more thorough write-up may follow as I'm curious to find out what the practical range limitations are!