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.

Carson’s Status Report for March 23rd, 2024

Progress

This week, we assembled and tested our prototype PCB. I did most of the testing to confirm that the new board worked, including determining how to use a Raspberry Pi debug probe to flash code to the new board as well as rewriting the code to work with the changed pin assignments.

Some notable things I discovered while testing included the SD card connector being inconveniently backwards, the display pins being inverted (which we fixed by rotating the display around), and there was a noticeably longer time to get a GPS fix than there was using the breakout.

Pacing

The fact that the PCB functions is very good news; though this deviated from the original plan we now can start measuring energy consumption and checking for the accuracy of the GPS fix. I still have not gotten energy harvesting measurements, but now that we have a more concrete setup it should be easier.

Planning

Next week, I will:

  • Finally determine the energy harvesting scheme we will use
  • Start design of the final PCB

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.