MajorAlvega

My wife knows me much much better than that ;)

patience is something we are used to regarding LEGO documentation

Yes it is. The whole LPF1 IR protocol is implemented "straight", just put the relevant nibbles in the block and leave the CRC part for the Hub to take care. Also the block that sends the command retains the last command sent. So no need to keep sending it.

Sorry, I'm locked home with wife and kids... if I build a train track in the leaving room my wife kills me :D I believe it can (something simillar occurred me) at least if the train isn't moving extra fast.

You can butt them up without any gap. The maximum distance is still unclear, at least 2.5 meters.

Just to confirm: - the new 3.1.0 App delivers 2 new blocks that allows a Color Sensor to be used as a IR emiiter - there is no information at all from LEGO on known websites - we can use those blocks to initialize the Color Sensor in a mode that allows us to send commands in Single Output Mode (from LEGO LPF1 IR specs) - the new firmware uses these BLE commands so some of you might update your tools/apps/libraries and skip LEGO Powered Up App: To initialize the Color Sensor in the proper mode/frequency/color/whatever: 0a004100070100000001 To send 'x' speed to red port on channel 'y': 090081001151074x0y To send 'x' speed to blue port on channel 'y': 090081001151075x0y where 'x' in range [0..F] (0 increments to 7 in one direction, 9 decrements to F in the other direction) and 'y' in range [0..3] (this assuming a Color Sensor at port A of a Powered Up hub no.4)

Hi. Thanks. it is possibile to use EV3 with an external (USB) bluetooth controller that supports BLE (most, if not all, USB BT 4.0 do). But since the EV3 firmware doesn't recognize these controllers, you will have to boot the EV3 from a microSD card with a proper operating system. The only one I know that supports BT BLE is ev3dev (a version of Debian linux made for EV3). it is possible (in theory at least) to use some sort of gateway to work with native EV3 firmware - like, for instance, an Arduino that connects to the EV3 through the UART or the I2C and receives commands written in EV3-G blocks and translate them to GATT commands that control the Powered Up; or a Smartphone that talks with EV3 through (native) Bluetooth messaging and translates to GATT commands.

@Toastie I like your backlog :) And I didn't say Microsoft Windows is bad (i can say that on other discussions more related to security, it's my day time job to deal with MS servers... their bad decisions pay my kids' school)... just that the Windows kernel wasn't designed for real time or direct hardware control operations - you are using VB6, i remember it was a problem to use VB6 with parallel (printer) ports, a special driver was needed for that. Not that linux is perfect or easier or whatever... it isn't, it just better feats my own needs like VB6 feats yours. I'm surprised that VB6 has support for BLE nowadays, that's an amazing feature.

If you want fast changes (like a fast Technic car with SBrick) you will want to send short messages and don't waste time with answers. Vengit guys implemented a shorter command format just because of that. The Powered Up "Hub no.4" is not designed for fast Technic cars (to be honest... I still think that BT BLE itself wasn't). Probably the new "CONTROL+" announced for August will have a new kind of smart hub and maybe (just maybe) will handle it better. But even "Hub no.4" can handle 5 to 10 commands per second. If you have several hubs at the same time you will need a BLE controller that can handle more simultanous sessions (or several BLE controllers) and an operating system that handles better those kind of operations (Windows is now better but still not really designed for that and sometimes Microsoft likes to release an hotfix that breaks everything without warning).

hmm... you are pushing it to the limits :) you should really try pygatt or pygattlib and subscribe for notifications if you need to get the outputs. I'm not a programmer but I know you can make system calls with the subprocess library and get returns but your code will became complex.

chipsets are not all equal You might try taking gatttool in Interactive mode out of the equation and using system calls directly, i did that a few years ago while testing SBrick (there was no decent BLE library for python at that time): from subprocess import call ... command="gatttool -b 00:07:80:7F:28:E1 -i hci0 --char-write --handle=0x0025 --value=01"+channel+direction+dt_hexa[2:]; call(command, shell=True);

I was suspecting that you were running linux :) you can reset the hci device with "hciconfig -a hciX down" then "hciconfig -a hciX up". Sometimes I have problems with my Intel-based internal BLE adapter (Dell laptop) but never or almost never with my Cambrige-based USB dongle. Can you checj with "hciconfig -a" and perhaps "lsusb" what chipset you have? Also the problem may be from Hub's side: when this happens, after a while the link drops (the hub starts blinking and disconnects) or it stays connected? If it stays connected then the hub is really receiving the commands and doing nothing with them.

not sure... what python library are you using?

some sort of buffer full on client side? what bluetooth device are you using?

Like Jim said, python, java, C or any other high level languages may allow big structered projects but don't give "per se" other possibilities to EV3. In some cases you may even lack some EV3 possibilities (like daisy chaning, still being addressed by ev3dev project). But when used on a full operating system like ev3dev then lots of other possibilities arise. For a start, you have the full network stack. So you can use standard network protocols with your EV3. And also other linux stacks, like BueZ (Bluetooth) and ALSA (Audio). So you can pair your EV3 with a bluetooth speaker or an USB audio card and get decent sound. Or use your EV3 as a MIDI device. Then you have the device support from the kernel. That means some LEGO devices that Linux still supports (like the old LEGOCam and the original WeDo 1.0) can be used with your EV3. And some NXT devices that no longer work with the current EV3 firmware can still be used as well (like the RFID sensor or the IRLink). And lots of non-LEGO devices - like USB fingerprint readers. Now mixing all this can be difficult. And that's where I think python shines, not because it's a better language but because there is an huge amount of libraries available so you don't need to re-invent the wheel. Like complex mathematics or image and audio processing.