Hurricane Harvey, the most powerful storm to hit Texas in 50 years, wreaked havoc on Friday. The area of Texas that's currently underwater is comparable to the distance between New York and Boston. And the worst is yet to come.
Now a Tropical Storm, Harvey will continue to devastate this large geography for the next several days, delivering as much as another 30 inches of rain and producing destructive tornadoes.
Walking around the Silicon Labs headquarters in Austin today, it was impossible not to stop and talk about the devastation impacting fellow employees, family and friends who live and work in Harvey's destructive path.
Thousands are without power and stranded in their homes. Major roads flooded, rail lines shut down, and schools, airports, hospitals, and nursing facilities closed – and the storm isn’t over yet.
During this challenging and emotional time, we need to come together as a community. Businesses, government agencies, non-profits, faith-based organizations, and others must contribute and coordinate emergency relief efforts to help as many people as quickly as possible.
"I am calling upon other technology community leaders in Austin to make sure Harvey’s impact is met with an equally strong response – a commitment to provide disaster relief, infrastructure repair, and help rebuild lives and our economy in the wake of this storm," said John Hollister, Silicon Labs CFO and chair elect of the Red Cross Central Texas board of directors. "Silicon Labs is donating $50,000 to the Red Cross for disaster relief and will match contributions up to $2000/employee."
How You Can Help
We must do everything possible to support our communities during this natural disaster.
How Your Donations Will Make an Impact
We will feel the devastating aftermath of this storm for years to come, so please continue to provide your time, talents, and financial resources to help.
Arun Manickaraj joined Silicon Labs as a New College Grad (NCG) in July 2014 after serving as a Product Test Engineer Intern. In his current position as Operations Analyst II on the Operations team in Singapore, Manickaraj is responsible for building reports and dashboards and providing data for ad-hoc analysis by the management team and end users. Manickaraj’s supervisor, Albert Chee, said, “Arun is helpful, responsive and can provide solutions quickly. He is a great asset to the Ops Team and has much growth potential.”
“The make and break of a company depends on the people working together to build it,” said Manickaraj. He had a very welcoming experience as an intern and NCG and said, “The culture of grooming and growing newcomers is embedded deep into the DNA of the company and I stand as a testament to it.” His favorite Silicon Labs value is “Do the right thing,” which he believes includes everything from “hiring the right set of people, placing then in the right job roles, setting the right priorities based on customers, providing the right work-life balance and giving back to the community in the right way.”
Manickaraj also serves as the chairman of the SLI Recreation Committee, allowing him to create volunteer, wellness and employee engagement activities for all SLI employees. He said, “Even though I was a newbie, I was given the opportunity to take up such leadership roles and was given ample support and guidance by my organization. I am ever grateful to my peers for recognizing my leadership skills and my team for supporting me throughout.”
When asked where he would live if he could live anywhere in the world, Manickaraj said he would love to live a peaceful life in New Zealand. He continued, “It is the best untouched country on this plant…Being a wanderlust myself, I would love to go on backpacking trips to explore [its] extremely wonderful scenic beauty.”
Arun Manickaraj, thank you for your hard work and commitment to Silicon Labs. We are proud to have you on our team!
Silicon Labs had the opportunity to sit down recently with our customer Jerry Wilmink, CEO and Founder of WiseWear. With a Ph.D. in optical-sensing and biomedical engineering, Wilmink built a company that creates connected IoT devices that can predict, prevent and alert users in times of potential danger.
Can you tell me about where the idea for the WiseWear application came from?
In 2010, I lost my grandfather shortly after he fell in his home and never recovered from the fall. After the loss, I asked the CTO of the Air Force if I could get a bunch of smart people to come to my house in San Antonio and build a product that could predict and prevent this from happening in the future. We built a bio-sensing hearing aid that could detect and alert a senior when they were dehydrated or when their gate or balance was off. With this prototype in hand, I completed an executive MBA at the University of Texas and put together a business plan. After winning several competitions with the prototype, I decided to build a business. So I cleaned out my retirement account and started WiseWear in 2013.
We’re now making a whole family of connected safety and security devices that keep everyone in your family safe and secure. We launched our first consumer product last year at CES where we actually fused advanced-antenna technology and sensors for safety and security into a jewelry offering. We’re now making a standalone connected device using low-power and a wide access network with extended battery life that does not require a cellular connection for children’s health & safety.
So you were able to marry your personal interests with your background. Tell me about some of your design challenges. What were some of the hurdles you had to make? Especially around the design to create something that people want to wear.
We are primarily technologists with an eye for design, but we ended up partnering with Iris Apfel, former interior designer for the White House and a bunch of New York-based jewelry executives. We had them fly down to San Antonio in the initial product design meeting, given we didn’t know what jewelry should look like. They flew down and it was like the Devil Wears Prada visits the nerds. We sat at the table and fused together these two worlds of fashion and engineering. And we had a tug of war about what’s possible and what’s not possible in terms of form factors. The thing about connected technology design is the product is never done – you’re always updating firmware and apps. But in fashion, once the product is made, it’s done.
The challenges of this process were significant because this was the first kind of fused jewelry with sensors and electronics. Most wearables are made of plastics or elastomers or use a watch screen to transmit the signals through. Our patented technology allowed us to transmit the Bluetooth signals right through the metal material.
Was there any distortion or does that impact the signal at all?
Yes, but we have two patents to address this problem. For Bluetooth, we’re actually seeing the range from the bracelet to the phone is actually further than the phone to the bracelet, so the antenna works quite well, including distances of 50-70 feet. Manufacturing is a whole different challenge because we had to manufacture the jewelry piece with extensive orders for jewelry cuts. The cuts had to be precise enough that we could fuse the sensors and electronics into the jewelry piece while keeping quality and high fidelity signals.
I imagine size was an issue when getting the right components, such as sensors and chips?
Yes, we developed custom designs to get the right chips and components. We actually have one of the smallest boards inside any wearable. We couldn’t use anything that was off the shelf in terms of a complete board, so we had to design our custom builds with the antenna inside.
Tell me about how Silicon Labs got involved? What was it about our products that stood out over the competition?
You guys make the best components. Right now we’re using the Wonder Gecko 32-bit MCU and in some of our products going forward we’re going to be using even more of your components. We’ve always loved working with Silicon Labs and your components are just always the best that we come across in the industry. Given that we make a whole array and family of different types of products and services, Silicon Labs always seems to have some of the best in terms of quality and price.
Where do you see connectivity and IoT heading in the next 5 years?
Technology continues to gets closer to the body as we move from desktops, to laptops, to wearables, to smart apparel, to implantables - technology is invading us. The connectivity part is really the hot button item because the natural take on a wearable device is to just throw a CDMA or GSM chip in anything and connect it to the Internet. The reality is that’s like putting a gaming laptop on your wrist – it’s not a smart decision in terms of battery life or the utility of that connected product. So we’re starting to use low-power, wide access networks and make products that can connect at a very low cost.
Also, I’m pretty bullish on the development of smart apparel products for physiological monitoring and safety and security. I think that’s going to the next very important move before we get to implantables.
The technology design transitions we are seeing today can be likened to the transition of matter as it moves from a solid to a liquid to a gas. The initial smart phone and wearables were clunky looking, sort of like an ice cube. And now they’re starting to turn into a liquid and follow form factors that are more ascetically appealing and wearable. Then it turns into a gas and it’s ubiquitous, right?
Silicon Labs provides RF range calculators for customers to help estimate the actual range of their wireless applications. Simple RF Range Calculator is available to download here.
RF range depends on the following parameters
Propagation factor, depends on the environment
Simple RF Range Calculator
This simple RF range calculator is for those customers who don’t want to deal with difficult RF questions just simply would like to get fast and reasonable results for both outdoor and indoor environments.
Simple RF Range Calculator provides fast and accurate result as the customer selected the frequency band and set TX and RX parameters:
Simple RF Range Calculator with frequency band selection
Frequency bands and custom frequency channels also can be selected:
Simple RF Range Calculator with custom frequency channel set up
TX Output Power and RX Sensitivity need to set up based on the radio device’s actual link parameters based on the data sheet. If the exact antenna parameters are unknown notes at the right side can help to determine the closest values:
Simple RF Range Calculator with notes
Joe Broms is the founder and CEO of newly-launched ProtoBricks, which makes it possible for users to build digital logic into LEGO designs. Here he shares a little about how he's bringing this vision to life.
This has been a 6-year labor of love for me, the inventor, as I struggled to turn an idea into a hobby and finally into a real product. Today I’d like to focus on the heart of the product, the “hub”, and how Silicon Labs microcontrollers became the center of the ProtoBricks electronics universe.
The ProtoBricks Hub is a 12x6 stud LEGO™ sized brick with a grid of electrical contacts and LEDs on the top. We put a full-height two layer PCB board inside the brick. The bottom of the board has four spring loaded pin contacts: Power, Gnd, UART TX, UART RX, plus bare-board contacts for programming. The top is where the magic is; the edge contacts (studs) are the IO pins for the circuit. There are also two rows of RGB LEDs (one for each IO pin). Finally, one of center rows needs to do most of the heavy lifting: measure resistance/voltage, send/receive UART messages and switch between these tasks at a moment’s notice. This has gone through many iterations to squeeze out the optimal form factor, functionality and cost. Now we just need a microcontroller that is up to the task.
Wanted: A Very Capable Microcontroller
Breaking down the requirements further I needed to select a microcontroller with at least two UARTs. One of them needs to handle TX and RX flipped at different times. I needed at least 35 or so GPIOs pins to handle the exposed IO on the brick and service the other chips on the board. I also needed to light 24 RGB LEDs in three banks with varying intensity. Finally, I needed an accurate and quick ADC for detecting bricks via precision resistors and computing potentiometer positions.
I also needed a way to program the boards in the field and a way to easily debug without completely taking them apart.
Performance wise, everything has to work with many of the microcontroller peripherals turning enabled, disabled, started and stopped at the granularity of 100us. I set a hard deadline to service my main circuit emulating loop at a target rate of 1KHz. The most time consuming development task was organizing and breaking down the tasks into small, stateful chunks that could be prioritized properly. Fortunately for me I have been a PC C++ developer for 20 years and always enjoyed writing lower level code and optimizing tight loops – how hard can it be?
In the end, I chose Silicon Labs’ EFM32G232 with 128KB of flash, 16KB RAM. It had the right balance of IO pins, USARTs, a good ADC, and a reasonable price.
Inside the hub brick.
Here’s a few of the highlights, features, and tricks I learned along the way:
World’s First Brick Compatible Debug Connector
We wanted to provide power, UART and microcontroller programming pins in a very compact 2x2 stud size footprint , so I built this board with a 3D printed enclosure. Now I can connect to my boards in style and without taking apart my bricks every time. The pogo pins pointing up connect to SWCLK, SWDIO, SWO, and RESET.
Debug bricks: the center 4 pogo pins connect to the microcontroller
Prototype from last year, debugging the hub microcontroller using the Gecko development board.
One of the UARTs needs to be flipped from RX to TX depending on the brick position left to right. To do this I wired directly to the same UART peripheral but using two different pinout locations. Using the alternate location flag I could flip the UART without any external hardware or busing. Every penny counts with consumer electronics. Brick-to-brick communication uses 115 KBps UART without an external crystal. No problems here. I tested pushing that up to 1Mbps which worked most of the time, but I think this was more an issue with my board design than anything the microcontroller could handle.
The center row of many functions (voltage reader, resistance reader, UART communicator) ended up being serviced via two low-ohmic analog multiplexers (IDTQS3VH251) which then fed into the microcontroller’s UART and ADC pins. Everything was then time multiplexed on the microcontroller very quickly – turning on/off the ADC, UART, internal voltage dividers, addressing the MUXes. The EFM32 was up to the task: very fast at enabling/disabling peripherals and never getting into some weird state or timing issue. This saved me tons of time, board space and cost compared to dedicating more hardware! The only issues I had were of my own making. I needed to write a fairly sophisticated scheduler in firmware to service all the bricks optimally.
Pumping out the data
While all this is happening I still need to service the LEDs quickly. This was done using the final USART block available configured as SPI. Here I am just shifting out the data over DMA as fast as I can (bursting 96 bits at a time at a rate of 1 Mbps) to a chain of constant current LED drivers. At the same time, I needed to turn on and off PMOS transistors to power the 3 banks of LEDs, all time-multiplexed. Everything had to refresh very quickly because I wanted control the intensity of each LED via PWM.
In the end, I was trying to refresh 32-levels of intensity 200 Hz for 3 banks (3*32*200) = 19200 Hz with some custom GPIO bit flipping all in an interrupt handler! It held on, but barely. This was starting pushing the limits of what was possible with this design. I think if I had added an extra shift register or offloaded servicing the entire LED calculation/bitshifting effort to a tiny microcontroller (EFM8 Busy Bee?) I could get it to what I really want, 8-bit intensity levels and faster than 200 Hz multiplexing. Life is full of tradeoffs.
For LED blinking light lovers out there, 200 Hz is really too slow for LED multiplexing. You don’t notice it at first, but there are beating (stroboscopic effect) problems at this rate: especially with cameras. We had a video shoot last month and after some early testing decided to sacrifice most of the intensity levels for a faster overall refresh (500-600 Hz). We have one video shot where two cars go down a race and run a simple lockout circuit. 600 Hz LED refresh is a tad too slow when doing slow motion capture, but fine for realtime video.
Compiler and toolchain support
I can report after writing many thousands of lines of code the compiler never generated the wrong output. YMMV, but I found the compiler and debugger to be very robust. I was able to breakpoint and probe variables and stack frames inside of and out of interrupts without issue and very quickly. This sped up my development time considerably towards the end of the project. Very solid. I am still using Simplicity Studio 3 because I did not want to rock the boat with my toolchain towards the end of my prototyping. I am excited to see what 4.0 has to offer.
After starting in the firmware in C, I longed for just a modest amount of C++isms. Function pointers in structs are great and all, but after passing around essentially a “this” pointer at the beginning of many of my functions, things started getting quite verbose.
Fortunately for me, Simplicity studio added C++ support and I never looked back. Just writing interface pointers so I could pass around some of the high-level blocks reduced the coding task considerably without much of a runtime hit. I could even call a few C++ objects within some of my interrupt code without a problem. Nerd note: For the first time in my career, I wrote a placement new operator! That was fun. I never needed a malloc or any dynamic memory to get the job done.
There were a few places where it was very helpful to do a floating point divide or multiply (my own ADC calibration process for instance). Since I was using the ARM M3 core, it does not have a floating point unit, but the software-generated one worked just fine. I’ve kept an eye on the code size - it didn’t add too much (I’m at 90K of compiled code right now). If need be, I could drop back to fixed point math.
In the end I am happy to report Silicon Labs MCUs and software suite was very much up to the task and rarely caused me problems during development (I had to restart the software a few times, but that’s minor compared to my real issues). I was able to focus my energy on building my product, pushing the hardware to its limits, and dealing with other challenges which there were plenty!
If you are interested in teaching kids about digital logic in a hands-on and fun way – then check out ProtoBricks’ Indiegogo campaign starting August 15th, and if you want to see how I did it we will release all the Silicon Labs firmware and board designs for anyone to hack or modify.
Silicon Labs CMO Michele Grieshaber discusses how the decision to add connectivity shouldn't be taken lightly, and how the IoT can open up new avenues if learning and iteration is part of the product design process.
With 20 billion connected devices expected to be online by 2020, it’s easy to get caught up in the hype of what some consider the next industrial revolution. But before running headlong into developing a connected component to your offering, it might be a useful exercise to consider what exactly you want to achieve.
Carey Smith, founder of Big Ass Fans, recently penned an article in the Harvard Business Review in which he candidly recounted how his company’s venture into the world of IoT might have been a bit overzealous. Armed with all the familiar data points about adoption, the company produced the world’s first internet-connected fan that could connect to a lighting system and be programmed to operate according to an occupant’s personal preference.
In the end, it was the design and quality of Big Ass Fans that kept the customers coming, not the whiz-bang smart, connected features.
If you’ve spent any time thinking about the IoT, it’s likely you already have a notion of what features a “smart” version of your product should offer. But it’s important to keep an open mind when considering what opportunities the IoT may present for you. If there’s one thing we know about humanity, it’s that we’re always moving toward the next thing. The IoT is no exception, and what it’s capable of is constantly changing with new advances in software, sensors, radios, and, frankly, the connected products that other companies are developing. So what’s possible today in your particular industry may be but a precursor to what’s coming, some of which may not have even crossed your mind.
This integration of the IoT into our daily lives is a multigenerational event, which makes it hard to predict what the next killer app will be or what things will become part of our everyday lives. So patience, coupled with open-mindedness, can be a powerful combination for recognizing where you can go with the IoT.
For example, we work with a power tool company that decided to enhance the value of its products. This particular company was a pioneer in the use of lithium ion batteries so its tools were already very powerful and could run all day without a charge; pretty much the two things you want from your power tools. So how to improve? A new digital user interface was the first thing they set out to do. A power drill only has a few buttons, but you could add connectivity to enable an enhanced interface for advanced configuration settings through a smartphone app. Through the process of developing a smartphone-based configuration feature, they realized that device connectivity also lets builders use their phones to track a tool’s location using GPS, as well as configure custom RPM settings to deliver the precise amount of torque so they did not over-rotate fasteners during fragile installations. The tool can also be disabled and rendered useless in the case of theft. And because it’s cloud-based, new features can be delivered to tools already in the field.
Although this example company set down a path to only build an expanded user interface, through ongoing development, they uncovered new applications of value to their customers. This approach opened up new business models. Rather than be thought of as just a power tool manufacturer, they now provide services that can be delivered through the cloud.
Another example is Propeller Health, which was founded in 2010 to help users of inhaled medications understand what factors contribute to their symptoms. The medications to treat asthma and COPD are actually very effective, but patients didn’t have insight into what might be making them symptomatic. Propeller’s device uses sensors, accelerometers, and even microphones to listen to breathing sounds and determine whether or not the user is inhaling properly. What started out as a simple data collection mechanism morphed into much more. Propeller was able to evolve into a service that was useful for not only tracking usage, but improving outcomes by giving users the advantage of knowing what might be aggravating their asthma or COPD in the first place.
There’s a natural “what-if” component to design, and anticipating what consumers want and how they’ll interact with the products are important factors in this process. But we should guard against setting our sights so fixedly on an expected outcome that we’re blind to possibilities. We should also be willing to iterate. Carey and the gang at Big Ass Fans aren’t likely to close the door on looking for innovative connected solutions for their fans and lights, but the five questions outlined in his article are a good place to start before jumping into the IoT fray.
For most of us, connectivity isn’t a question of if, but how. Click here To learn more about how companies of every stripe are using connectivity in unexpected ways.
Hello and welcome to this inaugural article for Timing 101. My goal is to introduce and review technical topics of interest to board and systems designers who apply timing components or ICs (aka “clock chips”). Clock chips deliver frequency and phase information via clock waveforms, and in some cases packetized time information.
In this post, I will go over a common test set-up measurement situation whose results may be unexpected when one initially encounters jitter attenuators. I will first review some requisite background material, then present the "mystery" and its root cause, and finally suggest an improved test set-up.
Jitter and Phase Noise in a Nutshell
Briefly, clocks are periodic signals with digital signal levels used to sample data in a synchronous digital system. In other words, clocks provide the “heartbeat” or cadence necessary for sampling and sequentially processing data in synchronous digital circuits or systems. They are usually, but not always, at or near 50% duty cycle.
Ideal clocks would provide a perfect specified frequency and phase to optimize this process. However, practical clocks have timing jitter which can be defined as the short-term timing variation of the clock edges from their ideal values. One reason to care about clock jitter for synchronous digital systems is that it eats into the timing margins and, therefore, the reliability and validity of the data.
There is also a frequency domain counterpart to jitter: phase noise. Phase noise measures the random short-term phase fluctuations of a clock. It’s an indication of the spectral purity of the clock.
In short, this is a tabular or graphical plot of L(f) [script ell of f]; the noise power in one phase modulation sideband versus carrier power, at frequency offsets from the carrier. For example, -70 dBc/Hz at 100 kHz and –150 dBc/Hz at 20 MHz. The dBc/Hz units refer to power in dB relative to the carrier power per Hertz of bandwidth. Phase noise is typically measured using a phase noise analyzer or a spectrum analyzer with a phase noise option.
Often shown on the same plot are non-random short-term clock phase fluctuations referred to as spurs or spurious. These spurs, depicted as discrete components, have units of dBc.
As with other systems analyses, we will generally find it easier to understand clock devices and clock distribution networks or clock trees in the frequency domain. (I plan to cover phase noise and spurs in more detail in a subsequent post.)
The Role of Jitter Attenuators
It’s not uncommon to have to work with (or at least start with) relatively noisy or jittery clocks. These can arise for a number of reasons. For example, when the clock is:
In such cases, we need a particular type of clock device, a jitter attenuator or "jitter cleaner", to attenuate or minimize phase noise and spurs over the offset frequencies of interest. The resulting output clock is then distributed to the devices that need its improved jitter performance.
The distinguishing characteristic of Jitter Attenuators is that they are essentially narrowband Phase Locked Loops (PLLs) with a "low pass" jitter transfer function. That is these devices attenuate jitter components whose frequencies are greater than the PLL's loop bandwidth (BW). Modern jitter attenuators often have programmable loop BWs over a wide range, from as low as 0.1 Hz to as high as 1 or a few kHz.
By contrast, another category of clock chip, the clock generator, is a wideband PLL used primarily for clock multiplication from a low jitter source. These devices usually have fixed loop bandwidths on the order of 100s of kHz to 1 MHz.
The Measurement Problem
So what's the problem? Well, every so often a customer will contact us and write something like 'We're testing one of your clock chips and comparing the output clock versus the input clock and it seems surprisingly jittery'. Invariably we will find that the test set-up boils down to something like the following where the oscilloscope is being triggered by the jittery input clock.
The result will often look similar to that shown in the below. In this example the jitter attenuator is an Si5347 with loop BW = 100 Hz. The top yellow trace is the input clock which is a 25 MHz sine wave from a signal generator with 1 kHz FM, 100 Hz deviation applied. The bottom green trace is the output clock which is also 25 MHz just to keep things simple.
Shouldn't the output clock be less jittery? Is it jitter attenuated or not? This is the case of the (apparently) jittery jitter attenuated clock.
Given the measurement set-up shown earlier, three factors must be present to observe this apparent mystery:
Now you should be able to recognize the basic problem even if disguised in a more complicated application.
Note that if you triggered on the output clock then the input clock would look jittery by comparison. See below. Which clock appears jittery then is just a question of trigger perspective. This particular scope measurement is not conclusive without knowing which clock was more jittery a priori.
Diagnosis by Loop Bandwidth
You can obtain some insight as to what's really going on with this particular test configuration by playing with the Jitter Attenuator's loop bandwidth. Try narrowing and widening the BW and then observing the results on the scope.
Assuming a jittery input clock, you should generally see that widening the BW makes the output clock appear less jittery versus the input clock. This is because widening the BW means the PLL will track the input clock more, jitter and all. In Figure 4 below, the Si5347’s loop BW has been widened to 4 kHz. There is essentially no jitter attenuation and the output clock does not appear jittery compared to the input clock.
Conversely, narrowing the BW makes the output clock appear more jittery versus the input clock. That's because a narrower loop BW corresponds to more jitter attenuation. Ironically, it is the very success of the jitter attenuator in this test configuration that is the root cause of the apparent mystery. If the output clock simply tracked the input clock then the trigger source would be irrelevant. In the figure below, the Si5347’s loop BW is narrowed back down to 100 Hz.
A jitter attenuated clock is generally different from its jittery input clock, above and beyond any frequency scaling. If its spectrum has significantly changed, this should be relatively obvious when measuring and comparing the phase noise of each clock. However, as I mentioned before, this takes specialized equipment such as a phase noise analyzer or a spectrum analyzer with a phase noise option.
Third Party Arbitration
OK, so what's a better way to simultaneously compare the jittery input and jitter attenuated output clocks if all you have is a scope? Find a third party to arbitrate. In other words, find or generate a low jitter reference clock integer-related and synchronous to both the input and output clocks. Then use this reference as the trigger for both the input and output clocks. See the revised test set-up diagram in the figure below. Now you can clearly and fairly compare the jitter of the input and output clocks simultaneously in the time domain.
Here are a couple of example plots in which all the oscilloscope traces are 25 MHz as before. The top yellow trace is the jittery (frequency modulated) input clock and the middle green trace is the jitter attenuator’s output clock. The bottom blue trace is the new low jitter reference clock being used as the trigger. In the first instance, in the figure below, the jitter attenuator’s loop BW is 4 kHz and the output clock is fairly jittery just like the input clock.
In the second instance, in the figure below, the jitter attenuator’s loop BW is 100 Hz and the output clock is much less jittery. In this particular example, the standard deviation of the jitter attenuated clock’s cycle to cycle jitter dropped from 8.2 ps to 1.1 ps when the loop BW was decreased from 4 kHz to 100 Hz.
I hope you have enjoyed this first Timing 101 article and, if you are new to the field, that you won't be caught off guard should you run in to this scenario.
Some of the subjects I hope to cover in later installments include a deeper dive in to jitter, phase noise, clock trees, wander, and output clock formats. If you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to firstname.lastname@example.org with the words Timing 101 in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading.
Keep calm and clock on. And click here for more information
Below are the other Timing 101 articles:
We are featuring one of the Silicon Labs Community members who is active or new in the community on a monthly basis to help members connect with each other.
Meet our August member of the month: Ivan_Dousa
Q: Congrats on becoming our featured member of the month! Can you introduce yourself to our community members?
My name is Ivan Dousa, I'm an Electrical Engineer at TireCheck company located in Prague, Czech Republic. I'm responsible for the development of new electronic devices intended for tire inspection and tire performance monitoring. The design of electronic devices and embedded programming is also my hobby from the time I have studied at a high school. I really enjoy the creative process of building a new electronic device, breathing a new life into it by writing and embedded software and improving the device performance and capabilities based on the application needs and customer request. It's a great magic.
Q: How did you know about the Silicon Labs Community?
We have discovered the Silicon Labs Community at the time when we were evaluating a Bluetooth solution from different manufacturers for our new products. That time we were also looking for some information about the Silicon Labs solution and we have discovered that Silicon Labs Community could provide us a lot of useful information. We were able to find their answers to most of our questions, information about user experience with the product and also all device documentation. Since that time we use it regularly. It is also the right place where we can report any bug or functionality issue observed on Silicon Labs product and where we can get in touch directly with Silicon Labs employees that are willing to help.
Q: What features, products, services would you like to see in the future from Silicon Labs?
I think that Silicon Labs provides great and well-documented products. In addition there is a large Knowledge base and Forum where you can find a answer to most questions. You can also ask there any question directly to Silicon Labs employees or other community members. I think it works very well. Anyway, sometimes it happens that not all documentation provided by Silicon Labs is up-to-date. This is the point that could be improved.
Q: What advice would you give to someone new to the community?
Silicon Labs Community is a good place to find information about Silicon Labs products and solutions. You can meet many smart people that work with Silicon Labs products, have a lot of experience with them and that are willing to help you. If there is a question you were not able to answer based on the available documentation or any existing forum topic, don't worry to ask. If the question is clearly formulated it will be answered shortly.
Q: Thanks for answering the questions. Any final comment?
I'm looking forward for many new, interesting and innovative products and solutions from Silicon Labs.
Steven Cooreman is originally from Belgium and was introduced to Silicon Labs as an exchange student at Olin College near Boston. Cooreman obtained his MSc Electronics at Group T International College, Leuven in Belgium. The Boston team spoke highly of him and recommended he join the team in Oslo. Cooreman started at Silicon Labs in August 2014 as an NCG and Software Engineer.
In March 2016, Cooreman was promoted to Software Engineering Manager on the 32-bit MCU Software team. Cooreman said he appreciates creating software that’s being actively used by more than a thousand makers while still participating in workshops, writing articles and interacting with students. Cooreman’s currently working on mbedOs which allows him to collaborate closely with ARM.
Cooreman’s manager, Marius Grannæs described him as a quick learner. “He’s able to jump into new problems very quickly so he can help when problems arise. He’s also arranged a few social events for the group,” Grannæs said. Cooreman even took the initiative to study Norwegian at the University of Oslo, and after only one year in Norway, he speaks the language fluently.
When asked about his working at Silicon Labs, Cooreman said, “The open culture and the level of camaraderie I see every day at work. While we may forget about it after time, it really is a rare thing to have in a global company and something to be proud of and conserve!”
We always like to throw in a fun question during our employee spotlight interviews, so we asked Cooreman, if he could have any superpower, what would it be and why? His response: “I would get a superpower that gets rid of any and all weapons (including superpowers). That people feel the need to do harm to others, is something I just can’t wrap my head around. Let’s live in peace and build a better future for those coming after us, not a worse one.”
We think you’re super Steven Cooreman, and we’re glad to have you on the Silicon Labs team. Thank you for all that you do!
We had a wonderful opportunity to speak with Brad Zdroik, Founder of Deep Freeze Fishing. A leader in the emerging IoT development occurring in the outdoor sports market, Deep Freeze Fishing helps fishermen and women avoid the cold while ice fishing by providing an alert system for their lines, freeing them to monitor catches from afar.
So for people not acquainted with Deep Freeze Fishing, tell us about yourself. What’s the elevator pitch explanation of what you do?
We manufacture and sell ice fishing equipment. We’re based in central Wisconsin, and we sell products throughout the northern third of the U.S. and up into Canada as well. We started off with an ice skimmer that clears slush out of your ice augur hole in one scoop, and that’s evolved into the current One Shot Skimmer Pro Edition. But our connected BlueTipz product is now our most popular offering.
How does BlueTipz work exactly? What’s going on under the hood?
BlueTipz is a tip-up alert for ice anglers. Instead of having to stare at your flag all the time waiting and waiting for the fish to bite, you can instead attach our BlueTipz transmitter on the flag. When the tip-up receives a strike and the flag goes up, a sensor in our device pings your phone, freeing you to be inside your fishing shack keeping warm for longer stretches of time until right when you need to actually take care of your line.
BlueTipz also allows you to be much more flexible during night fishing. Not only do we have a light on the tip-up that lights up, but you can also name individual tip-ups within the app so you know exactly which one has gotten a strike; it definitely saves you some stumbling around in the cold and dark. That’s a great benefit especially in the states that allow you have up to 10–15 lines going at once.
And what’s the story of how you arrived at a solution for ice fishing diehards? It’s definitely a unique niche. How did Deep Freeze Fishing even come about?
I actually went to school for electrical engineering and did my corporate cubicle stint and was just feeling restless. I moved back home to central Wisconsin kind of searching for what to do. I always loved the sport of ice fishing, and just fiddling around with my Dad, we created the One Shot Skimmer product that represents Deep Freeze’s beginning, though certainly not very techy of course.
Around the same time, smartphone apps were beginning to ramp up, and there were a couple other products beginning to hit the market that provided tip-up alerts. But my brother Ryan and I weren’t crazy about any of them and thought they could work much, much better. So we decided to build our own, and that is how BlueTipz was born.
How would you say your solution has evolved since 2012 when you started out, as well as your design challenges over time?
The core solution has actually remained the same since we started. It’s become more of a matter of putting more high-quality, sophisticated hardware pieces inside as technology has gotten better since we started out in 2012. That has let us extend battery life over time and continue to be able to keep working in temperatures as low as -20° to -30° F. Being able to withstand the brutal open cold is hands-down what’s always driving us. If a component can’t take the cold, we can’t use it.
We also have about a 600-foot range from BlueTipz to your phone, and that’s grown from our original capabilities. We’ve had to make sure the signal can make it through a typical fishing shack and the human body, so we’ve definitely invested in boosting the signal itself and always make sure the Bluetooth module can do its job.
What Silicon Labs’ product are you using in BlueTipz? And why did you select it?
We started out with the Bluegiga BLE112 and have actually transitioned over to the Bluegiga BLE121LR to get the extended signal range. It’s a good value and it can withstand the extreme cold. We couldn’t be happier with it.
What do see in the future for Deep Freeze Fishing?
Ice fishing is obviously a niche market within fishing; we hope to develop some applications for open-water fishing as that is obviously a substantially larger market. We feel the whole space is lacking in terms of IoT development.
In closing, we always ask our IoT Heroes one Bonus Question: Where do you see the collective IoT heading in the next 5–8 years in your opinion?
As I said, we think even just regular fishing is vastly lacking in connected development that could really be meaningful and helpful for end-users. The industry is just behind all the amazing things we see on the news. I think we are really going to witness a blossoming of applications across the board in the coming years for outdoor sports users, and that’s exciting.