-
Notifications
You must be signed in to change notification settings - Fork 0
Troubleshooting and Recovery
This page covers the most likely setup and field issues based on the source behavior.
- the hardware is not VESC Express
- firmware is older than 6.05
- Confirm the target is
hw-expressclass hardware. - Update firmware to at least
6.05. - Reinstall or reopen the package.
- Master CAN-ID is wrong
- the slave does not see the master on CAN
- strip targets are assigned to the wrong CAN node
- the node is still waiting for forwarded Refloat state
- Open the slave UI.
- Confirm it says the node is configured as a slave.
- Verify the displayed Master CAN-ID.
- From the master, verify the strip target CAN IDs.
- Re-save config from the master.
- the strip is targeted to SELF (-1) but physically wired to a slave
- the strip is targeted to the wrong peer CAN-ID
- pin number is wrong
- pixel type is wrong
- LED count is wrong
- Check the strip's Target CAN-ID.
- Confirm which node physically owns that strip.
- Verify data pin and highbeam pin values.
- Verify LED count.
- Verify pixel order such as GRB vs RGB.
- Toggle Reversed only if direction is wrong, not if the strip is completely dead.
Enable the appropriate Reversed option for the affected strip:
- Status Reversed
- Front Reversed
- Rear Reversed
The source contains a guard that disables active LED strip use on pin 0 in several cases.
Move the strip to another valid GPIO and update the config.
Tune Brake Light Min Amps.
Remember the source default is negative current, because braking/regeneration is expected to appear as negative total current.
- More negative value = harder braking required
- Less negative value = easier triggering
The package includes CRC checks and also migrates or clears some older config fields.
- Open
⋮ - Press Restore Default Config
- Re-enter the correct role and strip mapping
- Save the config again
On the slave page:
- Press Become Master if this should be the controlling node
Or, if you simply want to wipe it:
- Press Restore Settings
- Reconfigure from scratch
That is often normal behavior.
The source distinguishes between:
- Idle Timeout
- Idle Timeout Shutoff
- Increase Idle Timeout if you want the ride mode to persist longer before switching to idle behavior.
- Increase Idle Timeout Shutoff if you do not want the LEDs to clear so quickly after extended inactivity.
That is also often intentional.
The package has a global LED Max Brightness limiter. Runtime sliders are capped by that value.
- Check LED Max Brightness in config.
- Then recheck the runtime brightness sliders.
- Increase cautiously and verify temperature, power budget, and visual comfort.
Adjust both:
- Highbeam Brightness
- Dim RGB on Highbeam
This lets you balance the dedicated highbeam channel against the main RGB lighting.
When in doubt, this is the cleanest recovery path:
- Read current config
- Document CAN IDs
- Restore defaults
- Set role
- Set Master CAN-ID on slaves
- Rebuild strip config from top to bottom
- Save config on the master
- Test one strip at a time