[PUp App] Bug, Limitation or Other?

[Hod Carrier]

1 hour ago, Toastie said:

OK, here's a little update; I'll stop it here, because I believe that @Hod Carrier has really found a nasty bug in the City hub's (2IO) firmware, regarding the SetPower command.

Yikes!! Sorry about that, chaps.

I have to say that I've not been following the detail of your discussions, but the one take-away I did get was that the Set Motor Speed block doesn't like being looped because of the demands on the software. Based on this I did a bit of thinking today at work about how to make the loop only run when there is a control input, so I did this...

...but it's only a partial success. The motors are now able to respond to more than a single input, but ultimately I still loose control over them from the controller and the bluetooth connection to the hub still drops out.

[Toastie]

1 minute ago, Hod Carrier said:

Yikes!! Sorry about that, chaps.

No, if it really turns out to be true (others need to verify that as well - as of now, there are two of us ;)) it is the other way around: Thank you very, very much!!! The most valuable input for any developer is sound and reliable error reporting. And the more input we supply, the better the response may be. >IF< anyone "responsible" reads this thread ... and cares ...

[I had remotely comparable experiences with other - custom - firmware: Dave Baum changed the NQC firmware code, because I was asking for the possibility of introducing short jumps. This has nothing to do with the issue here, but with "how to develop" firmware. He did, and I was super happy. It meant that a SCOUT could do much more, as it has only about 400 byte code memory capacity - and a long jump crunches 6 byte codes, a short 3. Yes, I am old school - memory was most of the time I was coding - an issue. It is not anymore. Here, we are facing a completely different issue: The firmware becomes unstable upon using the SetPower command. And it looks like: Always. That is a big issue ...]

12 minutes ago, Hod Carrier said:

but ultimately I still loose control over them from the controller and the bluetooth connection to the hub still drops out.

I can only confirm that: Regardless of what you do: Repeatedly calling the SetPower command >always< leads to a crash. And that is bad. OK, here we go, I am citing from my favorite movie:

"I'm fuzzy in all good-bad things. What do you mean, 'bad'?

    Try to imagine, all life as you know is stoppin' instantaneously and every molecule in your body exploding at the speed of light.

       Total protonic reversal.

That's bad. Ok. A' important safety tip. Thanks Egon."

OK. It is not that bad. But bad.

Thank you very much for bringing this issue up!

All the best
Thorsten

[Andman]

@Toastie, Thanks for the test. I cloned your code. I'm running the loop with 0s delay and just crossed 5500 cycles with the technic hub 88012-1. I don't have the hub 88009-1, so i can't test it. Which phone/tablet did you use? I tested it with a Nokia XZ2.

[Toastie]

4 minutes ago, Andman said:

I'm running the loop with 0s delay and just crossed 5500 cycles with the technic hub 88012-1.

Well, my thought. The thing is, I can't get 88012 to run the motor with my program. It connects, and then runs the program without any glitch (counting to "insane" numbers), but does not turn on the PUp L motor.

Do you have the motor attached?

Best
Thorsten

EDIT: Sh*t questions asked, no reply: I am using a Motorola Moto g8 power with Android 11 and PUp App - wait - 3.6.0. And I have the Spider App 1.0 running on the screen, as I dropped the damned thing two days ago - onto a concrete floor

 

Edited June 2, 2021 by Toastie

[Andman]

1 minute ago, Toastie said:

Well, my thought. The thing is, I can't get 88012 to run the motor with my program. It connects, and then runs the program without any glitch (counting to "insane" numbers), but does not turn on the PUp L motor.

Do you have the motor attached?

Best
Thorsten

 

I have the Boost Interactive Motor attached, But I have the C+ L and the C+ XL motor available too. Can quickly test now.

[Toastie]

3 minutes ago, Andman said:

Can quickly test now.

That would be nice!!!

@Hod Carrier: This is fun!!!

Edited June 2, 2021 by Toastie

[Andman]

L and XL are working. App v3.6.0 (11883). Firmware of Technic Hub is up to date as far as i can tell.

[Toastie]

10 minutes ago, Andman said:

L and XL are working. App v3.6.0 (11883). Firmware of Technic Hub is up to date as far as i can tell.

How do you tell, and how do I update?

Man, this is so cool - it says a lot ...

Edited June 2, 2021 by Toastie

[Andman]

Just now, Toastie said:

How do you tell, and how do I update?

At least the Control+ app updates the Firmware automatically once there is a new one available. I don't know if the Powered Up app does the same. So, since there was no notification for a new firmware, I assume it's up to date.

[Toastie]

Just now, Andman said:

At least the Control+ app

Wait, will call up that one ...

[Hod Carrier]

27 minutes ago, Toastie said:

No, if it really turns out to be true (others need to verify that as well - as of now, there are two of us ;)) it is the other way around: Thank you very, very much!!! The most valuable input for any developer is sound and reliable error reporting.

Thanks Thorsten. It seems that we're all learning plenty today.

28 minutes ago, Toastie said:

And the more input we supply, the better the response may be. >IF< anyone "responsible" reads this thread ... and cares ...

Ah. Hmm... 

[Toastie]

No chance, the app tells me "wrong connections", regardless of what model I am selecting.

Updates usually come upon connecting hub and app - with that colorful LED play. Nothing here.

Conclusion: Firmware is up-to date, or Moto g8 sucks, right?

@Hod Carrier: What device are you using?

 

[Toastie]

OK, there is another Technic hub here. Swapped batteries: This one does the LED color play and seems to load a new firmware. Done, connect to PUp app, all is good, no motor response.

So all this is caused by my phone??? Running Android version 11, security update on April 1st, 2021 - well that may explain it: April 1st ...

But honestly: Holy crap I did not know how bad things have become ...

Best,
Thorsten

[Hod Carrier]

51 minutes ago, Toastie said:

@Hod Carrier: What device are you using?

It's an iPhone 8 Plus. I did wonder whether these problems might be related to the device but it sounds like it's not if you're having the same issues as me.

[Toastie]

3 minutes ago, Hod Carrier said:

I did wonder whether these problems might be related to the device but it sounds like it's not if you're having the same issues as me.

No, these problems are buried somewhere else ... it is definitely not the IOs vs Android system!

 

[Toastie]

1 hour ago, Andman said:

Thanks for the test. I cloned your code.

Just to be sure and I know how that sounds, but you are using the SetPower block, not the SetSpeed one, right?

Best
Thorsten

[Andman]

2 minutes ago, Toastie said:

Just to be sure and I know how that sounds, but you are using the SetPower block, not the SetSpeed one, right?

Best
Thorsten

Don't worry. I can confirm that code looks exactly like yours.

[Toastie]

11 hours ago, Andman said:

I can confirm that code looks exactly like yours.

@Andman and @Hod Carrier,

hooked up the Technic (4I/O) hub. Temporary access of PUp app to "location" on the phone was enabled: No motor operation (although it does connect and runs the program ... ) .

>> Global activation of access to "location" on the phone: Boom - works. Should have known better, as this was mentioned elsewhere, and repeatedly.

Result: SetPower runs >flawlessly<, as you said @Andman, on the Technic (4I/O) hub. Loop count now reaches 2500 - and I guess that is it: Works!

Back to the City (2I/O) hub: Exactly the same behavior as described in my previous posts: Crash (= no response and disconnect) after (almost) arbitrary #loops.

Conclusion: Bug in City hub's firmware.

I cannot think of anything else ...

Best
Thorsten

 

Edited June 3, 2021 by Toastie

[Andman]

2 hours ago, Toastie said:

Conclusion: Bug in City hub's firmware.

Would assume the same. Now what?What's the best way to let TLG devs know?

[Toastie]

2 hours ago, Andman said:

Now what?What's the best way to let TLG devs know?

I don't have the faintest idea. Maybe @kbalage or @Lok24 would know?

It would also be favorable if others confirm that erroneous behavior of the City hub, when using the SetPower command repeatedly.

Code to crash the City (2I/O) hub without wasting much time:

 

Best
Thorsten

Edited June 3, 2021 by Toastie

[kbalage]

15 minutes ago, Toastie said:

don't have the faintest idea. Maybe @kbalage or @Lok24 would know?

It would also be favorable if others confirm that erroneous behavior of the City hub, when using the SetPower command repeatedly.

Code to crash the City (2I/O) hub without wasting much time:

I don't really have time to read all the previous discussion at the moment but I quickly tested the code there and it runs ok on an iPad Air 2 with the latest PU app, with a city hub and an XL Technic motor attached. Could you guys provide the exact conditions when it failed?

 

[Toastie]

16 minutes ago, kbalage said:

Could you guys provide the exact conditions when it failed?

I am running the code on a Motorola moto g8 power Android 11 phone, latest PUp app installed (3.6.0), City hub, and as far as I can tell the latest City hub firmware installed (it does not do the LED color play when connecting to it). Only one PUp L motor is hooked up to the hub on port A.

The code runs fine for almost arbitrary #loops (note: Sometimes < 5 loops, sometimes >180 loops), I simply copy here very simple measurement results from above, sorry for that:

This was done with this code:

 

 

Code runs fine on Technic hub. (Same phone, same app, Technic hub with the latest firmware installed (it did the color play yesterday upon testing), same PUp L motor attached to port A.

Best
Thorsten

Edited June 3, 2021 by Toastie

[Hod Carrier]

13 hours ago, Toastie said:

Conclusion: Bug in City hub's firmware.

I cannot think of anything else ...

It's a shame, but I think you may be right.

Until this bug has been sorted out I have written some replacement code in the form of a fairly crude feedback loop to replicate the function of the faulty block. Static testing with the model works well but the real test will be under load to see if it can cope with the mechanical drag of the model and alter the motor settings as necessary.

A big thank you to @Toastie, @Andman, @kbalage and everyone else who has contributed to this discussion for your hard work in pursuit of the source of the problem. You guys prove the value of the community. 

Edited June 3, 2021 by Hod Carrier

[Toastie]

8 hours ago, Hod Carrier said:

You guys prove the value of the community.

And that certainly does include you. Should this turn out to be a bug, you found it, you reported it (after I bet numerous - as in very, very many - test runs). And as said before: These are the most valuable reports to a) the community, so others don't rip out their hair because they think it is them - this is usually my approach and usually true: Almost every time such things happen, >I< screwed up ... and b) to developers. And they need even more input - could be my phone, maybe yours, maybe two faulty hubs (sh*t does happen ...) - who knows!

I do hope others will run the tiny test program as well, and then we'll see.

More importantly: Yes, your updated program is a nice approach to resolve the issue for the time being! I also believe it will work quite well, when the load is not becoming too excessive, as the L-motor does develop quite some torque (when you don't gear it up). I believe what you coded is a "proportional" (P) control loop. I may be wrong though, others here know much better. Under high load, i.e., when the torque of the motor cannot easily compensate for the sum of changes of forces pointing in the reverse direction of movement, it may come to oscillations. But that is fun to see as well, as it tells you that your program is trying very hard to do what you want it to do! I have no clue, but maybe you can add the "integral" (I) and maybe even "differential" (D) corrections using the PUp code; then you have full PID control. However, as said: Most probably not required at all, and P will do!

[As a note: As it stands, you are polling both rotation sensors - on a train equipped with two motors, the readings should be (within margins of error) identical, right? I believe you could save program run-time overhead by reading just one sensor and then adjusting the power to both motors in the same loop?]

It will be very, very interesting to see your results! I sure hope you find time to share these results here!

All the best and have a nice day,
Thorsten

   

Edited June 4, 2021 by Toastie

[Toastie]

On 6/3/2021 at 4:22 PM, kbalage said:

and it runs ok on an iPad Air 2 with the latest PU app, with a city hub and an XL Technic motor attached.

@kbalage, did your config make it persistently all the way through? Because when it did, it means the behavior @Hod Carrier and I were noticing, it is either our phones, or the L-motor, or the City hub. I believe it is worthwhile to follow up on this, right?

Best regards,
Thorsten