Here's a list of things that I've found while doing (a little bit weird) bringup for supporting my mnemos project.

• The display VCOM toggle pin is connected to the Pi Zero, not the RP2040. This means that the RP2040 cannot persist the image on the display while the Pi is off. Being able to drive the display AND the VCOM from the RP2040 would be good, but at least with just VCOM, the RP2040 could persist the last drawn image from the Pi during deep sleep. Sharp's documentation, the "VCOM" section discusses this
• There appears to be parasitic draw to the Pi Zero even when Q1 "Pi Power" mosfet is disabled. I believe this is caused by the 2x4.7k and 1x10k 3v3 pull-ups on the i2c bus. This could cause a few mA of draw, and probably isn't great for the attached hardware to be idling at a few volts (1.7v seen on the 5v0 rail on an MQ-Pro). This could be fixed by adding another mosfet between the 3v3 rail and the pullup resistors, so this could be cut with the same signal as is used for Q1 today.
• The FDX0019B1 "pogo" pins are not compatible with some boards, such as the MQ-Pro. I needed to design an adapter board to handle this. I could not find a datasheet for these, but it seems that 1.0mm PTH diameter works well (and the MQ-Pro must be smaller than this). It would be nice to use "real" spring loaded pogo pins in the future, for better compatibility.
• There have been issues with the TPS boost regulator failing short. It might be good to put a 1.0/1.5/2.0A polyfuse on the input power (between battery + vusb and the TPS)

Howdy repo description still say beepb*rry

A prototyping area added to any blank space on the PCB would be useful to add through hole or smd ICs and other components without requiring external mounting.

Something like this:

https://learn.adafruit.com/adafruit-proto-shield-arduino/overview

I want to make a shield like PCB for the side expansion I/O. Unfortunately the pins would interfere with the SDCARD/MIPI jacks.

I don't care so much about the MIPI jack, but I imagine I'll be inserting/removing the SDCARD a bunch. Unfortunately the 3 pins that interfere on the SD side are I2C. I'd like to use those guys for sensor integration.

In V2 (if you keep the 0.1" I/O), slide the headers down a little so this interference is avoided.

I like the sharp display, but it would be awesome if you could choose between it or a color alternative.

Maybe you could make the displays sit on carriers, so you could choose the type.

This adafruit 2.8" COTs TFT is mechanically bulky, but you could probably find another generic OEM compatible ILI9341 display at https://www.buydisplay.com/.

When I print the case of nylon, it breaks. The producer suggests 2mm for the case of nylon, and 1.5mm for PLA and resin.

When doing development on the keyboard, I'm constantly sliding the power button on / off with the V1 case. I have to use a small screwdriver because the switch is tiny.

It would be nice it the V1 case had a small slide button so you could use your finger instead.

The current enclosure is awesome, but it would be nice to have a flexible case to put around it to protect from drops. Something that's flexible like TPU, similar to a phone case.

The qwerty keyboard doesn't clearly show alternate symbols like: [,],<,>,|, tab, pg up/down etc. It also doesn't show common modifiers like ctrl-c.

Add some documentation that talks about the key map for the default firmware.

It took me a couple of hours of fiddling to figure out the map so I could use tmux on the device.

It would be fun, to add gpio header from rpi set up to plug LTE module like this:
Simcom A7670E
Or this
Simcom A7670C which seem to be smaller
Or some similar one
They need just serial and two outputs to control power and sleep, which is optional, but possible.

Of course, this module does not allow for any high data transwers, but it would make beepy independent in from wifi, or even allow for voice calls and use gps.

I like that you broke the extra I/O out for expansion. Mechanically though, I'd like to see it consolidated into single stack able header. I'd also switch from through hole to SMD like J45. You could probably route of all the expansion down just below the RPI header.

Having printed the two halves of the slim case, the exact Amazon Torx-head screw part suggested by the README seem to spin freely in the bottom half of the case.

Is there any way we can get access to CAD files so that we can adjust the screw diameter of the holes?

I'm not sure how you'd package it, but it would be neat to integrate a LoRa transceiver in the next version of the board. You could use it to send and receive text like messages using LoRa gateways.

Use cases:

• Burst based text messaging
• One way broadcast paging
• SOS (that's a stretch without a GPS too, but maybe a coarse location could be calculated using multiple gateways w/o GPS.)

I was able to use a piezo element to get my beepberry to speak using espeak. It would be nice if the next rev of HW had a buzzer/piezo for indications and audio.

A little tinny, but it's usable.

It would be awesome if you could choose to use either rpi zerow or a CM4 module. Maybe you could make a conversion carrier? The volume seems to jive. I guess heat might be an issue though.

I'm a fan of filling with ground plane. In v2, I think you should fill both sides with ground plane. If you did that, you could flip the RPI over and heat sink it to the ground plane. If you stitch the edges with via, it will help transfer heat from one side to the other.

Flipped RPi with ground plane fill:

Ground plane stitching example:

Add kicad files, both the schematic and PCB.

The v1 enclosure looks great. Can the models be published as STEP or IGES files as well? Although STL's can be manipulated in FreeCAD using mesh to object conversion, the result is typically harder to work with than a direct export to STEP/IGES.

It would be nice to be able to have additional volume in the enclosure for daughter card add ons. I'm thinking a gps or maybe a lora transceiver.

The Raspberry Pi Zero case has a variation that can accept a RPi camera. Adding this capability to the Beepberry case would enable QR code input for things like restaurant menus and TOTP seeds.

https://datasheets.raspberrypi.com/case/raspberry-pi-zero-case-with-camera-mechanical-drawing.pdf

The ideal solution would have hardware compatibility with a wide range of Raspberry Pi Camera variants: https://www.raspberrypi.com/news/new-autofocus-camera-modules/