MessageTorch - torch fire animation with WS2812 leds + message display

@peekay123 that’s cool, the project going to Maker Faire :slight_smile: :-)!

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. :smile:

@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?

That would be fantastic! Git er done! :slight_smile:

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.

1 Like

@peekay123 It is done!

1 Like

@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 :spark: then I get flashes of RED on the :spark:
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 ?

1 Like

Hi @rudyvan

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. :smile:

2 Likes

Hi all,

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! :smiley:

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!

Hope this helps you, too!

3 Likes

There are already changes and reduction ram usage on the core-firmware.

Next firmware push to web ide will definitely fix it!

1 Like

Great news! That would probably allow enabling cheerlights and digitalstrom again :smile:

If you love following what we do:

https://github.com/spark/core-firmware/tree/ram-optimization/newlib-nano-option

3 Likes

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).

1 Like

@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! :stuck_out_tongue:

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. :smile:

1 Like

Thanks @peekay123

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 =]

how does your curl command line look like?

For me, the following works fine to set params (make sure there are no spaces in the args string):

 curl https://api.spark.io/v1/devices/xxxxx/params -d access_token=ttttt -d "args=up_rad=50,side_rad=40,heat_cap=10,spark_tfr=40"

One caveat however - the length of the string the spark API can transfer is limited to something around 50 chars. Longer strings will not get through.

I have tried several formats for passing the access_token. For example:

curl -H “Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” --data “mode=2” https://api.spark.io/v1/devices/zzzzzzzzzzzzzzzzzzzz/params

curl --data “mode=2” https://api.spark.io/v1/devices/zzzzzzzzzzzzzzzzzzzz/params?access_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

curl https://api.spark.io/v1/devices/zzzzzzzzzzzzzzzzzzzz/params -d “mode=2” -d “access_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”

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!)

1 Like

So just to be clear: in this part of the command

args=up_rad=50,side_rad=40,heat_cap=10,spark_tfr=40

The args= part is swallowed by the cloud and what your params function on the core gets is just this part:

up_rad=50,side_rad=40,heat_cap=10,spark_tfr=40

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 "===.