Posted on

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).

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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
Posted on

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.

Posted on

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
Posted on

Gary’s Progress Report for 16 Mar 2024

Progress

This week, I mainly focused on improving and refactoring our existing firmware code. The core of this was additional improvements to the serial handler: as it’s the only communication channel with the GPS, I want to make sure that channel is as simple reliable as possible. I had several frustrations with the implementation of the channels implementation we previously used for the UART communication… the most severe of these was the fact that it provided no way of “pending” (triggering) the UART interrupt handler while writing a buffer, which is necessary in order to actually get the chip’s UART to transmit from the buffer. To solve this, I worked with Carson to totally re-implement the ring buffer-based channels that are used to communicate between the UART handler and the GPS task. The new implementation provides a clean asynchronous interface to the channel which allows me to move more of my lower-level boilerplate logic out of the main code.

Pacing

I’m a little behind now, since I was planning to start on the mapping this week. However, with the overall codebase improvements I made this week I think that task should go smoother now.

Planning

Next week I plan to finally take my first stab at the map interface, and also to work on improving the firmware’s date/time handling.