[E1][T] Portrait prisms and 400 x 400 GUI?

A project log for Tetinerary [gd0151]

A head's up display specifically for displaying my itenerary.

kelvinakelvinA 05/28/2024 at 10:240 Comments

So I was watching a MrWhoseTheBoss video about the Apple Vision Pro and it highlighted that I need to think a bit more on the actual aesthetics of Tetinerary. Additionally, I was annoyed how Tetent, which could be as slender as 72mm wide, would be expected to be 93mm wide just because of the display mounted in landscape mode (and mentioning this will be relevant in a moment).

I started looking into hats, particularly ones that hid the forehead since the actual prisms need to be mounted a tad over eye level and usual hats end much higher than that (such as the one I designed in the render).

It didn't take long at all to realise that women's hats were at least an entire magnitude more glamorous than anything in the men's section.

So I seeing all these hat designs and then imagining the prisms on them and it wasn't really working out, and then I remembered this meme when I was instead looking through my display options for #Tetent [gd0090] (while coming to the simple yet inescapable choice that I'd need to mount whatever screen I choose in portrait):

The inverse is also true; just because I have to pay for the whole prism display doesn't mean I have to actually use the whole prism display. At 32PPD, I'd rather the display take up less of my vision area anyway, and only using 400 x 400 out of the 640 x 400 display should be more than fine enough. I was already planning on only really using a 640 x 320 resolution anyway because of the desire to have the end result look like a HUD Dynamic Island.

I went back through the images I saw (and, with the sample data, also imagined some new ones) and mentally rendered 2 small, frosted glass prisms off to the far side of each eye (so that each eye doesn't see both prisms, resulting in 4 prisms visible in the user's FOV) and I belive it works well both from the first and 3rd party's point of view. For the 3rd party's PoV, I think the reason is because it's no longer "something bulky on your face" but an artistic choice of the hat. Like, a logo on one's forehead is going to be noticeably out-of-place, but that same logo on a hat is just business-as-usual.

Yes. It will likely look like a 7 - 8 inch square that only has 400 pixels each side. It's certainly no Galaxy Fold levels of graphical fidelity.

The screen is still low-res, no way around that, but at least the area that it takes up is less. Add to the removal of the black box that has the display and initial lens, as well as the part of the prism that is only responsible for totally internally reflecting the image, and there's a substantial amount of reclaimed FoV. I wouldn't even be surprised if I actually use 320 x 320, partially because there's a low-cost 2.6 inch transflective display (see below) I could use for Tetent, and partially to further increase the eye-relief and decrease the FoV used up by the module (the standard eye relief is 19mm, which is probably fine).

And in other news, I'm thinking of merging Tetrescent into Tetinerary, or at least adding solar panels onto the band. Tetrescent requires slightly-custom Tetrinsics, but Tetinerary should be able to share the same as Tetent. Additionally, the controllers for transflective screens are currently the major percentage of the expected power draw, reducing the overall effectiveness of solar energy harvesting. I will need to see how much the ECX336CN uses.

[May 31] I found power consumption numbers for the very similar ECX336BF

For the 2000nits column, I can only assume that either 185mW should be 188mW or that the total should be 192mW.

Considering that the 336CN is 3000 nits and uses 180mW total, I can do some extrapolations for the full numbers, but what is most important is the VDD1 consumption as its constant. At only 7mW, I think over a week of continuous Tetinerary use is possible, and the solar cell may even extend that to an extra week. 

The STM32U5G9 (an MCU with vector-graphics acceleration) really does seem like the better strategy than an MPU running Android when battery life is concerned. I'll have to wait to find out what vector-graphics performance the ESP32-P4 has before I decide to go with that instead; it's better in almost every way (other than the ADC and seemingly no built-in Type-C controller) except for the part where it doesn't exist yet.