L10 to JST for combined speed/temp with an older controller?

[irf23]

Hey folks,

I have an older Phaserunner (V2) and a CA-DPS. Looking at a few different motor options from Grin, I was wondering if anyone knew how to connect the L10 motor standard to the older JST with regards specifically with the combined thermistor and speed signals coming from the L10. I could leave the speed disconnected and use the speedo from the CA-DPS, but how can I route the temperature to the CA-DPS?

This is the cable I am looking at, and I am a bit confused how I to deal with the 3-pin speed/temp signal. Any advice is appreciated. I have an e-mailout to Grin but haven't heard back yet.

 

[slaphappygamer]

I’m curious about this too. I was thinking that you could parallel connect the temp wire to the speedo. That is to say, have the speed and temp (from the motor) both connected to the speed signal of the PhaseRunner. Since both signals typically run on the same wire, I’m thinking this connection method would also work and let the CA interpret the two signals.

 

[irf23]

I’m curious about this too. I was thinking that you could parallel connect the temp wire to the speedo. That is to say, have the speed and temp (from the motor) both connected to the speed signal of the PhaseRunner. Since both signals typically run on the same wire, I’m thinking this connection method would also work and let the CA interpret the two signals.

The V2 Phaserunner has just 3 cables coming out of it; a 6-pin Cycle Analyst cable, a 5-pin motor hall sensor cable, and a 3-pin throttle cable, so I don't know if I could parallel connect the temp wire to the controller as you mention.

The L10 Harness to JST has the following pinout (1 =N/C, 2= Temperature Input, 3 = Speedo Input), while the CA-DPS has the thermistor input (1 = Gnd, 2 = NTC).

 

[amberwolf]

There is a note in the PR manual, IIRC, about how the speed/temperature signal is multiplexed to go into the PR. It shows the resulting waveform, etc.

The CA can't demultiplex this signal by itself, so you would have to use the separate speed and temperature siganls from the PR to feed the CA. (or build a circuit to do it)

If your PR doesn't support the multiplexed signal input and have separate outputs to the CA, then you'd probably have to go into the motor and disconnect the speedo from the temperature signal, and run it out separately if possible, or just use temperature from the motor and use an external wheel speed sensor.

Note that if you are using a wheelspeed sensor on a PR, and that sensor isn't read often enough by the PR, it can transition to using the motor hall signals to feed the CA with a speed signal that is then many times faster than it should be. There is no way to disable this behavior that I am aware of; until they change the firwmare on the PR to not do it or to give the option to not do it. I don't know when the problem started, but suspect it's always been that way, but it's been reported on PRs as new as v6 IIRC. (there's at least a couple threads around here about it).

 

[slaphappygamer]

V4 and up have the demux circuitry.



The V2 doesn’t seem to have this circuitry. I also don’t see mention of thermal rollback and the pinout for a temp sensor in the V2 manual.

 

[irf23]

There is a note in the PR manual, IIRC, about how the speed/temperature signal is multiplexed to go into the PR. It shows the resulting waveform, etc.

The CA can't demultiplex this signal by itself, so you would have to use the separate speed and temperature siganls from the PR to feed the CA. (or build a circuit to do it)

If your PR doesn't support the multiplexed signal input and have separate outputs to the CA, then you'd probably have to go into the motor and disconnect the speedo from the temperature signal, and run it out separately if possible, or just use temperature from the motor and use an external wheel speed sensor.

Note that if you are using a wheelspeed sensor on a PR, and that sensor isn't read often enough by the PR, it can transition to using the motor hall signals to feed the CA with a speed signal that is then many times faster than it should be. There is no way to disable this behavior that I am aware of; until they change the firwmare on the PR to not do it or to give the option to not do it. I don't know when the problem started, but suspect it's always been that way, but it's been reported on PRs as new as v6 IIRC. (there's at least a couple threads around here about it).

Thanks for this. Good tip about the CA speedo with the PR.

V4 and up have the demux circuitry.

View attachment 370485

The V2 doesn’t seem to have this circuitry. I also don’t see mention of thermal rollback and the pinout for a temp sensor in the V2 manual.

Appreciate the confirmation.

Given these replies, I wonder if the only plausible solution is demux the signal and feed them to the CA for accurate speed. I would need to pop open the CA to replace the hardwired speedo.