Hi everyone,
I recently experienced some odd behavior with a tritium quad blade and a kr pixelstick v1. I’ve solved the problem, although I do not understand the relationship between the symptoms and the solution–but am sharing in case anyone else ever experiences similar issues.
The symptoms: the blade did not fully light when booted, but eventually lit–although sometimes it required triggering clash or blaster effects, and the blade styles did not function properly–only part of the blade would exhibit fire effects with the fire blade style for example.
The suspected cause: I made the blades and thought it was a hardware issue, like a short, or a power issue–either insufficient awg or the battery. Both blades were made with resistors for blade-id. 10k on one, 33k on the other.
The actual culprit: I was experimenting with defines in the config to get blade id to work, based on conversations between Sabersense and Profezzorn, without fully understanding how they work. Here are the defines I was using:
#define BLADE_DETECT_PIN bladePin //only 1 pin is going through the 13 pin connector
#define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3>
#define BLADE_ID_CLASS SnapshotBladeID<bladeIdentifyPin>
#define BLADE_ID_SCAN_MILLIS 1000
#define BLADE_ID_TIMES 15
#define SPEAK_BLADE_ID //SAY IT!
Removing those lines fixed the problem immediately and the blade works just fine. I also suspect it is only the first two that cause the issue–but haven’t fully tested yet.
The 89Sabers hilts experiencing this issue are not wired correctly for blade-id, and have pixels wired in parallel on data pin 1–but I was hoping to get something to work so I could tell when a standard blade or a twin/quad blade was installed… I’ll go back to experimenting when I’ve finished my fully custom build projects, where the wiring will be correct for blade-id.
best,
Js
This is bad.
Blade detect is different than blade ID.
Blade ID can be done with the bladePin, but blade detect requires a separate pin. Using bladePin for blade detect will make two things try to use the same pin, which will definitely cause problems.
1 Like
Thanks Fett263! Thank you for sharing this–while my issues were different than what is discussed on that thread, I will incorporate elements of your suggestions into my high pixel count blades–I hadn’t thought about increasing the speed (other than the ignite speed that can be easily adjusted through your site).
The main symptom was that the styles did not progress the full length of the blade–only part would light up, and only some pixels would flash–not flash slower than expected.
Note: this is with a V3.9 proffieboard and OS7.14, although I also had the problem with OS7.12 and with a V2.2 board. I had read about perceived issues with the KR pixelstick v1, but I only see advantages. My blade configs use subbladewithstride, allowing independent control of 2 sides for the KR V1 and 4 sides with the tritium.
Changing the config (specifically, not trying to run Blade Detect on the same pin as running data) has fixed the problem–and the blade is also noticeably brighter.
And, now I have a better understanding of what the problem is…
Hey Fett263,
I saw the blade config in the article/video had a single blade defined–did you also test the V1 with SubBladeWithStride to create two blades? Since fixing my blade-detect blunder, I’m not having any issues with my V1.
I split my V1 into two blades using subbladewithstride–one style with a control layer and copy without a control layer, and everything seems to be working great. I could be wrong–but I think using separate styles for each side of the blade normalizes the expected timing for a style to travel the length of the blade.
SubBladeWithStride was created after I tested the V1, but yes, it was intended to help with the V1 blades issue.
1 Like