PCB Version 2

Bugs:

• LED control should not have gone on GPIO46. It’s a bootloader pin, and it doesn’t reliably work as a digital output. There are a couple of other unused pins nearby that can be used instead.
• The LED control pin also needs a pull-up resistor because it is active-low. This means that when the ESP32 goes to sleep, the screen will still be on, blank white.
• Green LEDs are way too bright (I see spots in my vision after looking at them). They also get a bit warm. These LEDs are just for debugging.
  • Yellow LEDs could also be a bit brighter.

Things that work:

• The ESD protection diodes on the USB didn’t break it!
• The buzzer works now that a pmos is being used.
• The screen and stuff works after I rewired it.

Pictures of PCB rewire:

Button Debounce Requirements

• Surprisingly, the buttons we are using aren’t that bouncy. After looking at the waveform, it doesn’t ring for more than 10 ms.

GNSS Time Acquisition Testing

• Indoors, and even outdoors, it takes a while (more than a few seconds) for the time to resolve itself.
• When to call the time and date “good”:
  • When gnss.getTimeValid() and gnss.getDateValid() return true, then the time and dates provided can be trusted for our purposes. The only major thing to be aware of is that it doesn’t guarantee leap seconds are correct (which means you have a +/- 1 second uncertainty).
  • Even when this happens, the number of satellites reported seen might be zero.
  • When inside the W3VC radio club near the window, it takes 1-2 minutes on average for the time and date to validate from a cold start. (This is different from simply resetting the MCU/code. When simply resetting code, time and date validation takes less time.)
• A note about “valid” and “confirmed”:
  • There are four functions available: gnss.getTimeValid() , gnss.getDateValid() , gnss.getTimeConfirmed() , and gnss.getDateConfirmed() .
  • “Confirmed” is a more strict check than “valid”.
• See GitHub repo for modifications on custom library this week.

BLE Schedule Uploading

• Define a struct for each event to be sent from the desktop app to Remigotchi

#include <stdint.h>

typedef struct {
    // 32 bytes
    char name[32];
    // 2 bytes
    uint16_t period;
    uint16_t start_time;
    uint16_t end_time;
    // 1 byte
    uint8_t days_of_week;
    uint8_t padding[1];
} event_t;

• Rewrote BLE Serial testbench, there were some bugs with the code blocking until a total of 4 bytes were sent. Now, it doesn’t block, but continuously polls the serial buffer.
  • Commit here: 4283f08

Battery Monitor

• I finally got around to testing the battery monitor, which is a 100 kOhm and 270 kOhm voltage divider connected to one of the ESP32’s GPIO pins.
• Luckily, the Arduino framework provides a function analogReadMillivolts(), which does in fact work. So all I have to do is call that.
• I confirmed with a Fluke 233 multimeter that values read by the aforementioned function are accurate.

New Tools and Knowledge

I needed to learn a bit more about how the SPI peripherals on the ESP32-S3 were set up. The main strategies I used were forums about ESP32 SPI usage, as well as ESP’s official documentation page and chip datasheets.

I also learned a bit about communicating with the GNSS module on the board. I learned how to use it by first looking up popular, well-tested libraries, and decided on the SparkFun GNSS V3 library. From there, I learned how to extract the time from the device by reading the library’s docs as well as the device’s datasheet.

Below is a photo of the LCD screen connected to a Remigotchi PCB used for field-testing the GNSS connectivity.

GPS

• Copilot was able to do a lot in this area. Most of my work involved finding the right library to use, finding the right version of that library, and making sure it was properly installed.
• There were some comments in the library source code explaining some nuance to the order in which functions should be called, so I had to refactor to touch that up a bit.
• But for filling in functions like estimating UTC offset or calculating the day of the week, Copilot was quite helpful. It’s most useful when I already have the structure and clear inputs and outputs defined.
• I tested the code by running the code, printing out the number of satellites in view, and printing the time and date received.
• After I verified the ability to receive time of day from the satellites, I worked on integrating that functionality with the use of the ESP32’s RTC peripheral, and building that into a custom library that will provide the caller with the most accurate time possible.

SPI Issues with the LCD Screen

<aside> ✅

Fix: In the User_Setup.h file in the library source code (terrible architecture by the way) make sure #define USE_HSPI_PORT is uncommented.

</aside>

• Recall that we are using an external library for driving our LCD screen via SPI. That library is TFT_eSPI.
• Simply changing the SPI pins between the breadboard version of the code and the version for the PCB did not work.
• The board would completely crash somewhere within in the tft.init() function call. (To be clear, this is a function provided by TFT_eSPI).
• So, I went back to the basics and ran the SPI testbench code from last week where it would simply send an incrementing byte across the line.
• Both SPI buses simply sending an incrementing/decrementing value separately does work. Code is below.

SPI Sanity Check

#include <Arduino.h>

// #include <TFT_eSPI.h>      // Include the graphics library
// TFT_eSPI tft = TFT_eSPI(); // Create object "tft"

#include <SPI.h>
#define SPI2 FSPI
#define SPI3 HSPI

#define LCD_CIPO 13
#define LCD_COPI 11
#define LCD_SCLK 12
#define LCD_CS 10 // Chip select control pin
#define LCD_DC 9  // Data Command control pin
#define LCD_RST 3 // Reset pin (could connect to RST pin)

#define SHARED_COPI 38
#define SHARED_CIPO 39
#define SHARED_SCLK 40

#define SD_CS 41
#define RFID_CS 42

SPIClass lcd_SPI(SPI2);

SPIClass shared_SPI(SPI3);

#define BUTTON_1 14

void setup(void)
{
  pinMode(BUTTON_1, INPUT_PULLDOWN);
  while (!digitalRead(BUTTON_1))
  {
  }

  Serial.begin(115200);
  Serial.println("begin");

  pinMode(LCD_CS, OUTPUT);
  pinMode(SD_CS, OUTPUT);
  pinMode(RFID_CS, OUTPUT);
  digitalWrite(LCD_CS, HIGH);
  digitalWrite(SD_CS, HIGH);
  digitalWrite(RFID_CS, HIGH);

  lcd_SPI.begin(LCD_SCLK, LCD_CIPO, LCD_COPI, LCD_CS);
  shared_SPI.begin(SHARED_SCLK, SHARED_CIPO, SHARED_COPI, -1);

  // tft.init();
  // Serial.println("tft init");

  // tft.setRotation(1);
  // tft.fillScreen(TFT_DARKGREY);
  // tft.setTextFont(2);
}

uint8_t l = 0x00;
uint8_t s = 0x00;
void loop()
{
  Serial.printf("lcd spi = %x shared spi = %x\\n", l, s);

  lcd_SPI.transfer(l++);
  shared_SPI.transfer(s--);

  delay(250);

  // tft.fillRectHGradient(0, 0, 160, 50, TFT_MAGENTA, TFT_BLUE);
  // tft.setCursor(10, 10);
  // tft.print("Horizontal gradient");

  // tft.fillRectVGradient(0, 60, 160, 50, TFT_ORANGE, TFT_RED);
  // tft.setCursor(10, 70);
  // tft.print("Vertical gradient");
}

• I went back and tried to make it not crash during tft.init() again.
• What ultimately fixed it was simply configuring the library to use the HSPI port. It’s a line in the User_Setup.h file that you uncomment. I’m attaching a full copy of the User_Setup.h file to this web page for reference.
  • Interestingly and frustratingly, the ESP32-S3 doesn’t necessarily have FSPI, HSPI, and VSPI ports anymore. Instead it has two SPI peripherals, SPI2 and SPI3. However, the old terminology appears to have stuck around for backwards compatibility reasons. ChatGPT explains it some more at the beginning of this conversation here (scroll up all the way to the top).
• Lastly, I added some SD card code from last week into this project, and I’ve verified that at the very least, I can display a static picture on the LCD screen and then

RFID Scanner

• I first encountered an issue where the RFID scanner would not communicate back to the ESP32.
• After looking at it with an oscilloscope, the SCLK and COPI lines looked normal. However, the COPI waveform looked incredibly weak.
• I eventually realized that I did not have CS connected to the RFID scanner itself.
  • Part of this oversight was due to the fact that on the module’s silkscreen, there is no “CS” pin labeled. It’s just that the pin labeled “SDA” also doubles as the CS pin while being used for SPI 💀
• After connecting a CS pin, the RFID scanner functioned just fine, and I was able to read the UID from an RFID tag.
• Next, I need to verify that the RFID, SD card reader, and LCD screen all work in conjunction with each other.

PCB Work

• Now that most of the elements on the PCB have been validated, and not to mention the deadline is drawing near, I went back to making edits to the schematic and redoing the layout.
• I decided to completely redo the layout because I added a few things to the schematic, I got rid of all jumper bridges (we’re not in prototype mode anymore), and I wanted to prioritize a compact and smooth form factor.

Photos

Current layout and 3d model (components not yet routed):

What happens when you forget to include a CS line on your SPI-connected device: