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.
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.
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.
It's kinda weird since the payload seems to be (repeat:u8 + rgb565:u16)*, so always multiples of three bytes, not two.
Given how this is sort of software is usually written, my guess would be they originally didn't have the RLE encoding and were just sending (rgb565:u16)*. That'd explain it.
> 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.
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)
13 comments
[ 3.0 ms ] story [ 45.2 ms ] threadNow, 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.
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?
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.
Given how this is sort of software is usually written, my guess would be they originally didn't have the RLE encoding and were just sending (rgb565:u16)*. That'd explain it.
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.
Improvement would be to send number of RLE datas (number of 3 byte quantities)