I have made a digital POV display on a computer, with dashed lines moving back and forth, on Paint. Here is the title of the video, which you and others can search on RU-vid: Continuous Meter Display (Persistence Of Vision) The video shows a meter with an arrow, which moves back and forth, continuously independent of the pixels. It is the dashed lines that give the illusion that the arrow on the meter is sliding forward. I like your display! Good explanation! :-)
I built a similar one that goes onto a ceiling fan and displayed the time, it was one of my early electronics projects like 20 years ago, used couple AA's and a msp430 micro. Today they have the ws leds so its super easy to make a grid for something this size. I had the idea back then to make billboards using this, as they are huge and need many thousands of very very bright leds, but did not ever finish it. Instead of swinging a board or leds, those would be centrally located and I was using fiber optic cable to get very high resolution and light weight at the edges. I still have not seen anyone do that all this time.
Dude, you're awesome. I'm just beginning to get into PCB design, etching coils into a pcb is a fascinating alternative to using brushes. Starke Leistung :D
Thank you, Timo. Making planar, circular coils with PCBs is tricky. While the math behind is simple and easily available on the net, tools are rare and also PCB makers struggle. I am using KICAD for PCB design (free, open source). However, I had to trick it. I approximate circular leads with a series of straight lines. Start and endpoints were calculated externally.
I'll have to remember this. I want to do more hardware stuff, and while I'm not sure I'd make reproducing this my first project, I'd still love to try. One thing that would be an interesting hack that I can see right away is the possibility of making this two colours, assuming the 1mm gap between LEDs isn't an issue. You could have, for example, one lot of LEDs red and the other white, green and blue, yellow and blue, or whatever takes your fancy.
Amazing work with great attention to details like perfect balancing, stable picture and two rows which are offset half a pixel outward. The only thing I found odd is that you placed your LED modules at a 90° phase angle. It would produce smoother animations and less flicker at 180° placement, as this would effectively give you interlaced scan, but in polar coordinates. All the disbalance could be coped with counterweights which you have to use anyway.
thank you for your thoughts. The 90 degree angle was a result of mechanical considerations. However, I am currently working on a color display which will have 180 degree placement.
It would be very interesting if you dedicate a video to explain the software in detail. Those of us who are just starting out would learn a lot. I greet you from Spain. Great job .
thank you for your interest. I assume that just a few people would be interested in that kind of detail. However, if I find time, I will think about it.
an esp32-S3 could easily do it all on its own. It has enough connections to control all LEDs directly. The maximum output current can be set by software, so no resistors are needed. The ESP32 also has an inbuilt HALL sensor. The ESP32 has 2 processor cores, one takes care of the WIFI, the other takes care of the control of the LED's
thank you for your interesting thoughts. I like the idea of directly driving the LEDs with the GPIOs. However, there is almost no documentation on the current sink drivers of the GPIOs (if any) of the ESP32-S3. The ESP32-S3 documentation is not really clear on that point. However, POV displays live and die with the timer and the related interrupts. It needs a free running mode (auto.re-start), and a high priority interrupt, once the max count is reached. I am using more sophisticated timer modes in order to control the brightness of the LEDs. I am not sure, whether the ESP32 gives you sufficient control and priority, but it would be worthwhile trying. Regarding color, total current is clearly a concern, but can be handled. My color display (56 RGB LEDs) is almost finished - I just need to implement some mechanical changes on the power supply. I will publish the results in a few weeks.
@@LHM000 Driving the LED'2 directly would certainly exceed the permitted total current of the ESP32, I hadn't considered that. However, the drivers could be simplified. Search for "CAT4016" and "STP16CP05". They can drive 16 LEDs with an adjustable current. This saves the LED resistors and the complicated timing for dimming. The output current can be controlled with a resistor. You would have to work with either a digital potentiometer or an adjustable current sink. There may be other driver ICs that can be dimmed digitally or with PWM. I also had the requirement for tight timing in a project. The software on the ESP32 is based on FreeRTOS. The disadvantage is the scheduler, which interrupts the programme 1000 times a second for a few microseconds. I cannot judge whether this is a problem. An interrupt takes about 5 microseconds to arrive in the software, but is constant. Instead, you could implement the control of the shift registers using SPI and DMA, then the hardware takes care of it and the processor/FreeRTOS cannot interfere. The ESP32 is also capable of dual and quad SPI. This would allow 2 or 4 shift registers to be written directly, which would simplify the timing even further. The ESP32 can SPI with up to 80MHz, which the shift registers cannot withstand ;-) However, 20MHz is very easy to implement, the Arduino is nowhere near that.
Unfortunately, there is very little information about the ESP32-S3 specification regarding the current ratings of the GPIOs. However, in a color display design the number of GPIO ports would not be sufficient anyway. I ended up with STP24DP05BTR, which is ideal for the application. Regarding the timing, my assessment is clear: the ESP32 is not suited for a POV display. Neither the timer , the interrupt handling, nor the real time capabilities are sufficient. The processor is made for high level programming, not for low level, time critical bit crunching. Anyhow, you can try your luck. You would save an additional processor and some other components in the range of 3$ total.
@@LHM000 If you absolutely want to use the Arduino Nano, then search for LGT8F88A This is a replica of the ATmega328, but much better. I've used it a lot and have ignored the ATmega ever since. It has 4 key advantages: 1. cheap, you can get a board for 1€. 2. 32MHz clock frequency and therefore twice as fast. 3. optimised microcode. Where the ATmega needs 3 clock cycles, only one is needed here. My experience has shown that the LGT8F88A is about 2.5 times as fast as the ATmega. 4. mathematical functions. With this you could run the SPI with 16MHz
I would assume that the computing power of the ESP would be sufficient to accomplish everything. However, the challenge is the prioritization of tasks. The wifi function, as well as other tasks, need high priority in order to work. On the other hand, the control of the LEDs is extremely time critical as well. We are talking about response times of microseconds. Every delay would be visible in the display image, immediately. It turned out, that the best way to manage this is to use a dedicated microcontroller for LED management, only. However, even the Arduino nano, which really is a slim and minimalistic device, has its pitfalls. The controller does not have a way to prioritize interrupts. Instead, it works through the interrupts sequentially. Unfortunately, there is not only the timer 1 interrupt, which is most critical for the LED control. There is a clock interrupt for the system time (used in functions like delay()), there are multiple interrupts for serial, SPI, and I2C interfaces. All that interferes with the LED control. In comparison, the ESP is much more complex and even more difficult to control. Anyhow, I did not find a way to manage priorities on the ESP such, that the image quality would be acceptable.
@@LHM000 Thank you for the insight. I bet an ESP32 could handle it all! Thanks for sharing. I'm interested to see this project evolve into the future!! RGB might be a fun next version. :)
A magnificent job. It is not clear to me why the two rows of LEDs are necessary. And I would also like to know how the images are loaded? That is, do you have an application to "draw" the image you want and generate the table that the microcontroller reads? Thank you very much, congratulations for such detailed work.
You could also make a display with just one LED row. However, this would reduce the resolution by a factor of 2. The web user interface allows you to easily upload images from a computer or smartphone to the display. All kinds of image formats work (JPG, IMG, PNG, …) No additional software needed. The image can be color and high resolution - there is a function which rescales it and makes a black and white image out of it. The software for this is part of the web page of the web user interface, which means it is programmed in Java Script. This is a big advantage, because JS has a huge functionality and the computer or smartphone has much more computing power, than the ESP microcontroller. I should point out, that the web pages are hosted on a “little web server”, which runs on the ESP microcontroller. This is a fantastic function of ESP!
The work is so interesting that many ideas occur to me. Wouldn't the brightness control be simpler if the common power supply of the LEDs were controlled by a PWM?
The problem would be, that the frequency and wave form of the PWM would interfere with the (individual) on/off signals of the LEDs. However. PWM has to happen “within the pixels”. The only way to make your idea work would be to make the PWM frequency much higher than the pixel frequency. Pixel frequency can be up to 10 kHz. Frequencies of PWM are usually lower.
Hi Jack, there is a simple reason, why I did not use the magnet/ coil approach. I did not think of it ;-) Great idea! However, the generated energy would depend one the speed of the rotation - that is not the case with my approach. Anyhow, thanks for reaching out.
@@LHM000 Thanks for responding. Your design is still very elegant and incorporates many electronics aspects which will be of great help to those wishing to resolve similar design problems.
Amazing work. It's a high level criativity. Thanks for sharing and the detailed explanation. I was wondering if it should be possible to make one using a RGB(W) LED like WS2812B, for example.
Here is an answer which I prepared for a similar question on instructables.com: A color display would be a real stretch. First and foremost, the memory size of both the Arduino nano and the ESP8266 would not be sufficient for a color image. Here is the simple calculation: The current display needs 40 bits per line (5 bytes), the number of lines per round is 240. This makes 1200 bytes for one image. The nano has 2048 bytes of SRAM, only. If we want to make a real color display, we would need to deal with brightness levels (on and off would not be sufficient). If we assume we use 8 brightness levels per color, we would need 3 bits * 3 colors * 40 pixels/line * 240 lines = 86400 bits = 10800 bytes. This is obviously a factor of 9. The next challenge would be how to set the brightness for each individual LED. I have some ideas, but it would probably need a faster timer and a more powerful microprocessor. Here comes the next challenge: the communication between the ESP and the Arduino microcontrollers is based on I2C right now. This is very slow, and definitely too slow for transferring images with 9 times the size of what I have today. As the ESP also would need to have more memory, we would need a different model anyway. I would probably use a second SPI interface for connecting the two microcontrollers. A more practical challenge would be to somehow fit 120 LEDs on a 120mm disc. I made an experiment with 80 LED, and I could fit it. However, more LEDs will really be tight. The only way might be to use SMD components. And lastly, with moving towards more powerful microcontrollers, power consumption will likely go up. I believe to still have some spare power with the wireless power supply. However, we would need to figure out whether the power available would be sufficient. Sorry for the lengthy answer, but it is a simple question with no simple answer ;-) Cheers, Ludwin P.S.: The WS2812B would most likely be too large, and communication would be too slow. Speedy communication is really of essence. The timing is about a few microseconds. The WS2812B would probably not do it.
@@LHM000 Thanks again for another free lesson (just kidding) and you don't have to apologize at all. Please understand that I am just a curious and admirer. I really appreciated your knowledge in everything you did. Hope more amazing projects from you. Greetings.😉
Excuse me. After sending my question, I watched the video again and found the explanation of why it uses the two rows of LEDs. But I don't see it very clearly, because in an instant of time T, only the LEDs of a row of LEDs light up?
well, that is the principle of “persistence of vision”. It does not really matter WHEN a LED lights up. The only thing that matters is WHERE it lights up. In other words: the LED needs to light up just in the moment when it is in the right place. As long as things move fast enough, the eye (and brain) cannot resolve time. But obviously we can resolve space.
Great project-product! …. I would have used a second static PCB to carry the Arduino’Nano and most of the the electronics and let just the LED strips on the rotating PCB ….that should increase the MTBF and reliability of the whole solution …..
@@juancarlosabad3298 Respectfully, I don't think that makes sense. If you put the Arduino and most of the electronics on a static board, and the LEDs on a rotating board (the rotor), then how would you transmit from the static board to the rotor, and illuminate the LEDs by radio? To do that, you would need a circuit on the rotor that receives the radio signal, decodes the packets and turns on the appropriate LEDs at the required time. There is also latency to consider. Such a design would need a wireless receiver, a microprocessor, and LED drivers on the rotor. In other words, you would end up with a design very similar to the one shown here, but with more components (potentially 2 Arduinos and 2 ESP-01s). That would increase the MTBF, not reduce it. Personally, I think the solution shown in this video is very elegant. There are no slip rings, so apart from the motor, everything else is solid state. There is very little to go wrong.
You can light up 56 LEDs with 8 lines using "Charlieplexing", which is a multiplexing principle. The LEDs are addressed sequentially, one after the other. Fundamentally, there is no reason not to use Charlieplexing in "persistence of vision" (POV) displays. However, there are several implications: 1. timing: a POV display is all about timing. You would need to light up your 56 LEDs about 240 times per turn. This would require a very high multiplexing frequency. 2. intensity: if you light up 56 LEDs one after the other, each LED will be on only 1/56th of the time. As a consequence, brightness will be reduced by a factor of 56. In multiplexing, LED currents can be set higher, but it will not be possible to compensate for a factor of 56. Anyhow, there are less "aggressive" multiplexing approaches (wich need more lines), which are definitely an option for POV displays. In fact, I have been working on such a model for a while. Will keep you posted.
@@LHM000 Most of the reasons take place. I agree. But as for "one-by-one", it's not correct. An entire row is always "active". Let's say bit #0 is "active" - connected to a ground, and so a row of LEDs, and bits #1-#7 could have +1 (or be in a Z-state) and light up an individual LED on this row. Then bit @1 becomes "active" and is connected to a gnd, and bits #0, #2-#7 can light up LEDs. Thus you will need only x4 faster scanning. If this is too fast, then 24 parallel outputs will be more suitable for sure.
I doubt you can light more than 1 LED at a time in Charlieplexing, if you want to properly control the LED current. How would you handle the series resistors? Depending on how many LEDs are on in a row, you would need different resistors. No way. Forget about Charlieplexing. Standard multiplexing is an option, though. It needs extra components to control rows and columns. But it can be done.
@@LHM000 Open drain is open drain. So, The "active" line just shorts cathodes to gnd. Each remaining line can feed only one(!) LED (others belong to inactive rows). So, one LED, one resistor, a certain current. That's it.
Excellent project and a great video. Thank you for sharing. I like your solution to have power transmission and rotation on one board, and power reception and display logic on another. You've cleverly avoided the need for slip rings. 74HC595 shift registers are awesome. Here is an LED cube that I designed many years ago using Arduino and 74HC595 chips ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-WdWw8wt4VhY.html
thanks, Mick. I am using the high power version of the 74HC595. It is from TI, called TPIC6C595. However, probably the 74HC595 would work as well. Thanks for the LED cube video. My son made a similar one. Would be interesting to rotate this thing or something similar. ;-) We could make a 3D display out of it.
This looks like a spherical display. I am thinking of a true 3D display. Imagine a flat array of for example 64x64 LEDs. Put it upright, and rotate it around a vertical axis. You could draw 3D objects in space
Hi dear maker and thank you for this amazing design. i have an issue. i build this project but when i connect to RD40 wifi and want to open ip address wit browser, it won't open any page in my browser and showes me an error. yet display still shows ip address. i double and triple time flashed both arduino and esp but nothing changed. can you help me please? thank you
Hi Sam, it sounds like you have not loaded the flash disk data. Please refer to the description in my instructables.com article: www.instructables.com/Rotating-LED-Display/ It is described in Step 5. You are very close! Both microcontrollers seem to be running. Please let me know if it still does not work!
What I am trying to say is this: you need to load both the program itself and the flash disk data to the ESP. This needs two separate uploads. There is a special upload method for the flash disk data. The flash disk data contains the html, css, and java scripts of the web interface. Without that, the web interface cannot load.
Hi dear maker. Thank you for your reply. Yes you right, i missed that last part which was uploadin flash data. it works perfect now but i have another problem now, in the time zone, some zones not have correct times. i tried all of them, i just wanted to ask you a favor if its possible, im not a coder and i can not add a feature which read clock from computer or mobile phone or even set time and date, manually. Is it possible to ask you do me this favor? I spent so much cost and time to build it, i will be so grateful if you add only one of the features i mentioned earlier. Thank you dear maker
Can you send me a private message on instructables.com? Click on my username lhm0 and send your email address, please. That will make communication much easier
