Stephen carlson notebook - snowpuppy/augreality GitHub Wiki

Table of Contents Lab Notebook Before this semester First reflective glass prototype Week 1 (8/18) Refined glass prototype Week 2 (8/25) GPS testing Week 3 (9/1) XBee Range Test Initial Schematic Week 4 (9/8) LCD Screen/Raspberry Pi Power Testing Week 5 (9/15) I2C Driver Saga Week 6 (9/22) Week 7 (9/29) Week 8 (10/6) Week 9 (10/13) Week 10 (10/21) Week 11 (10/28) Week 12 (11/3) Week 13 (11/10) Week 14 (11/17) Week 15 (11/24) Week 16 (12/1) Week 17 (12/8)

Meetings

• 4/24/2013 (2 hours): First meeting
• 5/9/2013 (2 hours): Second meeting
• 6/23/2013 (2 hours): Third meeting
• 7/7/2013 (2 hours): Fourth meeting
• 7/21/2013 (2 hours): Fifth meeting
• 8/4/2013 (1 hour): Sixth meeting
• 8/18/2013 (2 hours): Seventh meeting

Accomplishments

• Hardware Research
• STM32F4 basic initialization code b806beb
• First reflective glass prototype
• GPS NMEA data parser for latitude and longitude
• Basic Kalman filter for 9-DOF unit

• Learned how (not) to cut glass properly
• Glass has antireflective coating and therefore is sensitive to which side is up
• Glass sourced from this site

(larger)

Summer Work Total: 20 hours

Project Work Total: 20 hours

Individual Meetings

• 8/22/2013 (1 hour): HW0 Project Proposal completed
• 8/24/2013 (4 hours): Test XBee devices, set up lab notebooks

Accomplishments

• Refine reflective glass prototype
• HW0 Project Proposal
• Prior art research
• Initialize this lab notebook

Installed GPS, IMU, and processing units + battery and antenna onto earlier prototype. Used off the shelf Arduino clone similar to proposed microprocessor design (Maple).

This particular display has low dpi and low surface brightness (it's a 362 leftover). Tried with a TFT display on an oscilloscope, details come through fine but brightness can still be a problem. May need dark cover (baseball cap, helmet) in bright sun to see image effectively.

(larger) (larger) (larger)

Weekly Work Total: 5 hours

Project Work Total: 25 hours

Individual Meetings

• 8/29/2013 (1 hour): HW1 Final Project Proposal completed

Accomplishments

• GPS data parser to retrieve GPS coordinates from Venus GPS module (standardized NMEA) a258f58
• GPS accuracy and resolution testing (see below)
• HW1 Final Project Proposal

GPS track captured below from test unit with production antenna and module. GPS has very high resolution, on the order of feet, and updates at (configurable) 5-10 Hz. Accuracy is generally very good, within 1 meter, but had issues near Elliott Hall when dealing with nearby buildings and tree cover.

(larger) (larger)

Second GPS track with more tree cover was still very accurate, easily superior to a smartphone that was simultaneously recording the same track. Decreasing update rate to 5Hz trades off the lower fix frequency with noise. We need to use the GPS configuration utility to disable "standing still" (position pinning) detection for better response times when changing directions.

Weekly Work Total: 6 hours

Project Work Total: 31 hours

Individual Meetings

• 9/1/2013 (2 hours): Meeting to test range of XBees using elevated platform
• 9/2/2013 (2 hours): Work on Project Specific Success Criteria, describe requirements for preliminary headset schematic
• 9/4/2013 (1 hour): Edited Project Specific Success Criteria
• 9/7/2013 (3 hours): Comparison range testing with larger antennas and 2.4 GHz modules, HW2 PCB Design completed

Accomplishments

• Continued Xbee range testing
• Website update script (477grp5 is now up to date and linked right!)
• TCSP 1 Project Specific Success Criteria
• HW2 PCB Design
• Continued Hardware Research
• Preliminary schematic for headset 55aa7b6

Followed Dr. Robinson's advice to increase altitude of transmitter and tested with one antenna on top of a campus parking garage. Another user with a second XBee walked with line of sight into the Intramural fields. This gained us 50 yards to almost 300 yards. The range is still about half of the "indoor" range and less than 10% of the "line of sight" range.

The orange box in the picture below shows how far we got. Not quite 6 miles, but getting there.

(larger)

Continued tests on Saturday 9/7 yielded no noticeable improvement with a larger, more powerful antenna mounted on the 900 MHz XBee units. Surprisingly, the 2.4 GHz XBee Pro modules gained nearly 100 yards line of sight, even though PAL was likely an interference issue. These units may be used as a replacement, but we are still not getting anything close to the advertised range of 1 mile on the 2.4 GHz modules.

Thor called Digi International and found that elevation is crucial to achieving the advertised range. For example, to get 1000 yards, the antennas need an elevation of 32 feet, which is impractical as this requires an antenna several stories tall. For the advertised range, almost 100 meters of elevation is required. Since the CCU cannot be placed on a skyscraper, the misleading advertised range will not be achievable (nowhere in the datasheet is the height requirement stated for optimal range).

(larger)

First try at selecting and creating parts in EAGLE for this project. Hardware Research updated as some of the parts were discontinued or NRND. This schematic uses the STM32F4 microprocessor and also features a Raspberry PI connector. Thus, it can perform basic rendering on its own using the display headers, or interface with a Raspberry PI for graphics processing.

Weekly Work Total: 16 hours

Project Work Total: 47 hours

Individual Meetings

• 9/12/2013 (1 hour): Tested power consumption of Raspberry PI Model A and composite screen
• 9/14/2013 (4 hours): Continued screen power testing, start I2C and IMU drivers

Accomplishments

• TCSP 2 Design Constraint Analysis / Parts Selection
• HW3 Design Constraint Analysis
• I2C and IMU drivers started

Worked with Steve Ellis to test the Raspberry Pi Model A using the 3.3V rail, and found that it uses less than 500 mA even with the OpenGL demonstration running. Attaching a keyboard adds about 80 mA, but there is no difference when the screen is plugged in.

The LCD screen selected for trials is 5" and nominally powered by 12 V. Instead of a 7805, it uses a buck mode switching power supply, with a second constant current source supply to run the backlight powered by the 5V rail. Clipping the buck mode regulator and feeding it 5V from the VDISPLAY line on the schematic will operate the screen without issues. Power consumption is unfortunately unchanged even at the lower brightness settings, so maximum settings will be used to increase the surface brightness of the display.

Weekly Work Total: 16 hours

Project Work Total: 63 hours

Individual Meetings

• 9/16/2013 (0 hours): No work for next four days due to Industrial Roundtable and associated interviews.
• 9/21/2013 (4 hours): Work on packaging and data formats, work on USART and I2C/IMU drivers

Accomplishments

• I2C and USART drivers completed 4de0cad, interrupt mode (not DMA)
• Found several issues with the pinouts on the STM32Discovery board

Created the I2CExample test project in GIT and copied the example STM32F1 driver for I2C, but things did not go smoothly. I2C initially refused to work. Two hours of debugging managed to fix the problem, which was a combined cause of interrupts not being properly enabled, the BUSY flag not being checked, and several other issues. Then, the data was garbage, so we needed to debug the data onto the PC.

Initial attempts to use USART1 and PA9 to send the data back ended in framing error failure. An investigation into a wrong crystal frequency setting in the .a files went nowhere. But a schematic investigation of the Discovery board found out that PA9-PA13 were used for other things and thus would not work for this purpose. Switching the serial port to PB10 got us what we wanted.

The final cause of the garbage data was that the STM32 built in pullups were far too weak, unlike the STM32F1 which can work fine on its built in I2C pad drivers. Adding two 4.7k pull ups worked fine at 200 KHz and were OK at 400 KHz as well. These are on pins PB6 and PB9 of the discovery board but need to be added to the schematic!

(larger) (larger)

It works! Note that the LEDs in the center of the Discovery board change color based on orientation proving that the sensors are working properly.

Weekly Work Total: 7 hours

Project Work Total: 70 hours

Daily Log

• 9/23/2013 (6 hours): Much of the day was spent on a better update script that converts this transcript to EXACTLY the html requested by the course staff. Long live github and ruby-fu.
  (larger)
  Old SIGBOTS Robotics repository files were searched through to locate some Kalman/IMU drivers used for the same I2C device set last year. Had a meeting with Alec to get his STM32F4 Discovery board compiling and executing code
• 9/24/2013 (1 hour): Lab notebook capture script was updated to comply with teammates' lab notebooks (to as much of an extent as possible). Thor's notebook is passing, but Steve Ellis and Alec Green still need to add dates and content.
• 9/25/2013 (3 hours): A meeting occurred with Alec Green to work on schematic TCSP and report. Several issues were clarified with theory of operation involving the power management section, including the power dissipation of regulators and the separation of power rails.
• 9/26/2013 (4 hours): A meeting occurred with Thor Smith to work on parts ordering. Updated the Hardware Research page to compensate for parts that can actually be sampled. Worked on schematic revision 2 6005c4f:
  (larger)
  • Substituted 1206 components for 0805 footprints to avoid ordering passives
  • Added I2C pull-up resistors
  • Adjust port mapping selection for better PCB routing later
  • Exchanged the MIC5216 for MIC5219 to allow samples ordering
  • Readability improvements
• 9/28/2013 (4 hours): The debug connectors were modified on schematic revision 2, and status LEDs and breakout vias were added on critical signals. PCB revision 1 was placed and routed. For a first route this went surprisingly well, with good power/ground plane coverage from all directions, only a few vias under the chip, and surprisingly good power distribution:
  (larger)

Accomplishments

During this week, the lab notebook update script was overhauled to match the course format, tag for tag, due to obsessive requirements of the course staff. The schematic was updated to fix several minor issues, and the first PCB place/route was performed.

Weekly Work Total: 18 hours

Project Work Total: 88 hours

Daily Log

• 9/30/2013 (2 hours): A meeting occurred with Blaine during consultation hours regarding initial PCB design. The following issues were fixed:
  • Impedance matching on oscillator (within 0.1mm) was improved
  • Impedance matching on USB (within tolerance of 1.25mm described in http://www.cypress.com/?docID=32407 ) was considered
  • Two acute angles were modified
  • GPS headers were reversed
  • Mini USB plug was moved closer to the board edge
• 10/1/2013 (5 hours): The PCB silk screen was overhauled to label everything (including switch positions, LED meanings, and peripheral locations) and fixed the spacing of the GPS headers. Two weakly connected ground plane islands were adjusted for better connectivity.
  (larger)
  TCSP 05 and Homework 06 were started.
• 10/2/2013 (2 hours): Several small revisions were made to TCSP 05. Talked to Thor Smith about parts ordering and found out that we can get the MAX17043 after some smooth talking to Maxim Semiconductor. Talked to Steve Ellis about battery selection and concluded that https://www.sparkfun.com/products/8484 was favored for its smaller form factor over competing 18650 cylindrical cells (see image detail) which made it fit in the current packaging design much better. The team also selected and ordered all the remaining passives, connectors, and batteries as shown on Hardware Research. Once the final parts arrive, a 1 to 1 test on the PCB will need to be completed, and the eval board for the MAX17043 will need another I2C driver.
  (larger) SparkFun prismatic vs. (larger) Adafruit 18650
• 10/3/2013 (3 hours): Homework 6 was completed and submitted. The crystal oscillator footprint was modified to a through hole component to match parts availability (see image detail). While completing the homework, realized a potential issue with the schematic where the RSSI pin on the XBee probably should be connected to an input capture pin on the STM32F4 if we decide to use transparent serial mode instead of API mode.
  (larger)
• 10/4/2013 (0 hours): There will be no work for the next three days due to October Break.

Accomplishments

During this week, the headset PCB ec71d78 was almost completed, with the routing done and the silkscreen nearly complete. The remaining parts for the headset PCB were ordered, including connectors, batteries, and oscillators as shown on Hardware Research. TCSP 05 PCB/Layout Narrative e09bb29 and Homework 06 90c9c9f were also completed.

Weekly Work Total: 12 hours

Project Work Total: 100 hours

Daily Log

• 10/7/2013 (2 hours): The RSSI signal was added to the PCB on pin 15 (PA1/TIM5_CH2 Input Capture) and several silk screen aids were added, including markers for the spare RX/TX and signal names for each signal padded out to vias. Therefore, we can still use Transparent Serial mode and use the STM32 Timer capture modes to determine the signal strength simultaneously without code intervention.
  It was determined that the BOOT0 signal needs to be held high to load code from USB, so a second push button switch BLD was added to enter USB DFU mode next to the RESET button. This location makes it easy to use one finger to press both buttons at once to enter upload mode. Work was started on slides and notes for the PCB section of the Design Review, including screenshots without copper fills. While the PCB 1 to 1 still needs to be done upon return to Purdue, the PCB should be ready to go out once that passes.
  (larger)
• 10/9/2013 (2 hours): A meeting occurred with Dr. Johnson discussing the future Cornell Cup applications for our senior design project. The application deadline is October 17th, so the next week will need to be dedicated to Cornell Cup entry submission due to the relatively early schematic and PCB completion.
  A meeting occurred with the entire team. The PCB was tested 1 to 1 and every component that was available (the battery is still in shipping) passed with flying colors.
  (larger) (larger)
• 10/10/2013 (3 hours): A meeting occurred with the entire team to work on the Design Review presentation. The slides were put together and a trial run was conducted.
  The course staff looked at the team's PCB and suggested an increased clearance on the power and ground planes to reduce the chance of accidental shorts. The clearance was increased from the default 8mil to 12mil which should improve manufacturability. This change required a re-route of a few traces and the addition of two more vias.
• 10/12/2013 (3 hours): A meeting occurred with the entire team. The batteries were received and tested to fit the PCB level connectors and fuel gauge evaluation board. Significant re-organization of the parts area was also completed to make parts easier to find.

Accomplishments

During this week, the headset PCB was completely routed, with only a few missing silk screen issues preventing it from fabrication. The Design Review presentation was also completed and presented to the course staff.

Weekly Work Total: 10 hours

Project Work Total: 110 hours

Daily Log

• 10/14/2013 (4 hours): A meeting occurred with Thor Smith to work on the Cornell Cup application for the future continuation of this project into next semester. The changes to the processing and graphics were heavily discussed, and a conclusion to remove any explicit "central control unit" references was reached to avoid constraining the device into needing a separate control device. In addition, the Cornell Cup-specific performance metrics for the device were modified to include specific targets for mass and battery life.
• 10/15/2013 (3 hours): Work continued on the Cornell Cup application. A functional block diagram was created of the system as it will appear after the changes to the Intel motherboard, including a switch from purely hardware to include software components. A draft of the application was also submitted to Dr. Johnson for review.
  During the design review makeup, the team learned from Joe that it is safe to ignore the bake and humidity warnings when hand soldering moisture sensitive parts. Since a reflow oven will not be used, there is no chance to boil water accumulated in the chip which could cause a steam explosion. Therefore, it is safe to remove the microcontrollers from their packaging for PCB one to one testing before soldering if done by hand.
• 10/16/2013 (4 hours): A progress report was given to the course staff, and the microcontroller was fitted one to one with the PCB. Additional work on the Cornell Cup application also occurred, with significant updates to the solution and performance metrics referencing a more specific use case as suggested by Dr. Johnson.
  (larger)
  Work occurred on the packaging and optics assembly, with the reflective acrylic being re-plated with the privacy film in a much smoother manner. While the methodical peel approach did much better on smoothness of surface, the uneven tension pressure on the film created varying thicknesses, leading to colorful interference bands. More even, careful pressure needs to be applied when the film is re-done.
  (larger) (larger)
• 10/17/2013 (4 hours): Final work on the Cornell Cup application was completed, with the signatures scanned and the application submitted on time. A meeting occurred with the entire team, with Steve Ellis bringing in a Fresnel lens for re-focusing testing. After adding this lens at the bottom of the dark box, the image was magnified to greatly increase the field of view and slightly improve focusing. Possible future attempts include moving the lens closer to the screen to experiment with adjusting the focal distance.
  A mounting hole was added to the PCB at the correct location to match the Raspberry PI mounting hole. The PCB was also checked on FreeDFM without errors and submitted for fabrication to Joe. Hoping for success...
  (larger)
• 10/19/2013 (3 hours): A meeting occurred with the entire team. During this time, the OpenGL demo was modified to work with the framebuffer size of the Raspberry PI, and successfully displayed a flying cube which bounced around the screen. Focusing on the moving object is still a challenge, but the depth perception of the object when compared with the background is surprisingly good.
  (larger) (larger)
  The boot screen of the Raspberry PI was also customized to a large degree to eliminate the wall of text which scrolls by at implausible speeds during the loading process. A custom splash image, shown in the picture, replaces the text boot sequence. Further work will involve actually changing the image to an appropriate one, and fixing problems with switching back to the regular UI.

Accomplishments

During this week, the Cornell Cup application was completed and submitted on time. The packaging for the design was also improved, with resurfaced reflective glass and a magnification system substantially boosting the visibility of the virtual image. Work was also completed on rendering moving images on the Raspberry PI's display screen oriented properly for the headset display.

Weekly Work Total: 18 hours

Project Work Total: 128 hours

Daily Log

• 10/21/2013 (2 hours): Code clean up was started for the "example" projects in the testing directory to increase code readability and quality. A tutorial was also created to help the last two team members set up the development environment for the microcontroller on their computers. Future work to make the upload process work on Linux, and to hook up a debugger, will be necessary before embedded development can start in earnest.
• 10/23/2013 (4 hours): Effort began to have the microcontroller debugging and SWO (serial wire output) operational to ease development. SWO allows printing of debugging information without the use of an external serial port, to reduce the effort required to connect the device to a PC during testing. During this exercise, it was discovered that the microcontroller cannot be debugged during its power save modes, unless a bit is set in the Debug registers. In addition, the ITM (instrumentation trace macrocell) needs several configuration bits set in a few different registers to unlock it and output the data in the correct format.
  (larger)
  Once this is working, the next step will be to make printf() and other standard I/O functions work properly over the SWO bus, and to get breakpoints/single-step operating. The printf() viewer built into the manufacturer provided ST-LINK Utility (shown in the picture) will be very useful to avoid additional hardware requirements for viewing program output while debugging.
• 10/24/2013 (2 hours): The I2C fuel guage (MAX17043) was connected to the STM32F4 discovery board and tested. After a few attempts, battery voltage and state-of-charge (SOC) data was retrieved from the Maxim chip. Tests with the Agilent volt meter confirmed that the voltage reading was well within the datasheet's tolerance of 5 mV (0.005 V), but further testing is required to verify that the SOC estimate is correct. Charging and discharging of the battery will need to be performed while the fuel gauge is connected and powered.
  (larger) (larger)
  During development of the fuel gauge code, overflow errors occurred on the ITM print return line (SWO) that dropped data after about ten characters set. It was determined that the buffer on the STM32F1 chip inside the ST-LINK v2 programmer was being filled too quickly. After online research, writing a divider value to a poorly-documented asynchronous clock speed register successfully allowed all characters to be sent, so printf() now works over the SWO bus reliably. Further work to get breakpoints working consistently without lock ups is still required.
• 10/26/2013 (3 hours): Continued work to exercise the fuel gauge was performed, with the battery charged using a lithium-ion compatible charger at 1 A with the fuel gauge chip continuously monitoring the charge, along with the voltmeter for comparison. Once again, the voltage reading was well within the stated 5 mV tolerance of the actual voltage, a difference likely also influenced by voltage drops across cables. The test setup is shown below:
  (larger) (larger) (larger)
  The chart shown above, a subset of the charging graph (the complete charge sequence with this charger and a 6000 mAh battery about 50% full would take over 4 hours), shows that the chip is magically capable of sensing a slowly increasing state of charge (the state of charge is reported to the nearest percentage point, thus the step on the graph) even though the voltage is essentially constant and no current sense resistor is used. This phenomenon demonstrates that our project can successfully monitor the estimated battery state of charge.

Accomplishments

During this week, a substantial amount of code for the microcontroller was written, including drivers for the ITM macrocell and I2C fuel gauge, while the PCB is being fabricated. In addition, work was done to simplify microcontroller-level coding, with code cleanup of unnecessary code, better code documentation, and improvements to debugging. The fuel gauge chip was tested and found to be able to track the battery state of charge while charging.

Weekly Work Total: 11 hours

Project Work Total: 139 hours

Daily Log

• 10/27/2013 (0 hours): There will be no work for the next two days due to exams and a phone interview.
• 10/29/2013 (3 hours): The microcontroller SPI slave driver was written and tested to work with the Raspberry PI using the same SPI (SPI3) and pins (PC10-PC13) allocated on the PCB. After a few false starts where the SPI peripheral was disabled and interrupts were set up incorrectly, the code worked in interrupt mode with few issues at a 4 MHz bit rate.
  Test setup: with oscilloscope (larger) and with Raspberry PI (larger)
  Waveforms: (larger) (larger); the Raspberry PI handles NSS for us!
  It was found that the Raspberry PI WiringPI library works in SPI Mode 0 (CPOL 0 CPHA 0) by default with the MSB first; these settings must be duplicated on the STM32F4 for compatibility. In addition, it was determined that the data to be sent in response to a given byte on the SPI port comes out two bytes later, as the data is first loaded into a buffer and then stuffed into the shift register. Therefore, two padding bytes will need to be inserted, or data will need to be loaded into the shift register in advance of the command being received, when the SPI packet communications protocol is written.
• 10/30/2013 (4 hours): The PCB was received and soldering of parts began. The power supply was installed first to allow an overnight burnin period to reveal any faulty parts up front.
  (larger) (larger)
  During power-supply burn-in on a resistor box using the test setup shown below, the IMU regulator was found to be under voltage. A hair-line short was found on the PCB near IMU pin #1 that was causing a low impedance on that supply line; a trip with the utility knife fixed the problem.
  (larger) (larger)
  All three main power supplies was within 5% of the nominal voltage as specified in the datasheet. However, the IMU regulator was still 300 mV under. Replacing the part did not completely resolve the issue; as 3.0 V will still work, the issue will be revisited later.
  (larger)
  Further work after burn-in involves soldering the microcontroller and beginning peripheral testing.
• 10/31/2013 (7 hours): The microcontroller and supporting components were installed, including decoupling capacitors and the Raspberry PI header. Several hours were spent debugging a failure of the microcontroller to start altogether, with no responses on I/O pins and no core voltage on the decoupling capacitors. Changing the capacitance value of the decoupling capacitors did not resolve the issue. However, the under-voltage analog regulator was eventually fixed by resoldering a cold solder joint, at which point the microcontroller core regulator turned on! The brown-out detector was likely engaging due to the large voltage difference causing current back flow.
  Afterwards, the microcontroller responded to serial boot loading, but the USB code loader did not work. The oscillator was inspected using an oscilloscope, and it was revealed that the oscillator did not start. Replacing the 22pF load capacitors with 39 pF capacitors fixed the issue. During this exercise, it was learned that the capacitors installed on an oscillator must be twice the "load capacitance" in the datasheet due to the equivalent 2-capacitor series capacitance being 50% of the nameplate value.
  Lastly, the fuel gauge was attached. However, several attempts caused either short circuits or floating/dodgy pins. As of the end of this day, the fuel gauge was still not working consistently, and will be the next item addressed before the radios are installed.
• 11/1/2013 (6 hours): A meeting occurred with the entire team to work on the PCB and getting software to start up. After a fresh start, another attempt at fixing the fuel gauge caused a pin to break off. Refusing to give up, a piece of wire wrap was used to replace the pin, with low chances of success. Stunningly, it worked, and the fuel gauge responded with beautiful values using the test code in the repository. The repair is shown in the lower left corner below as the piece of black wire, which was later snipped down to size.
  (larger)
  Next, the Raspberry PI stacking was tested, both to ensure that the Raspberry PI could start up and to check the SPI communications. It worked perfectly once the Raspberry PI built-in regulator was disabled, and we were able to see the impact of running GPU code on the battery voltage and state-of-charge using the fuel gauge.
  (larger)
  The peripheral headers for the GPS, XBee, and IMU were attached, and each peripheral was tested in turn. Everything worked on the first try, with the modified sample code to match the pin assignments on the actual board.
  (larger)
  Future work will involve creating the program to fetch meaningful data from each sensor, and to integrate the wireless protocol and sensor filtering onto the microcontroller. Much was learned about the importance of careful PCB layout and good design reviews, as the PCB worked without faults. Personally, I am 6-for-6 lifetime on first time PCB functionality
• 11/2/2013 (4 hours): A meeting occurred with the entire team to work on getting actual data values. The team took the PCB outside with the GPS antenna and took another sample GPS track. The results were then copied to the Raspberry PI GPU and used to display a sample object as it might be viewed over the screen. The object's path was reasonable, with the scaling and noise within expectations. The team also worked on packaging, with the second prototype gaining a PCB enclosure, battery holder, and GPS antenna. As the 3-D printed enclosure is not yet available, a temporary box was used on the helmet.
  (larger) (larger)
  Work also occurred on modifying the LCD display to allow it to be used on the board's 5V supply, cutting off and shorting the switching regulator and inductors used to step down 12V to 5V. A female header was also added to the supply wire to allow it to connect to the PCB. An attempt to work on the RSSI signal strength detection for the XBee did not work, with no input capture events apparently occurring on the microcontroller TIM5 IC2. Further work will involve getting this driver to work successfully.

Accomplishments

During this week, the microcontroller drivers were finished up, with the SPI communications driver tested and committed. The PCB also arrived and was fully populated, with the microcontroller, power supply, all peripherals, and the battery charger/fuel gauge all checking out successfully.

Weekly Work Total: 24 hours

Project Work Total: 163 hours

Daily Log

• 11/4/2013 (3 hours): A meeting occurred with Thor to work on wireless communication. An issue regarding the packing of structures and floating point numbers was discussed, since attempting to directly transmit a structure may cause results varying on the compiler or platform. It was decided to manually construct and destroy the packets to ensure maximum software compatibility. In addition, the endian nature of floating point numbers and multi-byte integers in packets was also discussed. Little endian was chosen for wireless transmission since all platforms used in the system are little endian.
  The RSSI driver received continued attention, and the issue was finally tracked down to a transposed equals sign in the interrupt routine. Therefore, the RSSI was being correctly calculated the entire time, but it was not being stored in the location where the main program was expecting it to appear, so an erroneous result of "0" was always being returned. The RSSI signal was then measured with the oscilloscope to determine its typical range of values; at full signal strength, it is always high, and if not, the signal is a 73 us period PWM which drops off linearly with decaying signal strength. The PWM period was not equal to the period specified by several sources. The project can now successfully monitor the current wireless signal strength.
• 11/5/2013 (2 hours): A meeting occurred with Thor and Steve to work on the reliability and safety analysis. Potential failure modes for the power supply and charging/fuel gauge components were discussed, including short circuits from power to ground and outputs out of tolerance. Since the independent battery protection circuit will trigger on an over current condition, the device is fairly unlikely to cause a personal safety hazard if a failure occurs, as two failures must occur to allow a high fault current that could cause a fire or explosion.
• 11/6/2013 (3 hours): A meeting occurred with Alec to debug issues occurring with the IMU sensor fusion. The floating point math was causing severe problems, displaying lock ups, crashes, and stack corruption from executing math functions like atan. printf was reconfigured to allow printing of floating point numbers, but the problem could not be reproduced on another computer with the same microprocessor, pointing to potential compiler or library configuration problems with Alec's setup.
  (larger) sqrt(atan(1.0)) = 0.886 on both micro and PC
  The USB to serial driver was also implemented successfully. Although unoptimized, the code works and connects as a "STM32F4 Senior Design" serial converter for easy debugging. Charging is not impeded over USB during this time, and other peripherals still work. In addition, the USB includes and several other files were collapsed into another pre-compiled library, and the source files were moved into an src folder for ease of maintenance. Further work involves optimizing the code properly.
  (larger)
• 11/8/2013 (3 hours): A meeting occurred with Steve to investigate 3-D printing for packaging. A first attempt at printing on the IEEE MakerBot Replicator Dual failed when the extruded plastic warped and blocked the print head. After some advice from the IEEE Computer Society president, the heated bed temperature was increased and the mat was removed. Although the case still came out warped due to uneven bed heating, the case was usable as the PCB and battery still barely fit inside. The GPS antenna port, XBee port, and composite video port were slightly off-position but were close enough to be usable.
  (larger) (larger)
  Further revisions will involve moving the XBee cutout to better match the RP-SMA antenna, additional structural integrity on the top of the box, and increasing the battery compartment width to handle battery expansion during charging.
• 11/9/2013 (0 hours): There will be no work for the next day due to preparation for a robotics competition.

Accomplishments

During this week, the wireless signal strength was successfully calculated and displayed. In addition, the USB to Serial debugging driver was completed and tested in a usable form for printing test information. A workable 3-D printed case was developed after a few false starts for packaging the headset PCB.

Weekly Work Total: 11 hours

Project Work Total: 174 hours

Daily Log

• 11/10/2013 (3 hours): A meeting occurred with the entire team to work on improving the packaging of the headset and central control unit. During this time, the wiring on the headset was significantly improved, with the GPS antenna moved inside the helmet and the screen re-mounted with black electrical tape that leaks substantially less light than the masking tape used before. The reflector was also attached with rigid 14-gauge copper wire that allows walking and running without the screen bouncing either up or down, while still being adjustable by sliding the rod along the rails.
  (larger) (larger)
  The central control unit was also packaged for the first time. A screen modified to run at 5V was attached to the Raspberry PI GPIO header for power, and an XBee Explorer and numeric keypad were mounted to the system for wireless communication and initial user input. With only an antenna and an external USB power supply, the CCU booted up fine. A user account with the name "1000" was created to allow login using only numbers.
  (larger) (larger)
  Further work with the CCU packging will involve cleaning up the rats nest of wires shown in the picture and cutting a hole for the SD card.
• 11/11/2013 (2 hours): Continued work occurred on improving the USB to Serial drivers to reduce their overhead and code size. The code currently being used was based on an example given by the manufacturer which was meant for a slightly different board and expends needless amounts of time in USB interrupt service routines. Optimizations include inlining functions used only once, stripping USB Host functionality, eliminating global variables, and removing dead/duplicate code.
• 11/13/2013 (0 hours): There will be no work for the next two days due to an interview with Texas Instruments in Dallas, TX.
• 11/15/2013 (4 hours): The USB to Serial optimized drivers were completed, with much better integration with the other functions in the communications library, and nearly 3000 bytes combined code and RAM saved.
  (larger)
  Now that this is done, work on the general software will continue in earnest, and the second PCB will be populated once parts come in for multi-user testing.
• 11/16/2013 (5 hours): A meeting occurred with the entire team. Significant progress was made on communicating actual data from the IMU, fuel gauge, GPS, and signal strength meter to the Raspberry PI via SPI. The device was able to display a primitive first 3D object with a real model at a position according to the GPS and IMU position. Tests outside, after getting a good GPS lock, were able to render objects according to the incoming data in real time! Pending some improvements, the project can now display objects depending on GPS and IMU coordinates, leaving one PSSC to go!
  (larger)
  Additionally, work began on soldering a second headset PCB to test collaborative games. With the lessons learned from last time, the fuel gauge was soldered in 10 minutes on the first try, and a second non-warped enclosure for the second headset was also manufactured by a helpful classmate. Initial power supply burn-in revealed no issues.
  (larger)
  Further work will involve finishing up the second PCB, creating a second set of packaging to mount it, and running it through start up checks to verify functionality.

Accomplishments

During this week, the device packaging was substantially improved. The USB to Serial driver library was improved, and construction of the second headset using the additional PCBs which arrived this week also began. PSSCs have been nearly finished up, with the device successfully displaying objects depending on the user's position and head orientation using SPI communication.

Weekly Work Total: 14 hours

Project Work Total: 188 hours

Daily Log

• 11/18/2013 (4 hours): A meeting occurred with Thor and Steve to work on the second device PCB. Due to the need to test cooperative simulations, two headset devices are required; the second PCB was fully populated and tested. Experience from the first PCB allowed the microcontroller to be quickly installed and tested. Everything appeared to check out fine.
  (larger)
  Further work will involve transferring software to the second Raspberry PI unit and creating another head-mounted helmet unit for the second headset.
• 11/19/2013 (6 hours): A meeting occurred with Thor and Steve to work on device packaging and debugging. The second PCB was test fitted into the new enclosure, and everything fit very well.
  (larger)
  Several hours were spent troubleshooting issues which arose when trying software on the second PCB. Latent bugs with the LED pin mode, buffer sizes, and GPS parsing were discovered and fixed. The root cause was finally tracked down to the new GPS and XBee modules not being configured to the correct settings. Further work will involve a re-write of the GPS parser to a stream parsing mode (as opposed to blocking) and setting the proper configuration on the modules.
• 11/21/2013 (3 hours): A meeting occurred with Thor and Steve to work on software. The second GPS module and XBee were configured properly for the new PCB; the XBee took a lot of fighting to program the correct settings. To make this easier in the future, the settings profile was added to the repository.
  (larger)
  In addition, the GPS parser was re-written to parse in a stream mode, never blocking if a partial line is received. Hangs during the main state machine loop were thus eliminated when the GPS does not have a lock.
• 11/22/2013 (2 hours): An issue was reported by Thor with the USB to serial drivers causing a conflict with I2C. After examination, it was determined that the I2C drivers were not at fault and that the incidence was caused by problems with USB to serial sending data when there was nowhere to put it. The code was changed to not fill the USB transmission buffer unless someone is listening, and to drop characters if the buffer is full instead of hanging.
• 11/23/2013 (0 hours): There will be no work for the next two days due to projects for other courses.

Accomplishments

During this week, the device packaging was finalized, with the second PCB fully populated and installed in a new enclosure that fits the components together in a better manner. Its GPS and XBee were also set up to work together with the existing central control unit and headset prototype. Several problems with device configuration and firmware code were found and fixed.

Weekly Work Total: 15 hours

Project Work Total: 203 hours

Daily Log

• 11/25/2013 (3 hours): A meeting occurred with Thor and Steve to work on IMU filtering. The primitive filter implemented by Alec did not even use the gyro, explaining the noisiness and lack of transient response of the yaw axis. A simple complementary filter using just the gyro Z axis drastically reduced yaw noise. Further work will involve accurately segmenting the gyro rotations according to orientation to unrotate the axes like they should. Currently, there are issues with the headset yawing excessively on a roll input.
• 11/26/2013 (2 hours): A meeting occurred with Thor to investigate issues involving the GPS sometimes failing to start. After investigating several potential issues with the GPS parser and serial drivers, the issue was fixed by inserting a buffer clear before the code starts. Apparently the GPS was filling the serial buffer with garbage, somehow preventing parsing.
• 11/27/2013 (0 hours): There will be no work for the rest of this week due to Thanksgiving break.

Accomplishments

During this week, issues with the GPS and IMU were tuned to improve headset performance, especially to ensure a turn key startup. The IMU filtering was also substantially improved in terms of response time and noise.

Weekly Work Total: 5 hours

Project Work Total: 208 hours

Daily Log

• 12/2/2013 (0 hours): There will be no work for the next two days due to interviews.
• 12/5/2013 (3 hours): A meeting occurred with Thor to work out the bugs in file transfer. After extensive debugging, the issue was drilled down to a buffer full of garbage being sent to the headset as "padding" for file transfers. Occasionally, a valid command byte appeared in the buffer, causing the headset to interject unintended data into the middle of a file. Zeroing out the buffer resolved the issue, allowing binary file transfer to successfully complete. Further work involves integrating this code with the graphical headset code to update graphics on start up.
  The headset packaging was also slightly improved, with masking tape replaced with more permanent zip ties wherever possible. As a result, the headset looks better and should survive walking and running without cables coming loose.
  (larger) (larger)
• 12/6/2013 (0 hours): There will be no meetings with the team for the next two days due to interviews. Work on the report sections of the project will occur during this time.
• 12/7/2013 (2 hours): The "Senior Design Report" was completed, describing what we learned from the project and how we used our knowledge.

Accomplishments

During this week, file transfer over the XBee was sorted out. Some elements of the headset packaging were also subtly improved for better appearance and reliability. Some elements of the final documentation were also completed.

Weekly Work Total: 5 hours

Project Work Total: 213 hours

Daily Log

• 12/8/2013 (2 hours): A meeting occurred with the entire team to work on the final report and presentation. Personal sections for the PCB Layout, Design Constraint Analysis, and Individual Contributions were filled out during this time.

Accomplishments

During this week, the final documentation was completed and submitted, including the report and presentation.

Weekly Work Total: 2 hours

Project Work Total: 215 hours