Jim

BuWizz - High Performance LEGO Power Functions Controller and Battery

Recommended Posts

8 hours ago, msk6003 said:

I don't know this was asked before but is someone tried use spike essential's small motor as steering servo with buwizz 3.0? I tried it today after get my 3.0 but it seems not work right.

Doesn't work with Buwizz 3.0 yet, sadly. It works with latest firmware with Technic and City hub, though. Also works great with Pybricks custom firmware on these two hubs.

Edited by Gorkron

Share this post


Link to post
Share on other sites

The issue with the hub shutting down with two buwizz motors has been a known issue for at least 10-11 months. I've opened a case recently and was told that they are working on a FW update but there is still no timeline for release. I was advised to try adjusting ramp values. I spent $600/€600 in March of 2022 and I would not have purchased had I known about this limitation. How could fixing this NOT be the highest priority for their dev effort?

The lack of a defect fix doesn't just affect a consumer channel of their product, it affects an entire secondary market of MOC designers who rely on revenue from selling their designs. Designers who create pull-through revenue for Buwizz when consumers buy the MOC and then the Buwizz units to build their dream model. 

There are two possible reasons for it taking this long:

  1. Buwizz didn't initially prioritize a fix thinking the scope was not as bad or that didn't affect as many users. They have now realized it, adjusted their priorities, and are working heads down to deliver a fix in the days to weeks timeframe.
  2. They are unable to fix it via firmware update. A fatal design flaw in the motors or with the circuitry in the hub itself. 

I sure hope it's (1) because I want Buwizz to succeed and will actually continue to throw money at them if this is the case. I am withholding a $1200/€1200 purchase until such time as I can validate a fix. I recommend that everyone withhold ordering anything from Buwizz for the same reason.

If it's (2) then I will ask: when did they find out versus when/what did they communicate to their customers? If they are continuing to market a defective product while hoping to sell units then it is fraudulent behavior.

I love the Buwizz concept, but the execution is not meeting with expectations thus far: center steering, lack of robotics control, lack of physical controller support, etc are all major disappointments. These things imply a dev effort that is overwhelmed or very poorly managed.

I work for one of the largest and most well known tech firms on Earth. We are not allowed to run our lines of business in this way. We know that mistakes are inevitable. But we also know that our valued customers will stick with us if we are transparent, honest, and provide open communications to them when things go wrong. When we make mistakes, it costs money to fix. Trying to avoid that and the cover up is always worse than the crime.

  1. Anything short of a well-publicized effort to own the defect and provide periodic updates on the progress implies that we are embarking on a darker chapter.
  2. Their website has seen many updates, they produce tons of slick marketing videos, and even held a camp recently. If I was @Sariel or @kbalage I would be hesitant at this time to use my likeness to continue to market this product until there is more clarity.
  3. Further, anyone selling MOCs that include Buwizz should temporarily pause sales of those MOCs.

I'm not saying this with any anger or malice--I WANT Buwizz to succeed! Many designers NEED Buwizz to succeed! 

Loyal customers will help you fix the problem by buying more product but they will ONLY do this if you are open and honest with them. 

@Zerobricks print this out and take it to your management, their actions over the next week will define which fork in the road they choose.

Edited by shroomzofdoom

Share this post


Link to post
Share on other sites
8 hours ago, shroomzofdoom said:

How could fixing this NOT be the highest priority for their dev effort?

I really have to agree with this point. This is really frustrating for many users, and it's a fundamental problem because it effects all other apps that try to control the Buwizz units.

8 hours ago, shroomzofdoom said:

The lack of a defect fix doesn't just affect a consumer channel of their product, it affects an entire secondary market of MOC designers who rely on revenue from selling their designs. Designers who create pull-through revenue for Buwizz when consumers buy the MOC and then the Buwizz units to build their dream model. 

Sure us MOCers could say that it's not our fault but that of the Buwizz unit, but that would be lame, and our models would still possibly not work well in the hands of MOC buyers.

8 hours ago, shroomzofdoom said:

They are unable to fix it via firmware update. A fatal design flaw in the motors or with the circuitry in the hub itself. 

I did fear / think about this as well and hope this is not the case. It seems that there's a third possibility though, and I have already written it down in this thread. In the Buwizz camp I asked about this, and I was told that they outsourced the writing of the firmware and they are having a hard time getting it fixed by the company they work with. Not sure about the underlying reason though, whether it's just too complicated, or it's a communication issue or what. But let's hope it eventually gets solved over time. It would really be reassuring to know about how this issue evolves to understand whether there's a fundamental HW issue or not.

Something of a remedy for the meantime: I realised that using a physical controller reduces the probability of shutdowns, because it's easier to smoothly ramp up the speed (shutdown often happens at sudden speed / direction changes). Non-linear power curves also help (logarithmic seems to work for me in BrickController).

Share this post


Link to post
Share on other sites

Same as @aFrInaTi0n - the fast motorcycles we like to build, as well as anything else fast, absolutely need a failsafe when they get out of range. If you don't have that, you can be certain your 300€+ of bricks are going to hit a curb, go in the only water for miles, end up on the autobahn, etc.

Also same as @shroomzofdoom: you sold it to me the BW3 and two BW motors package on the premise a BW3 can power two BW motors without shutdowns. It can't. Frankly, that's false advertising and the EU already has something to say about that.

Edit: just looked through the website for the wording which I reckon claimed that, there is none. Either I'm crazy, or it was removed in the meantime.

Edited by amorti

Share this post


Link to post
Share on other sites
On 9/6/2022 at 4:19 PM, shroomzofdoom said:

Their website has seen many updates, they produce tons of slick marketing videos, and even held a camp recently. If I was @Sariel or @kbalage I would be hesitant at this time to use my likeness to continue to market this product until there is more clarity.

Just to make it clear, I participated in a competition organized by the team, I was not there to promote specific features of their products. 

On 9/7/2022 at 8:39 AM, amorti said:

Also same as @shroomzofdoom: you sold it to me the BW3 and two BW motors package on the premise a BW3 can power two BW motors without shutdowns. It can't. Frankly, that's false advertising and the EU already has something to say about that.

I understand your disappointment, but frankly almost every tech company and product could be questioned based on this. Just an example, I wanted to use my GoPro 10 as webcam on Windows 10, which is an advertised feature. Well except it doesn't work, their forums is full of complaints about it, and the company (that is on a slightly different scale than the BuWizz team) did not resolve it for a year now. Customer service acts like they didn't know anything about the issue, and they cannot provide any solution either. Do I ask everyone to boycott GoPro? No, I see no point of doing it. Does it affect all customers? For sure not, but for me personally it is still annoying. I bought the product because this was one of the features I wanted to use, maybe next time I'll do a better research. 

Regarding BuWizz 3.0 and 2 BuWizz motors, I honestly don't remember whether it was explicitly advertised as a feature that works. But even if it was advertised, did you really expect it to be working under all circumstances? I could overload the BuWizz 2.0 unit with some solid torturing using 2 XL motors only. What if someone gears up the output of the BuWizz motor or slaps it in a 5kg model and still expects it to run without shutting down? I would say that there are scenarios when you can power 2 BuWizz motors with a single 3.0 unit, and there are scenarios when it will shut down even with a single BuWizz motor, it heavily depends on your usage. As a MOC designer you can test your model and see whether it works or not, and you can set the expectations accordingly.

I don't think that there'll be any magic firmware fixes that might make the 2 motors work with a single 3.0 unit under sudden heavy load. What the BuWizz team could and should do is to provide more clarity when it works with some examples, builds and videos to manage expectations. Removing the simple speed selector switch was not a good idea for BW3 in the app, since it makes the output adjustments more difficult with the power curves.

Btw I think the "running out of range" issue is a way more critical one and that one should get priority. It existed in BuWizz 2.0, I had some serious challenges with it when I was doing the speed record. Apparently it exists in 3.0 as well, and that is more concerning than any other problem.

All in all, I'm not sure a boycott or anything similar is the most reasonable thing to do. If you are disappointed with the product, then return it to the company. Maybe someone else is fine with it, as it fits their needs. What we would need from the BuWizz team is a very clear and up to date communication about their products to avoid such scenarios, e.g. removing the feature on the BW3 product page that says it works with the all PU sensors, I don't think it actually does. It should be 100% clear what are the features that they want to implement in the future, and what are the features that are working today. Regarding the issues that are actually fixable, as @shroomzofdoom said we should have a clear and public timeline.

I was planning to do a video with the BuWizz motors and BW3 for some time now but I will definitely extend the test to see what are the exact circumstances and models where it does and doesn't work. Once that's done I'll reach out to the team and ask for their feedback and a public clarification, that's what I can do from my side. 

 

Share this post


Link to post
Share on other sites
31 minutes ago, kbalage said:

Just to make it clear, I participated in a competition organized by the team, I was not there to promote specific features of their products. 

I understand your disappointment, but frankly almost every tech company and product could be questioned based on this. Just an example, I wanted to use my GoPro 10 as webcam on Windows 10, which is an advertised feature. Well except it doesn't work, their forums is full of complaints about it, and the company (that is on a slightly different scale than the BuWizz team) did not resolve it for a year now. Customer service acts like they didn't know anything about the issue, and they cannot provide any solution either. Do I ask everyone to boycott GoPro? No, I see no point of doing it. Does it affect all customers? For sure not, but for me personally it is still annoying. I bought the product because this was one of the features I wanted to use, maybe next time I'll do a better research. 

Regarding BuWizz 3.0 and 2 BuWizz motors, I honestly don't remember whether it was explicitly advertised as a feature that works. But even if it was advertised, did you really expect it to be working under all circumstances? I could overload the BuWizz 2.0 unit with some solid torturing using 2 XL motors only. What if someone gears up the output of the BuWizz motor or slaps it in a 5kg model and still expects it to run without shutting down? I would say that there are scenarios when you can power 2 BuWizz motors with a single 3.0 unit, and there are scenarios when it will shut down even with a single BuWizz motor, it heavily depends on your usage. As a MOC designer you can test your model and see whether it works or not, and you can set the expectations accordingly.

I don't think that there'll be any magic firmware fixes that might make the 2 motors work with a single 3.0 unit under sudden heavy load. What the BuWizz team could and should do is to provide more clarity when it works with some examples, builds and videos to manage expectations. Removing the simple speed selector switch was not a good idea for BW3 in the app, since it makes the output adjustments more difficult with the power curves.

Btw I think the "running out of range" issue is a way more critical one and that one should get priority. It existed in BuWizz 2.0, I had some serious challenges with it when I was doing the speed record. Apparently it exists in 3.0 as well, and that is more concerning than any other problem.

All in all, I'm not sure a boycott or anything similar is the most reasonable thing to do. If you are disappointed with the product, then return it to the company. Maybe someone else is fine with it, as it fits their needs. What we would need from the BuWizz team is a very clear and up to date communication about their products to avoid such scenarios, e.g. removing the feature on the BW3 product page that says it works with the all PU sensors, I don't think it actually does. It should be 100% clear what are the features that they want to implement in the future, and what are the features that are working today. Regarding the issues that are actually fixable, as @shroomzofdoom said we should have a clear and public timeline.

I was planning to do a video with the BuWizz motors and BW3 for some time now but I will definitely extend the test to see what are the exact circumstances and models where it does and doesn't work. Once that's done I'll reach out to the team and ask for their feedback and a public clarification, that's what I can do from my side. 

 

Well, I am not very sure about few points here...

-To say that other companies, such GoPro, fail in the same problem is, in my opinion, a weak argument. The solution, to me, should be to pose a complain to both companies instead of just asuming that "shit happens".  

-I also remember that it was stated that the aim was that a single Buwizz 3.0 would be able to handle 2 buwizz motors. You are of course right that that statement depends on the setup you are using. Probably me -and, as it looks like, other users too- assumed that that statement was true for relatively light models and with no up- or down-gearing. As I tend to make heavy MOCs, I normally use 2 Buwizz motors powere from 2 BuWizz 3.0. What I give to the BuWizz company is that, what I remember about this statement, is that it was said during the development phase; thus, I assume that they might not have reached that goal. But in such case, I would say that I am missing -again- an official communication about what it is achieved, and what it is not. 

-For me, the issue of the range is not critical, but I can understand that for several MOCrs, it is indeed crucial. For me, the major missing feature is the rotation control (but, obviuosly, it might not be the same for many others). 

-From my side, I am not boycotting the Buwizz company. Indeed, I considered to ask them to return the items, but in such case I assume I would need to pay for the shipping costs. Unfortunately, at least from here (Switzerland), it is not possible to internationally ship Li-Po batteries; thus, the only way is to do it via Fedex or similar, which is significantly expensive. In case that I have the opportunity to give them back -at the current status- I would ask for the money back. 

 

At the current situation, I see two aspects of concern. One is for those who have already purchased the BuWizz 3.0 and found that they did not delivered what they said it was going to be delivered. That is, considering the price of the BuWizz, quite frustrating -at least for me-. Many people here have been quite patient from the begining (just remember how long it took the Buwizz 3.0 to be delivered and when it was intended to be delivered) and also when we found that the released app was not working as it was intended. But I think that the patience of everyone has its limits. And beyond those limits, normally comes the frustration and deception. The second aspect of concern is for those who are potential buyers of the BuWizz. Well, for those, I think, the situation is easier: they can judge from the comments of the first group. 

 

Nevertheless, even with all this said, somehow, I still have a little hope that they will be able to deliver something better to what it is now. When? Well... let's hope is before Lego changes again their motor line! ;)

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, HectorMB said:

-To say that other companies, such GoPro, fail in the same problem is, in my opinion, a weak argument. The solution, to me, should be to pose a complain to both companies instead of just asuming that "shit happens".  

I did not give this example to find excuses for the BuWizz team, just wanted to point out that tech companies have regular issues with advertised product features versus reality. Citing EU laws is nice but we could spend half of our lives at court if every similar scenario was taken seriously. 

21 minutes ago, HectorMB said:

From my side, I am not boycotting the Buwizz company. Indeed, I considered to ask them to return the items, but in such case I assume I would need to pay for the shipping costs. Unfortunately, at least from here (Switzerland), it is not possible to internationally ship Li-Po batteries; thus, the only way is to do it via Fedex or similar, which is significantly expensive. In case that I have the opportunity to give them back -at the current status- I would ask for the money back. 

Well it wouldn't hurt to actually ask them how you could return your purchase. If the shipping terms are not acceptable for you then there's still an option to negotiate with them about a compensation. 

Share this post


Link to post
Share on other sites
2 hours ago, kbalage said:

What we would need from the BuWizz team is a very clear and up to date communication about their products to avoid such scenarios, e.g. removing the feature on the BW3 product page that says it works with the all PU sensors, I don't think it actually does. It should be 100% clear what are the features that they want to implement in the future, and what are the features that are working today. Regarding the issues that are actually fixable, as @shroomzofdoom said we should have a clear and public timeline.

This is a point everyone here seems to agree with.

Although, I wonder how many people would have purchased Buwizz 3.0 and Buwizz motors if their page said something to the effect of:

"Please be advised that you will need a single Buwizz 3.0 to operate EACH Buwizz motor if you plan on building larger models or if you require the ability to change directions quickly"

Short of a fix, I don't see anything that would convince me to buy additional products from Buwizz until this FW update is addressed. 

Share this post


Link to post
Share on other sites
9 minutes ago, shroomzofdoom said:

until this FW update

Is this really a FW issue? I don't have any BW products, so I better don't join in on any of the issues people are having.

It is my understanding from this thread (and much has been said!) that the BW controllers do have a power drop out issue when - for example - two outputs are operating two BW motors under some load. If this is correct, then it can even be a HW issue. To me, the BW controllers (version 2 or 3) don't look like thermally optimized super-power devices. As they have the rather delicate BLE HW along with some micro-controller brain, they also have electronics on board that - according to the BW website, the BW3.0 can deliver a sustained current of 4A per PF terminal (6A peak). The same is reported for the 4 BW2.0 PF outputs (max. current is even 6.5 A).

And that is only one of several other numbers that have to be taken into consideration - the LiPo capacity, max. current it can deliver, etc. but that is not the point here - these can usually fry every electronic circuity of the BW controller size.

The thing is that a stalled 5292 LEGO motor (which is about the same as the BW motor regarding the electrical characteristics - it even has, according to the BW website, 20% higher power than 5292) draws about 3.2 A current (Philo's motor comparison page). As the BW motor is not up/down geared internally (according to the BW website), it even may get earlier to the stalled current limit (model under some heavy electrical load, either caused by weight or grade or whatever).

Now it may very well be that the power electronics can handle that current as per data sheets. It also may be that the LiPo can easily handle these currents (I am almost sure it can). However, when there is a rather nervous temperature sensor inside, just to make sure the BW doesn't cause any trouble due to overheating, which may cause trouble with the LiPo pack, which may get it up in flames, then this one will certainly cause power interruption. I am pretty sure that this needs to implemented in EU made electronic devices.

If 2 BW motors almost stall and draw 6 - 8 A of total current, there will be also some heat generated internally, which has to be efficiently dissipated. The "sealed" BW ABS enclosures appear to the least efficient way of doing that. So it may also be that the temperature rises internally to the point that power is cut off.

It may even be a HW issue in the motor, as these have "Increased current protection" according to the BW website. For what exactly? Maybe this protection is too nervous - or they just want to make sure that the motor does not burn out when stalled/almost stalled for a longer time.

The BW website doesn't explicitly say anything wrong; the individual numbers may all be correct. Nowhere "sustained" is defined. Nowhere they say what kind of motors/lights are attached, when operating all 4/6 outputs. However, some of the pictures suggest (1BW controller + 2BW motors in one photograph, for example) it may work.

I agree that making everything much clearer on their website would certainly help here. As it stands, something is largely off.

I doubt though that this is a SW issue. Which renders things much more difficult for them to resolve.

This is all just pure speculation. I simply do not understand why the do not communicate these issues clearly.

Just my 2 cents.

All the best,
Thorsten

 

Share this post


Link to post
Share on other sites

@kbalage In my specific case, I'm asking a bw3 to handle two BW motors off the fast output direct to a 91mm tyre, in a motorcycle weighing @700g. I don't think it's an unreasonable ask, but it will shut down under hard acceleration. I specifically spent over 250€ on a BW3 and two BW motors with the expectation that this would work.

Firmware can't magically whistle up enough power to drive a full size pickup truck at full speed, but it should be capable of reducing power to keep it running without me manually setting up power curves. Those should be a default. It also shouldn't completely shut down when overloaded. Maybe go into a limp mode so you can still at least try to brake or steer.

Even with this whinge out of my system, the out of range issue is, as you rightly say, a much bigger concern. Those ten metres or so of range (don't tell me it's "up to" 100m!) disappear very quickly at 25+ km/h.

Edited by amorti

Share this post


Link to post
Share on other sites
9 minutes ago, amorti said:

Firmware can't magically whistle up enough power to drive a full size pickup truck at full speed, but it should be capable of reducing power to keep it running without me manually setting up power curves. Those should be a default. It also shouldn't completely shut down when overloaded. Maybe go into a limp mode so you can still at least try to brake or steer.

Sounds like an interesting approach, would be great to know if it is technically possible.

10 minutes ago, amorti said:

Even with this whinge out of my system, the out of range issue is, as you rightly say, a much bigger concern. Those ten metres or so of range (don't tell me it's "up to" 100m!) disappear very quickly at 25+ km/h.

Based on my experience range depends heavily on the smart device, the difference can be easily the half/double! Btw any BT connection range disappears in seconds if you try to run things at 25+ km/h :D 

Share this post


Link to post
Share on other sites
On 9/9/2022 at 9:19 PM, Toastie said:

Is this really a FW issue?

I think the point was not that it is a firmware issue, but rather that it could potentially be solved in the firmware.

On 9/9/2022 at 9:32 PM, amorti said:

Firmware can't magically whistle up enough power to drive a full size pickup truck at full speed, but it should be capable of reducing power to keep it running without me manually setting up power curves. Those should be a default. It also shouldn't completely shut down when overloaded. Maybe go into a limp mode so you can still at least try to brake or steer.

On 9/9/2022 at 9:44 PM, kbalage said:

Sounds like an interesting approach, would be great to know if it is technically possible.

And according to my understanding from talking to them at the camp, this is what they aim to try; to slow down the motors when the firmware predicts that a peak in the current is coming. Probably the prediction part is non-trivial; it needs to predict the peak, because if it actually sees the peak then it may already be too late. And if it's too cautious, it may slow down too early and not use the full potential of the motor.

I do believe that certain situations can be prevented with optional firmware settings, for example the firmware does have a ramp up/down time setting already, and some reasonable non-zero value could be default. That may be useful to prevent sudden direction changes (though BrickController2 and ControlZ apps don't not have such an option to set, and when I experimented with it in the Buwizz app, it behaved a bit strange, was hard to set a usably low ramp time). But I guess it is not a solution for all situations. For example, I have seen models that can go full speed fine on a flat surface, but when they hit an uphill (and start to get slower naturally, so no sudden speed change), the Buwizz shuts down.

Share this post


Link to post
Share on other sites

Just found an interesting bit about the Buwizz protocols. The Buwizz 2 protocol has a command to set current limits for each port. The documentation says:

"If the motor current is above the current limit, the PWM duty cycle of the affected motor is reduced until the current falls below the limit. PWM duty cycle will increase if the motor load is reduced."

The Buwizz 3 protocol has no such command. But I guess the same could be added. Wonder why it was removed in the first place though..

Share this post


Link to post
Share on other sites
On 9/9/2022 at 6:15 PM, kbalage said:

Btw I think the "running out of range" issue is a way more critical one and that one should get priority. It existed in BuWizz 2.0, I had some serious challenges with it when I was doing the speed record. Apparently it exists in 3.0 as well, and that is more concerning than any other problem.

I also found something in the Buwizz 3 protocol that may be related to this issue. There is a command to set a connection watchdog, a timeout value. The documentation says:

"If timer expires, the device drops the connection and uses the parameters of the ... command for the stop."

And the options for stopping are: braking motors, coasting them, or coasting them to stop in N seconds.

Maybe this means the following: if the connection drops (for example because of running out of range) for a certain time, then this stopping mechanism kicks in. I guess that would work, no? I have not yet seen a setting for this in the app though.

Share this post


Link to post
Share on other sites

@kbalage Any recommendation on good client devices with good range?

Tested with my old Galaxy S5,S7 (both BT4 if I remember correctly) and current S20 with BT5.

Not really any differences I would say.. No Apple user, but I think all vendors have to stay in range of allowed tech specifications to be able to sell in the regions (US ->FCC,EU->CE). So there shouldn't be any huge outstander phone by my understanding..

Here are two of my caught-on-video fails:

4wd with 4x buggy motors as direct drive, powered by 2x BW3:

The mentioned 28km/h crash with a bike (2x buggy motors, 1x BW3, one metal ballbeared liftarm for the rear):

 

Had some more unfortunately... 😅

 

@Zerobricks: I think the antenna of the Buwizz is put into the PCB - or is it like the MKs with a little solderingpoint to have a short cable on?

I am no expert at Wifi and Hardware specs of antennas, but maybe from back in the alpha-stage days of the bw3: was there an external antenna and if yes, made it any differences in range?

Share this post


Link to post
Share on other sites

Hey guys, have a question - I have Buwizz 3.0 and 2.0(I guess) and I purchased a Playstation 5 several months ago. 
Is it possible to perform features management not via the smartphone but via gamepad? What hardware and software are required?

Edited by Aleh

Share this post


Link to post
Share on other sites
7 hours ago, Zerobricks said:

BuWizz 2.0 has a small wire for antenna and 3.0 has antenna from metal.

Did you remember if range was tested with different antenna lengths (thinking of this kind of change to test if with it somehow more range can be supplied - and yes I know that opening would make me lose all warranty on the Buwizz etc..)

Share this post


Link to post
Share on other sites

@aFrInaTi0n I compared my devices years ago back in the BuWizz 2 days so that's not really relevant anymore. I'll try with something more recent, although I don't have the latest and greatest smartphones and tablets :) 

Share this post


Link to post
Share on other sites

Thanks for taking a look into this - but as said I think there wont be big differences..

Had a look at the BT portocol and its different Versions, so from the Versions 1-5 it is like this:

BT Class 1 = 100mV power output max, resulting in up to 100m range
BT Class 2 = 2.5mV power output max, resulting in 10-50m range
BT Class 3 = 1mV power output max, resulting in 1-10m range
BT Class 4 = Using BLE (Bluetooth Low Energy) profiles to even reduce power consumption and save battery, range varies for different scenarios
BT Class 5 = Using more advanced BLE stacks, ranges also vary (Wikipedia: "Bluetooth 5 provides, for BLE, options that can double the speed (2 Mbit/s burst) at the expense of range, or provide up to four times the range at the expense of data rate")
 

So from my understanding the newer versions have more and more power saving functions - so forcing the BT device to use Class1 with highest power consumption would be best - but may be the case that newer devices cover the older modes with BLE profiles too... no expert here..

at least from the Buwizz API sheet:

"BuWizz3 is a smart connected power brick device compatible with Lego elements. It features a builtin rechargeable battery, 4+2 power outputs (e.g. for motors) and a wireless connection using Bluetooth Low Energy (BLE, Bluetooth Smart). Long-range mode, introduced in BLE 5, is supported to achieve even longer operational range than before."

Here it gets interesting if BT1 would be superior to a BT5 Long Range mode - or if this mode utilizes all the phones max sending output... I read further... there is a Flag at the BW3 API to show if the BLE long range PHY_CODED is enabled:

Quote

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. Once the connection with the master device has been established, the BuWizz3 device will automatically request the master to switch to PHY_CODED mode. If the master device supports this mode, both devices will switch into that mode. If the master does not support this or does not agree with the change, the communication protocol will stay in legacy 1 Mbps mode.

This would really be nice as a indicator to the user in the Buwizz UI like "Connection is using long range mode on/off".

Edit3: As I also pointed out already, I am with @shroomzofdoom's opinion - at least the topic of communication towards their (future) customers may be reconsidered. As @Zerobricks already pointed out, he seems to be the only person who has a deep knowledge of what the community currently has in mind (like our discussion here in this thread, but not every interested person will join EB, so I think we complaining here may somehow be the tip of a mid sized iceberg..). If I could ask for a favour, it would be nice to address this general communication-topics-issues to Roni himself - maybe with support from @kbalage to have more voices for this.
As @shroomzofdoom pointed out I think nobody of us here wishes s.th. bad for Buwizz - we would just like threadened like welcomed and grown-up customers.
 

@Toastie Things you are missing are the surface-size of the small pin-connectors + the overall small diameter cables. Look at rc-hobbies cables for power-transportation and their diameter..

So there will be plenty of things you have to keep in mind at defining the specs for such a device:

  • CE certifation needed to be sold in EU (there may be others for other regions, like FCC in the US when it comes to Wifi..), It basically means "this device is in compliance with all the regulations for its used components (battery, PCB board safety against overcurrents to not start burning, meet Wifi regulations for max transmission power)"
  • physical limitations need to be considered (max throughput of cable diameter, thermal cooling on the channel-driver ICs)

Think we also can understand those needed to be taken into consideration when the products were designed.

Edited by aFrInaTi0n

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.