Phaserunner startup issues (v6 and v1, each running an Ultramotor)

[amberwolf]

So...this is probably going to be complicated, and requires some explanation of the setup, both as it is now where it doesn't work right, and as it was before when it did work fine. So...apologies for the length. I'm very tired after working on this for the last 12+ hours, so I'll probably miss things, if you have questions I'll clarify tomorrow.

Previous working setup was:
-- a just-prior-to-last generation Grinfineon in sensored mode running an MXUS 450x (can't remember which winding) on the left rear wheel of SB Cruiser,
and
-- a Phaserunner v6 running an ex-A2B Ultramotor on the right rear wheel.
-- Both in ~21-22" wheels (actual tire diameter).
-- Both driven simultaneously with paired throttle inputs from Cycle Analyst, but same results happen from direct throttle input so it isn't a CA issue, hence the CA's setup isn't covered here.
-- I could gently roll on throttle, or pedal, and slowly and smoothly accelerate or roll at just a very slow walking speed, or full on throttle or pedal fast and accelerate rapidly and smoothly up to 20MPH, completely silently in either case, from the motors.

Then on my way home from work Saturday, something large and metal fell off the back of a truck full of junk as it passed me, and went under my left wheel before I could do anything about it, and damaged the tire; I was forced to ride the remaining mile and a half or so on the flat, with four broken spokes. Surprisingly the rim itself wasn't apparently damaged; all previous road-debris/condition encounters have damaged the rim and not the spokes (and sometimes the tire but not like this).

Anyway, since I already had the rim and spokes and spare Ultramotor, and had already planned to do this whenever the time and energy happened simultaneously, I decided to change the entire wheel out now. The plan had been to just swap the wheel out and run it off the Grinfineon as the MXUS had been, but the Andersons on the cable with the UM were apparently so poorly crimped (from factory?) on the controller-side cable extension that two of the contacts and shells just fell off as I was lacing the motor into the rim. Since I was going to have to redo the connectors anyway, I thought "hey, why not try out that old PR v1", so I set the motor up in a bike frame upside down as a test stand, since I hadn't put a tire and tube on it anyway. The PRv1 successfully autotuned the UM, though interestingly even though they're both ex-A2B motors they're different windings:
--rightside ultramotor 102.0mohms 571uh 8poles 8.81rpm/v
--this leftside ultramotor 76.0mohms 394uh 9.21rpm/v
and the PR insists that the green hall is stuck high, and yellow hall stuck low, so it will only run sensorless. I haven't manually tested the halls yet, but they do activate on the PRSuite dashboard tab, as I manually slowly rotate the wheel, so they aren't actually stuck and I don't get why the PRv1 thinks they're stuck. So I left it in the sensorless mode it defaults to when this happens, and saved all the parameters to the PRv1, along with my working system settings as used on the first PR (v6), such as battery voltage, throttle range, regen, etc etc.

All other settings in the PRv1 are (like those in the v6) left at the PR defaults. No manual tuning of the system has been done, as none was needed on the PRv6 to make it work "perfectly".


I then spent a few hours getting the new wheel onto the SBC and mount the PRv1 and wire it in (no need to detail that here). Then I test rode it around the yard, and it performs AWFULLY, even the PRv6!

Issues:
--Because the PRv1 is running sensorless, it pretty much ALWAYS jerks backwards before going forwards...I'd expect a 50/50 chance of the right direction, but I think it happened only once in all the startups (under load or offground...offground is a problem because the pedal drive chain goes to that motor, to a freewheel on the inboard (left) side of it....) There's no errors or LED flash codes.
--The PRv6 is jerky and noisy; feels as if it's running intermittently on a single phase, or a sensor problem, but there are no LED flash codes and no errors on the PR setup program. Nothing has changed on that wheel or motor or wiring, so it should perform exactly as it did beforre, which should be working perfectly.
--Between the two of them it barely will even get started from a stop on PAS, and mostly can't start from a stop on throttle. If it weren't for my pedalling pushing it started forward, it probably wouldn't start from a stop on PAS either.
--Once it does get going, it still feels rough and doesn't have the push it should, especially for a system with two PRs on it, set to 90A phase, 40A battery, 52v system. (normally with the previous setup it would pull up to 80A between the Grinfineon and the PRv6 for a few seconds as it hauled me up to 20mph....not seeing more than 10A *total* now, which is ridiculously low for this setup).
--sometimes, but not always, the UM on the right side run by the PRv6 makes hissing sounds (like I used to hear from the MXUS motors when I was testing the SFOC5 several years ago, as a natural part of how that controller worked). I don't recall that ever happening before with the PRv6, and the PRv1 isn't doing it.

I gave up at midnight because I couldn't focus my eyes on tools and wires anymore, went inside and have been writing this up as I doze and wake; eventually hopefully I'll really fall asleep but no sign of that yet.

Tomrrow (well, today, since it's about 2am now) I'm going to put PP45s on the UM's extension cable and verify it's hall sensor operation, then set it up with the Grinfineon, and see if things work correctly at least on that side, and see if ti makes the PRv6 suddenly magically work right.

Any ideas are welcome, keeping in mind that the PRv6 / UM combo on the right side worked perfectly fine with all it's settings exactly as they are right now, until I swapped out the leftside motor and controller....I just don't get it. :/

The PRv1 hasn't been tested (by me, anyway) until now, and neither has the UM it's running, so either or both of those could actually have a problem, or there may be manual tuning required.

 

[offGridDownUnder]

Both driven simultaneously with paired throttle inputs from Cycle Analyst, but same results happen from direct throttle input so it isn't a CA issue, hence the CA's setup isn't covered here.

Amberwolf is asking for help?

But seriously, how does each motor work when they are completely separated?

 

[E-HP]

Can you swap phaserunners to test if the symptons follow the controller or motor?

 

[lnanek]

That's interesting that a PRv6 can start from a stop without a little push. My BRz9 has never been capable of that. Will have to update the firmware, and worst case, upgrade to latest hardware.

Re OP, that's a super heavy trike with dual drive, isn't it? Maybe PRv1's sensor less algorithm that tries to jerk the wheel forward and back to get a little back EMF to start sensing motor position doesn't work in that case. Heavy trike moves less than a bike, and it's got another motor doing its thing side by side also complicating the movement. Theoretically there might be a sensor less start delay/strength parameter that could help with the former, but not sure anything would have been programmed to deal with the latter.

 

[amberwolf]

Amberwolf is asking for help?

Well, as much as I'd like to, I don't know *everything*. :lol:

But seriously, how does each motor work when they are completely separated?

The same as they do together. They suck. One of the tests I probably forgot to post was disconnecting power to each PR in turn and retesting, expecting the v6 to work normally, figuring that the v1's jerk-start-in-reverse thing might be causing the v6 to start wrong...but no difference.

I don't know how the PRv6 and Grinfineon did separately, as I don't recall ever needing to try that.

Can you swap phaserunners to test if the symptons follow the controller or motor?

Not easily, but yes. First I'm going to just try the Grinfineon in place of the v1.

While both motors are "the same" (ex-A2B Ultramotors), only the left one of them has the A2B connector on it, with the A2B controller-side harness wired up to the v1 (since that had no connectors on the cable). The other one was just the cable, no connector, so I wired it up to half of an L10 extension cable to plug into the L10 PRv6.

So to swap them I have to take the L10 extension off the right motor and wire it to the A2B controller-side harness, so the PRv6 L10 can plug into the leftside motor. Then connect the bare cable from the PRv1 to the bare cable of the rightside motor.

That's interesting that a PRv6 can start from a stop without a little push. My BRz9 has never been capable of that. Will have to update the firmware, and worst case, upgrade to latest hardware.

Well, it did before, paired with the Grinfineon. Now, though.... ;(

But normally it doesn't have to completely startup on it's own, as I have the pedals geared super low so that I can push it just a little bit with them and start and ride completely via PAS. When I'm on an uphill slope, or my joints just hurt too much, I have to use the thumb throttle as a "get-started button".

Re OP, that's a super heavy trike with dual drive, isn't it?

Yes. With me on it it's probably a few hundred pounds. With various changes since the last time I actually knew it's weight, I lost track of it's actual weight and don't have scales I can use to weigh the whole thing anymore, but I would guess that it's 400-500lbs with my 200lbs-ish on it.

Maybe PRv1's sensor less algorithm that tries to jerk the wheel forward and back to get a little back EMF to start sensing motor position doesn't work in that case. Heavy trike moves less than a bike, and it's got another motor doing its thing side by side also complicating the movement. Theoretically there might be a sensor less start delay/strength parameter that could help with the former, but not sure anything would have been programmed to deal with the latter.

There are sensorless start specific parameters on the main tab of the PR suite; I have not done anything with the defaults yet.

I'm sure they don't know how to deal with the other motor (on the right side, v6) but the v6 is running sensored, and works normally, so it should move forward normally and help the v1 get started.



What I suspect could be going on is that the PRv6 may never have been able to completely start on it's own, and the Grinfineon was helping it, masking the issues like you've had. Now that it's paired with a sensorless-can't-start-properly v1, it's just not able to do what it did before. I really hope that's not the case, since it worked amazingly before, and I don't know why it couldn't now.


So..I'll try the Grinfineon shortly, now that I'm "awake" enough to safely work on it.


If the GF works and returns it to the way it was, then I'll probably just have to leave it that way for now.

If it doesn't (since it may only work sensorless as well), then to fix that problem I'd have to unlace the UM and fix it's halls, if they are actually bad, and it's not a wiring issue. Once they work, then retry the GF, and if it all works then at least I'll be ready for my workweek tomorrow. But I'm not sure I have the time/energy to do a wheel uninstall, unlacing, testing, fixing, relacing, reinstall, and retesting, and still get enough rest to work the next day...because once I take the wheel off and start unlacing it, I'm committed to a minimum of several hours of working on it, because it has to go back on the trike and be working before I can rest.

We'll see.

 

[amberwolf]

Success!

It now rides (almost) as good as it did before this whole mess started (except for regen; see below). It will smoothly startup from a stop via throttle or PAS, and run powerfully (or minimally, or anywhere between) all the way up to the 20mph limit. It might even be a bit torqueier, a hair quicker from 0-20, but I can't really verify it without testing the new configuration against the old one, and that's not worth all the hardware changes back and forth I'd have to do. It's good enough, and it works.




So...the PRv1 issue turns out that whoever installed the motor cable on there (factory?) swapped the white wire and the green one. AFAICT the green wire is a thermistor, NTC, that reads around 3kohms when the motor casing is very warm (but not hot). I forgot to check it's value when the motor was ambient; have to do that later once everything's equalized.

The white wire is one of the motor position halls, and all three of them work normally, powered from and pulled up by either the PRv1 or the Grinfineon. All the other wire colors are as expected for their functions, just greend and white swapped. Wierd.


Since I'd already unwrapped the wiring to get to the hall wires, I went ahead and tested it with the GF; but I went thru every hall/phase combo and found only one "forward" combination and no reverse ones that were correct (some false positives that were too fast or noisy). I suspect I was having connection issues during this, at the hall wires, so I removed the JSt and got out the tiny version of the PosiLock connectors I was already using to test the phases with (whcih work nicely for temporary connections, probably even permanent ones). But it didn't make a difference, and I still only found the one forward, and I suspect it is also a false posiitve even though it is only 1.68A full speed no load current, and the right speed at full throttle, because both controller and motor get warm very quickly under load, while the PRv6 and it's motor don't, even with sharing loads equally (about 75A peak for a few seconds at startup from a stop till I near 20mph). It was also noisier than normal--not trapezoidally noisy, still running sine mode (sensored), but not quite right.


I reconnected the leftside UM to the PRv1, but this time with the white wire instead of green , and autotune now ran successfully as sensored. Testing offground no load worked as it should, with no reversals or any other unexpected behavior.

Test ride was as expected, just as good as before all this started when using the v6 and GF with the MXUS.

The only part that is worse is regen braking--the GF provides what little regen it can as soon as I apply the variable brake, at whatever level I apply, regardless of speed. But like the PRv6, the v1 doesn't even begin applying braking unless I'm below around 10mph (forgot the exact speed). At that point it brakes pretty hard; they're both set to 20A battery / 90A phase, which the PR setup program says is around 90-something Nm of force. (don't know where it calculates that from).

There aren't any settings I can find for what speed regen begins at. I scrolled one at a time thru the 512 individual addresses in the PR setup program (without a controller connnected) to see what they all are (as there is no list, and you can't search for anything in the program****), and nothing in the addresses, either.

I'm still poking thru the long Phaserunner development thread

Compact Field Oriented Controller, ASI + Grin, limited run - ES 1.0 Graveyard

to see if there's any info about this there, but nothing so far in the first few pages, and nothing elsewhere on the forums about why regen doesn't start until you're below a certain speed, and where that limit is stored in the PR. (it's definitely not a CA thing; the PR is getting the braking voltage, verified via the Dashboard tab in the PR software, regardless of system speed--it's just not doing anything with it until it drops below this limit).


This isn't a dealbreaker, but it's RFA.



At some point I'll have to figure out the issue with the GF and the UM phase/hall combo, to be sure I have a working combination I can use if I have a PR problem on a trip somewhere and have to use the GF as a backup controller. (I always have at least one extra controller left bolted to the trike, just not connected; it's saved me from trouble more than once over the years since I started doing that back on CrazyBike2).






I still don't know what the deal was with the PRv6, but suspect it has to do with the wierd hissing noise the motor was sometimes making (just sitting there doing nothing), which it isn't doing today. Since intermittent problems are almost always connections or wires, I verified all the hall and phase connections between the rightside UM and PRv6, but found no issues. There may be a wire damaged inside the cabling itself, so it may have problems in the future. It's working for now so I'm not messing with it, potentially breaking it completely without time to deal with it before the workweek starts back up tomorrow. :/


But at this point either PR will start me smoothly from a stop via PAS or throttle, which is required since it's a dual-motor system not just for the extra torque but also for the redundancy.

Each one by itself is very sluggish to do it, but it will do it, and that's good enough. Together they are much more powerful than just the separate performances added together--they multiply because each is helping the other, I suppose.







**** this post

Compact Field Oriented Controller, ASI + Grin, limited run - Page 49 - ES 1.0 Graveyard

shows a version of the setup software that once existed that did actually show a list of the parameters, and let you sort the list by name or address, though you still coudln't search for anything specific. Still way easier than the present version of the program, in that you could see a bunch of the list entries all at once, which is a whole lot faster to sort thru than a single line at a time.

the only way to get a list of parameters is to change their values, one at a time, then don't save anything to the PR, and then click the "list unsaved parameters" button that will give a dialog with that list. Not useful for the purpose of seeing what's there, since you'd have to manually go thru all 512 and change something in every single one to get them into this list...and then youv'e already seen the list, so there's no point!




Iv'e also attached a zip of all the PRv1 and v6 settings files, as well as screenshots of each tab for each version, both for others to use as reference if they need it, and to archive them for my own use later if I ever have trouble and don't have the files anymore for whatever reason.


Also, this post

The SB Cruiser : Amberwolf's 2WD Heavy Cargo Trike & Dog Carrier

I have a sister and a cousin who are both gluten intolerant. They both had to find it out on their own. Bread is not really a good nutrient anyway, like donuts it just tastes good. I have a friend who is borderline diabetic so he started wrapping his sandwiches in lettuce leafs instead of...

endless-sphere.com

has mechanical details, etc., and pics of the laced up UM and the damaged MXUS wheel, and the PRv1 mounting/heatsink.

 

[amberwolf]

That's interesting that a PRv6 can start from a stop without a little push. My BRz9 has never been capable of that. Will have to update the firmware, and worst case, upgrade to latest hardware.

Ok, so now that I've got this thing working again...maybe we can figure yours out:

What settings do you have on yours, and what's your complete setup/etc?

 

[amberwolf]

So while this system "works" and has so far been reliable since getting to that state (making me leery of experimenting with any settings), the two things that are less than optimal are:

--Acceleration. The trike accelerates pretty slowly up to around 10-12MPH, where it begins to pickup more rapidly. When i'm around 15MPH even a slight throttle goose pedalling a bit faster (cadence PAS from CA) will rapidly max me out to 20MPH.

--Braking. Opposite of acceleration problem: Above 10mph or so, regen braking is nonexistent, regardless of lever position. Below that, it will suddenly kick in hard (if lever is fully pulled) and get harder right up untiil I stop, where it begins jerking the wheel back and forth if I am still pulling the lever.



I would be happy enough if the two problems were reversed (slow acceleration after reaching 10mph, and no regen braking below 10mph). But...they are both basically the opposite of what i need them to be, and honestly the opposite of what I would have expected them to be.



I've already verified that throttle and braking voltage settings match what's actually being fed in at the PR throttle connectors (not just what the CA says is happening, since my wires are very long). Took a bit of adjustment from the screenshots previously attached, but not by much (those were set by what the CA says is being output). No change in behavior, however.


Both are hall start and sensorless run, fault tolerant hall / fallback to sensorless.

Phase amps are set to 90; I left battery amps at 40 on both (what previously was enough on the PRv6 in combination with the 30A Grinfineon).

Regen amps are set to 20. (battery is spec'd at 0.5C charge rate, and is a 40A pack, but very old***).

Regen HVC is set to 61.5v cutoff and 61v start.

LVC's are set to 42.2v cutoff, and 47.1v start.


No tuning of anything other than the above has been done, so all those settings are as seen in previously posted screenshots and the PRS files. Any differences between the two PR's settings there is from the default settings built into either them or the PR setup program's built-in profiles for those controllers, as I started from default settings for each one.

But even though there are differences in those settings, they do not behave any differently, as far as I can tell, in actual operation.




***Even at full charge of 56v (14s, 4v/cell because of it's age), it sags down to around 52v or more (depends on ambient soak temperature, as low as around 50F as high as around 70F right now) at startup acceleration of ~80A.

 

[amberwolf]

So...I either misread the previous info I linked from Grin about the advanced Dev Screen parameters (addresses / functions), or it doesn't contain the actual specific instructions on how to get to them (haven't gone back to looK), but today while looking for something to help Stancecoke over here:

Activate walk assist on an ASIBac500

Can someone give me a hint. I'm struggeling with an old ASIBac500 (firmware version 5.5190). I want to drive it with a simple analogue LED Display, using the "jog" mode (register 210 Assist mode source =1). Register 138 let you choose the input for the walk mode, but I don't know, if my firmware...

endless-sphere.com

I accidentally found how to get to this list, so now I can examine the list and find functions that may relate to my issues much much more easily.



To get to it, open the Phaserunner Suite program, and go to the Edit menu, and choose Edit Parameters (Alt-E then Alt-P).


That will bring up a dialog to select which parameters to edit, where you will click the + button:



That brings up this dialog with the actual list of parameters:



Note that I am not actually using this dialog or part of the PRS at the moment for anything other than seeing what all the functions are, so I don't know how it all works--I'm only using it to see multiple functions at once, instead of the one-at-a-time you're limited to in the dev screen (the only other place you can see them).

I haven't done anything with it yet, as I just found it...but as soon as I have more info, I'll post it here.

 

[amberwolf]

Found the window resizes, so here's a complete list of parameters/addresses in screenshot form, alphabetical by name (rather than the much less useful address order). Considered using an OCR website to convert this to text, but then I'd have to proofread and correct it, so this is what there is for now.

If I could just find the ASI documents that explain exactly what each of these does, and exactly what values in each are valid and what they do (or which bits set to on or off in the address (and how many bits each has) do what), then it would *really* be useful. But all the links I find to such documentation require an ASI login, and nobody has posted the actual documentation anywhere I can find.

Quite a few appear to be internal states to be read, rather than written to.

Some of them have the same address as others, implying that only some bits of that address apply to each parameter.

Using any of those would probably require the documentation, at least to use them risk-free instead of writing potentially hazardous values to them. (unless Grin has proofed the firmware against it, I would bet that the ASI firmware inside the PR has no protections against invalid or dangerous values for any of it's parameters, no checks against anything at all, given the various posts about being able to brick an ASI BAC by writing wrong values. Also other manufacturers like Kelly (and others) seem to have no protections against it either, at least in some FW in some controllers).



But just knowing which fields there are narrows down the possible things to explore, and a list like this makes that a lot easier to figure out.

So far I don't see any parameters that could have anything to do with the two issues I'm still having, at least by the parameter name itself.

 

[amberwolf]

OK, so, lots of testing during my work commutes later:

it's not that there is *no* braking happening above the ~10mph speed, it's that it's a *different kind* of braking, and however it is doing it is not sufficient to even feel the braking action (could probably detect it with GPS speed change logging, or an accelerometer).

Above that speed, it's totally smooth, and if I pull the lever full on, for the highest possible braking force (and current), at 20mph, I get about -26A peak reading on the CA, so it is regenerating current back to the battery from the motors. I don't know how much comes from each PR/motor set, as the current all goes back thru a single shunt, read by a single CA.

Once speed drops down to that speed, braking becomes rough, "cogging" like typical on/off regen braking on a generic trapezoidal controller, and it is MUCH greater force; the CA shows a positive 3.2 to 3.8A peak current at that moment, decreasing rapidly as the trike slows rapidly to a stop from there, in perhaps 20 feet (a couple of trike lengths or so, maybe a bit more).

So at that transition speed, it changes from regenerative braking to active braking forcing the motor to stop (as if you were reversing the motor direction for traction).

Below that transition speed, I can feel the left motor pulling (braking) significantly harder than the right; whether that's from the differences in the motor properties or something different in each PR's design/firmware, I don't know.

The difference is enough to actually skid that wheel in a left turn (since weight transfers to the other one), and if I'm slow enough when I engage the brake at the moment I start the turn (like into my driveway) it doesn't take much steering input to turn full 90 degrees left; the difference in motor braking on each side will do it for me.

On the straights I have to compensate for the leftward pull with steering input; it's not that much if I'm not already trying to turn.


But overall, this may give me something to work from to troubleshoot the braking issue.


I still don't know why acceleration is so low below the transition speed vs above it.

The battery current limits should be more than enough, at 80A total it should zip me right up to speed; it's at least the same as the Grinfineon plus generic controllers were...

The phase current limits I would expect to be higher on the PR than the others, but I have no way of knowing what those others could do; the PRs are set to 90A each.

There *is* a difference in motors: I"m now running two Ultramotors (albeit slightly different from each other), where before it was one UM on the right (first with the generic and then with the PRv6), and an MXUS 450x (3 or 4, dont' remember which) on the Grinfineon (until the wheel was broken by unavoidable junk falling off a truck). So, if the MXUS has sufficiently greater torque capability than the UM, it might be enough to cause the insufficient acceleration I get now vs what I had before the PRs.


If I can respoke the MXUS in a wheel I can use on the SBC, I can test this relatively easily (I just don't want to risk riding on that damaged wheel; it's missing four spokes and I'm pretty sure at least two more are completely broken but still sitting in their nipples, and I have no idea how many others are at the edge of failure and I don't want to crash because of a complete sudden wheel collapse.

 

[chuyskywalker]

So...the PRv1 issue turns out that whoever installed the motor cable on there (factory?) swapped the white wire and the green one. AFAICT the green wire is a thermistor, NTC, that reads around 3kohms when the motor casing is very warm (but not hot). I forgot to check it's value when the motor was ambient; have to do that later once everything's equalized.

I don't have much technical insight to provide here, but I will commiserate with you on that absolute head slapper of a moment.

 

[amberwolf]

I ought to be used to checking and verifying all wiring and not even *try* to assume that any particular wire color means a thing at all...but, I didn't, for that one. :/

Heck the Stromer Ultramotor had red, black, and white phase wires, and I forget what the hall wires were, but they weren't anything like usual either.

 

[kuromaku]

Once speed drops down to that speed, braking becomes rough, "cogging" like typical on/off regen braking on a generic trapezoidal controller, and it is MUCH greater force; the CA shows a positive 3.2 to 3.8A peak current at that moment, decreasing rapidly as the trike slows rapidly to a stop from there, in perhaps 20 feet (a couple of trike lengths or so, maybe a bit more).

So at that transition speed, it changes from regenerative braking to active braking forcing the motor to stop (as if you were reversing the motor direction for traction).

Below that transition speed, I can feel the left motor pulling (braking) significantly harder than the right; whether that's from the differences in the motor properties or something different in each PR's design/firmware, I don't know.

The difference is enough to actually skid that wheel in a left turn (since weight transfers to the other one), and if I'm slow enough when I engage the brake at the moment I start the turn (like into my driveway) it doesn't take much steering input to turn full 90 degrees left; the difference in motor braking on each side will do it for me.

I briefly had a setup that bore some similarity to yours, with a PRv2 and a PRv6 driving electrically similar Shengyi SX1 and SX2 motors. I found that the PRv2 uses plug braking, while the PRv6 does not (could your PRv1 also be plug braking at low speeds, causing the huge braking force and leftward pull?) Doesn't seem to be a way to disable the plug braking in my PRv2.

On the acceleration front, I had noticed some combinations of high phase currents at low wheel RPM with the PRv6 could contaminate the speed signal enough to cause the CAv3 to erroneously go into speed limiting and disturbing the PID loop until the phase currents got low enough for the CAv3 to read correctly. Swapped that bike over to dual DD motors, and swapped the PRv2 for a PRv6 and retuned both PRv6s for lower bandwidth to suit.

HTH