New Feature request - Use internal memory to store an untethered animation

[Danimations]

I realise this is quite a departure from your repurposing of the badge as a low-res tethered monitor, but I'm seeking to do the following with the same b1248 LED badge unit:

• load a series of 1-bit or 2-bit images (from .GIF files ideally)
• set a frame rate for playback
• loop them continuously

I would like to use this as an untethered badge and make use of the existing internal storage (though I understand this is very limited).

Thanks for showing us that this device is most definitely hackable!

[Effix]

This sounds like an interesting addition. I'll have to do some investigation to see how big the serial eeprom actually is.

[Effix]

The external eeprom looks like it is only 256 bytes. Combined with the 512 byte internal eeprom, about 5 2bpp frames could fit (or about 10 1bpp frames) without compression.

Of course the external chip could be swapped out for a pretty big one, if you are adventurous with a soldering iron.

[stoggi]

I'm also trying to figure out how much external EEPROM is on these boards. There doesn't seem to be much information about ATMLH314 chips. It looks like they are a clone of something. But it doesn't make sense to only put 256bytes down. Why would they bother?

They probably need something to store the font glyphs.

[Effix]

I totally agree, so I kept digging :)

I thought the marking was 2D which was for their 256 byte flavor, but 2DC is the truncation code for the 16kb chip. I found the matching code in this datasheet (and page 15 explains the crazy marking code for the SOIC package). http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8734-SEEPROM-AT24C128C-Datasheet.pdf

16kb is bunches of space. That's almost 4 seconds of 2bpp animation at 30fps.

[stoggi]

That's a great find! Putting their main chip marking as ATMLH-Year-Work-Week of assembly.

(╯°□°）╯︵ ┻━┻

[Danimations]

16kb of storage sounds good to me!

So, are these file size and screen time calculations correct?

I'm asking because I'm new to this math.

• A 1-bit per pixel (2 colour) image at 48*12 res = 72 bytes
• A 2-bit per pixel (4 colour) image at 48*12 res = 144 bytes
• A 4-bit per pixel (16 colour) image at 48*12 res = 288 bytes

16kb storage = 16,384 bytes and has capacity for:

• 227 1-bpp images or
• 113 2-bpp images or
• 56 4-bpp images (not supported)

In terms of screen time, this would equate to:

1-bpp animation:

• 7.56 seconds @ 30 fps
• 15.13 seconds @ 15 fps
• 18.9 seconds @ 12 fps
• 37.8 seconds @ 6 fps

2-bpp animation:

• 3.76 seconds @ 30 fps
• 7.53 seconds @ 15 fps
• 9.4 seconds @ 12 fps
• 18.83 seconds @ 6 fps

Hypothetical 4-bpp animation (not supported):

• 1.86 seconds @ 30 fps
• 3.73 seconds @ 15 fps
• 4.66 seconds @ 12 fps
• 9.33 seconds @ 6 fps

How am I tracking with this?

Also, could you estimate how much storage would be required for other data? Presumably this would reduce the total storage capacity available for image data?

[stoggi]

I think you could improve things by only storing the differences between frames.

Maybe something like:

Write a single pixel:

0b00000001  first byte is the pixel address (0-127)
0b00001111  write data 00001111 to the 8th, 9th, 10th ... pixels

Write multiple pixels:

0b10000001  first byte is the pixel address (0-127 + msb indicates a multiple pixel command)
0b00000011  the number of bytes that follow
0b00001111  write data 00001111 to 8th, 9th, 10th pixels
0b10101010  write data 10101010 to 16th, 17th 18th pixels
0b11110000  write data 11110000 to 24th, 25th, 26th pixels

That way you could do efficient single pixel updates that "cost" two bytes (address + data) per eight pixels. But also large frame updates that only add two bytes (address + length) to the sequential writes.

[Effix]

The math is spot on for uncompressed frames. Though, there isn't support for 4bpp images, just 1 and 2.

I don't think there will be much overhead for non frame data... maybe give-or-take a frame? There is the internal memory where this can be stashed as well, and if it all fits there, it will basically be free.

Of course compression will allow many more frames to fit in the average case. A combo of run-length-encoding plus partial frame updates would probably do a decent job of crunching it down. How fancy the compression can get will be limited by program space.

[Danimations]

As an animator, I find the playback time estimates based on these storage calculations pretty exciting... even without compression. Here's a little table showing some prospective playback times based on commonly used frame rates.

1st row uses 1bpp frames, 2nd row uses 2bpp frames.

[Danimations]

I have a question: is there a standard 2-bit palette I should use for making 2-bit artwork? If so what's the palette order? Darkest to lightest, or lightest to darkest?

I'm happy to make some sample animations with mid-tones stepped in 3rds. What I propose is

• 0% (black)
• 33% (dark)
• 66% (light)
• 100% (full brightness)

Of course what might appear mathematically correct and what appears visually correct could be significantly different. I should have some badges (five different colours) within the next fortnight to help me participate more actively in this project.

[Effix]

You got it - that's exactly how it is. 0 is black and 3 is full bright.

There is a gamma curve on the output to make it perceptually step in thirds. sRGB is probably a reasonable estimation for this on the computer.

What are you going to use to flash the firmware onto you badge? Do you have an arduino? I'd also be worth cracking open the badge to see what kind it is on the inside. You'll need to do this anyway to flash it.

[Danimations]

Thanks for answering my palette question, @Effix .

I currently have an RPi at my disposal, but don't have an Arduino. Can the firmware be flashed with an RPi? If not, what should I buy? I will be ready to crack open my badges when they arrive: they are all in transit at the moment.

Regarding features, if the hardware is comparable in all five colour variations I've ordered, I'd like to assist you in optimising/tweaking the two halftones used in displaying 2-bit images to maximise the contrast. I suspect that the optimal brightness/tones might vary from one coloured badge to the next... but setting them for white would be the obvious starting point.

So far I have ordered one of each available colour, except for red. That includes: white, blue, green, pink and yellow/orange.

[Effix]

There is a command to tweak the hold time of each intensity value, so you can tune this for each of the screens.

It looks like it is possible to do this with a Raspberry Pi. There is a tutorial here: https://learn.adafruit.com/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins/overview

[Danimations]

This manual looks helpful. Thanks for the tip:

https://cdn-learn.adafruit.com/downloads/pdf/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins.pdf

So what else will I need to flash the badges? Some wires, pins and clips? I can seek some help from my local hackerspace crew when it comes to flashing the badges. I rarely tinker with hardware (aside from upgrading/assembling desktop PCs and NUCs) so this is new ground for me.

I apologise if you've already covered this in your project documentation.

[Danimations]

Oh, and coming back to this feature request: would it be possible to use the badge's USB port to load, clear and reload images stored on the badge after the firmware has been updated? That would be very helpful.

[Effix]

You should only need 6 female-to-male wires to do the programming.

I don't have a lot of documentation for the programming. I'll beef that up a little once I finish with this round of refactoring.

Yes, once the firmware is flashed, it is all usb controlled after that.

[Danimations]

Great! PS... your enthusiasm for this idea (and note re: screen optimisation possibilities) just prompted me to buy the missing colour... so I have a red badge on the way now too. So far as I'm aware, that's the full set. Please keep us posted as you progress!

[Danimations]

I have now prepared indicative 2-bit colour palettes for each of the 6 available b1248 LED badge colours.

I have some simple looping 2-bit animations ready to test, that I've drawn using the program Aseprite. It's a great value ($15 USD) pixel art and animation program. It makes it very easy to shuttle through frames and test animations at a variety of frame rates quickly and painlessly. It also allows palettes to be loaded, swapped and edited easily which is a big plus.

Here's an example of a 2-bit animation frame for you.