Silicon Labs Silicon Labs Community
silabs.com
Language
  • 简体中文
  • 日本語
  • MCUs
    • 8-bit MCU
    • 32-bit MCU
  • Wireless
    • Bluetooth
    • Proprietary
    • Wi-Fi
    • Zigbee & Thread
    • Z-Wave
  • More Products
    • Interface
    • Isolation
    • Power
    • Sensors
    • Timing
  • Development Tools
    • Simplicity Studio
    • Third Party Tools
    • Thunderboard
  • Expert's Corner
    • Announcements
    • Blog
    • General Interest
    • Projects
  1. Community - Silicon Labs
  2. Blog

Chapter 6: User Interface Experiments Part 1 - Human Reaction Time

08/224/2015 | 11:20 PM
lynchtron

Level 5


makersguide_ch6_1.png

User Interface Experiments

When a user picks up and interacts with your gadget, the physical interface will give that user a sense of the quality of the device.  Touch screens are becoming common, but may not be appropriate for all devices.  Many devices rely on electromechanical switches or buttons.  If the buttons are hard to press, feel flimsy, or if the functions are not intuitive, the user will have a bad impression.  You can fix all of those things with good physical product design, but just as important is how the device reacts to the user input.  If the interface is slow or if a single press results in multiple presses intermittently, that will leave a bad impression.

 

Button Input Reaction Time

How fast does your code need to react to user input to be considered a snappy interface?  I wrote some code that you can run on the Starter Kit to find out for yourself.  The following code will illuminate TEST LED1 on the Starter Kit when the button PB1 is pressed, after a DELAY_VALUE in milliseconds is elapsed.  Note that the utilities.h file is described in previous lessons and is available on the blog website.

#include "em_device.h"
#include "em_chip.h"
#include "em_cmu.h"
#include "em_gpio.h"
#include "utilities.h"        // Source available on the blog webpage
 
#define DELAY_VALUE           100 // ms
 
/**************************************************************************//**
 * @brief  Main function
 *****************************************************************************/
int main(void)
{
      // Chip errata
      CHIP_Init();
 
      setup_utilities();
 
      CMU_ClockEnable(cmuClock_GPIO, true);
 
      // Set up the user interface buttons
      GPIO_PinModeSet(BUTTON_PORT, SET_BUTTON_PIN, gpioModeInput,  0);
 
      while (1)
      {
            if (get_button())
            {
                  delay(DELAY_VALUE);
                  set_led(1, 1);
            }
            else
            {
                  set_led(1, 0);
            }
      }
}

 

In my tests, I found that delays of 100ms or so were fast enough to be considered responsive, but 150ms started to seem like a slow response, and 200ms seemed like an eternity.  We humans expect the interfaces to respond within 1/10th of a second. 

 

Reaction tests at Human Benchmark measures both the recognition of an event and the reaction to the event.   The average reaction time is around 250ms.  Interestingly enough, the site mentions that your own computer can introduce a lag of 30ms to the test, and that it is getting longer as technology moves forward, due to operating system overhead.  My reaction times on my computer were around 400ms.  I switched to my smartphone and found that it dropped to an average of 280ms.  I have a wireless mouse for my computer, which could be contributing to the lag, likely due to power-saving sleep states in the mouse hardware: if it can sleep for 100ms and then wake up to check for an event, the batteries will last longer.  These are all things that you will need to consider as you develop your gadget.

 

To make things more interesting, I changed the program to illuminate TEST LED0 immediately, followed by the original TEST LED1:

      while (1)
      {
            if (get_button())
            {
                  set_led(0, 1);
                  delay(DELAY_VALUE);
                  set_led(1, 1);
            }
            else
            {
                  set_led(0, 0);
                  set_led(1, 0);
            }
      }

Now when I run the code and press PB0, I see an immediate response in TEST LED0, followed by 100ms and then TEST LED1 illuminates.  It is now very clear to me that TEST LED1 is showing a lag that would be unacceptable if both lights are intended to illuminate at the same time.  By adjusting the value of DELAY_VALUE, I found that 27ms was an acceptable delay where both lights would illuminate simultaneously, at least to me.  Therefore, if you have code that needs to read the environment (like an indicator light, for example) and act on it immediately, you have about 27 ms for your code to react to the event if you are hoping to provide a simultaneous response.

 

This 27ms translates to 37Hz if the illumination was in the frequency domain, like in a moving video.  I am able see display flicker at up to 75Hz.  Those old monitors that had a 60Hz refresh rate drove me crazy with flicker!  We now have LED HDTV’s that interpolate 24 to 60Hz video feeds and “upconvert” to 120Hz, which is about 8ms between screen updates.  That adds a hyper-realistic quality to video content and seems to be near the lower limit of human perception.

 

Note: The eye can distinguish colors or frequencies of light in the 450 to 700 GHz range.  However, we can’t tell if two colors such as red and blue are blended to create purple by alternating them faster than 30 Hz, or if the color is truly purple.  Likewise, the ear can distinguish frequencies between 30 and 20kHz, but the sound needs to hang around for a while to be detected by the brain.  The eyes and ears are fantastic sensors, but the brain still needs time to make sense of the data.

 

Run this program on your Starter Kit and see what YOU think of these delays?  This will help you determine the best response time for your gadget.

 

PREVIOUS | NEXT 

  • Blog Posts
  • Makers
  • erikm

    Pathfinder
    Level 7


    Replied Sep 03 2015, 8:27 PM

    a bit related. NEVER use anything with switches that react on switch release. It is about the most annoying 'feature' anyone can come up with.

    0
  • nrrathi

    Level 4


    Replied Jun 26 2016, 1:17 AM

    Hi 

     Sir could you please help me with utilities helper file. I am right now studying chapter 10.2 : Control an accelerometer over I2c and for the second time I got introduce to utilities.h. I am not able to find the source of this file. In which previous chapter you thought this? I refered to all but no luck. 

    waiting to hear back from you.

     

    Thanks. 

    0
  • microcubs

    Level 3


    Replied Sep 25 2016, 10:46 AM

    I am beginer and while reading the technical training article i came across the programs. I need utilities.h file. The article says its available on blog but i did not found. pls locate

    0

Tags

  • Wireless
  • High Performance Jitter Attenuators
  • EFR32MG21 Series 2 SoCs
  • Blue Gecko Series 2
  • Zigbee SDK
  • ZigBee and Thread
  • Internet Infrastructure
  • Sensors
  • Blue Gecko Bluetooth Low Energy SoCs
  • Z-Wave
  • Micrium OS
  • Blog Posts
  • Low Jitter Clock Generators
  • Bluetooth Classic
  • Makers
  • Flex SDK
  • Tips and Tricks
  • Smart Homes
  • IoT Heroes
  • Reviews
  • RAIL
  • Simplicity Studio
  • Mighty Gecko SoCs
  • Timing
  • Blue Gecko Bluetooth Low Energy Modules
  • Clocks
  • Ultra Low Jitter Clock Generators
  • General Purpose Clock Generators
  • Industry 4.0
  • Giant Gecko
  • 32-bit MCUs
  • blue-gecko-xpress-modules
  • Bluetooth Low Energy
  • 32-bit MCU SDK
  • Gecko
  • Microcontrollers
  • News and Events
  • Industrial Automation
  • Wi-Fi
  • Bluetooth SDK
  • Community Spotlight
  • Biometric Sensors
  • General Purpose Jitter Attenuators
  • Giant Gecko S1
  • Flex Gecko
  • Internet of Things
  • 8-bit MCUs
  • Isolation
  • Powered Devices

Top Authors

  • Avatar image Mark Mulrooney
  • Avatar image Siliconlabs
  • Avatar image Nari Shin
  • Avatar image lynchtron
  • Avatar image deirdrewalsh
  • Avatar image Lance Looper
  • Avatar image lethawicker

Archives

  • 2014 December
  • 2015 January
  • 2015 February
  • 2015 March
  • 2015 April
  • 2015 May
  • 2015 June
  • 2015 July
  • 2015 August
  • 2015 September
  • 2015 October
  • 2015 November
  • 2015 December
  • 2016 January
  • 2016 February
  • 2016 March
  • 2016 April
  • 2016 May
  • 2016 June
  • 2016 July
  • 2016 August
  • 2016 September
  • 2016 October
  • 2016 November
  • 2016 December
  • 2017 January
  • 2017 February
  • 2017 March
  • 2017 April
  • 2017 May
  • 2017 June
  • 2017 July
  • 2017 August
  • 2017 September
  • 2017 October
  • 2017 November
  • 2017 December
  • 2018 January
  • 2018 February
  • 2018 March
  • 2018 April
  • 2018 May
  • 2018 June
  • 2018 July
  • 2018 August
  • 2018 September
  • 2018 October
  • 2018 November
  • 2018 December
  • 2019 January
  • 2019 February
  • 2019 March
  • 2019 April
  • 2019 May
  • 2019 June
  • 2019 July
  • 2019 August
  • 2019 September
  • 2019 October
  • 2019 November
Silicon Labs
  • About Us
  • In the News
  • Email Newsletter
  • Cookies
  • Contact Us
  • Community
  • Site Feedback
  • Investor Relations
  • Blog
  • Privacy and Terms
  • Corporate Citizenship
Copyright © Silicon Laboratories. All rights reserved.
粤ICP备15107361号-1