• Hello ES! We could use some help to get us past the finish line on building the new knowledgebase for the forum.
    Can you donate? Please see our fundraising page. Thank you!

First DIY conversion kit with cassette integrated torquesensor

I've been looking at getting this if the 26" one ever comes back into stock. Or is there any other similarly priced 250w rear hubs kits with torque sensor which is pretty inconspicuous?
 
Or is there any other similarly priced 250w rear hubs kits with torque sensor which is pretty inconspicuous?
I don't know a similar set at the moment.
I know, that there are hub motors from Bofeili, Truckrun and Aikema with the Kclamber cassette sensor, but I guess, they are for OEMs only. :(
@mechaniker has built several test bikes with various sensored motors already, but a Plug&Play set like the A3 from Yose is still the only one that is (was) available commercially.
I'm recently using a Hailong battery integrated JYT controller (with the EBiCS firmware) recently on my commuter bike :cool:
 
Last edited:
and seems to require using a phone as a display
The (wireless) display is optional, I think. And there is no information about the torquesensor. No photo, if it is the one from KClamber...Just one sentence in the description
Built-in Cassete Torque sensor
So quite an adventure to buy one.
Delivery time 45 days and 100$ shipping costs :eek:
 
Last edited:
I'm very interested in the A3 pro kit for the stealth aspect of the bottle battery and minimal wiring coupled with the torque sensor in the motor. A little concerned about no online docs (I expect this is easy to install though) and spare batteries don't seem to be available yet.

Is there anywhere to find to find a long-term review of a kclamber motor torque sensor or similar technology? Anyone with experience?
 
Last edited:
Seems they now offer more powerful versions with l1019 connectors. looks like a beefed up bpm - could be interesting!

1762623060055.png
 
Last edited:
Seems they now offer more powerful versions with l1019 connectors......
Who is "they"?

This topic is about a hub motor with integrated torque sensor.
I can't find any information if this is the case with this rear hub motor too.
 
Last edited:
Who is "they"?

This topic is pointing to a hub motor with integrated torque sensor. I can't find any information this is the case with this rear hub motor too.
Truckrun, chinese company. Those hub motors with cassette tq sensor are popping up from time to time on aliexpress or similar chinese platform under different brands.
 
Last edited:
Truckrun, chinese company.
We discussed it in this thread:
The problem is still the availability of a suitable controller. KClamber has two different UART protocols meanwhile. The old one has 7 bytes message length, the new one 8 bytes. The new one spends one full byte for the temperature.
So the controller has to match to the protocol version.
It makes no sense to buy a single motor, you won't get a matching controller :(
 
We discussed it in this thread:
The problem is still the availability of a suitable controller. KClamber has two different UART protocols meanwhile. The old one has 7 bytes message length, the new one 8 bytes. The new one spends one full byte for the temperature.
So the controller has to match to the protocol version.
It makes no sense to buy a single motor, you won't get a matching controller :(
Is this table correct Stancecoke ? It's the extracted kclamber uart protocol based on this code: EBiCS_Firmware/Src/hubsensor.c at Kclamber_v2 · EBiCS/EBiCS_Firmware The listing is reversed, since your code scans for the eoff byte and works backwards.


1762778861499.png
 
Last edited:
The byte order is vice versa, but it's correct in principle. And this is the 8Byte protocol. The 7Byte protocol is in another branch.
Thanks. This means I have to write a condition in lisp that checks for message length first based on the 0xff byte, and adapts the parser accordingly. If the only thing changing is the temperature byte, it should be straightforward.
 
that checks for message length first based on the 0xff byte
My solution is a little quick and dirty. The sensor sends the data without a defined break between the messages, so the "UART idle" interrupt, that I use for the display communication, doesn't work for the sensor. Now I read slices of 16 bytes by DMA and search for a valid message within this slice. It works reliably, but I miss every second message this way. But it's still fast enough for a smooth assistance behaviour.

1762790007683.png
 
Last edited:
My solution is a little quick and dirty. The sensor sends the data without a defined break between the messages, so the "UART idle" interrupt, that I use for the display communication, doesn't work for the sensor. Now I read slices of 16 bytes by DMA and search for a valid message within this slice. It works reliably, but I miss every second message this way. But it's still fast enough for a smooth assistance behaviour.

View attachment 380325
Yes so I've seen in the code. Without a dedicated start byte and timeouts, I don't see how to do it otherwise in order to be sure to capture a full sequence. I'll have to do the same in lisp, and setup a 16B buffer for uart_read to filter out.
 
Is that a standard 9 pin julet connector? How they managed to get it working with kunteng controller?

Usually 9 pin has 3 phase, 3 hall, plus, minus and speed sensor for a geared hub

Where would they fit the extra pin for the PAS?
 
How they managed to get it working with kunteng controller?
Kunteng will have built a special controller with a new firmware, that reads the UART messages of the cassette integrated torque sensor from the white wire of the motor connector. There is no classical "PAS" signal, all information like torque, cadence, wheel speed, motor temperature is transmitted by the UART protocol.
I wonder, if Kunteng is using a faster processor now, or if the old 8bit STM8 is capable of this additional UART job.
 
43908.jpg
If it was possible to read the model number it would be easy check if the controller is newer version

But still for uart you need 2 wires rx and tx, mybe they are using 1 wire communication
 
But still for uart you need 2 wires rx and tx, mybe they are using 1 wire communication
You should read this thread from the beginning ;)

I wonder, why the Kuntengs are more expensive than the JYTs. The JYTs are FOC controllers. I'm using the JYT from YosePower for the Hailong Battery holder with this sensor, but of course with the EBiCS firmware.
This is a really clean and stealthy setup.
 
Last edited:
Back
Top