Ochi – Version 1

A couple of weeks back, I posted about designing a pair of smart glasses. Now that university has finished for the year (results tomorrow!), I’ve had a lot more time to work on my glasses – though I started employment on Monday so I’m not completely free.

I have however been developing both an app and finishing off the glasses. I got the PCBs from OSHPark and I’ve got to say, the purple soldermask is great! Most of the other components  were from my stash though the display was from BuyDisplay.

Android app
I would in no way ever say that I know Java well enough to write a well functioning stable app so I can’t at all claim most of the code used for this app. I have however used little nuggets of code from around the internet to enable me to build an app capable of parsing the BBC News RSS feed (I should’ve used a proper XML parser…), along with the OpenWeatherMap API (I also should’ve used a proper XML parser…). Once parsed to a suitable string, the string is split into 20 byte packets and sent to my glasses through Bluetooth LE. The 20 byte packet size is due to the maximum transfer size imposed by the BLE standard. It took me a while to realise this so I’ll put it in bold here to hopefully ease someone else the pain of finding it out!

The protocol for sending packets from the phone to my glasses is really simple, it consists of 3 characters used for symbolising and that is pretty much it:

  • ‘{‘ is used to denote the start of a packet. The glasses side ignores any data until this character has been detected. Once this character has been detected, a flag is set and all subsequent data is stored in a buffer until the end of the transmission character is found.
  • ‘|’ is the character used to delimit data. I use this for packets like the calendar data where even though the main chunk of data is the event and location string, the time and date are sent in conjunction to reduce client side processing.
  • ‘}’ is the final packet symbol which denotes the end of a packet. After this, the flag that was set after the packet start is cleared and a “new data” flag is set. This allows the Bluetooth handler to parse the string and store the results in the correct area.

The second character after the start packet symbol denotes the type of packet that is being sent. Currently, the only characters that are implemented are ‘n’, ‘w’, ‘c’, ‘t’ and ‘d’. These denote news, weather, calendar, time and date. The app allows for a single transmission or repeated transmissions (with a variable delay between transmission). Weather, news and calendar information are obtained before each transmission and are compared to the previously obtained value in the code to see if there have been any changes. If there have been changes, the new data is transmitted. I’ve decided to do it this way to try and further reduce battery consumption on both sides. The app was built around a bluetooth example I found online and modified for my own usage. Many of the samples I use (for example getting calendar entries) were found on StackOverflow, the greatest programming information website ever!

Hardware side
The glasses themselves are based around an STM32F051K8 microcontroller (LQFP32 for easy soldering!). All the firmware is custom written though I got the LCD driver initialization codes from the BuyDisplay examples. The firmware is written using a somewhat “co-operative scheduling” with interrupts methodology and for most of the time, the microcontroller is sleeping until something needs to happen. Along side all the Bluetooth and LCD software, I’ve included my SoftTouch library for the two touch buttons on the side of my glasses. These are used to change screens and change items within the screen e.g. move to the next news entry.

To ensure I could get a reasonable amount of text on the screen, I wrote a new font using the MikroElectronika font generator. This font was 4×5 allowing for up to 10 lines of text (with 1 pixel line spacing) or 12 lines (with 0 pixel line spacing). I’ve not had any major problems with this font though a couple of letters (for example M and W) look a little weird and squished!

The Bluetooth side is mainly interrupt and flag driven. As explained previously with the packets, once the “started” flag has been set and the firmware has reached the Bluetooth handler, it waits until the finished flag is set. This is done so the packet can be processed the second it has been received. Without using this method, some packets were being dropped/corrupted as they wouldn’t be processed before another was sent. I somewhat alleviated this too on the Android side by throwing a couple of thread sleeps in the packet transmission function.

Each packet is parsed by the Bluetooth handler and is stored in a struct dependent on what type of packet is was. News packets go into the BL_News struct, weather packets go into the BL_Weather struct, calendar packets go into the BL_Calendar struct and time values get written directly to the RTC module in the STM32.

The screen side of the module is attached to the glasses using thick copper wire. This was so I could move the screen around to find the optimal point of where the screen should be with respect to the lens and my eye. Kynar wire was used to wire all the various parts up namely the battery and capacitive touch sensors.

Finally, the whole device is powered by a single 10440 Li-ion battery which fits nicely into a standard AAA holder.

Pictures

 

Improvements
Ochi 2 will definitely have some improvements over this prototype. I’m hoping  to find both a high resolution screen (preferably circular) and a better lens compared to on this one. This prototype was definitely just a proof of concept more than anything to show that I could use the lenses from a google cardboard headset, 3d print a piece and design a PCB small enough to have a somewhat functioning eye mounted smart device. For the next device however:

  • IF I can get a camera working with an STM32F446 through DCMI without everything exploding, hopefully I can include a cute little GC0309 camera module
  • Integrate a micro USB socket and battery charge circuitry so I no longer need to remove the battery to charge the glasses
  • Add backup power for RTC functionality – most likely to be a super capacitor if I decide to go down the LQFP64 STM32F4 route.
  • Find a better lens with a wider diameter but lower focal length so the whole device doesn’t need to stick out as far from my face!
  • Include 3 touch buttons as opposed to 2 for increased ease of use – 2 works great for simple stuff but other than navigating simple screens, its a bit of a chore for menu based things.
  • Re-design the Bluetooth handler to take advantage of custom passwords, glasses name and low power modes.
  • Use larger(/more) caps/smaller inductor for the OLED boost converter because DAMN is that boost converter whine annoying.
  • 3d print a case for the electronics
  • And finally, hopefully include a nicer GUI than just text, I’m a man of functionality not aesthetics!

Keep tuned for more updates on these!

20 thoughts on “Ochi – Version 1

      1. Interesting! Didn’t know that it’s also a Romanian word. Probably they loaned it from Slavic languages, because it also means eyes in Ukrainian, Bulgarian, Belorussian, Czech, Serbian, Slovak, Slovenian and Macedonian 🙂

      2. If an etymology dictionary was used to trace the origin of the word, it would be discovered that it traces back to the vulgar latin oclus. Probably slavic languages borrowed the term from that source as well. Oh and to rectify a common mistake, romanian is not a slavic language, and culturally are closer french, spanish and italian.

  1. Cool stuff! Thanks for posting all this information, its great to get an “eyes view” of what the project looks like. Once I finish my project I’ll drop a link here…

Leave a comment