Issue With Unity and Metr.at Module while Logging data

Yes if you can figure out how to link that record it would be very helpful to get to the bottom of it.

1 Like

@CiscoV if you go to your metr app and select the record and then click upload options it’ll create a sharable link

2 Likes

@Deodand
https://metr.at/r/4pMOi

4 Likes

Yeah brother. Thank you. All I had to do was copy it :man_facepalming:t2: Lol

1 Like

it looks stuck at constant motor current not constant speed…

Happened to me too with a flipsky remote, but I wasnt on the board and good thing the board got stuck under a car tire and did burnouts for a good while

2 Likes

Hm ok yeah so this isn’t cruise control which is good to know. The motor amps got locked to 40.5 which would be consistent with the ppm getting locked. The only question now is whether the reciever was continuously sending that ppm value corresponding to the amperage or if the unity locked it in for unknown reasons.

3 Likes

Whatever it was bitch didn’t wanna slow down haha.
Constant motor amps= constant speed with my ass on it

4 Likes

Damn, homie I’m glad you ok … this fuckin blows

3 Likes

Can you try slamming throttle around on the bench? See if you can get it to glitch again? If it’s possible to repeat it gets really simple to diagnose.

3 Likes

you can see the motor current line is more flat than the speed during the “issue”

1 Like

Yeah. It’s odd. Specially since it happened right after the fw update

Shouldn’t the board “throttle response” die if turn remote off while riding!?

Yes one would hope that would be what the receiver would do but since it is black box to me it is difficult to say for certain. I can imagine a glitched state that would continue to send last ppm signal if certain fail-safes aren’t in place. Both receiver and the unity would get power-cycled and reset.

I know within the firmware there is a timeout running that will cut motors if the receiver quits sending commands which is the only reason this seems likely to me.

2 Likes

the “consumption” line momentarily drops to “0” before the motor current locks at 40a…

1 Like

Yeah this seems to happen a few times during the log. doubt it’s related I think it is probably just an incorrectly interpolated datapoint or something.

If he can reproduce it on the bench while connected to the Unity desktop tool with heartbeat enabled and all that stuff, dunno… will it throw an error in the terminal or will the desktop tool output an error that might point to a cause?

I am curious to know if communication would stop or not from the Unity if he were able to reproduce it while connected to PC with realtime data streaming to the desktop tool.

1 Like

the other dips i find in “consumption” appear associated with actual drops to 0 motor current

2 Likes

Yep, good catch.

It looks like the unity was able to continue reporting data through metr so I doubt it. the best thing would be if he could get it to glitch and unplug the receiver. If it continues on in glitched state its unity side. You might want to run metr log when running such a test, its best to reproduce same circumstances.

2 Likes

That was right around the time I was passing a cyclest. Sometimes I tend to let off the throttle n reposition my feet. Specially around people that can’t see me I slow down a lot for them Idk if that explains that line dropping down to zero

3 Likes