MessageTorch - torch fire animation with WS2812 leds + message display

@Dragonsshout, the function of interest is injectRandom(). The second part of the function injects “random sparks at second row”. perhaps commenting that out will give you what you want. :smile:

@peekay123, thank you for your help! I will try that and let you know if it worked. :smiley:

Turn down flame_max and flame_min (and the difference between the two) along with spark_probability and you should see less flicker and less sparks. =]

1 Like

@Elijah, thank you for your input ! I will also try that solution. =))

@peekay123, if I comment “random sparks at second row” in injectRandom(), there are no more flames. So that’s not the solution. :wink:

@Elijah that’s for reducing the flare-up, but I’m trying to disable it. :blush:

@Dragonsshout

I think if you increase spark_tfr it will lead to sparks giving off most/all of their energy to surrounding cells more quickly, effectively ‘hiding’ the bright sparks

Maybe also increase side_rad and up_rad a teensy amount also.

@Elijah,

Yes, I think that can do the trick! I will try, thanks :smiley:

Once done, I will post some pics here. I ordered made-to-measure plexiglass tubes, we will see how it looks like :wink:

2 Likes

Here are some pics of the finished MessageTorch as promised. :smiley: :smiley: :smiley:

8 Likes

Hey @luz ,

Is there any way I can flip the flame animation, so that the light strip is at the top, and the flames are falling down instead of going up? I know that I can just flip the lamp physically, but I want to ideally have a Spark function, or add it on the params function in which when called, it flips the animation. The reason: I want to make a weather station out of your animation, but when the forecast is rain, I want to flip the animation and change the color to blue so it looks like rain is coming down. :smiley:

I am a little new to coding, so any help will help tremendously! Thanks!

Hi @hassaan22,

I just added a new variable / param named “upside_down” which does that.
What it does is quite simple - the function calcNextColors() starting at line 891 transfers the flame simulation’s “energy” into LED colors. In lines 901 to 905 you see the two variants how it is done - either the energy values for calculating the LED colors are taken starting at the first element of the nextEnergy array (ei = i), or when upside_down is set, from the last (ei = numLeds-i).

Hope this helps - drops instead of sparks is a nice idea, hope to see some pics when it’s up and running :slight_smile:

3 Likes

ahhhhh!!! Thank you so much!!! This is great! I am so excited!
I will definitely post my lamp once I get the flame/rain colors integrated with my local weather, along with my code (if done sufficiently :wink: ) so that anyone else who wants to use their lamp as a weather indicator can use it!

I cannot thank you enough!

Edit: For the Upside_down value, will 1 turn it on, and 0, off? or What are the parameters for the value input?

1 Like

Looking at the code, that indeed seems to be the case:

byte upside_down = 0; // if set, flame (or rather: drop) animation is upside down. Text remains as-is

Which can be set using the parameters:

else if (key=="upside_down")
      upside_down = val;
1 Like

@kennethlimcp whats the OD of your torch?

I’m looking a a glass vase 15cm diameter and 80cm tall. I want to put the LED’s on the inside and put a 15% 1 way mirror film on the outside to hide the strip but let the light pass through

I think i will run the vase upside down to make it somewhat waterproof, ill have the LED strip with a 1.5cm gap between spirals at the top and reducing to 0.5cm gap at the bottom. i think 12m of LED’s will run out about 10cm from the bottom. in the last 10cm i will mount the core and im guessing a fairly beefy power supply :slight_smile:

Hope to have this done in my 2 weeks off just in time for my sister in laws wedding!

@luz in the first post you have a link to a website to send messages to your torch… http://mixwerk.ch/message/ could you share how you did this so i can set up a torch at my sister’s wedding for people to send congrats messages to :slight_smile:

The OD is a little hard to determine since I hacked it with some paper to increase the width as the original isn’t a best fit.

But anyhow, the original is around 10.5cm

Hmm maybe 15cm diameter is a bit much then! oh well its ordered now so ill make it work! If i need ram I’m going to hack everything I can out of the spark-firmware code!

Whats everyone’s thoughts on cutting the strip into short lengths and leaving a gap at the back where you cant see it? it will be against the wall… and with the mirror film on the outside you shouldn’t be able to see in very well

if the ID of the vase is 15cm, i calculate (with 2.5mm thick strip inside) a length of 45cm per layer or 27leds. if i leave a 5cm gap and make it 40cm and 24 led’s thats 3 LED’s less per layer… over 36 layers thats a saving of 108 LED’s! or nearly 1.8M of strip!

I could get some flexible card and stick the LED strips to it, i will mark it out so the Strips have an exponentially increasing gap between them starting at no gap up to a 2cm cap between layers at the very top. ill link 5v to the end of each short strip so there will be next to no brown out. curl it up, link the data line and stuff it in!

You have the FRAM/uSD shield so no ram issues. Haha!

If you want it fast and neat, I would recommend wrapping them around the cylinder!

Now we are talking! I have a few of them!

But how would I make that work? I'm looking at the code and guessing that this is what allocates the buffer (im a genius yeah) so this is straight into ram? so i would need to change it to FRAM.. how do i do that?

{
numLeds = aNumLeds;
// allocate the buffer
if((pixelBufferP = new RGBPixel[numLeds])!=NULL) {
    memset(pixelBufferP, 0, sizeof(RGBPixel)*numLeds); // all LEDs off
    }
}

@Hootie81 and @kennethlimcp, having worked with the FRAM a lot, I have to say the SPI write/read cycle may slow down the neopixel refresh considerably. All of the operations currently done in RAM would have to be converted to FRAM operations. Single byte operations to FRAM take several SPI cycles since the FRAM address must first be written and then the data. I believe it adds up to about 22us per single by operation.

Before you go to FRAM, have you tried compiling and (dummy) running your code to see if you get a RAM SOS error? There may be enough RAM to drive the number of LEDs you need. How many neopixels are you trying to drive?

1 Like

I would like to try for 720 :heavy_exclamation_mark:

i see what you are saying with the SPI, i guess another thing is the neopixels are driven by the SPI MOSI pin without any SS line so that probably wouldn’t make things any easier too

the complier says

In a nutshell:
 Flash used 81196 / 110592 73.4 %
 RAM used    15560 / 20480 76.0 %