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.