ReflectionsOS VS JPEGDEC

I am searching for a GPS antenna for a wearable project. It uses an ESP32-S3 and ATGM336H GPS module (basically an inexpensive version of the UBlox Neo-8) on a custom designed 34 mm round board. This is in the Reflections open-source project at GitHub - frankcohen/ReflectionsOS: Arduino-based Internet enabled watch project and reference architecture to make your own projects.

Below is the source code I wrote. It is part of the code I wrote for https://github.com/frankcohen/ReflectionsOS and does not compile by itself - I include it as an example to write your own code. I am distributing it under a GPL v3 license - free software, when you change the code you need to publish your code to the world. I use the code in my Reflection's open source project at https://github.com/frankcohen/ReflectionsOS in the BLE.h and BLE.cpp code files.

I've been working on an ESP32-S3 open source project (https://github.com/frankcohen/ReflectionsOS). It's a 34 mm round board, double sided, for building a mobile entertainment experience. I've been successful at producing short runs (less than 10) in China and having the assembly work done in California (Surface Mount Solutions in Santa Clara does an excellent job). I'm coming up on a decision to manufacture 500 of the boards and I'm split between sourcing the boards and parts in China and having the assembly done here. I'm expecting the reject rate on the board testing will justify the California assembly costs.

other documents are there, for example using ESP32 and SD/NAND as MSC, using JSON data, and other sketches are at https://github.com/frankcohen/ReflectionsOS/tree/main/Docs

Thanks! My hope is my project becomes a useful open-source resource for other makers too. I want to get the USB upload working to the same degree as the reference dev boards. That's why I'm working on this now. The repository is at https://github.com/frankcohen/ReflectionsOS

Thanks! I'm glad to hear your experience with TFLM and the others. I found the Dynamic Time Warping algorithm to train and find patterns. I got it working today on ESP32-S3 and an LIS3DHTR accelerometer. It's accurate about 70% of the time. I'll publish the source to the Reflection's Experiments repository https://github.com/frankcohen/ReflectionsOS/tree/main/Experiments soon.

That's a cool project! I'm making an esp32 wrist watch too (https://github.com/frankcohen/ReflectionsOS). It doesn't have a touch screen, it does have a compass/gyro/accellerometer/gps. I'm thinking of adapting your code to use the accelerometer to do the pointing. If it works I'll post the results to github. Thanks for the inspiration! -Frank

To be clear, I haven't done any of this, but I'm assuming these would be the steps. With the S3, you can certainly emulate a mass storage device - and here's a link for someone who did that: https://github.com/frankcohen/ReflectionsOS/tree/main/Devices/Hoober/Software/USB-MSC Ok, now for the next part - fat32 (or more specifically, long filenames) - looking at the example above, it looks like everything is done at the block level, so I would guess that would mean when you're doing your partition table on the ESP32, you'd set aside some amount, like let's say 200k, and instead of using it for NV (like LittleFS or whatever), you'd then perform the block read/write functions. Assuming this is the case, then really the format of the partition is irrelevant to the ESP32, it's only handling blocks - it would be the PC that would format it FAT32 or whatever - so this should work.

I agree, there's nothing like making your own board. My open-source open-hardware ESP32 project is here: https://github.com/frankcohen/ReflectionsOS. It's a round 34 mm double sided board for a wrist watch project. Hoping to do what you did next week, post the schematics for feedback and quality improvements. Thanks for the inspiration. -Frank

It takes some time to decode, but I can grab- for example- this 259k JPEG: http://placekitten.com/3840/2160

And display it from the microSD card with this code: https://gist.github.com/Gadgetoid/0b8e352e377135d743338c9483...

As more or less demonstrated by this example: https://github.com/pimoroni/pimoroni-pico/blob/main/micropyt...

Decoding is done via Larry Bank's JPEGDEC: https://github.com/bitbank2/JPEGDEC

It uses roughly 20k RAM to provide the necessary buffers both for decoding JPEGs into blocks which are passed to a drawing routine that handles copying the data into the display RAM buffer (on our larger Inky display this is backed by PSRAM). I don't believe there's a hard limit to the size of the JPEGs you can display. The main bottlenecks are decoding time and the relatively limited scaling options: FULL, HALF, QUARTER, EIGHTH.

This aside, the authors solution is actually quite elegant. As long as you have control over the image pipeline there's no real reason to encumber the device with handling large (both in bytes and pixel dimensions) files. You'll also get much better dithering results writing your own routine to convert files from JPG to the raw 4-bits per pixel format for the display. Our built-in dithering is just a plain ordered dither matrix and, while quaint and retro, it leaves much to be desired visually.

If you're trying to use a public API you can also make GitHub actions automate the whole image conversion process and publish the results to GitHub pages. This works great for, for example, the daily XKCD, serving both to reformat the strip for the display, credit the author, extract the "alt" text and avoid excess requests to the origin. Eg: https://pimoroni.github.io/feed2image/xkcd-800x480-daily.jpg. Though the astute will notice I still opted for jpeg in this case.

I'm doing the same thing with MJPEG and the JPEGDEC library https://github.com/bitbank2/JPEGDEC. I preprocess the video using ffmpeg to scale the video down to 240x240 and remove the compression.