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.

Thanks. I've space for it on this particular project, the Powered Up Conveyex: so I've removed the hacked cable I was using and now the only non-LEGO parts are the 4DBrix (monorail car extensions, rail ramp extensions and rail diagonals)

Oh I'm a lucky privileged guy, I've seen many amazing things in my live and also have much more LEGO and electronic gadgets than the average. I was thinking in kids in general - small not so rich countries like mine, far from "the center", have smaller geek groups and usually smaller events. Our LUG (PLUG) usually have a Technic/MINDSTORMS table but we are just 3 or 4 guys, we do our best but we are really playing in another league :)

This is truly awesome! I remember sawing a video of your work perhaps 2 years ago and got amazed by then but you kept growing and increasing the complexity... well done! Too bad we never have the chance to see such creations in our country :(

For my Powered Up Conveyex Monorail I need more power than the Hub can give so I've made a Relay that allows me to turn ON/OFF the monorail motors with the Powered Up Hub (using the Handset or a program) but using the Power Functions LiPo battery for the motors, increasing the autonomy of the Hub's 6xAAA batteries: I've made a LDcad model and generated the instructions, they are available at my blog: https://ofalcao.pt/blog/2019/lego-powered-up-relay

One advantage of LEGO released this in github is that we can open issues (people already did since it was announced). So guys please open suggestions and/or point incorrections there.

almost :) WeDo 2.0 would have been also a public release.

Initially I would agree with Conchas, the simplest explanation would be that this is the 3rd major release of the documentation. but... the first sentence of the document says: "The LEGO Bluetooth 3.X Hub Profile consists of a single Bluetooth LE GATT service." And WeDo 2.0 Profile has more than one BLE GATT service. There was a big revision from WeDo 2.0 to BOOT/Powered Up, consolidating every functions in just one service (characteristic) and implementing OTA (over the air) firmware upgrades, some networking (mesh) functions and multi-mode (master and slave at same time). So WeDO 2.0 is probably LWP 1.x or maybe 2.0.

If you are using latest stretch-based snapshot, yes. But first try just the usual debug procedures like just one Raspberry Pi (without the BrickPi). If you are a patient guy also test booting with a Raspbian SD Card to check if it really show something.

No, it doesn't. But meanwhile found this issue at ev3dev: https://github.com/ev3dev/ev3dev/issues/856 it has comment for this: https://github.com/ev3dev/ev3dev/issues/956#issuecomment-328325190 so I guess it should show something-

You are using HDMI, I suppose? I only used my BrickPi in headless mode so not sure if ev3dev supports the native HDMI output for console by default. ev3dev documentation has a link to David post about using Adafruit PiTFT as a display: https://lechnology.com/2016/05/adding-a-display-to-brickpi/ It has a reference for "using the HDMI as well" so it looks like HDMI should work so perhaps you just need to edit the configuration file for video options? https://www.raspberrypi.org/documentation/configuration/config-txt/video.md