One of the things I have not previously tried is LED strips/panels.
These are quite clever as they daisy chain one data line, allowing you to send colour data to every LED in a sequence, and hence make them all have any pattern you like. They are pretty quick too. There are a few chips out there, but Amazon have loads of strips and panels, such as a 1m/144 LED strip for £12 using WS2812B controllers.
Obviously libraries exist to make this easy to control. I use the ESP32 chips with the ESP-IDF development environment. However I am (for reasons too tedious to go in to) using CMake now instead of Make. I really do not know CMake well. So was fooled initially. Trying to include "led_strip.h" did not work.
It turned out that all I had to do was add "led_strip" to the CMakeLists.txt in COMPONENT_REQUIRES. And bingo. I am sure I tried that first, but must have got it wrong, but worked in the end.
It is then easy to use. Simple call to initialise, clear, set pixel colours, and flush out.
So what was the project? Well, I printed one of these from thingiverse. It is designed as a light. I struggled the thread the LED strip into it, and so I recommend printing 10% larger. I then wired directly to a USB powered ESP32 module, so 5V to the LED strip, and the 3.3V data line. To my surprise that works, as I was expecting to need to switch it to 5V data. Also, the LEDs can easily draw too much power causing USB to shut down, but by limiting the brightness (it was way too bright anyway) and using only 72 not 144 LEDs, I have kept it working. I just needed a bit of glue gun then.
This is the result :-)
The sequence is too fast for proper dialling, obviously, and it is spinning a blue LED not actually turning the ring. It lights in the chevron positions, but not the actual chevrons. But the bright light for the kwoosh, and then sparkly/fadey for the open gate, seem to work quite well. All on github.
It talks MQTT so I made it that when the house (electric) gates open, the gate opens in the living room :-)
That said, I also have a Shelly button1 lying around that does it too.
Nice. You could probably make a full Pegasus galaxy gate quite easily; where the symbols themselves illuminate instead of the gate rotating
ReplyDeleteIndeed. I suspect it would mean manually wiring up the LED modules (or making a PCB, which would be fun) rather than just bending a stripe around the gate (you'd want that too for the kwoosh effect). I wonder about making as a couple of PCBs - one with the symbols and holes for the LEDs to shine through, rather than a 3D print at all. That could be fun...
DeleteI saw the Stargate film for the first time a few weeks ago, and while the idea was interesting, some of the details seemed a bit confusing.
ReplyDelete1. Why do you need six destination coordinates? Two absolute points in 3D space determine a line, and four would determine two lines. If those lines intersect at all (and there is a high chance they won't), they will intersect at a single unique point. So what benefit do you gain from the other 2 coordinates, other than to over-specify the solution and reduce the number of combinations that will represent a real point in space?
2. The dialing symbols represent constellations. But a constellation is not a point in space, it's a 2D image seen from a particular position (Earth), consisting of stars which may be nowhere near each other. What is the 3D point which corresponds to a particular constellation? Is it just the average of the positions of all the stars in that constellation?
3. Wouldn't the locations where you could put a destination gate be so limited as to be almost useless? It has to be (1) ON a planet or some other habitable environment, and (2) at the EXACT intersection point of three lines determined by very coarse input coordinates (constellations). Most coordinates would result in lines which don't intersect at all, but if they do, the chance that a useful destination planet exists at that location is pretty much zero.
Perhaps I need to watch the subsequent series to better understand how it is supposed to work.
Yes, those, and several other questions come up. There is a whole idea of adjusting for stellar drift, even though "using reference points" that would drift anyway sort of removes that being needed, and they don't explain how these adjustments change the gate address. They also don't explain why you need "point of origin", and, on a proper DHD, also to press the middle. Best to avoid worrying about those details.
Delete