The project looks super cool, but the idea of wearing a sharp screen that close to my eye on a bike could be one reason it didn't sell.

I'm still figuring out how to integrate this with my existing wearable system. I've been using a Vufine monocular display which is nice as a real HDMI screen but the wire is clunky. So far I'm experimenting with extending the Python code to read images from a directory and display them, newest first... from that I see a path to doing useful stuff with notifications, even turn by turn navigation.

This is the first time I've seen the product, and I was immediately excited.. until I saw the product.

Now, I don't know what it does that my $40 smart watch doesn't do, by passing my voice to google / alexa / <choice>. I like where this is going, I just don't think that this generation has even the same features, as what I carry on my wrist, sadly.

Very cool hack.

As an avid cyclist I never felt the need for this, my cycle computer has everything I need at a glance anyways. But I've seen some similar googles for skiing or swimming, which I might check out more. The skiing one is mostly vanity (like knowing my speed and other stats in the moment is not that useful), but the swimming one is nice as it's hard to track how you're doing without glancing at your watch. Anyone else have experience with these kind of devices?

I can immediately imagine how useful this could be for reading books (or other texts) while riding in a packed subway car. I'd only need to invent a way to control page turning without taking the phone out of the pocket; maybe by tapping, or something similar.

lol I just ordered a pair - many available on eBay at this listing (same as I bought from): https://ebay.us/m/t2i9YF

Very interesting! Seems like a Bluetooth-connected display is kind of rare.

This part:

The one thing I’m left scratching my head over is the length field. If I have 0x20 bytes of image data to send over, I actually need to put 0x10 into that field.

Made me think the protocol simply assumes at least 2 bytes will always be used, so it transmits the length using the unit of 16-bit "words" instead of bytes. That would not be unheard of, and is kind of smart even.

I can't be the only one who read the title and expected an article about Red Solo Cups right?

> If you wanted to do something useful, you could just run while true; python client.py /tmp/hud/*.png; sleep 1; done and have cron scripts generating images that get dropped into /tmp/hud.

It's a wearable version of the clockwork orange movie player! Or maybe the parallax view.

For such a low cost I'm tempted to order one.

Can anyone point me to the modern incarnation of Google Glass? Looking for something that provides a similar experience.

Length being a multiple of 2 makes sense. Rgb565 means 2bytes per RLE value. Data stream is half values half lengths. So every datum is 3 bytes. So it makes sense to send number of half words. Worst case: you overlong by one byte. NBD. The alternative means sending one byte extra ALWAYS to have enough bits for length.

Improvement would be to send number of RLE datas (number of 3 byte quantities)