Team Status Report for 06 April 2024

We have no new risks that we are worried about, nor are there any changes we have made to the design of the system.

We have run some tests on GPS location accuracy, walking around CMU campus in various conditions and testing to see how long it takes to get a lock and how accurate this lock is. For accuracy, we will compare Landhopper’s location fix against a known-good and known accurate position source, a U-Blox ZED-F9P (which we will borrow from Roboclub). The ZED provides very high-accuracy and high-precision RTK-GPS position fixes, accurate down to a few centimeters, so it is an ideal “ground truth” for comparison.

As for actual cases we will test, we want to experiment with various positions for the antenna on the wearer’s wrist to determine which results in the most accurate fix. Simultaneously, we hope to test the amount of battery taken to get a fix, as well as the amount used in typical usage by logging the battery levels along with each location store. We hope to be able to analyze both of these results in order to meet our use case requirements of a week-long hiking trip with high-fidelity tracking, by synthesizing the position data from Landhopper with the power consumption data and visualizing it with QGIS.

Through the course of the project, we have done much analysis to see what energy harvesting source we should use. Though we tried several times to figure out the best way to attach the piezo tiles to a metal band, they always popped off of the band when it was bent to the necessary curvature. We’ve gone through a few versions of the gearbox for the motor generator option, but all of them have either. At the current stage, we’re thinking of cutting our losses on the piezo option, but we’re still going to give the motor option one or two more iterations. If we get it to the point of generating any amount of useful power, we’ll definitely give it a proper comparison against the solar option by determining which harvests the most energy in both indoor and outdoor scenarios.

Solar harvesting is showing to be very fruitful so far: the 15mA we have achieved from full sunlight far outpaces the maximum power generation given in our referenced papers for the piezo and motor techniques (the most given was around 9mA). We will further test with different orientations and positions of the solar panel on the watch case (like with the antenna) to determine which results in the most power generation outdoors. We’ll visualize this data alongside the position and other parameters to make sure we’re meeting our planned requirements.

Twain’s Status Report for 06 April 2024

Between last and this status report, I helped with attaching more pieces to the circuit board, and I also soldered together resistors to be fine tuned for our energy harvesting purposes.

My progress is on schedule.

Next week, I hope to help with the firmware more.

Carson’s Status Report for March 30th, 2024

Progress

This week I was very busy with preparing Robobuggy for rolls, so I didn’t have much time to spend on this project. I mostly made some tweaks to the map and worked on updating the HAL (hardware abstraction layer) library we use to a later version so that it was compatible with the SD card library, so that we can start working on adding map tiles.

Pacing

We are somewhat behind on overall progress, but we have a really strong set of features for the demo. Fortunately we can have some asynchronous tasks (i.e. having the next PCB be ordered while we work further on firmware).

Planning

Next week we will do final preparations for interim demo (real energy harvesting numbers, demo firmware, etc).

Gary’s Status Report for 30 March 2024

Progress

This week was yet another firmware refactoring adventure, this time in pursuit of getting the SD card working. The reason this required refactoring was because of how Rust handles sharing of objects, specifically sharing the SPI interface handle. Previously, the entire SPI bus was a single struct which was solely owned by the Display struct, but the issue is that this provides no way for the display to share the SPI bus with the new SD card handler, which also needs to use the same bus. The solution to this comes in the form of a whole lot of refactoring: Carson ported the hardware abstraction library to a newer version of the standard HAL interface which will allow (somewhat clunkily) sharing the SPI bus, and I began working toward integrating this with our code, which ended up requiring modifying several of the libraries we use (the reason for this mostly boils down to the libraries using an old implementation of Mutex which had been superseded).

Planning + Pacing

Tomorrow, the plan is for me to work (possibly with Carson) on finally getting the SD card working. I don’t have any other homework urgently pending so I think this is totally doable to get it done by the interim demo. Adding the SD card will allow us to demonstrate location logging and dynamic map loading: those features should be straightforward to implement once the memory card itself works.

Team Status Report for 30 March 2024

This week was mostly all about firmware changes: we implemented the ability to switch between a watch face and a map on the screen using the buttons, and made more progress toward getting the SD card up and running.

We have no new risks that we are worried about, nor are there any changes we have made to the design of the system.

Twain’s Status Report for 23 March 2024

Between last and this status report, I worked on the PCB and attached all of the parts that we had that were needed for the PCB.

My progress is on schedule.

Next week, I hope to put in orders for more parts and start to work on more of the mechanical aspects of the watch.

Gary’s Status Report for 23 March 2024

Progress

This week, I helped Carson and Twain assemble our dev board (I mainly did the through-hole components), and spent a while working with Carson to get that board working as well as our breadboard prototype. I also worked on getting our microcontroller’s real-time clock working, and got it to the point where we have a working clock and calendar but was unable to get the wakeup timer working… this should be fine, but it’s a bit irritating (the library we’re using follows the wakeup timer initialization routine listed in the manual to a T, but it loops endlessly waiting for something to start).

Also, I worked with Carson to get a very basic map drawing program working! This uses data we processed from OpenStreetMap, and uses the standard Web Mercator map projection. The projection of the lines from lat/lon into Web Mercator coordinates happens when we process the raw data, and then the watch just transforms this to screen-space coordinates. Currently the map data is just stored in flash, but this is temporary (I’m gonna get the SD card working soon)

Pacing

I’m about on pace.

Planning

Next week, I want to improve the mapping mainly: goals are getting the map to center on the current location (and show a marker), and get the SD card working for logging and loading map data.

Team Status Report for March 23rd, 2024

This week, we assembled and tested our prototype PCB. Twain did the initial SMD components, Gary assembled the through-hole components, and Carson modified the software to fit the new layout and did the testing. Fortunately (and maybe surprisingly), we were able to confirm that all of the board functionality that we wanted worked, including:

  • The debug/programming interface
  • The GPS module
  • The display
  • The low-power external crystal oscillator
  • The energy harvesting (not integrated)

There were a few layout problems that can be fixed in the finalized PCB, but this was still highly successful. Below is an image of us testing the new development board outside, showing both a successful GPS fix and the functioning display.

Carson’s Status Report for March 16th, 2024

Progress

This week I helped write some of the asynchronous backend code for the firmware (along with Gary) and did some preliminary energy harvesting tests with the solar panel. For the energy harvesting, I did some measurements of the solar panel to see if it would be viable. We purchased a solar panel small enough to fit on the band of the watch (23mm x 25mm) and tested it outside with a variety of resistances to find the optimal range for power output. Unfortunately, the weather was changing too quickly to do a complete test, but all measurements showed at least 5mW of power output, and one showed above 15mW. These numbers are incredibly high, and give us a considerable margin for losses should we decide to use a panel. To further test this idea, I built the ADP5090-based boost converter circuit and used it to power an LED. Simply pointing my phone’s flashlight at the solar panel from ~10cm away was enough to power the LED intermittently. This was very impressive. Again, I will need to do more thorough tests in the future, but this is a promising power source.

Pacing

This week I would’ve liked to get some more quantitative measurements of more sources, but I was very busy with other obligations. Next week I don’t have much to be working on, so I should be able to catch up on the testing.

Planning

Next week, I will:

  • Finish the measurements of the motor system
  • Finish the measurements of the piezoelectric system
  • Determine how efficiently the ADP5090 can charge the battery