I'd love to hear more about the low power design. You mentioned going for a MSP430 on here, and the high level architecture blogpost has some infos about the power domains too. But I'd love to see another blog post with some more nitty-gritty powersaving stuff.
I was also wondering... have you thought about adding a simple streaming compression algorithm to increase battery life? Less data to write would mean less time of VDD_B being active. Could maybe even be implemented on the FPGA. I was thinking of something like delta encoding, with two different code lengths for small and big brightness changes (per color channel.
E.g. first bit 0 -> 5 bits of +/-32 brightness delta following. First bit 1, 11 bits of brightness delta.
You'd loose some minimal information if brightness changes by more than 2048 between two pixels, but you could just "smear" that change over two consecutive values (e.g. [0, 0, 4096, 4096, 4096] would end up as [0, 0, 2048, 4096, 4096])
Thanks for the suggestions! The compression is an interesting idea. It's been a while since I touched the FPGA RTL but I think there might be space to fit something like that.
Related to compression -- a dirty little Photon secret is that currently, the 12-bit RAW pixels are written as 16-bit words, so 25% of the SD card (the high 4 bits of every pixel) is actually zeroes. So an easy compression win is to compact those pixels, and we'll go from being able to store 20k photos to 27k photos, and spend less time writing the photos (like you said) which should translate to longer battery life.
It would be interesting to quantify what the biggest consumer of power is while capturing a photo. I'm honestly not sure what the power breakdown would look like (image sensor vs SDRAM vs SD card vs ICE40).
I'd love to hear more about the low power design. You mentioned going for a MSP430 on here, and the high level architecture blogpost has some infos about the power domains too. But I'd love to see another blog post with some more nitty-gritty powersaving stuff.
I was also wondering... have you thought about adding a simple streaming compression algorithm to increase battery life? Less data to write would mean less time of VDD_B being active. Could maybe even be implemented on the FPGA. I was thinking of something like delta encoding, with two different code lengths for small and big brightness changes (per color channel.
E.g. first bit 0 -> 5 bits of +/-32 brightness delta following. First bit 1, 11 bits of brightness delta.
You'd loose some minimal information if brightness changes by more than 2048 between two pixels, but you could just "smear" that change over two consecutive values (e.g. [0, 0, 4096, 4096, 4096] would end up as [0, 0, 2048, 4096, 4096])