You need to test it up to it's rated load. No load is easy. See what it does when your circuit is malfunctioning. A voltmeter may be adequate, an oscilloscope would be best.
And no, I don't really have an explanation about why the performance would differ, though a photo of the setup might make it obvious.
Yeah I don't have an oscilloscope but I will put my multimeter on it a bit and see what I get. The circuit is set up as per the diagram, however I have disconnected all of the strips barring the powercell one as that's the nearest to the board. Just that one running still has the issue. Its as though there is a delay in the code when there isn't.
When I use a 5V switching regulator to supply an ESP32, a 3.3V device I find that putting a good quality cap on the 3.3V line greatly improves reliability.
If the circuit worked in the breadboard but not in the unit then, to me, the correct circuit has not been replicated. After breadboarding and troubleshooting, I leave the circuit on the breadboard and use separate components to the build and test a prototype board.
Reads like the MCU may be doing multiple resets. I'd suspect a power issue.
Yes I would usually do that as well, however I didn't have a spare nano and concluded that if it works with the components on the breadboard then there is no reason for then to not work in the final piece if I use the same ones. I am wondering about power so I will test it again with the original power supply as it worked fine with that and go from there.
Yes there is a reason, the circuit could be layout sensitive, causing it to pick up more interference than your bread board circuit.
According to the same set of eyes that put it together. Please post images.
1 Like
I will get some pictures when I can not the best light at the moment.
Anyway I went out before to test everything. Voltage is 5.02V and stays that way throughout test, even when issue is present. I placed a new capacitor at the strip and also moved the resistor to the strip as well. Tested with original transformer as well. All conditions still create the issue.
During the start up 'BOOTING' case the lights work correctly. As soon as it switches case to 'RUNNING' the lights then update incorrectly . When the switch is turned off the sketch switches to 'SHUTDOWN' Case and the lights are then running correctly again.
What part of running is running slowly?
case RUNNING:
Serial.print("RUNNING ");
Serial.print( millis() );
Serial.println();
WandBarON();
Serial.print("A ");
Serial.print( millis() );
Serial.println();
WarningOn = false;
IsFiring = false;
cyclotronspin(); //start cyclotron LED ring at idle speed
Serial.print("B ");
Serial.print( millis() );
Serial.println();
PowercellRamp(); //ramp up powercell LED strip
Serial.print("C ");
Serial.print( millis() );
Serial.println();
if (startpack == HIGH) {
Serial.println("Switch is Off");
ShuttingDown = true;
STATUS = SHUTDOWN;
break;
}
if (fire == LOW) {
STATUS = FIRE;
IsFiring = true;
fireMillis = millis();
break;
}
if ((fireMillis - millis()) > 2891) {
starthum();
fireMillis = 0;
}
if (musicstart == LOW) STATUS = MUSIC;
break;
You can add more millis() prints which should point to the place that is taking the longest to execute. Let us know.
I assume it's the whole of it. However I currently only have the powercell strip connected and that is doing it. It runs full speed until it gets to RUNNING and then it seems to update the strip one led in the time it should have scrolled the whole strip. The ring neopixels don't chase but instead just light up in sections around the ring in time with the powercell strip. It's not easy to debug as the item it is in is huge and I only have a small cable to my desktop pc.
Why do you have break; in your if statements?
Because if I don't they fall down and don't execute.
So, I take it you're not going to add any code to see where the slow/wonkiness is coming from?
break statements are not needed in if's anyways. Good luck.
I will but can't now as it dark and the unit is out in my unlit workshop.
That's what I thought until it wouldn't run correctly unless I did. The breaks are to stop the case right there and retest without running through the rest of the case.
The danger of all the breaks being inside an if statement is that you could miss one.
You are better having just one break at the end of all the code and just expand the use of the if statements so that only one of those conditional is run (if that is what you want).
By using a set if if then else statements.
That's exactly what I did but it caused certain things to not run for some reason. The only way I found to ensure that operations ran was to break them at source.
Could it be that you didn't do it right?
Could you post what you tried and it did not work.
I don't have the old iteration but there is no harm in having them. There is always a break at the end of each case anyway so it always breaks the individual switch cases.
The breaks are not the source of my issue though.
I am going to bring in the unit tomorrow and hook it upto the desktop and see what is going on in the code when it runs.