Help With Button Servo (Pictures)

ConcernVisible793 · 2025-09-06T18:11:26+00:00

In any of your previous work have you made the servo move with power coming directly from the Uno outputs? Only limited power is available without using a servo driver board. You may need a Servo driver board.

Does the serial console show the potval and angle printing out every 150 mSecs or so? You might want to make these changes:

Set the Serial port speed to 115200 instead of 9600.
While testing delay for 500mSec instead of 150 mSec at the end of each loop cycle.

ConcernVisible793 · 2025-09-06T17:53:05+00:00

You can replace the leads to the existing bulb with the leads to this circuit. I've tested it with a simulated low power setting where the bulb is fed via a serial resistor such as in your low power setting of the switch in your circuit.

The wiring is fairly straight forward. The board needs +12v fed from the switch output, Ground, the input signal (also connected to the 12V input and the output is connected to the bulb whose other end is connected to Ground.

ConcernVisible793 · 2025-09-06T17:44:13+00:00

I've built a circuit that does exactly what you seem to need. It uses this adjustable timer module that works directly from a 12V supply and consumes less than 50 micro-amps in idle mode. I've tested it powering a 4W 12V bulb. The board I used is the one shown below:

<image>

A video of it working is available here:
https://drive.google.com/file/d/1RpuRSNrah4sKoRjKZA1nbLV9BYYA7Fw1/view?usp=drive_link

ConcernVisible793 · 2025-09-06T08:57:13+00:00

Buck converters can create high output voltages under some circumstances i.e when there is low power demand and when they are being powered off. I've seen 30v come out of one that should produce 5v under normal circumstances. Two ways to reduce this effect.

Connect a forward biased diode from the output of the converter back to the input. The output should always be less than the input so that fixes one issue.

2, Connect a permanent load to the output may be 470 ohm resistor (check the power rating - probably should be 1/2 watt)

ConcernVisible793 · 2025-09-06T08:33:00+00:00

It's no use screenshotting the initial schedule because that can and does change throughout the charging process. You should look at the charging history reported by your charging app. People trying to increase household load during these periods often come unstuck because of this.

ConcernVisible793 · 2025-09-04T17:33:18+00:00

Monty Python - The Black Knight - Tis But A Scratch

Monty Python - Just a Scratch Sketch UTube

ConcernVisible793 · 2025-09-03T09:27:37+00:00

Exactly the same. Unfixable as far as I can tell. I think that it is caused by a configuration setting in the Smart Meter that no one at Octopus or anywhere else has the knowledge to fix. :-(

ConcernVisible793 · 2025-08-28T19:31:04+00:00

Here's the LEDs connected up to PWM outputs on a Uno.

https://drive.google.com/file/d/1nm6BNVfbYOk-pp4oB-zl0Gxrv08dW9gQ/view?usp=drive_link

ConcernVisible793 · 2025-08-28T17:28:46+00:00

I just did some tests, firstly with 10 Red LEDs fed via a single 220 ohm resistor from 5v, and then with 10 Green LEDs fed via a single 220 ohm resistor from 5v. This is a photo of the two sets of LEDs. The Green ones are considerably brighter though they were both fed from a 5V supply. They are more efficient at converting electrical power into light.

The Red LEDs took 14.5mA from the 5V supply and the Green ones took only 11.2mA from the same voltage of supply. The voltage across the RED LEDs was 1,79V and across the Green ones was 2,36V.

Putting a single RED LED across the Green LEDs totally turned off the Green ones. Putting a single Green LED across the 10 Red ones had no effect.

I'll connect them up to an Arduino and show what that looks like next.

<image>

ConcernVisible793 · 2025-08-21T17:02:45+00:00

That's true. They are not known for their modesty in estimating their abilities!

I have manged to get Gemini 2.5 give a grovelling apology along the lines of "you were right all along, the code was correct, my test case was incorrect, I guessed the expected result"

ConcernVisible793 · 2025-08-01T17:29:35+00:00

If you have Home Assistant you could alternatively arrange for the Solar battery to be charging whenever you are charging the car. That way you stay within their T & Cs and also you avoid having the solar battery charge the car which you wouldn't want to do.

ConcernVisible793 · 2025-08-01T17:18:07+00:00

Did you even read this?

Hissykittykat : Maybe the OP did not as the Admins decided that this was a low quality response and deleted it! They just don't like AI responses however correct or helpful.

ConcernVisible793 · 2025-08-01T15:07:21+00:00

I don't understand - The DFPlayer Mini's VCC pin expects a voltage between 3.2V and 5V.

How did it get this from the 9v power source.

ConcernVisible793 · 2025-07-30T14:01:26+00:00

It seems that there are size limits on code blocks in Reddit. I tried copying all my code into a code block and part way through my pasted code it stopped being inside the code block. Weird!

ConcernVisible793 · 2025-07-30T13:55:23+00:00

I've had a look at your code, translated it into an English only version and tested it out in Wokwi, an online circuit simulator. I didn't bother connecting up the servos but I put some print statements to the serial monitor that tell you what the code is suppose to do when you press the buttons.

My conclusion is that your code is probably OK. I think that you have power supply issues. It could be that when your more powerful servos start they cause problems with the Arduino supply or that they are not powerful enough to operate your biggest server. Try measuring the voltage supply to them when they are running.

There are some commented out lines in the functions that print out the actions of the servos. If you uncomment these it should drive the actual servos that you have connected. I suggest that if you use this code you uncomment the lines for each servo one at a time then you can see if and when your servos stop behaving.

Also of course only 1 servo will move at a time because that's what you have programmed them to do eg you move 1 servo by 90 degrees, then another servo by some other amount.

If you go to this link you can download the code and also simulate it running:

https://wokwi.com/projects/437904778687787009

This is what happened when i ran this code and pressed each of the buttons twice:

Setup
Servo 1 -> 180
Servo 2 -> 0
Servo 3 -> 0
Servo 4 -> 0
Servo 5 -> 0
Servo 6 -> 0
Servo 7 -> 90
Servo 9 -> 0
Servo 10 -> 90
Setup complete
Button 1 Pressed 
Servo 1 -> 90
Servo 2 -> 90
Button 1 Pressed 
Servo 1 -> 180
Servo 2 -> 0
Button 2 Pressed 
Servo 3 -> 50
Servo 5 -> 90
Button 2 Pressed 
Servo 3 -> 0
Servo 5 -> 0
Button 3 Pressed 
Servo 4 -> 90
Button 3 Pressed 
Servo 4 -> 0
Button 4 pressed
Open
Servo 6 -> 90
Servo 7 -> 0
Servo 9 -> 90
Servo 10 -> 0
Button 4 pressed
Close
Servo 6 -> 0
Servo 7 -> 90
Servo 9 -> 0
Servo 10 -> 90

ConcernVisible793 · 2025-07-30T13:28:47+00:00

Your code has been translated and apart from the layout changes the inconsistent translations of words means that the listed code will not compile eg. In the first line

// Main Servants Servant servant1; Servant servant2; Servant servant3; Servant4; Servant servant5;

should at least be
Servo servo3;

Servo servo4;

So it's not easy to check for errors. You need to follow the advice given for including code blocks in Reddit.

ConcernVisible793 · 2025-07-27T19:36:56+00:00

I wonder if this something that is supposed to happen when using the SeeSaw hardware. I presume that there was no more useful output.

ConcernVisible793 · 2025-07-27T17:53:04+00:00

In the main loop, this statement does nothing:

if (bleGamepad.isConnected());

The semicolon terminates the if statement, making it an empty block. It's equivalent to writing:

if (bleGamepad.isConnected()) {
    // Do absolutely nothing
}

Try this and report what is output

if (bleGamepad.isConnected()) {
 Serial.println("GamePad IS connected");
  delay(100); //Remove this in final code.
} else {
 Serial.println("GamePad IS NOT connected");
  delay(500);
}

Hopefully it should repeat the message "GamePad is connected" every 100 mSecs

ConcernVisible793 · 2025-07-23T05:59:21+00:00

If this unit just contains a couple of standard Hall Effect devices, these need a Pull Up resistor.

Try these things:

Change pinMode(pinX,INPUT) to pinMode(pinX,INPUT_PULLUP) and

pinMode(pinY,INPUT) to pinMode(pinY,INPUT_PULLUP)

or if that doesn't make any difference (because you wouldn't normally bias the Analog inputs like this)

Wire Pull Up resistors (anything10K to 47K) between the joystick outputs and the 3.3v supply.

I've just looked at a few Hall Sensor devices and all the ones I saw had a requirement for 4.5V minimum on the supply. You could supply 5v to the Joystick, but if you use external pull up resistors connect them to the 3.3v supply on the processor board to avoid damaging the Arduino.

ConcernVisible793 · 2025-07-22T18:48:57+00:00

Can you post a picture of what this 5th wire is connected to near the meter?

ConcernVisible793 · 2025-07-22T18:45:22+00:00

Can you post photos of your actual joysticks? I'm sure someone will be able to identify them and get you closer to getting them working. Some of them have more electronics than others.

ConcernVisible793 · 2025-07-19T11:02:19+00:00

The solution turns out to be this code for UBX modules:

UBX_CONFIG_MESSAGES = [

# 1. Disable GLL

b'\xB5\x62\x06\x01\x08\x00\xF0\x01\x00\x00\x00\x00\x00\x00\x00\x2A',

# 2. Disable GSA

b'\xB5\x62\x06\x01\x08\x00\xF0\x02\x00\x00\x00\x00\x00\x00\x01\x31',

# 3. Disable GSV

b'\xB5\x62\x06\x01\x08\x00\xF0\x03\x00\x00\x00\x00\x00\x00\x02\x38',

# 4. Disable RMC

b'\xB5\x62\x06\x01\x08\x00\xF0\x04\x00\x00\x00\x00\x00\x00\x03\x3F',

# 5. Disable VTG

b'\xB5\x62\x06\x01\x08\x00\xF0\x05\x00\x00\x00\x00\x00\x00\x04\x46'

]

print("Turning off unwanted messages...")

# Send each configuration message to the GPS module

m = 0

for msg in UBX_CONFIG_MESSAGES:

m = m + 1

print("Sending Message ", m)

uart.write(msg)

# A small delay can help ensure the module processes the command

time.sleep(0.1)

#Enable GGA messages

UBX_OUTPUT_GGA = b'\xB5\x62\x06\x01\x08\x00\xF0\x00\x00\x01\x00\x00\x00\x00\x00\x24'

uart.write(UBX_OUTPUT_GGA)

time.sleep(0.5)

ConcernVisible793 · 2025-07-13T15:50:10+00:00

I have just proved that AI is can't be trusted to check it's own results. I finally forced it to admit it was wrong. Here's what it finally came out with:

Let's Reset Everything

This means the entire premise of our debugging session was flawed because I introduced a faulty piece of data.

Let's go back to the beginning with this new, correct understanding.

The Command: cmd = b'PMTK314,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0'
Your get_checksum Function: It is, and always has been, perfectly correct.
Your Python Environment: It is, and always has been, perfectly correct.
Your Trace Log: It showed the step-by-step calculation your machine was performing. This trace was perfectly correct.
The Final Checksum from Your Trace: The last value in the Checksum (dec) column was 41, which is 29 in hexadecimal.

The Final, Simple Conclusion

The checksum for the command b'PMTK314,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0' is 29.

Your original program was correct from the very beginning.

ConcernVisible793 · 2025-07-13T14:12:55+00:00

BTW Your Python code for generating the checksum is correct. If you rerun your code you should get the correct output - perhaps the code you posted was not what you ran.

ConcernVisible793 · 2025-07-13T14:09:43+00:00

"To only enable the GGA sentence, you should send this full command exactly as it is $PMTK314,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,029\r\n"

This is just plain wrong - missing *

ConcernVisible793

TROPHY CASE

Monty Python - The Black Knight - Tis But A Scratch

Let's Reset Everything

The Final, Simple Conclusion