@peekay123 that’s cool, the project going to Maker Faire :-)!
And the enhancements sound great - I’m a Pebble user myself and would be eager to hear how you’ll be doing that - I assume there’s a smartphone app involved to connect BT with the spark cloud? And making it a TwitterTorch is certainly also a nice idea! Will you post these mods on github?
luz, of course we will post on github! @ChrisLewis posted a Pebble Tinker app that works great and I was going to use that as a foundation for the Torch app.
@peekay123 Thanks for the mention. Thinking of stripping the Pebble Tinker app down to a bare minimum for Spark <–> Pebble interaction, with documentation.
Is there any wider interest in such a resource, or is there already one out there?
Great! When it is done I will post a new topic to stop derailing this one - a very cool project indeed! Reminds me of the huge wheel the London Science Museum has to show messages on.
@luz, just tried the Message Torch with the latest firmware, it looks like I can do only 8 rows of 14 leds anymore. When I put 9 rows and I download the code to then I get flashes of RED on the
This is really a pity, is this due to the latest firmware ?
I just both 4 meters of 144 LEDS/meter strip and wanted to make a real nice Message Torch. I hope one day the sparkteam get’s this solved.
Does anybody have a solution to this issue ?
Memory problems have risen to the top of the Spark team’s list and now with last version bringing Spark.subscribe(), I think everyone understands the need for memory optimization.
If you can build locally, you might be able to reduce some buffer sizes and get your torch to work with the full LED strip.
rudyvan, to use a longer LED strip, I commented part of the original cod out, including the VDSD api code and the cheerlight code. With that removed and compiling with v2.1 master on local build, I am able to get 16 levels of 17 LEDs per level.
when I had to cut my own MessageTorch down to 10 (of originally 18) levels yesterday due to ever increasing RAM usage of the Spark Firmware itself, I thought that this is not funny any more and sat down to squeeze out bits to reduce RAM usage.
As @peekay123 and others already pointed out, removing cheerlights and digitalstrom also helps a lot, so I added conditionals for that at the top of the source file.
Optimizations and disabling cheerlights/digitalstrom together got the original 18*13 LED torch back for me, running on current spark FW v0.2.2!
I very much hope future spark FWs will get optimized for using less RAM, so we could add features and effects instead of removing them over time!
Thank you luz and everybody for all their input on this project
.I wanted to give my experience some working with this project. First, the silicone casing was very helpful. I used some clay to make a tray to hold my Spark and to fasten ‘ledges’ near the bottom of the cylinder to help support the coil. The clay can be smeared fairly thinly across a glass tube, and I built up from that to make the ledges.
I got a 5V/10A power supply and a heft >1000uF capacitor to power it, although in hindsight I will never need that much brightness in my typical indoor settings. I powered the Spark Core off of the LED strip, so the power supply goes from the wall to one end of the LED strip, and through to the other end. The +5V, GND, DIN wires from one end of the strip connect to the Spark +5V, GND, A5 pins, respectively. I wanted to share a Fritzing diagram with you guys, but I have been having issues getting them to reset my pw.
I hope you don’t mind luz, but I added a function to draw an (m x n) matrix of color values scrolling across a window of ‘x’ pixels. Unfortunately it depends quite a bit on the diameter of the cylinder used and how many levels of LEDs there are before an LED is vertically above another.
This has been a great project for me, and a great way to get back into creative endeavors. Cheers!!
(P.S. When I try to change one of the parameters through api.spark.io I get a return_value: 1, but the parameter does not seem to be changed. Sorry, this may be better for another thread).
@Elijah, I am super glad you got everything working! This is the kind of project where physically building it is almost as difficult as programming it!
One simple way of testing your Torch functions is to use Spark Helper. You can easily put in your function name and parameters to test things out.
I am testing it out by editing the firmware and re-flashing it and then sending a POST with curl. I’ve narrowed down the problem to the condition (j<0) in handleParams() is being tripped and breaking out of the while loop before any keys can be matched. I’ve tried formatting my command in various ways with no luck. Sometime today or tomorrow I’ll see if I can figure out what’s up.
OK, when I POST a single argument “key=val”, it is not getting matched with any of the values in the ‘else’ statements. If I post “,=key=val” however the command goes through. The code looks fine to me so I don’t know what’s up, but I’m glad I can change variables by sending POST data vs. flashing the core =]
I tried --data “=mode=2” and got nothing, but --data “q=mode=2” works, so it looks like the format requires “%=key1=val1,key2=val2,…” where % is any number of characters (within reason, and NOT “access_token”).
I kind of hope the API can be adjusted so that -d “key1=val1,key2=val2,…” passes the entire string, but it’s pretty flexible this way.
Also, a photo from setting up the cylinder and LEDs:
You can see a large 4700uF/10V capacitor across the 5V/10A power supply, the +5V,GND,Data wires from the WS2812b are screwed into terminal blocks on the breadboard, and the +5V/GND from either end of the strip are connected to the external power supply, supposedly to help prevent “browning out” at the ‘far’ end of the strip.
Thanks again, luz! (P.S. Great work on the updated code/drivers!)
Yes, also as long as my --data field is enclosed in double quotes the "args= part can be any short string that isn’t "access_token=, including "!/ $\ 4p;= or "a=, or " === but not "===.