Introduction to Electronics through a Blinking X-Mas Tree

[member='Marius G'] had an idea before Christmas for the last hacking event in 2012. The mission was to introduce as many as possible to the joy of soldering and electronics here at Energy Micro. When I heard his ideas about a blinking X-mas tree, I naturally decided to help him out! Even though the blinking x-mas tree electronic kit has been done countless times before, we decided to do an EFM32 version as well. After all, it is Christmas time and nothing is more suitable than blinking LED's when it comes to learning electronics and soldering.



Christmas Tree Features

We quickly settled on a few criteria for the project.
 

• It should be easy to solder for people who have never soldered before.
   
• It should have blinking LED's, preferably as many as possible.
   
• It should be battery powered.
   
• It should include some form of user input.
   
• It should include some awesome features that differentiate it from the rest of the blinking LED projects out there.
  
  
  
  After some brainstorming we ended up with the following design ideas and features:
  
  12 Bi-color LEDs for multiple colors. They should have a wide angle of emission to be visible from all directions.
  
  Powered by two AAA-batteries. Should last at least through the Christmas holidays.
  
  Capacitive touch button for user input and possible low power sleep mode when not in use.
  
  Dual-PCB design to make the tree stand on its own, achieved by having two PCB's mounted together perpendicular to each other. 6 bi-color LEDs are mounted on each PCB. We decided to use the EFM32TG222 device which can be soldered by hand since it is a QFP48 package.
  
  An the interesting feature we included an IR-receiver which can receive signals from standard television remote controls. This can be used to trigger special blinking sequences remotely by a remote control. Place it next to your television and watch the tree light up when you turn on/off your television for example. If several trees are placed together, the IR-signal can be used to trigger individual trees or make the trees blink with special patterns synchronously. Definitely many possibilities for further improvements here.
  
  Charlieplexing LED's
  
  Each bi-color LED actually contains two LEDs, one green and one red. The two LED's are mounted in parallel, but with opposite polarity inside each physical LED package. This arrangement requires the MCU to be able to drive either side of the LED to a high or low voltage. Since we are driving these LED's with an MCU, we decided to use a special driving scheme to save pins. This would greatly simplify the PCB layout. There exists a driving scheme called charlieplexing which we decided to use. (See this page for a description of charlieplexing) This arrangement takes advantage of the tri-stating possibility of a microcontroller pin to achieve more output states with fewer pins than what is possible if only driving outputs high or low.
  
  Success Story
  
  We managed to design and order the PCB and components in time before the last hack-a-gecko event in 2012. Almost 40 people signed up for a tree, many without much soldering experience from before. During the hacking day and the next couple of days the soldering station was busy almost all the time. At the end we had quite a few happy Christmas tree owners:
  
  
  
  Admittedly it is not straight forward to solder a 0.5mm pitch QFP device by hand without a bit of previous soldering experience. We had to help out with soldering the QFP package and the necessary decoupling capacitors for some of participants. But everyone who signed up for a tree, managed to solder the LED's, battery connector and mounting the two halves together, Great Success.
  
  Building your own X-mas Tree
  
  Everyone is welcome to use our design to make their own X-mas tree. Also feel free to modify it as you see fit. At the end of this post I have included eagle design files, gerber files and software.
  
  This picture shows all the components that the tree consist of, excluding the IR receiver.
  
  
  
  Components in this picture:
   
• PCB #1 with EFM32
   
• PCB #2 only LED's
   
• EFM32 TG222 device
   
• AAA Battery holder for two batteries
   
• Decoupling capacitors
   
• Bi-Color LED's
  
  
  
  Components used
  
  This is a list of all the components needed. With Digikey part number.
  
  1 EFM32TG222F32: Energy Micro sample program or 914-1029-2-ND
  
  12 Bi-Color LED's: 160-1058-ND
  
  4 Battery holders: 82K-ND
  
  4 100nF capacitor: 490-1524-1-ND
  
  1 1uF capacitor: 490-1544-1-ND
  
  1 10uF capacitor: 490-3896-1-ND
  
  Circuit Board
  
  
  
  
  
  The PCB was designed with Eagle. A link to the EFM32 footprint used can be found here.
  
  Video
   
  
  
  Software: xmas_tree_software.zip
  
  Hardware: xmas_tree_pcb_design_files.zip
  
  
  
  
  This Hack a Gecko project is a result of a “fun hacking session” and are provided as is, free of charge with no guarantees or support from Energy Micro, to partially or fully show and demonstrate EFM32 Gecko microcontroller capabilities. Get inspired, use at own risk, and build some awesome and cool applications.”

Hi, vanmierlo

Most of the community requests are handled internally and they have been delayed due to urgent web and Salesforce related projects. We are sorry for the inconvenience caused and will try our best to follow up on your community requests as soon as possible. I have escalated following requests to our team with high priority. I will get back to you once a target delivery date is confirmed. 

• The ability to make the ‘Sort By’ option not to get reset when returning to the main forum page
• The ability to change the default ‘Sort By’ option to ‘Last Updated’
• The ability to display the last reply information by when and whom
• Fix the numbering issue

The @ mention feature is likely to be delivered by our platform provider in 2019 according to their roadmap. 

There are two main reasons why we chose the current community platform. As the community and the silabs.com website use the same platform, we are able to use consistent tagging system which allows us to display search results from different Silicon Labs pages. It means that community users can search for any support content that resides in silabs.com such as app notes, data sheets, and reference manuals through the community search bar. 

The other reason is to provide a better prioritization tool for our support teams. The number of forum questions increased by 75% in the last 2 years so it was necessary to find a platform that helps the team manage forum cases through Salesforce integration. 

We are aware that it's critical to reflect feedback from community members for the success of the community. This year, we have been working on making the community platform as stable as possible, but we will spend more resources to address your and other members' feedback going forward. 

Date: Tuesday, December 11, 2018
Time: 10:00 AM Central European Time
Duration: 1 hour

Applications receiving Power over Ethernet (PoE) often face the dilemma of maintaining power budgets while meeting the demands to develop full-featured solutions.  With higher power classifications becoming more frequent at the end device, Silicon Labs delivers a set of PoE Powered Devices (PD) solutions to optimize BOM solution cost, efficiency, and performance while reducing development time.

In this technical webinar, we discuss how Silicon Labs’ PD controllers meet ever increasing power demands and demonstrate our evaluation kits’ drop-in ready designs.

These examples show how to set up a coordinator (the sink) and (sleepy) end nodes (the sensors) using the built-in example project, configuring/compiling/running them.

In the case of Sink/Sensor example, the supported network structures are star and extended star topologies:

The configuration of Sink/Sensor example consists of two independent projects:

The Coordinator/Sink

First, we need a coordinator, to which the nodes can connect. In Simplicity Studio Launcher page, select the desired device.

Start to create a new sink project by starting the wizard by clicking on the  button. Select the desired Flex SDK, choose the Connect (SoC): Sink example and complete the remaining steps of the wizard.

The AppBuilder will open automatically where you can configure the high-level settings of the project. Radio parameters can be configured by switching to the Radio Configuration tab:

After completing the required changes (if any), the Studio will generate additional files necessary for the project by clicking on the  button. A pop-up window will appear about overwriting the flex_callbacks.c file, which is not selected by default. Keep it unselected.

Compile () and debug () the project.

To configure the coordinator, a terminal software is necessary to set up the parameters. The firmware prints some basic help by issuing the help command. When the firmware started, issue form 0 (form a network on channel 0) and pjoin 255 (enable join of nodes for unlimited time) commands:

At this point, the coordinator is up and running, accepts incoming joining requests, so sensor nodes can connect to the sink.

The Nodes/Sensors

The next task is building sensor nodes. Go back to Launcher view and select one another device then create a new project by going through the wizard, except select Connect (SoC): Sensor from the list. All the settings can be kept as default, but the radio configuration must match with the sink settings.

Compile and debug/run the project. Beside multiple other commands, the two most important ones are join and join-sleepy. Issuing join, the device will try to connect to the coordinator, and if the join process was successful, the node becomes part of the network. In case of issuing the join command, the device will not try to enter to sleep or idle mode at all, keeping the device wake with relatively high current consumption. To enable to enter sleep state the join-sleepy command should be issued. However, since by default the Idle/Sleep plugin is not enabled in AppBuilder, even connecting by join-sleepy will not cause the device to sleep whenever it is possible, but using this command does not cause any issue and later we can exploit the advantage when we enable the Idle/Sleep plugin. After a successful join process, the device starts sending the sensor data to the sink periodically (with 1s rate by default):

At this point, a network consist of a coordinator/sink and one node/sensor should work, the sensor data should be sent by the sensor and received by the sink with 1s periodicity. More nodes can be added to the network by downloading the sensor firmware into multiple devices.

When starting the experiment with sensor/sink examples it is a good practice to issue the leave command on both sink and sensors. For example, the coordinator maintains information about the previously connected nodes (based on their EUI64 ID), the nodes also store information and tries to reconnect to the coordinator automatically at power-up based on this information. By issuing the leave command these pieces of information will be cleared.

There are cases when the node cannot join to the coordinator. In these cases, the firmware prints only numerical codes on the console, instead, a textual description of the problem. The table below contains the codes and their meaning:

• 0x40: no ACK received, the node that a message was transmitted to, did not respond

• 0x41: indirect MAC timeout, may occur if the sender did not get a poll request to send its pending message

• 0x70: Invalid call, usually when an unexpected operation is carried out (e.g., joining when joined or sending when not joined, etc.)

• 0x90: Network up, the expected status after forming/joining networks

• 0xAB: No valid beacons, the other radio can’t be heard (e.g., no antenna attached)

The Energy Profiler is a useful tool to inspect current consumption real-time. The following graph shows the consumption of a non-optimized sensor node.

The first step which reduces the consumption the most is enabling Idle/Sleep plugin. The plugin enables entering EM2 mode when it is possible. The Idle/Sleep plugin can be enabled in AppBuilder under the Plugins tab by enabling Idle/Sleep plugin:

Note, that if the Idle/Sleep plugin is enabled, issuing commands through CLI (UART) is not possible. Thus, it is practical to apply all necessary settings before enabling of Idle/Sleep plugin.

Changing the report period can significantly reduce the average consumption if the sleep consumption is low enough. To change the report period, open flex-callbacks.c and modify sensorReportPeriodMs value:

By default, the network status indicator LED is on when the network stack is up, ie., after the join process it is continuously on. Changing this behavior can reduce the consumption by a few hundred uA. The code responsible for setting the LED status is also in flex-callbacks.c in the emberAfMainTickCallback function:

The solution can be made to comment out the halSetLed() portion or invert the if statement.

In the example project, the Heartbeat plugin is enabled. To decrease the consumption further, this feature can be disabled in AppBuilder under the Plugins tab by disabling Heartbeat plugin:

Applying the modifications above the sleep current can be reduced to ~10-12 uA. However, all the radio boards designed by Silicon Labs contain an SPI flash chip which consumes ~8-10 uA if left uninitialized. The required SPI Flash plugin must be enabled:

Additionally, halEepromInit() and halEepromShutdown() functions which initialize the flash and set deep power down mode of the device have to be called, thus it must be added manually to flex‑callbacks.c (preferably to emberAfMainInitCallback):

Finally, if these modifications applied the sleep mode current consumption should be reduced significantly:

It should be noted that the built-in current measurement of the WSTK board is not really accurate in uA range and below. The current consumption of the above sensor node setup should be in 2-5 uA range.

We’re excited to introduce the new Wireless Xpress BGX13P starter kit, which helps you jumpstart your design with no software development necessary. Some of the key features of this kit include:  

• Bluetooth 5 BGX13 module requiring no firmware development
• Zero-overhead serial-to-Bluetooth cable replacement solution
• Smartphone app for Bluetooth LE command, control, and sensing
• Secure connections with encrypted communication, bonding, and ‘just works’ and passkey pairing options
• Ideal solution for smart home products requiring Bluetooth control with a mobile app, and the ability to add point-to-point wireless interface to industrial applications

Want to try it for yourself? We’re giving away five Wireless Xpress BGX13P starter kits to our community members, and this is your chance to get your hands on one.

How to Participate:

Explain up to 2 ideas on how you want to use the Xpress kit for your project and why. You can submit your idea by leaving a comment below on this page by November 11th (CDT). 

Judging Criteria

Our Wireless marketing team will judge submissions based on the following criteria:

• Market Potential (50%)
• Differentiation (30%)
• The fit between the Xpress kit and your project (20%)

Prize

Number of Winners: 5

Prize: 1 x Wireless Xpress BGX13P starter kit

Contest Period

Oct 22nd 2018 – Nov 11th 2018 (CDT)

The winners will be announced on this page soon after the end of the contest.

By entering the contest, you acknowledge that you have read and agree to the attached Community Contest Terms and Conditions.

Our Wireless marketing team picked the five winners as follows:

• Jimhenson’s EEG reader for smart phones
• Namo_Aton’s speech therapy device
• Kos_t’s current flow detector
• HallMark’s battery charger bootloader
• Dominic_Doty’s keyless entry system

Congratulations! The winners will be contacted shortly via email.

We want to send a big thank you to everyone who participated in the contest and please stay tuned for the next one!

Nari | Community Manager | nari.shin@silabs.com 

Our Wireless marketing team picked the five winners as follows:

• Jimhenson’s EEG reader for smart phones
• Namo_Aton’s speech therapy device
• Kos_t’s current flow detector
• HallMark’s battery charger bootloader
• Dominic_Doty’s keyless entry system

Congratulations! The winners will be contacted shortly via email.

We want to send a big thank you to everyone who participated in the contest and please stay tuned for the next one!

Nari | Community Manager | nari.shin@silabs.com 

We’re excited to introduce the new Wireless Xpress BGX13P starter kit, which helps you jumpstart your design with no software development necessary. Some of the key features of this kit include:  

• Bluetooth 5 BGX13 module requiring no firmware development
• Zero-overhead serial-to-Bluetooth cable replacement solution
• Smartphone app for Bluetooth LE command, control, and sensing
• Secure connections with encrypted communication, bonding, and ‘just works’ and passkey pairing options
• Ideal solution for smart home products requiring Bluetooth control with a mobile app, and the ability to add point-to-point wireless interface to industrial applications

Want to try it for yourself? We’re giving away five Wireless Xpress BGX13P starter kits to our community members, and this is your chance to get your hands on one.

How to Participate:

Explain up to 2 ideas on how you want to use the Xpress kit for your project and why. You can submit your idea by leaving a comment below on this page by November 11th (CDT). 

Judging Criteria

Our Wireless marketing team will judge submissions based on the following criteria:

• Market Potential (50%)
• Differentiation (30%)
• The fit between the Xpress kit and your project (20%)

Prize

Number of Winners: 5

Prize: 1 x Wireless Xpress BGX13P starter kit

Contest Period

Oct 22nd 2018 – Nov 11th 2018 (CDT)

The winners will be announced on this page soon after the end of the contest.

By entering the contest, you acknowledge that you have read and agree to the attached Community Contest Terms and Conditions.

Hi,

1. One of the arguments for the cmd_le_gap_set_advertise_phy command is the handle for an advertising set.  What is an advertising set and how do I get the handle?

Advertising sets are a Bluetooth 5 feature. It is possible to set up a number of simultaneous advertisements. For instance, you could have simultaneous iBeacon and Eddystone beacons without having to stop advertising, change the data being broadcast and then restart advertising. The handle is just an integer used to identify the advertisement set. Our stack supports up to 4 such advertisement sets so you can pick the handle yourself. If you only use one advertisement set you can use 0 for the handle.

2. Can I get an explanation on the difference between a primary and a secondary advertising channel?  In what scenario would I want to use different phys on the different channels?

The coded PHY advertisements use this new type of advertising called extended advertising which has also been introduced in Bluetooth 5. The primary advertisment comes on one of the traditional advertising channnels (37-39) and gives a pointer to a data channel that will include the advertising payload. The secondary advertisment comes on the aforementioned data channel and contains the payload. I can't provide a scenario where you would want to use different PHYs, I suggest using the same PHY for primary and secondary advertisements unless there is a good reason not to.

3. Once I've made a connection, is there a way to check which phy that connection is using to make sure I'm actually using the coded phy like I think I am?

not directly, but the evt_le_connection_opened event comes with the 'advertiser' parameter to tell you which advertisment set the connection was established with. If you're not convinced, you can always call cmd_le_connection_set_phy and check the corresponding evt_le_connection_phy_status event.

4. I looked at the sample projects in the KBA article regarding scanning and advertising with the coded phy but couldn't see where it referenced the use of the le_coded_phy.  I looked through main.c in both projects and didn't see any use of the coded phy.  Is that code in a different file?

Please have a look in coded_phy_advertiser_main.c and le-connections-client-main.c, these are the source files that contain the main() functions for these two projects. I'll update the KBA to remove those two main.c files since they are not needed and potentially confusing to have them there.

Regards,

Steve