Cloud and Lightning Code

[lnevo]

Maybe you wanted to have lightning affects at night?

[cosmith71]

Added video to OP.

[89delta]

Loving the update for the lightning.....more responsive on my ldd-l's.....looks like real flashes now.

[lnevo]

Of course since I'm using InternalMemory for the schedule, start%, end%, etc. I can't just use this code as-is.

I'm going to modify at some point soon to use the PWM Override variables to apply the effect. Does anyone see any issue doing that?

The only thing I can see is that I won't be able to override manually without a flag to disable the effect, but that's easily addressed.

[cosmith71]

Could you just read the memory locations and use them in the PWMSlope function call?

--Colin

[lnevo]

Yes, I could... but I have four different channels that I'm controlling each with a separate offset and it's quite a lot of memory calls. Now imagine someone with the 16 channel custom module It's much simpler to call the function like this:

ReefAngel.PWM.Channel0Slope();
ReefAngel.PWM.Channel1Slope(5);
ReefAngel.PWM.Channel2Slope(10);
ReefAngel.PWM.Channel3Slope(15);

This takes care of all the schedulign using the standard memory and the dimmer settings as well.

Plus, I also have my acclimation code that I want to affect the dim % as well. I'm also building into my INO the option to choose different lighting schemes so I can choose Slope, Parabola, SmoothRamp (in dev branch). So it just gets messy.

[89delta]

Collin,

I've been using your update on the lighting effect for a couple of days now.....only issue i've seen so far though is after the lightning gets done any port that I shut off manually turns back on after the lightning.

[cosmith71]

Collin,

I've been using your update on the lighting effect for a couple of days now.....only issue i've seen so far though is after the lightning gets done any port that I shut off manually turns back on after the lightning.

Do they switch back to auto, or turn on? That's bizarre. I'll try to replicate.

--Colin

[89delta]

They switch back to auto.

[cosmith71]

Yep, they sure do. My theory is the delays cause the unit to reset.

It may need a different approach.

--Colin

[89delta]

Am sure if we can do some sort of last state on the relays before the lighting it'd fix it....

Sent from my SAMSUNG-SGH-I717 using Tapatalk

[cosmith71]

Am sure if we can do some sort of last state on the relays before the lighting it'd fix it....

Sent from my SAMSUNG-SGH-I717 using Tapatalk

I think it would be better if we could prevent the reset to begin with. I have some ideas. I'll work on them Monday when I have some time.

--Colin

[89delta]

Sounds good Colin. Thanks for working on a fix for it. But figured you would want to know about the "bug".

[cosmith71]

You're welcome!

--Colin

[cosmith71]

I have a fix, in theory at least. I haven't had a lot of time to test but it appears to work.

Find this section in cloudcheck()

Code: Select all

static byte cloudchance=255;
  static byte cloudduration=0;
  static int cloudstart=0;
  static byte numclouds=0;
  static byte lightningchance=0;
  static byte cloudindex=0;
  static byte lightningstatus=0;
  static int LastNumMins=0;

And add these two lines:

Code: Select all

static time_t DelayCounter=millis();
static int DelayTime=random(1000);

Remove this section:

Code: Select all

if (lightningchance && (NumMins(hour(),minute())==(cloudstart+(cloudduration/2))) && second()<5) 
      {
        int a=random(5);
        for (int i=0; i<a; i++)
        {
          analogWrite(daylightPWMPin, 255);
          delay(20+random(50));
          analogWrite(daylightPWMPin, 0);
          delay(30+random(20));
        }
        delay(random(1000));
      }

And replace with this:

Code: Select all

if (lightningchance && (NumMins(hour(),minute())==(cloudstart+(cloudduration/2))) && second()<5 && (millis()-DelayCounter)>DelayTime) 
      {
        int a=random(5);
        for (int i=0; i<a; i++)
        {
          analogWrite(daylightPWMPin, 255);
          delay(20+random(50));
          analogWrite(daylightPWMPin, 0);
          delay(30+random(20));
        }
        DelayCounter=millis();
        DelayTime=random(1000);
      }

This appears to work without setting off the watchdog timer and resetting the unit.

--Colin

[Sacohen]

I bit OT, but do the LDD drivers generate enough heat to be concerned about.
I'm putting my 4 up board in a Radio Shack 5x2.5x2 Project Enclosure with openings cut in the sides to gain access to the screw down terminals for wiring.



Do I need another source of ventilation?

[cosmith71]

I was surprised at how hot mine get. The more LED's on the string, the hotter they get. Some of mine get up to 60C, and they are open air.

--Colin

[Sacohen]

Thanks and thanks for the code.

Here is what my enclosure looks like.
I may have to leave it open air or have a fan blowing on it.

[rimai]

I think the reboot issue is the watchdog kicking in.
We need to reset it inside the lightning sequence.
I'm pretty sure if you use the original code and just add the code below inside the for loop, it will stop:

Code: Select all

wdt_reset();

[cosmith71]

How often does the watchdog timer need to be reset? I thought it was every second. The big delay is the delay(random(1000)) just outside the loop which might be pushing it over the top.

I'm thinking we may need more lightning. Like a chance during most of the cloud. Might be my day-off project.

--Colin

[rimai]

Yes, every second and you are right. You may need one wdt_reset outside the loop too.

[lnevo]

Do we need a delay here? Sorry I haven't looked deep enough at the code, but is there any way to be non-blocking? Delays can add up...

I've already seen slowdown in some calculations because my INO is slow to begin with...

What i would recommend maybe is increasing the watchdog timeout if possible or disable/enable before and after the delay is needed.

[cosmith71]

Take a look at the replacement code. It doesn't delay so much as it just doesn't flash again until an appropriate period of time has passed. The for() loop can take up to 600 ms max to execute, but past that it's non-blocking.

That, and in it's current form, it only happens for 5 seconds max in the middle of a cloud.

--Colin

[lnevo]

You don't need a for loop...we are already in a loop....if the for loop is what is taking time we can change that so its less stateful and doesnt require a second loop. I'll take a better look this week..

[cosmith71]

The new code has ran a couple of times today already. No resets so far.

--Colin

[lnevo]

Post it

[cosmith71]

I did. See previous page.

--Colin

[lnevo]

I meant the update...wasnt sure you updated the first post or not

[cosmith71]

I meant the update...wasnt sure you updated the first post or not

Not yet, I wanted to test it first. But I will soon.

--Colin

[cosmith71]

OP updated with non-apocalyptic timing. It shouldn't set off the watchdog timer and reset the unit anymore. It's also less monopolistic of resources when it's running.

--Colin