BuWizz - High Performance LEGO Power Functions Controller and Battery

[Toastie]

43 minutes ago, aFrInaTi0n said:

Does anybody know if the alignment of the antenna may result in some best positioning?

I don't believe the positioning of the antenna (plane) relative to the radiation source matters - actually, the source emission performance is equally important.

As the position of the Buwizz changes horizontally a lot upon operation (provided it is mounted that way in the MOC), the antenna should perform accordingly. From the picture you posted, it appears as if this is a very carefully designed meandered inverted F antenna. TI's application note AN043 shows some nice range/performance data. This is for a wireless 2.4 GHz USB dongle, but so what.

Vertical orientation may also not be of concern - I don't think the emission source is plane polarized in some way.

Best,
Thorsten

[BrickTronic]

21 hours ago, aFrInaTi0n said:

I just recognized the antenna for the buwizz two is on one side?! Thought this would be on the main horizontal pcb...


...

Hello

There is a Tear-Down Youtube-Video by GreenGecko of the BuWizz2 available.
But the Antenna is not where it is in your picture.
@Zerobricks are there different Versions of the Buwizz2 and what are the (Hardware) differences (obviously the Antenna)

For the Buwizz3 Sariel did a Tear-Down Youtube-Video
Here the Antenna seems to be a stamped metalic part

Jo

[Zerobricks]

3 minutes ago, BrickTronic said:

Hello

There is a Tear-Down Youtube-Video by GreenGecko of the BuWizz2 available.
But the Antenna is not where it is in your picture.
@Zerobricks are there different Versions of the Buwizz2 and what are the (Hardware) differences (obviously the Antenna)

For the Buwizz3 Sariel did a Tear-Down Youtube-Video
Here the Antenna seems to be a stamped metalic part

Jo

BuWizz 1.0 and 2.0 do indeed have different antennas, but I don't know the specifics. The one one the photo is 1.0.

[aFrInaTi0n]

Ok, sorry for falsly identifiying it as a Buwizz 2, will edit to correct it.

So I think from message from @Toastie changing or somehow modding the antenna wouldn't be giving any more range, because the transmission power will basically stay the same.

Sorry for so many questions from my side @Zerobricks, but do you know of any way to find out / see if the currently etablished connection uses this long range / coded mode?

"The BuWizz3 supports BLE 5 feature called long range / coded mode (also noted as PHY_CODED), where the range is improved on the account of lower data bandwidth and forward error correction." from the API docs.

[Zerobricks]

2 hours ago, aFrInaTi0n said:

Sorry for so many questions from my side @Zerobricks, but do you know of any way to find out / see if the currently etablished connection uses this long range / coded mode?

"The BuWizz3 supports BLE 5 feature called long range / coded mode (also noted as PHY_CODED), where the range is improved on the account of lower data bandwidth and forward error correction." from the API docs.

Sorry, don't know, but you can write a ticket and I will forward it.

[aFrInaTi0n]

21 minutes ago, Zerobricks said:

Sorry, don't know, but you can write a ticket and I will forward it.

Will write it up in a separate mail to the regular support mail address.

As always, thanks for your additional efforts you take to help! ♥

[gyenesvi]

15 hours ago, aFrInaTi0n said:

Sorry for so many questions from my side @Zerobricks, but do you know of any way to find out / see if the currently etablished connection uses this long range / coded mode?

"The BuWizz3 supports BLE 5 feature called long range / coded mode (also noted as PHY_CODED), where the range is improved on the account of lower data bandwidth and forward error correction." from the API docs.

FYI, I have some test software to communicate with a Buwizz 2/3 and as I read out the value of the long range mode, so far I have only seen a false value sent by the Buwizz unit. I don't know what it depends on though, maybe my phone's capabilities (but I am guessing an iPhone 12 has a good chance of having appropriate BLE HW for it). Also, the Buwizz API does not seem to have a way of turning this on, so I am guessing that the FW will turn it on automatically if it can.

[aFrInaTi0n]

@gyenesvi API docs say "if BT5 is supported" - just googled the specs, an iPhone 12 has BT5 (and should therefore also have LE capabilities).

Which software do you use? Would be interesting to know if a third party (android for me) app could get information on the smartphone side about the etablished connection.. I have the fear this wont be possible without rooting a( android) phone to be able to grep'em.

As Zero asked for, I described the situation which is kind of frustrating for a user and how some more detailed information would help to help yourself by being able to identify if the proper connection (and which kind and what you can expect of it) is etablished and therefore maybe get a clue about the reasons for it not working, like not BT5 on smartphone side supported.

The whole Buwizz team will hate me already with all my emails about missing details and feature requests 😅🤓

[gyenesvi]

18 hours ago, aFrInaTi0n said:

Which software do you use? Would be interesting to know if a third party (android for me) app could get information on the smartphone side about the etablished connection.. I have the fear this wont be possible without rooting a( android) phone to be able to grep'em.

I'm using an experimental software that I am writing on a Mac. It's simply connecting to the Buwizz via standard BluetoothLE connection, and using the Buwizz protocol to get info and try to control the hub. I don't know what info could potentially be queried about the connection if you did the same thing on Android, I don't have an Android device.

[aFrInaTi0n]

Ah ok, so your app does the initializationof the BT connection following the API docs? This explains, because with permission models by the OSes (mac and android) wont allow from one app to sniff the connections of another app, thats why I was asking.

And with your app following the API instrucions your app on the iPhone12 (BT5, LE are both supported) you don't get the flag set for PHY_CODED? :(

I am an IT guy, but unfortunately more kind of a system-engineer and no real developer... But maybe I will give it a try to install Android Dev Studio / VisualStudio and try some basic tutorials for Xamarin.. Would be funny if the firmware would never switch to that mode, but nobody realized yet... At least this would explain the poor ranges we get 😄

Edited September 30, 2022 by aFrInaTi0n

[gyenesvi]

On 9/30/2022 at 3:17 PM, aFrInaTi0n said:

Would be funny if the firmware would never switch to that mode, but nobody realized yet...

Well, I would not be surprised. As I am experimenting with it, I think I have discovered some sort of a bug or issue with the firmware. What happens is that as I am sending control commands to the unit, for example to set the motor speed according to the position of an on-screen slider, the Buwizz unit is too slow processing those commands and there can be significant delays in it responding. If I am moving a slider slowly, and sending commands whenever the slider position changes under my finger, it seems to overwhelm the firmware. If I keep moving the slider up and down slowly for say 2 seconds, and check how the motor responds, it may take it to process all the commands maybe 5-6 seconds. That's an amazing amount of delay! It only shows with slow slider movement however, probably that is why it is not manifesting itself all the time under regular use. If I move the slider quickly, it does not result in a lot of commands being sent, and hence the problem is not visible. This happens in generic PWM mode, and also in speed servo mode. The docs says that the PID controller of the servo runs at 100 Hz, which I interpret as it should be capable of processing messages sent with 10ms intervals. However, even if I wait 10ms after sending each command, the result is still not perfect, although somewhat better. If I add more delay, say 50ms, then that becomes the problem itself. By the way, the Buwizz 2 seems to be less prone to this happening.

The reason I believe this is actually a bug, and it's not just me doing something wrong is that I observed the same behavior in other apps as well. For example Controlz has an acceleration issue (progressive acceleration in the app results in a lot of delay in the actual model), which I have reported before, and I think is because of the same underlying issue. The BrickController app is less prone to this, because as I have seen it in it's code on GitHub, it applies a 10ms delay in the sending of subsequent messages, and also with a small physical joystick it is harder to make really slow acceleration (harder than with a larger on-screen slider). Furthermore, the Buwizz app itself also has a problem when setting ramp-up times, for example if you set it to 1 sec, the actual speed-up will be much longer (like 3-4 secs). I believe it is the same issue underneath.

As a reference, I have tested the same motors with the 4-port Technic Hub, and that one can quickly and smoothly control the motors, following the movement of the slider without practically any delay, so it does not seem to be a HW issue. From the Lego Wireless Protocol, I know that the way the lego firmware works is that while it is processing a motor command, if it receives multiple subsequent ones in the meantime, it only keeps and executes the last one, as that would override the the previous ones anyway. This way it does not process all the useless commands unnecessarily. I believe this is what the Buwizz firmware fails to incorporate, and the delay comes from processing many obsolete commands.

I have sent a message about this (and a few other issues) to Buwizz about 3-4 weeks ago, but did not receive any reply. I am hoping that others who have experience with Buwizz app development, like @imurvai and @_Ozzee_ can chime in to tell about their experience regarding this issue, and confirm or deny my theory. It is already frustrating for smooth speed control, but imagine how much inaccuracy this can cause in steering servo control for example! I believe this should also be top priority to fix.

[Toastie]

7 minutes ago, gyenesvi said:

This way it does not process all the useless commands unnecessarily. I believe this is what the Buwizz firmware fails to incorporate, and the delay comes from processing many obsolete commands.

Sounds absolutely reasonable, but also means that there is some sort of stack in the FW, doesn't it? When you ramp the slider up and down rapidly, let's say with some acceleration/deceleration profile, does the Buwizz process all the changes one after the other?

The LEGO hubs indeed override the last command (and even abort the acc/dec profile) at least this is what I seem to have noticed with my BR 89 locomotive running on a City hub and Legoino/ESP32 (latter does not matter - it is just firing out the commands): As it is a steam locomotive propelled by a PUp L motor, I use max. acc/dec settings (several seconds); when it decelerates and a "premature" or "rescue-me" :D stop command comes in (e.g. by a color sensor reading coded rails, picked up by the hub, sent to the ESP, which responds with a "stop" command), it stops with no delay, regardless of profile completion.

Well, this may be a major issue, right? I mean, this could mean quite some change in the FW. Or not, no idea. Just wanted to share my observations.

Best wishes,
Thorsten

[gyenesvi]

40 minutes ago, Toastie said:

When you ramp the slider up and down rapidly, let's say with some acceleration/deceleration profile, does the Buwizz process all the changes one after the other?

I haven't tried setting those yet, but to a 0 value to make sure that is not what is causing the delay. However, that seems to be faulty in the Buwizz app as well, maybe because of this very issue, though not sure how acceleration profiles are actually implemented.

43 minutes ago, Toastie said:

Well, this may be a major issue, right? I mean, this could mean quite some change in the FW. Or not, no idea.

Well I don't know either, but it may actually simplify the firmware. I mean it doesn't need to queue all the commands, only keep the last one and keep overriding it. That's actually simpler..

By the way, I just sent this issue again to the Buwizz team, let's see if I get a reply this time.

[Toastie]

1 hour ago, gyenesvi said:

but it may actually simplify the firmware.

Absolutely True.

To be honest: I have here a VB6 n/software BLE stack (they gave that to me for free, back in 2019, and I am very, very grateful for their move!!!). Don't even think about that - yes, I still program in VB6. I am older than dirt ... not the point. The thing is, it is unbelievable (to me) how many BLE commands come in. This appears to be "interrupt driven" - events fire in all directions and raise subroutines. So I made some sort of stack (or queue) to handle this machine gun fire - just realizing that this approach was at best garbage .

But it took me soo long to get to that - and it worked - but it was a pain to just press delete so-and-so often - and to come up with a better way of handling. Yes, it will make the firmware simpler, but I believe it will be a major programming effort.

And then we don't even know whether this is the issue or not ... but I understand your frustration! 

Hope they'll respond!

All the best,
Thorsten 

[shroomzofdoom]

I've been motivated by seeing @Zerobricks wildcat working and seemingly unaffected by the same headaches that I've encountered. It was heartbreaking for a while there to spend weeks on new designs only to watch them stall out. I've opened a few cases and gotten some useful feedback.

I'll leave my earlier posts intact to capture how upset I was at the time. But will add that I have actually ordered more Buwizz units.

The addition of ramps of 1.5s up and down and limiting BW3.0 to 2 RC motors per battery and limiting BW2.0 to a single RC motor power battery seems to have done the trick. 

It is undoubtedly more expensive (more batteries) and less fun (no tire spins) but it's a passable solution for now. The fact that I occasionally have to leave my buwizz 2.0 to completely discharge over a period of several days is still wholly unacceptable. 

I still am looking forward to alot of overdue updates and wanted to thank @Zerobricks for his support. 

Edited October 19, 2022 by shroomzofdoom

[gyenesvi]

On 10/7/2022 at 11:34 PM, gyenesvi said:

By the way, I just sent this issue again to the Buwizz team, let's see if I get a reply this time.

It's been more than a month now and I didn't get any reply to my second message to the Buwizz team either. Not sure what's going on here, but support is pretty lacking..

[aFrInaTi0n]

4 hours ago, gyenesvi said:

It's been more than a month now and I didn't get any reply to my second message to the Buwizz team either. Not sure what's going on here, but support is pretty lacking..

I started to be an absolute megablock and bombed their recent yt-videos with comments about not reacting... so maybe I won't be able to see any future videos of their channel soon or they will ignore this too...

Its really getting from "not nice" to a "i am feeling f^%$#ed" feeling in regard of honest communication to their customers... sadly still as the product itself (the hardware) is quite nice..

[Zerobricks]

5 hours ago, gyenesvi said:

It's been more than a month now and I didn't get any reply to my second message to the Buwizz team either. Not sure what's going on here, but support is pretty lacking..

I'm sorry, I have yet to get a reply, wish there was more I could do... 

[gyenesvi]

4 minutes ago, Zerobricks said:

I'm sorry, I have yet to get a reply, wish there was more I could do... 

Thanks for the response, maybe if you could try to urge them a bit that might be more effective than us trying to do so by messaging.. It would also be nice to understand what the reason is for not communicating clearly. That would release some stress from the community members.

Also, I guess many complaints could go away if the FW was fixed finally. Once that's in good shape, the community could build on it in 3rd party apps, not needing to wait for the Buwizz team to add features to their own app.

[HectorMB]

It's nevertheless a pity that now, we are relying more on 3rd parties apps than in the BW app itself to manage the BW3...

[wower]

On 11/18/2022 at 2:42 PM, HectorMB said:

It's nevertheless a pity that now, we are relying more on 3rd parties apps than in the BW app itself to manage the BW3...

I am sure not only myself but a gazillion other people asked Buwizz to produce some analog remote.. that would solve much! I mean BC2 app is great but when i use that plus a gamepad I often have some lag from 2x bluetooth and/or some permanent noise in my Buwizz3.

Maybe in a few years we'll look back on those dark times with a smile, then having all the products we need :-) <3

[HectorMB]

I'd be happy to look back to a time where we had a working app instead of looking to the future for one!

[Toastie]

43 minutes ago, wower said:

Buwizz to produce some analog remote

Analog in the sense of having joystick-like thingies? The joystick (or the like) positions, resistor values or whatever is characterizing that position, need to be a/d converted and then fired out via BLE, isn't it? The Buwizzes etc. do all their incoming/outgoing data on that communication channel, isn't it?

I don't understand the "analog" bit, that's all.

Best,
Thorsten

[gyenesvi]

1 hour ago, wower said:

Buwizz to produce some analog remote

48 minutes ago, Toastie said:

need to be a/d converted and then fired out via BLE, isn't it? The Buwizzes etc. do all their incoming/outgoing data on that communication channel, isn't it?

I have been looking into this problem lately. It seems they don't even need to produce it, it's already out there. Both Xbox Series and PS5 controllers support BLE, and I also believe they probably communicate through a standard HID protocol. Furthermore, it seems that the Buwizz unit should be able to connect to them directly through standard BLE connection. All that is required is FW support for it. Unfortunately, the Buwizz FW is not in really good shape and does not seem to be evolving too much..

However, configuration of the controls would still require connecting to the Buwizz unit from the mobile app first, but that's no big deal I guess.

[wower]

On 11/30/2022 at 9:41 PM, Toastie said:

Analog in the sense of having joystick-like thingies? The joystick (or the like) positions, resistor values or whatever is characterizing that position, need to be a/d converted and then fired out via BLE, isn't it? The Buwizzes etc. do all their incoming/outgoing data on that communication channel, isn't it?

I don't understand the "analog" bit, that's all.

Best,
Thorsten

yes.. 2 obvious advantages:

- haptic feedback (you know without looking at your fingers, where you steer your vehicles - touchscreen is shit and unprecise at best).

- simpler to set up for kids (1 button to press on remote and batterypack and they automatically connect.. not giving them your phone to play, set up 2x bluetooth etc, have some issue 50% of time)

as discussed 100 times.. mouldking has a battery+remote set, that does exactly that (2 actually, one with 4 ports and one with 6 ports) & works like a charm (only downside is the cheap-looking, ugly design and the low voltage, compared to buwizz). if ever something similar is sold from buwizz, I'd buy it immediately (even with their history of selling buggy things with FW issue).

PS: connecting the cheap mouldking to a higher voltage battery worked for me (was discussed somewhere here in that forum already)

Edited December 3, 2022 by wower