aFrInaTi0n

Any chance we can have a Status for the PHY_CODED long range mode beeing used for the etablished connection?

@wower here we go:

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 😄

@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 😅🤓

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! ♥

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.

I just recognized the antenna for the buwizz two is on one side?! Thought this would be on the main horizontal pcb... Does anybody know if the alignment of the antenna may result in some best positioning? Like having the antenna side standing horizontally and at the highest point? And second question: Does anybody know if the PCB arrangement of Buwizz 3 also has the antenna pcb sideways mounted?

@Rifka Think they use different commands, so I guess 4.0 and 6.0 are incompatible to each other... Indicators for it: the remotes work batteries of the other version + if I recall correctly, the MK App also differences (this may be wrong, havent it installed currently to dblcheck) And yeah, I would be fine with splittung contributions up so those could be hopefully implemented aswell. I can just offer this and its np to take that, but @imurvai has to say "yes" - because the real efforts will be at mapping & coding..

I could send you 1-2 devices (4.0 sytem) for reverse engineering - I also would take the delivery costs from Germany (or just fund you via PayPal to order yourself some - should be nearly the same amount of money..). Or would it be enough to gather up the BT signals via wireshark and hand you the results in (maybe with an order of which buttons were pressed, to create a mapping out of the signals)? I could also assist in this (old Android device laying around, would just need to get Android Dev Studio and ADB to work for getting the debuging-capabilities)

BT protocol is well known.. but yeah rev engineering may be some efforts... Don't know if a) the Buwizz APK can be installed on an emulated device on pc and b) if this would somehow help to gather the the correct commands..

Loving this very German detail of Adilettes together with socks...

Nice looking design! Any chance we can see it in action?* Best regards *We had our issue in the past, hope you don't take this question as hostile anyhow, just seeing it has electric components and you were mentioning big turning radiuses (this is unfortunately the same for all (rc-)motorcycles). I am just generally interested in unconventional technics like this and would like to see it in action.

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: 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.

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..)

@wower I was speaking about the 4ch. receiver + 4ch. transmitter. I could create a little yt video showing how to couple channels with the shoulder buttons and also how to couple up to three boxes with the app.

@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?

Also came to that conclusion and did exactly this.. :D Answer for the failsafe feature: no estimation, except hopefully before end of the year. Lets hope for the best.. guess its the only thing which we can do.. :) Edit: Yeah, honest (even if earlier deadlines have to be pushed etc) regular updates would be better than just no updates.

You paid ~100 € for this? Ouch..

Uh, do I remember that one video where one put two Buwizz together to double up their voltage? This shouuuld be possible to do with MK batteries too - but as we hopefully all know if one wants to play around with such things as an adult its fine, but never let your children get your dangerous things in their hands..

@wower with the 4 channel remote you can hit the left shoulder-button, this will combine channel B with A (if one of the channels needs to be reversed, do this for channel B separately by pressing both direction-buttons until the led shortly blinks). FYI: Right Shoulder-button combines Channel C with A also.. I would not recommend to put two motors (esp. buggy motors with their high starting currents, above 2A in some situations) on one channel - this can easily burn the driver of that channel. Better combine them via different channels. Whan one wants to use the MK app, the only way of binding more then one output channel to one input control, it is needed to bound them to the same BT channel (unfortunately this will make all 4 ports of both receivers of the same channel have the same functionality..)

@SNIPE: from my experiences ABS on ABS will heat up and melt parts more easily then having an axle out of aluminium, taking away the heat from the point of friction - but in the end there will be wear on the weaker parts. I think there are some common rules one should follow for using metal parts: They will create more wear on the next weak part, depending on the amount of axial forces applied For gears the best approach is having the gear with lower number of teeth being the metal one because the higher teethcount will wear out more slowly For axles I would recommend to use the ballbeared liftarms (although not possible in all scenarios), those will result in having no friction towards the surrounding construction

All good,sorry if my post felt harsh.... wasnt meant to be rude. So thanks for sharing the information with us.

Why not posting in the Bricklink Studio forums? There it may get picked up as a bug and will maybe get fixedone day.

@freakwave you can now download unofficial files too... Examples of the Daytona wheels: https://www.reum.it/ldraw-to-studio-exporter/index.php?part=73389.dat&unofficial=true https://www.reum.it/ldraw-to-studio-exporter/index.php?part=73398.dat&unofficial=true https://www.reum.it/ldraw-to-studio-exporter/index.php?part=80279.dat&unofficial=true

@2GodBDGlory I was asked by Jim to make it a generic metal part thread - but I can see your point to them being mentioned as an alternative before going for metal parts in some usecases.