KT LCD 3. P1 setting won't save.

[Circus jim]

I have an old crystalyte DD hub, resurrected with KT 25a controller and lcd3, working fine, but just can't get the P1 magnet count to stick below 20. Afaik there are 18 magnets. The speed is 1 or 2 mph below actual, as checked with a speed app on phone.
I've tried a variety of options, setting P1 then saving with long press of I/O , setting and scrolling through to P5 etc. It keeps reverting to 20!

From what I've read with a DD motor p1 equals the number of magnets, which makes sense if p1-20 is almost right. The destruction manual says p1 can be 1 -255 IMMSMR, so why won't anything below 20 save.

So I tried a different tack, wheelspeed sensor with signal wire connected to speed wire on controller with p2 - 1, it sort of worked but the reading jumped about a lot.
So still no nearer a correct speed and distance reading.
Any thoughts welcome.

 

[amberwolf]

No save <20 is probably a firmware bug, possibly an accidental interaction between that setting and some other supposed-to-be-unrelated one, where when that other setting is at a certain value then this one (and possibly others) can't be set correctly. Not much to do about it unless you can get a firmware file from KT for the controller or one from the display manufacturer (the more likely location for the bug) and flash them. (or go to the opensource firmware instead, which operates differently than the OEM fw).

The wheelspeed sensor issue is probably the magnet being misaligned to the sensor, or too close to it or too far away. (too close is the most common)

Sometimes the frmwrae is just terrible at averaging a 1-pole sensor input, so you can put more magnets on the wheel and change the pole count to see if that helps.

 

[docw009]

What happens if you use 36?

I don't have a direct drive motor, but I've fooled around with P1 on my geared motor with internal 12:1 gearing. P1 is something above 200, but my KT controller will run the bike at most any value, with the speed reading off. I seem to recall it will be close when P1 is within a factor of 2. I have also tried to get it under 20, but it probably didn't save either,

It can never be right because you only get to put in 16,20,22,24 etc as wheel choices, and the right way is to put in diameter to the nearest millimeter,

I also got jumpy speedo readings when I switched from an internal wheel sensor in the motors (burned out) to one mounted on the frame. Shouldn't be any difference.

 

[Circus jim]

Thanks. People have suggested putting in a random number 36, 46 etc, the speed/distance goes further out. The nearer to 18 the better it gets.
I'll try adding another magnet on the spokes, I've got at least one around in the shed, on the shelf by the elusive box of round tuits.

 

[Circus jim]

The answer from @amberwolf is the closest. It is the firmware but not a bug.

I sent an email to torquetech, who supplied the kit, the reply...
Hi Jim

I have a previous customer that once experienced the very same problem with a Crystalyte 408 motor.

Firstly, I should confirm an error with KT LCD documentation, where the user guide incorrectly states that custom parameter P1 can be set to 1-255. As you have discovered, '20' is the minimum acceptable value.

The solution to the problem was to set the wheel size to the next size up in order to bring the displayed speed back into alignment with the true GPS measured speed.

An erratic external wheel speed sensor reading will usually be caused by either a sensor positioned too far from the passing spoke magnet, or electrical noise on the signal line caused when running unshielded cable in parallel with high power motor or battery wires.

Best regards,

Dan

 

[amberwolf]

FWIW, the inability to set P1 down to the actual value is a bug, in that it is incorrect / undesired operation of the system...but it's apparenlty not considered a bug in that they *intended* it to be broken and require the user to faff around with workarounds instead of just doing things the way they actually are.

Seems typical of many software/hardware designers (not just these days, but always)...make the user screw around with things they don't understand with incomplete and incorrect documentation until they're frustrated enough to throw it out and get something else, instead of just designing and programming the thing correctly. :/

I can't count the number of bugs I've reported over the decades to companies and individual developers who just said "oh, that's as-intended" and refused to do anything about it, sometimes leaving a feature or function completely unusable.