ESP-12F Persistence of vision video brainstorming.
Daren Schwenke wrote 04/14/2019 at 08:14 • 1 pointI have the desire to be able to do POV *video*, using an ESP-12F, and some Dotstar modules.
Here is an example of a static image POV display: https://www.youtube.com/watch?v=1CB3UVmEcB0
I have some thoughts on how it could work.
My target POV platform is a 0.5m string of 144/m Dotstar modules. Two equal length arms flinging around, but the arms are offset by 1/2 a module spacing to double the resolution. Rotate the arms at 3600rpm.
That works out @Frank Buss to give me a polar coordinate display with 1 degree resolution, 288 pixels 'around', and 60Hz refresh rate. That is *well* within the update rate I have for the Dotstar modules, and still small enough to be visible during daylight. It won't be blazing, but it will be visible.
Give me an infinite amount of ram, and that is it. Done. I don't have an infinite amount of ram on the ESP-12F. I'm going to have to move the data to it, from somewhere. I will need to store, or stream, the video I intend to push to the POV display.
I'm *really* not confident I could stream the required data over wifi to SPI at sufficient speed, or at least with sufficient reliability/latency to be practical.
So I'm looking for other ideas.
I would like to store/send the data uncompressed, as a directly usable bitstream capable of being sent out SPI, as lines/frames. Each line of data forms one polar coordinate system 'line' of resolution, and new frames start at degree 0. I've actually done this part before for another project, but there I *did* have a virtually unlimited amount of ram as I used wires to drive my SPI. Unfortunately that interface of bending wires had a lifespan of about 30 minutes before it ate itself. I need something a little more robust here.
I have never tried slip rings, nor do I really want to trust them for high data rate transmission at high rpm.
The ESP-12F, Dotstars, (and whatever else) will be rotating here. I can give them reliable power. The data will ultimately have to come from wifi, but it doesn't actually have to be real-time data. I could just trigger playback of specific streams which I could store locally.
I could upload the data to a local storage medium, such as an SD card, and stream it out from there. I'm not sure I actually have the bandwidth to do so on a single SPI bus though.
My initial thought was... how about abusing SPI to directly provide the data for me...
Hook up an SD card to run via SPI, and wire the Dotstars directly to the return SPI bus. Initiate a transfer from the SD card to the ESP32, and then do absolutely nothing with it other than precisely controlling the clock rate to produce the required lines/frames.
Having the data coming directly from the SD card would require it to be already formatted as a stream I could send directly to the Dotstar chain. But if it was, and it was fast enough, then just controlling the clock of the transfer as I need it to could provide the entire data stream.
Or... if you have a project/idea in mind that does something similar, using two SPI data sources, at speeds sufficient to allow what I'm trying to do here... I'm all ears.
Thank you.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I don't think it will work with an ESP-12F. And streaming from SD-card would need some buffering. Maybe use an ESP32. Then you have lots of memory and the CPUs (it has 2) are faster.
What is the data rate? 144 pixels times 288 per revolution, times 60 fps, times 3 bytes per pixel is 7,464,960 bytes per second. You can transfer maybe 2 million bytes per second over WiFi what I've read. SD-card might be fast enough, but you need to buffer it and the SPI speed to the pixels might be too slow. But the closer it gets to the center, the less pixels you need (1 in the center itself), but you might need more pixels (and higher speed) near the border.
Are you sure? yes | no
Thank you @Frank Buss . Yeah, using an ESP32 would be better, but I got a nice stack of ESP-12F's sitting here. They got a little more ram than the older generations, so I was hoping it would be enough.
I can reduce the data rate as needed (just reduce rpm) if it can't keep up.
I was wondering if the SD card itself has any kind buffering. Once the data transfer starts it seems to be pretty consistent for large files, but I never have looked under the hood and I'm not really well prepared to do so either. I suppose coding a transfer and checking the data rate at high resolution would suffice.
I've read that the ESP-12F actually has two hardware SPI busses pinned out, but you aren't supposed to use one of them? What's up with that? I'm sure using both busses would give me the throughput to do a little buffering and smooth out whatever the SD card is giving me. Any insight?
Are you sure? yes | no
Looks like some people used 2 SPI buses:
https://www.esp8266.com/viewtopic.php?f=13&t=4800
If you just want to read it from SD-card, it might be sufficient, you don't need to buffer much. Just implement a FIFO on the ESP-12F in software, because the data format wouldn't be compatible: you have to send commands to the SD-card, and it answers with the data and at least a CRC, which would look like garbage on the display, so you need to filter this.
Are you sure? yes | no
Maybe use more than one ESP-12F'?
Are you sure? yes | no
@Daren Schwenke I think you need to edit your title. POV for younger generation and most people may initially mean: Point of View. It took me like a long time to understand you are talking about Persistence of Vision (POV). If I were you, I would even put a link or picture because many people may not know what Persistence of Vision is.
Are you sure? yes | no
Edited. Thank you.
Are you sure? yes | no