Cycle Analyst Speed Sensor All Over The Place

[chuyskywalker]

Setup: Main players: CAv3, PhaserunnerV6, MXUS XF19-FAT motor (has combined thermal and rpm pulses on one wire)

What's Working: Phaserunner is able to separate out the rpm/thermal signals no problem, debug screen (with wheel size and 1 pulse per rotation set) I see a km/h speed reading I would expect whether under motor power or pedal power. The motor temps come across fine as well.

Problem: The CA, sometimes, shows the speed all over the place and, as a result, is killing output throttle making the motor stutter start/stop.

Sometimes I turn the bike on and it's working fine and dandy showing me exactly the right speeds under both conditions. Other times, however, it turns on and thinks that I'm going 88mph no 15mph no wait 145mph hold on 8mph nah 75mph uhoh 15,043mph. Point is, it's all over the damn place and this triggers the CA to go into "over speed" mode or something and pulls the throttle down (even though I'm in bypass, which is odd...). This makes the motor stutter all over the place and is generally unrideable.

Theory: So, it would seem like there is some kind of occasional interference/noise on the signal line. I figured, maybe it was because I had the WP8 plug bundled up near a battery cable, or threaded through the internal housing, or bunched up with all the other junk at the top with the CA. So, I separated out the WP8 cable and pulled it waaaay off to the side, yet it still has the speed signal bouncing all over the places.

I did some searching around here (1, 2) but didn't quite pull up anything similar yet. I don't really want to go and have to install an external speedo, seems like a waste if I can figure out where the interference is instead.

Not really sure how to further debug what gnarly thing I've done to make this temperamental. Thoughts? Thanks!

 

[amberwolf]

The most common thing I've seen cause this is a connection fault on the speedo line into the CA, anywhere from the internal PCB all the way to the source of the signal. But because you're in Bypass mode, I don't think this is the issue.

If you're in Bypass mode, no CA limiting applies, so it is more likely to be the controller doing the limiting. If that's the case, it means the signal is already dirty before it reaches the controller.

What's the speed limit set to in the PR? (max available is 256.0 km/h, AFAICR, which is around 160mph, so you could try setting to this and see if it stops or reduces the stutter/etc, as a test to see where the limiting is occuring.)

Also, do you actually see the capitalized S on the CA's diag screen, indicating the speed limit is engaged? What is the speed limit set to in the CA? I think the max is 500kmh.


Once we know where the problem starts, we can start figuring out solutions.

 

[chuyskywalker]

Caught the behavior in a quick video:

 

[chuyskywalker]

The most common thing I've seen cause this is a connection fault on the speedo line into the CA, anywhere from the internal PCB all the way to the source of the signal. But because you're in Bypass mode, I don't think this is the issue.

If you're in Bypass mode, no CA limiting applies, so it is more likely to be the controller doing the limiting. If that's the case, it means the signal is already dirty before it reaches the controller.

What's the speed limit set to in the PR? (max available is 256.0 km/h, AFAICR, which is around 160mph, so you could try setting to this and see if it stops or reduces the stutter/etc, as a test to see where the limiting is occuring.)

Also, do you actually see the capitalized S on the CA's diag screen, indicating the speed limit is engaged? What is the speed limit set to in the CA? I think the max is 500kmh.

Yeah, the capital S pops up and on that same screen you can see the output throttle voltage drop to nothin. I also confirmed that I am in throttle "Pass-thru" which makes the throttle signal cutting out...odd. I wouldn't assume it would do that, but it does. I can clearly see the s going S and the voltage out being cut to 0.9v.

I know it's not likely the controller as, for verification, I hooked up a throttle and key to the phaserunner mains cable directly (unplugging the CA) and reconfigured the throttle input to match and the bike throttles juuuust fine. No issues on speedo from the laptop PRSuite debug screen. Even managed to take it around the block without issues.

 

[amberwolf]

Pass-thru still applies limits. Bypass does not.

But if the problem doesn't happen when the CA isn't providing the throttle, then it's likely there is a connection issue between the PR and the CA, or the PR's speedo signal output is erratic for some reason.

 

[chuyskywalker]

Wait, my bad, pass-thru != bypass; I had it on pass-thru (which does cut out). I switched it to bypass and, yes, it doesn't cause the motor to stutter out because of the sS behavior. However, the speedo being wonked is still present for sure.

 

[chuyskywalker]

then it's likely there is a connection issue between the PR and the CA

Which is a bummer because the CA and PR are both a grand total of 2 weeks old. I'll double check the pins, but I really doubt I've bent anything there. I guess I could open the CA and take a peek at the solder joint on the SPD pad -- but this seems really unlikely. Perhaps time to ping the Grin support email with a link to this thread.

 

[amberwolf]

First thing I would verify is that the speedo signal is good right out of the PR's connector. How to do that depends on what testing stuff you have available. If nothing else you can use a powered speaker with it's own volume control (very important for this if you like your ears) and setup a wire to it's amp input to feed it the speedo signal. (ground of the input goes to system ground)

Turn the volume almost all the way down, then start running the wheel motor, offground testing. The tone will go up in pitch with speed, and be consistent, if there is no signal fault.

If there are glitches in the pitch of the signal, the signal itself is already corrupted at that point in the signal path.

If you have an oscilloscope you can visually see the signal quality and shape and everything else.

 

[chuyskywalker]

If there are glitches in the pitch of the signal, the signal itself is already corrupted at that point in the signal path.

So, what I hear you saying, is that I have to buy an oscilloscope now? Guess I gotta! ;D

 

[amberwolf]

If you need the excuse, sure. There's some posts about which ones are good around here, mostly in the motor-controller-design threads.

But I've used the powered speaker trick to monitor signals plenty of times; as long as you can tell something useful from the pitch or the volume, or some other quality, it's very useful.

 

[chuyskywalker]

Amazon delivered the $30 scope. Only one lead, but good enough for me!

I took a WP8 extension cable and split it open and connected the ground and yellow speed wire up.

Here's a capture of a good startup where the speedo is working correctly followed by a bad with nothing in between but a simple restart the CA by way of the mutilfunction switch.

On the good run it's clearly doing what you expect, sending a pulse with every rotation. And then after the restart the pulsing goes NUTS.

One thing I did note, but I don't think is *wrong* per se, but worth pointing out:

Since I had to adapt this plug to the weird one for the motor, and since the motor combines signals, I connected the motor's "combined" wire (white from the motor) to the Grey (Thermistor) on the L10 connector. I took the speed sensor wire and combined it with the ground to pull it low so it would not float around and confuse the phaserunner.

Maybe the PR is doing this?

The Phaserunner V6 will automatically select the source of the wheel speed signal for vehicle speed measurement. If there are speed pulses present on the wheel speed sensor pin then these will be mapped automatically to the Cycle Analyst plug. If no speed pulses are detected even after the motor is spinning, then the motor Hall signals will get fed to the speed signal input instead.

If the CA is getting speed pulses from a hall, in this geared motor, it would be going WAY faster than expected (and also not going while coasting, a common problem with freewheeling geared hubs).

I wonder if there is an override in the PR that I can say, "No, only listen for pulses on the thermistor line, please".

 

[amberwolf]

If it does have such an override, it will be in the Dev Screen tab, in the Address list. Unfortunately it's not a dropdown with a readable list, you must use the little arrows (or your keybaord up/down keys) to change to each address in turn. IIRC, 193 is the sensor source, but I don't know what value you enter for each possible source, or what those sources are, or what happens if you enter an invalid number. :/


Maybe just connect the thermistor and wheelspeed wires on the connector, so that the PR gets the data on both lines and can decide what to do with it?


The reason it can go wonky reading a motor position hall sensor is all the electrical noise inside the motor, stray phase fields inducing noise into the sensors themselves , and even the phase currents in the cabling inducing noise into the wires.

Also, a motor hall requires the pole count for the motor in the Wheel Speed Pulses Per Rev field, and will read a MUCH higher speed than reality if that field is set to the low pole count of a typical separate wheel speed sensor (1, or 6, usually).

 

[chuyskywalker]

Maybe just connect the thermistor and wheelspeed wires on the connector, so that the PR gets the data on both lines and can decide what to do with it?

It's combined signal from the motor; not two separate wires. (I wish it was, that setup has always been more reliable in my experience, and annoyingly, this connector actually has two unused wires still so it could have been setup like that.)

Maybe I can look into demuxing them from inside the motor...though I have no idea how that is combined in practice and if it could be decoupled, easily anyway.

Also, a motor hall requires the pole count for the motor in the Wheel Speed Pulses Per Rev field, and will read a MUCH higher speed than reality if that field is set to the low pole count of a typical separate wheel speed sensor (1, or 6, usually).

This motor's pole count, in the PR config, is 75 and I vaugely recall that the CA will only let you set up to 36 pulses/rpm. So even if that's what's going on, it's unlikely to work.

If it does have such an override, it will be in the Dev Screen tab, in the Address list. Unfortunately it's not a dropdown with a readable list, you must use the little arrows (or your keybaord up/down keys) to change to each address in turn. IIRC, 193 is the sensor source, but I don't know what value you enter for each possible source, or what those sources are, or what happens if you enter an invalid number. :/

I'll shoot off an email to Grin; I think it's time for some deeper expert opinion. Pretty sure "I bought an oscilloscope to investigate" falls in the camp of due diligence

 

[chuyskywalker]

Well, I can quite positively say it's something in the Phaserunner doing this. I made a extension to go in between the motor and phaserunner sense wires so I could hook the scope up to read what the motor is putting out, just to make sure it wasn't doing some nasty junk (as was pointed out could happen).

Here's the video:

I was able to see the motor outputting the normal temperature voltage value (0.3v as it's nice and cool here) and as I rotated it by hand or under power, you can see the 0v drop out pulses that are expected as speed pulses. Everything looks good, then I power on/off twice to catch the badness where the CA is showing 70-80mph nonsense yet the pulses from the motor are still chugging away perfectly in time.

It's got to be something in the Phaserunner which is mixing up the signals being sent to the CA; I'm more and more leaning towards it picking to forward a hall sensor instead of properly demuxing the combined signal -- just not sure why.

 

[E-HP]

If you need the excuse, sure. There's some posts about which ones are good around here, mostly in the motor-controller-design threads.

My intermittent full scale current/power reading on my CA started happening again recently. I already know it’s the connector I’m using for my external shunt; but is that a good enough excuse to buy one too?? Spraying the connector with Deoxit once a year works, but I’ve always wanted a scope.

 

[E-HP]

Well, I can quite positively say it's something in the Phaserunner doing this. I made a extension to go in between the motor and phaserunner sense wires so I could hook the scope up to read what the motor is putting out, just to make sure it wasn't doing some nasty junk (as was pointed out could happen).

Here's the video:

I was able to see the motor outputting the normal temperature voltage value (0.3v as it's nice and cool here) and as I rotated it by hand or under power, you can see the 0v drop out pulses that are expected as speed pulses. Everything looks good, then I power on/off twice to catch the badness where the CA is showing 70-80mph nonsense yet the pulses from the motor are still chugging away perfectly in time.

It's got to be something in the Phaserunner which is mixing up the signals being sent to the CA; I'm more and more leaning towards it picking to forward a hall sensor instead of properly demuxing the combined signal -- just not sure why.

Did you scope the signal the CA is receiving? You might need to open the CA.
Never mind. I looked at the video full screen and your test points cover that.

 

[amberwolf]

It's combined signal from the motor; not two separate wires. (I wish it was, that setup has always been more reliable in my experience, and annoyingly, this connector actually has two unused wires still so it could have been setup like that.)

Yes...but the PR is only getting them on one wire. What does it do if it gets them on both wires? Does it then always correctly see there's a speed signal? (just theorizing)

FWIW, you can rewire the motor's sensors internally, so that they then use separate wires, if you prefer this. PITA, but if you have the available wires....

AFAIK the only thing they do to combine them is to wire them both up to the same wire. To separate htem, make it so the thermal sensor has it's own wire to the non-ground end, and the speed sensor signal output has it's own wire to the non-ground end. If there are any resistors from either signal to the 5v or the ground, you can disconnect them.

This motor's pole count, in the PR config, is 75 and I vaugely recall that the CA will only let you set up to 36 pulses/rpm. So even if that's what's going on, it's unlikely to work.

It won't work anyway since sometimes it does read the right speed signal, and then you won't get the right reading with the pole count set "wrong" to try to match the motor hall signal.

 

[amberwolf]

My intermittent full scale current/power reading on my CA started happening again recently. I already know it’s the connector I’m using for my external shunt; but is that a good enough excuse to buy one too?? Spraying the connector with Deoxit once a year works, but I’ve always wanted a scope.

The current / power reading isn't a pulsed signal, so the scope won't show you anything a voltmeter wouldn't, other than any electrical noise on the line (which isn't what's causing the issue).

So, you can buy the scope if you want, but it's not the most useful tool for this specific situation.

 

[chuyskywalker]

Yes...but the PR is only getting them on one wire. What does it do if it gets them on both wires? Does it then always correctly see there's a speed signal? (just theorizing)

Ah, I see what you mean. The manual states that it only looks for the "combined signal" on the temp line. I don't know what would happen if I fed it to the speed line as well. I would hope that the fact that it has a variable voltage wouldn't matter since it should still just be looking for pulses, but maybe the non-static voltage would mess up the pulse searching logic or something.

I'll wait back to hear from Grin if they have any theories; this really feels like a bug/deep-configuration issue in the PR that I can address with some setting.

It won't work anyway since sometimes it does read the right speed signal, and then you won't get the right reading with the pole count set "wrong" to try to match the motor hall signal.

Lol, that too. Would be a poor remediation, "just restart the bike repeatedly till the MPH is accurate."

 

[chuyskywalker]

I heard back from Grin, we nailed it:

This is an issue related to the demux circuitry in the newer Phaserunner and Baserunner motor controllers. Your assumption is 100% correct. If the controller sees a valid speed pulse signal, it will use the speed line as the input source for the speed pulses. If it doesn't see any pulses on the speed input line before a certain number of hall transitions occur, it will instead use the motor hall signals as the speed input source.

Is it possible that your MXUS motor only has a single magnet sensor for the wheel speed indicator, rather than 6 magnets as is more commonly the case? If so, you can solve this just by gluing in more magnets for the speed pickup. Most of the shells have spaces for 6 internal magnets but to save cost they often only populate 1 of them.

They also correctly intuited that the motor only has a single magnet -- thus only 1 pulse per rotation -- despite there being 6 available magnet spots. This means that if the magnet is juuuust past the reed switch, the controller will see dozens and dozens of hall transitions before the first speed pulse. It also makes, to an extent, logical sense that once a speed reporting method is determined, you wouldn't re-run that logic later on -- most bikes don't have motor hardware added to them mid-ride

No software remediation is available, so I'll likely open up the motor shell and add the 5 "missing" magnets to get the pulses to show up early enough to avoid this problem.

 

[amberwolf]

At least there's a fix, even if it's not the easiest one.

 

[ebikebuilder]

I heard back from Grin, we nailed it:

This is an issue related to the demux circuitry in the newer Phaserunner and Baserunner motor controllers. Your assumption is 100% correct. If the controller sees a valid speed pulse signal, it will use the speed line as the input source for the speed pulses. If it doesn't see any pulses on the speed input line before a certain number of hall transitions occur, it will instead use the motor hall signals as the speed input source.

If so, you can solve this just by gluing in more magnets for the speed pickup.

hey mate I just wanted to say THANKS, i have my BBSHD wired up with an L10 motor cable to a Phaserunner V6 L10. And have been plagued by this behavior for a while on a few of my bikes.

In my case I have a BBSHD wired up to a Phaserunner V6 L10, using an L10 motor wiring harness that I wired into my BBSHD, at first i had NO SPEED SENSOR installed, and i was getting crazy 100+MPH speeds, causing everything to cut out and stutter like crazy, and Grin tech couldnt explain where a speed signal might be coming from when I have NO SPEED SENSOR INSTALLED (apparently not all Grin customer support are aware of their controller intricacies)

Then I ADDED A SPEED SENSOR, and wired the wheel speed signal wired through the L10 connector, and I just have one magnet on my wheel, that fixed it 99% of the time on my 29er and it only has 1 magnet, I think if i added a 2nd magnet to that bike it would completely fix the problem.

BUT on my 20" wheel bike, that is geared very low, where the motor often spins crazy fast relative to the wheel (especially when first launching), this phaserunner cutting out due to phantom speed behavior was a complete show stopper. If I would give it half throttle and take it easy it wouldn't happen, But give it power and it constantly cuts out. Had to set the wheel diameter to 1MM in the CA to even get the bike to do anything, with a wheel speed sensor installed with 1 magnet. I have a feeling that bike will need probably 4, 8, or more magnets, it was really bad with that one. Especially riding in high resistance terrain like sand, where the wheel was barely moving, and the motor could really be spinning.

Hopefully that made sense its like midnight here and Im barely making any. but in any case this post helped me out , thanks a ton for documenting this issue !!

 

[chuyskywalker]

(apparently not all Grin customer support are aware of their controller intricacies)

To be fair, when I got into the nitty-gritty details, it was Justin that started replying

But, yeah, add a few more magnets to fix this. Or roll the bike to have the magnets activate before letting the motor spin up. If the PR sees pulses on the speed wire first, it'll take that and it won't re-evaluate again.