Our Smart Station hardware consists of a PIC32MX250 microcontroller with a 3.5mm jack for speakers, a TFT display, keypad, NeoPixel LED ring, microphone, and a host of I2C environmental sensor breakouts: i.e. accelerometer, temperature, humidity, and luminosity sensor breakouts. All of the electronics are neatly contained within a 3D printed casing. Our Smart Station system has two main features: environmental sensing and entertainment. The device is capable of displaying readings for all of the sensor peripherals on a continuously-updating graph display. Additionally, the device features a setting screen which allows users to input high and low threshold values for each sensor peripheral so that if the sensor reads in values outside of the provided range, alerts are displayed on the NeoPixel LED ring on the top of the device. On the setting screen the user can also manipulate the color of the selected sensor on the real time graph plot. Once a sensor is selected on the settings screen, returning to the graphing screen will display that specific sensor’s information, including the sensor’s name, the current value, a line graph of the data being read, and horizontal lines indicating the user-input triggering thresholds. Finally, our device features a music-adaptive entertainment console which can connect to any Bluetooth audio source using the RN-52 Bluetooth Module. Using UART commands, the PIC32 can send media button commands like pause and track skip to the RN-52 module to control the music output from an external Bluetooth device. Using feedback from the system’s built-in microphone, the device is capable of generating a unique light show on the NeoPixel LEDs which pulsate and change colors according to beats from music that is output to the speakers.
Our decision to work on this project stemmed from our mutual interest in remote sensing and control applications. When formulating project ideas, we came up with the plan to build a home base station that would alerting the user based off of certain sensor triggers. This idea evolved to include an entertainment feature after looking into the design of commercial smart stations like the Amazon Echo. To do this we added the ability to play back music and display an interactive light show using a NeoPixel LED ring. This project presented a multitude of hardware and software design challenges. Given the large number of sensors and peripherals we wanted to include, it was a challenge to properly organize them within our custom 3D printed housing in a neat and compact way. On the software side, we were faced with the challenges of setting up and creating our own PIC32 library to implement I2C protocol for all the sensors, creating a UART control API for the RN-52 Bluetooth module, as well as designing assembly code in order to bit-bang the NeoPixel LED ring with correct timing requirements.
The diagram above showcases all of the peripherals utilized in this project, as well the protocols that were used to interact with them. When all of our devices were finally wired in, we had used all but four peripheral pins on the PIC32MX250F128B. The configuration of the I2C, UART, digital outputs, and analog inputs also contributed to the overall complexity of our final firmware design.
The schematic below showcases all of the peripherals connected to the pins on the PIC32 chip. One problem that we ran into that we discovered was located in the PIC32 errata for this specific chip was that, if I2C1 is enabled, all digital output-only functions and all analog functions on pins RA0 and RA1 do not function properly. We worked around this issue by using a multiplexer (TI CD4501B) and having all of the analog keyboard outputs be generated from 1 analog pin instead of 4, as in Lab 2. Another important thing to note about our hardware is that the NeoPixel LED is designed for 5V logic, but can still be operated using PIC32’s 3.3V logic level. Datasheets and further information on each piece of hardware may be found in the appendix.
The purpose of the 3D printed enclosure was to properly house all the electronics, hiding the bundles of wires and the microcontroller while leaving only the necessary peripherals accessible: i.e. the TFT display, keypad, power supply port, and 3.5mm jack for the speakers. In early stages of this project, our intention was to use an ultrasonic distance sensor that would serve as a wakeup for the system. While working through the project, we discovered that the sensor used a 5V logic level as opposed to the 3.3V operating level of the small board we were working off of. Instead of implemented logic level-shifting circuitry, we decided to include a microphone and NeoPixel LED ring. For that reason, the CAD model and our 3D print had an extraneous opening for the ultrasonic sensor which was not necessary, and was lacking an opening in the back in which the wires for the microphone and the LED ring would rest. The extraneous opening was covered with black electrical tape to make it appear solid, and a notch was cut out in the back of the box with a dremel for the additional wires. Below are images of the first version of the CAD, the physical unit, and then the potential update to the CAD model.
The design of the perf board was most complex part of the hardware design of this project. In order to have all of the electronics fit nicely within the enclosure, a great deal of soldering and planning needed to be done. A separate perf board was used to connect all of the pins of the small board housing the microcontroller. These pins were broken out and sent to headers that were connected to sensors and modules. On this perf board, there were the in-line and pull-up/pull-down resistors for the keypad, all the SDA and SCL lines for the I2C protocol sensors, and all other I/O peripheral pins. Our intention was to keep the design as modular as possible, and for that reason, header pins were heavily utilized to facilitate simpler debugging of individual sensors and peripherals. Below is the perf board with all the electronics housed within the enclosure.
Ultimately, we feel that our final hardware design came together very well. As we developed our project, we sometimes had to pivot when we ran into roadblocks like the distance sensor requiring 5V instead of 3.3V, or when we were lacking pins two analog pins due to the fabrication error described in the errata of the PIC32 datasheet. The product came out clean, organized, and kept all the electronics securely housed within the enclosure. If we were to do the project again, we have some ideas on areas which we would like to have improved on. As previously discussed, the casing can be changed, not only to have the appropriate cutouts, but also make a sleeker, less boxy design. Additionally, the port opening for the 3.5mm jack and the power cable were a bit tight and needed to be sanded away so having a more open port design may benefit the system not only for functionality, but also aesthetically. Furthermore, different colors could be used for a friendlier look, and the 3D print could have been chemically bathed or sanded further to create a more polished look. Overall, functionality-wise, the hardware functioned exactly as we had intended, but aesthetically, we felt that it could have been improved.
The config.h header file includes the ‘plib.h’ library, and contains only a few defines for the project. Namely, it sets the oscillator source to be the 8MHz internal oscillator of the microcontroller, sets the div FPLLIDIV to be 2, the prescalar ‘FPLLMUL’ to 20, and the div’s ‘FPBDIV’ and ‘FPLLODIV’ to be 1 and 2, respectively. This combination of the divisions and multipliers generates a 40MHz system clock source and sets the peripheral bus frequency to be 40MHz.
The main function within main.c sets up all of the I/O pins used within the project, initializes the ADC and I2C modules, outputs the main menu screen to the TFT display, and sets up I2C transactions between the PIC32 and the accelerometer and luminosity sensor peripherals. First, the main function calls adc_setup() which sets, opens, and enables pin AN11 for analog microphone readouts using the following configuration parameters:
After initializing the ADC for the microphone peripheral, the main function initializes the TFT display and sets up pin RA2 as a digital output for the data in line of the NeoPixel LED ring. The function then calls the sensors_setup function, which initializes a global array of sensor structs with the following attributes for each sensor peripheral: name, maximum possible value, minimum possible value, high trigger value, low trigger value, and plot color. By default, the high and low trigger values were chosen so that, during our demo, we could interact with the sensors and cause them to trigger on certain events (i.e. shining a phone light on the luminosity sensor or breathing on the humidity sensor). After initializing the sensor struct, the main function then uses the i2c_rw.h driver, discussed below, to write registers that initialize I2C transactions with the accelerometer and luminosity sensors. Afterwards, the main function calibrates the accelerometer by performing a series of I2C reads and determining the appropriate constants for zeroing out the x, y, and z-acceleration readouts. Lastly, the main function calls a method which makes the NeoPixel LED ring at the top of the device turn blue before scheduling all of the program threads.
The pt_measure thread is responsible for calling of the sensor update functions and storing the new readings in the global array of current sensor values. This function reads out current microphone analog input voltage and squares it to obtain a sufficient statistic for the power output of the speaker. The program then averages the readout with the past 10 sensor readouts and stores the average power in a global variable that is used for reactive lighting in the pt_led thread. After calculating the sufficient statistic for the average mic power, the thread then calls the i2c_rw functions for the accelerometer, temperature, humidity, and luminosity sensors. These methods are described in extensive detail in the i2c_rw.h section, as well as within the comments for the file.
The pt_led thread contains all of the necessary logic for toggling between reactive music mode and idle modes depending on the current state of the device and the current power output of the mic. When the thread is first entered and the user is on the music screen, the NeoPixel LED ring will remain solid red until the first power spike in the speaker output. Once this peak is detected, the LED will alternate between one of three color states with varying levels of either red, green, and blue RGB values - with each state being based on the magnitude of the power spike (lower power spikes lead to more neutral coloring while higher power spikes lead to sharper coloring). Additionally, between any two power spikes, the direction in which the new color sweeps across the NeoPixel LED ring is reversed, creating a back and forth motion effect. Whenever the average mic power is below a specified threshold value, the NeoPixel LED ring will remain a solid color.
The protothread_input contains all of the necessary logic for reading/debouncing keypad values and performing actions on the device according to current menu that the device is in: either the main screen, the settings screen, the music screen, or the graph screen. The keypad readout code is based off of the example project located in the ZIP file on the index_TFT_display page of the ECE 4760 website. Initially, the thread declares the length 12 keytable array containing all of the various key encodings and initializes the input and output pins on the keypad. The keypad array is in order from 0-9, followed by * and #, where the absence of a valid key press is encoded by the index -1. In the while-loop for this thread, each row of the keypad is read out by driving the analog output A0 which is input to a demultiplexer, changing the demultiplexer control signal to switch between one of the first four input pins on the keypad, and reading the outputs on the keypad pins 6 through 8 which are connected to PIC32 digital input pins RB5, RB7, and RB10 respectively.
If any of the keys have been pressed, one or more of the digital inputs will detect a non-zero value which is compared with the entries in the keypad table. If there is a match, the index of the matched entry is stored in a variable. The index ‘-1’ encodes no match, ‘0-9’ encode digits 0 through 9, ‘10’ encodes *, and ‘11’ encodes #. In the debouncing state machine, there is a switch statement containing no push, maybe push, pushed, and maybe no push states. In order for a press to be registered as a valid button press and enter the pushed state of the FSM, the press must be detected for two consecutive executions of the keypad thread. The pressed state of the debug state machine contains a nested FSM where the each of the 4 screen states has its own independent switch-statement that defines what actions can be performed on that screen using the keypad buttons. The majority of these actions are simply for entering/exiting and inputting simple multi-digit integers, as performed in lab 2, with the exception of the music controls on the music screen.
The menu screen contains 3 options. Pressing the 0 key on the keypad enters the settings screen, pressing the * key enters the music screen, and pressing the # key enters the graphs screen. From any other menu within the program, this main menu can be re-entered using the * key.
The music screen contains 5 music control options, which are enacted by sending the appropriate UART command from the PIC32 to the RN52 Bluetooth Audio Module. Pressing 1 or 3 on the keypad will go back a song, or skip forward a song, respectively. Pressing the 2 key will toggle between pausing and playing the current track, and the 4 and 5 keys make the volume go down or up, respectively.
|Music Command||UART Command|
|(1) Previous Track||"AT-\r\n"|
|(3) Next Track||"AT+\r\n"|
|(4) Volume Down||"AV-\r\n"|
|(5) Volume Up||"AV+\r\n"|
The exhaustive list of UART commands that can be sent to the RN52 module can be found on the RN52 datasheet found in the appendix. Below is an image of the main music screen and a few snapshots of the reactive lighting.
The settings screen contains 4 configurable options. The first parameter is the current sensor name. Pressing the toggle button cycles through the list of sensors on the device to configure. After selecting the desired parameter pressing the # key cycles to the next configurable parameter, the color of the parameter plot on the graph screen. The last two parameters, the high and low trigger values, can be entered using the numbers on the keypad. If the chosen values are within the maximum and minimum possible values and the next button is pressed, then the values will be latched and the selection cursor will return to the sensor name. After configuring all of the settings, returning to the main screen and entering the graph screen will display the newly-selected sensors name, color, and trigger high and low boundaries on the real-time plot.
The graphing screen displays a real-time plot of the currently-selected sensor, as well as the current value that is being read out by that sensor. If the value of the sensor reading ever goes over the high or low trigger values, then the NeoPixel LED ring on the top of the device will turn from green to red and the status circle at the top right corner of the screen will turn red, as shown below.
The pt_timer thread is the least involved of all of the protothreads within the project. On each iteration of a while-loop, this thread captures the starting time using the method PT_GET_TIME. The thread then enters a switch statement, with case statements for each of the four possible menu screens. Within the case statements, the thread simply calls the associated gui.h method for displaying that screen and calls PT_YIELD_UNTIL with the specified frame rate for that screen. The main, setting, and music screens update twice a second, and the graph screen updates five times a second.
The gui.h header file contains all of the user interface code for each of the four screens. Within each animate function for each screen, the elements are partitioned with an if-statement control flow so that the static components are only drawn the first time that the screen is entered, and the dynamic components are drawn every time. The screens that are displayed for each of these functions can be seen in the various menu screen sections above.
One of the most important header files we wrote was the i2c_rw.h header file that contained all of the I2C functions that communicated with our I2C based sensors. At the top of the function we include definitions of the specific device addresses and register mappings for each of our sensors (Luminosity, Accelerometer, Temp/Humidity). We then have functions i2c_wait, init_gyro,i2c_write, i2c_read, read_imu_values, calibrate, init_luminosity, read16, get_luminosity, temp_get, and measure_temp_humidity.
The function i2c_wait is an assembly implemented delay function. The functions i2c_write and i2c_read, read and write a specified number of bytes to a given register and device address. The functions i2c_write_bits writes specific bits in a given device and register address, and read_16 reads two bytes from a given device address. It is important to note that the above helper functions all follow a fairly standard I2C communication frame and can be used to read and write to a variety of devices. These helper functions are then used in the device specific functions in order to initialize and read values from our various sensors.The function init_gyro initializes the specific registers in our IMU that allow us to communicate with it. We call this function followed by calibrate, which reads from our IMU 100 times - averaging over these readings - to effectively zero out our orientation upon the powering up of our project. Following this we can use read_imu_values to properly read acceleration information from our IMU. The function init_luminosoity sets up the proper gain and integration time for our luminosity sensor, and is followed by calls to get_luminosity that reads both broadband and ir luminosity values and converts the readings into the S.I. units of lux. Finally we have the method temp_get and measure_temp_humidity. The function measure_temp_humidity returns the values for temperature (in Fahrenheit) and humidity (in %), and does so by using a helper function temp_get to read from the temp/humidity sensor and then applying a linear equation to convert these values into the units specified above.
Another large and fairly complex part of this project was writing the neopixel.h library which contains all the functions which offload data on our Neopixel ring. The neopixel.h file contains 2 core functions called zero and one which are hand tuned assembly functions that output the specific pulse widths for 1’s and 0’s as specified in the diagrams below. The tuning itself was done using a Salae Logic Analyzer which allowed us to analyze the pulse-widths being output in real time.
In addition to these functions which write 1’s and 0’s to the DIN line of the Neopixel ring we also initialize an array of structs per neopixel that allow us to store the state of our entire ring (RGB values) in an easy to interface way. We then wrote several helper functions that allow us to manipulate said array and write it out to our rings dataline. The function display() iterates throughout our array of pixel structs and writes out the corresponding 1’s and 0’s using the functions zero() and one() discussed above. The functions setPixel, clearPixels, white, red, green, blue, color_all, colorWipe, theaterChase, Wheel, and theaterChaseRainbow all do as their names suggest and manipulate our array of pixel structs in various ways.
The purpose of this lab was to pick a project, then design and build it. For our project, we decided to build a smart home base station that could be a hub for a variety of different information (I2C sensors) as well as used for entertainment (music and LED indicators). During the course of our final design project we were able to do just that. In our final presentation, as discussed in the sections above, we created a complete smart home station that was able to graph sensor data in real time, with custom thresholding and data ranges, as well as stream music and provide a lightshow for the user to enjoy - all of which can be seen in the pictures below.
Some metrics that were important to us throughout the course of this project were user experience and system accuracy. In regard to user experience, we did not want the screen to flicker too much, or have too much lag when the user was entering inputs. After having a working system up and running, we were able to tune our protothreads delay so we had a partial screen refresh rate of 10Hz (partial meaning we never rewrote our whole display unless changing menu screens), which made our system appear fairly fluid and professional. Furthermore, by tuning our software debouncer, we were able to make the keypad responsive to user input - making the overall user experience very pleasant. While there is no quantitative data in regard to user experience, there is data for accuracy and timing. One of the other goals of our project was to present continuous and accurate data from all of our sensors. From our accelerometer we were able to properly read between 9.8 g’s and 9.9 g’s in the positive z direction (up from level ground) when the box was stationary - resulting in an error of ~1%. For our luminosity sensor, while we did not have any way of confirming our lux values were correct, the sensor itself is accurate to about 1 lux in standard lighting conditions. Finally, for our temperature sensor, we were able to confirm the measured temperature with our test rooms thermostat, and the humidity to the expected indoor humidity on a November’s day in the northeast region (accurate to within 1 degree and 5 % of expected values respectively). Furthermore, we were able to achieve communication with all of our I2C sensors at the standard I2C data rate of 100 kbit/s
Another important part of our project was the safety of our design. For our purpose this meant not having any exposed wires that could short, or any exposed edges that could cut the user. Our solution to this problem was developing the 3D printed casing that can be seen in the various images above. Finally, because we were using bluetooth, we wanted to ensure that our use case did not interfere with anyone else’s work or get affected by anyone else's work either. Since we used a prepackaged module, we were able to confirm that our use of Bluetooth avoided any issues by following the correct standards which are described in the standards section below.
Overall, our final system design worked very well, much in part due to the adaptations we made throughout the development process. We successfully constructed a smart station with a great deal of functionality that brings together a combination of useful environmental sensing tools and entertainment options. Although the smart station had a slightly different array of sensors than we had originally intended, we think that the addition of the NeoPixel LED ring with microphone really helped bolster the appeal of our project. One of our greatest strengths when creating this device was our willingness and ability to quickly adapt to new ideas and recognize that changes would result in a more put-together system and overall, better final product.
Even so, there are still plenty of opportunities for further improvement. As previously mentioned, the new 3D printed case design would allow for a more polished look requiring less ad hoc fixes to be made. In addition, one could utilize the RN-52 even further to control GPIO pins on the audio module. Furthermore, we could multiplex the audio output to the speakers to play soundbytes stored in the PIC32’s flash memory that could alert the user whenever the sensor ranges are out of specified thresholds. Another possibility would be to have the PIC receive information from the RN-52 rather than just send UART commands to it. It may be possible to read in information about the currently playing song and display that information on the TFT display. Lastly, with additional time we might have explored the option of using a different Bluetooth module to allow the user to get phone alerts whenever sensors read values outside of specified thresholds, as well as to set the thresholds remotely. Generally speaking, the improvements to explore for this system would be additional data transfer between the Bluetooth module and PIC32 to encode more information to control functionality of the Smart Station.
One of the standards which we had to conform to was that of the I2C protocol in order to talk to our vast array of sensors. In developing our I2C code for these sensors we had to ensure that all of our devices were communicating at the same data rate (100 kbit/s), and that every non terminating message was responded to with a nack, and every terminating message was responded to with an ack. We also had to conform to the various sensor requirements and modify our communication protocol so that our PIC32 would follow the sensors standards for communication as well. These standards were all found in the sensor datasheets that can be found in our appendix below.
The Bluetooth 3.0 RN52 Bluetooth Audio Module used in this device has been certified by Bluetooth SIG and the Qualified Design ID is 58578 and the Declaration ID is D023391. The module operates in the 2.4-2.48GHz frequency band, as required by Part 18 of the FCC rules. The device has a maximum RF transmit power of 4dBm, and is classified as a Class B digital device, pursuant to part 15 of the FCC Rules. The official Bluetooth SIG Qualified Design Listing Certificate for this device can be found in the appendix.
With the continuous growth of the Internet of Things (IoT) space, environmental sensing and small technologies under this application are becoming more commonplace. Various companies create sensor modules that perform actions such as reading in temperature or humidity and giving an alert when these values are out of ranges. For example, the Life Smart Environmental Sensor, which reads in temperature, humidity, and luminosity values but, unlike our smart station, does not measure acceleration or contain entertainment features such as the ability to play music or show reactive lighting. Other technologies, such as the JBL Pulse 3 speakers, offer this functionality with Bluetooth music streaming and pulsating LEDs on the speakers, but are incapable of environmental sensing. The system that we have built has many commonplace electronic components that can be incorporated in many different products, as evidenced by the previously mentioned commercial technologies. Our system is overall very simple but also effective. It is built to explore various wired and wireless protocols and sensors on the PIC32 architecture, which none of us had experience with prior to this course. Our specific combination of technologies and peripherals is much more expensive than products you might find available in commercial markets since cheaper, more advanced, and more integrated technologies have since taken their place. Most of the sensor technologies that we set out to include were much simpler and referenced example libraries written for educational and hobbyist purposes. Lastly, the hardware and industrial design for this project was created without any other references. As a result, we are certain in saying that we are not infringing on any other intellectual property or patents. Our project has common electronic elements that have open source guides which have been referenced, and we have put together the system in our own unique way with a host of firmware and user interface enhancements to integrate everything together.
During the process of working on this final project, we maintained our integrity and upheld the IEEE code of ethics. As per the code, we strived to better our own knowledge and improve on existing technologies by creating a novel use for this microcontroller architecture with an assortment of peripherals. During the process of building the system, many guides and online resources were utilized during the software and hardware development. These resources have been listed in the appropriate appendix as to properly give credit and reference for individuals who may want to recreate or improve upon on our system. In addition, we sought out criticism for our project. As we went through the weeks leading up to the submission, we completed status reports and had conversations with teaching assistants about the progress of our Smart Station. During this time, we took in feedback about the complexity of different sensors and integration with the PIC32 architecture given their past experience working with this system. Furthermore, throughout this whole project, we’ve maintained friendly and professional interactions with our professor, teaching assistants, and fellow peers. We have been fortunate enough to receive a great deal of advice and guidance when constructing this device, but at the same time have been able to offer up our knowledge to our peers. Whether their projects were directly related to ours (i.e. utilizing the same communication protocol) or simply when other groups had questions that we could answer using our past experience and knowledge of hardware design, we were always welcoming and willing to give a helping hand. Finally, as explained in the Intellectual Property Considerations section, we uphold other’s intellectual property by not only ensuring that we do not infringe upon any existing patents, but also by citing all relevant guides and sources used to create this project.
The RN52 Bluetooth Audio Module used within this project has received Federal Communications Commision CFR47 Telecommunications, Part 15 Subpart C “Intentional Radiators” modular approval in accordance with Part 15.212 Modular Transmitter approval. In other words, the end user can integrate the RN52 Bluetooth Audio Module into a finished product without having to obtain subsequent and separate FCC approvals for intentional radiation, provided that no additional changes or modifications have been made to the module’s circuitry, as is the case with our final product design.
The RN52 Bluetooth Audio Module has been tested and found to comply with the limits for a Class B digital device, pursuant to part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy, and if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:
Note: To satisfy FCC RF Exposure requirements for mobile and base station transmission devices, a separation distance of 20 cm or more should be maintained between the antenna of this device and persons during operation. To ensure compliance, operation at closer than this distance is not recommended. The antenna(s) used for this transmitter must not be co-located or operating in conjunction with any other antenna or transmitter.
"The group approves this report for inclusion on the course website."
"The group approves the video for inclusion on the course youtube channel."
The total spendings for this project were $124.60 of our $125.00 budget.
|Item||Acquired From||Quantity||Unit Price ($)||Total Price ($)||Notes|
|TFT LCD Display||Lab||1||10.00||10.00|
|SIP or Header Sockets/Plugs||Lab||130||0.05||6.50|
|Humidity and Temperature||Sparkfun||1||6.95||6.95|
|Accelerometer||Sparkfun||1||7.00||7.00||Purchased years ago on discount|
|Neopixel RGB LED Ring||Adafruit||1||7.50||7.50||Purchased years ago on discount|
|Audio Bluetooth RN-52||Sparkfun||1||44.95||44.95|
All the available code for this project may be downloaded with the link below.Smart Station Code
Timothy Braren - Responsible for user interface design and bring up of peripherals, namely the TFT screen and multiplexer controlling the Keypad. Integrated the system with the RN52 Bluetooth module. Created the Finite State Machine controlling the project.
Dhruv Gaba - Designed all hardware components from the 3D printed enclosure to the perf board. Integrated and assembled all sensors, peripherals, and internal modules into a compact form. Created initial GUI screens. Compiled and formatted the website.
Shaurya Luthra - Primarily focused on sensor and neopixel bring up. Created new libraries with modular code allowing for ease of use of all I2C sensors and the NeoPixel LED ring. Created the feedback loop for the microphone to the LED Rings for the music display.
The datasheets below describe the technical details of each of the electronics componenets utilized in the projectCapsule Microphone Microphone Amplifier Multiplexer Accelerometer Audio Bluetooth Module Temperature and Humidity Sensor Luminosity Sensor RGB Neopixel RN52 Bluetooth Certificate
The references below are to online resources that helped provide code examples and hook up guides for sensors, helped reference proper methodology to configuring sensors, how to build different hardware, inspiration for our project, and finally the template used for this website.Temperature and Humidity Sensor Luminosity Sensor RN-52 Bluetooth Module Accelerometer Neopixel LED Ring Microphone Amplifier TFT Display and Keypad Assembly of small board housing PIC32 Chip LifeSmart Environmental Sensing Unit Website Template