Support for WeDo 2.0/BOOST

[dlech]

I know someone will ask about this sooner or later (actually I'm kind of surprised no one has yet). If you haven't seen the news, LEGO Education has released WeDo 2.0. It is not compatible with Power Functions like it's WeDo predecessor (now being called WeDo 1.0). Instead, it as a new, unique electrical connector. WeDo 2.0 has a new "medium" motor that has studs on top which is kind of nifty. It also has what looks like the same motion (really distance) and tilt sensors as WeDo 1.0, just with the new style electrical connector. The hub is now Bluetooth instead of USB. It is advertised at BLE (Bluetooth Low Energy), but I saw some mentions that it might also work with Bluetooth 2.0. The hub takes only 2 AA batteries, which means it operates at 3VDC. I have a feeling that this means that the motor is not very powerful.

Given the fact that it is rather expensive compared to the usefulness that it provides, this is probably going to be pretty low in the priority list unless someone wants to make this his/her pet project.

[rhempel]

I may be getting one shipped to me after the initial orders are filled. My understanding is that it is BTLE and only the newer EV3 bricks have a compatible 4.0 BT chipset. I would be very happy to be proven wrong.

Yes, it will be pricey for the functionality, but how cool would it be!

[botbench]

Unfortunately, Andy Shaw has determined that, while they may be BT 4.0 compliant, they are unlikely to be BLE capable.

[JorgePe]

Hi. Got myself a bluetooth sniffer (Ubertooth One). Also managed to make the WeDo 2.0 App work with my Android phone so I finally have a working configuration I can sniff. First tests were good, already found what to and where to write in order to change the WeDo 2.0 Hub color. So in a week or two (I'll be busy at work this weekend, major downtime) I expect to publish one or two more tutorials (I was considering one for the color and other for the sensors, not sure if it makes sense a third tutorial for minor information like temp/voltage/current/version with the color).

But having a SDK would be much better to understand all modes and settings, not just the ones currently used by the App.

[dwalton76]

@JorgePe since you have a bluetooth sniffer (and if you are bored) could you take a look how the Robot Commander app connects to the EV3? I tried to get this working a while back, see #500 , but without a sniffer I hit a brick wall.

[JorgePe]

@dwalton76 I'm never bored but I'll be glad to help if I can.

[dlech]

The robot commander app works much like the EV3-G software in that it downloads a program to the EV3 and runs it. It uses Bluetooth RFCOMM. It won't work with ev3dev until someone implements the lms2012 VM for ev3dev #329.

[dwalton76]

ah bummer, don't worry about sniffing it Jorge

[JorgePe]

LEGO Education released the SDK today: https://education.lego.com/en-us/support/wedo-2/developer-kits

It's the first time I look to a SDK, not quite what I was expecting but already found info related to the PIEZO - as expected, the same handle (003d) that is used for the motors and the RGB LED has also a command (02) that plays a tune. Payload is 04 bytes: 2 bytes for Tone Freq in Hz and 2 bytes for Tone duration in ms (reversed). So this gatttool command plays a 1 KHz note during 1 s:

char-write-cmd 003d 050204E803E803

[Salva-OA]

Hi, Any of you could gess what is the cable pinout of the wedo 2 hub?.

I think if we can discover what pins the sensors use to show its analog value beetwen 0-3V you can integrate it with microcontroller cards to expand the posibilities of our creations. Since the cable has 6 pins i guess the other two are for some kind of comunication bus to address the motor and one sensor.

When i tried to connect the two sensors: tilt and distance the hub bloked the bluetooth link with the pc.

[JorgePe]

Up to now I just tried with motors - I managed to use an old LEGO 9V micro-motor with the WeDo Pins 1 and 2 are for motors - the other pins are not used in the WeDo 2.0 motor. https://flic.kr/p/K5jb75

CORRECTION: 3 other pins are used for Auto-ID, I wasn't using the LEGO App so didn't notice it. Philo reported a 2k2 resistor between pin 3 and 5 in the motor but that is not enough, the App shows an orange "?", detects a device but doesn't recognizes it, I found out that connecting pin 3 to 6 completes the Auto-ID.

[Salva-OA]

Thanks Jorge. So pins 1 and 2 can be used to turn clockwise or viceversa a motor, and making a "non- standart" cable adaptor we can join it to a PWM output to change the torque/velocity of our creations.

[JorgePe]

Yes. But the new plug is a pain, at least NXT/EV3 plug is "almost" an RJ plug. The easiest way to make an adapter is cutting a cable from a WeDo 2.0 motor or sensor and soldering pins 1+2 to a power Functions cable or to a non-LEGO DC motor. But WeDo 2.0 devices aren't cheap, I was hoping that LEGO would have already released Power Functions 2 devices and extension cables or even adapters... no joy.

[dlech]

This is a total guess as I don't have any WeDo 2.0, but I would suspect that the pinout is the same as NXT/EV3 but possibly missing some features on the WeDo hub.

So, for motors pins 1 and 2 drive the motor (already confirmed by Jorge). Pin 3 should be GND. Pin 4 is probably 5V. And pins 5 and 6 are not used for motors.

For sensors, Pin 1 could be an analog input, Pin 2 probably doesn't do much. Pin 3 is still GND and pin 4 is still 5V. Pins 5 and 6 could be used for some sort of digital communications. Also, pin 6 could be used as an analog input.

[dlech]

It looks like there is a retail version of WeDo 2.0 coming out in August 2017 called LEGO BOOST

https://www.lego.com/en-us/boost

[JorgePe]

Everybody is crazy today about the LEGO Boost :)

It's really just a WeDo 2.0 on-steroids, the Boost Move Hub is simillar to the WeDo SmartHub but uses 6 batteries, includes 2 motors with encoder (so, in this aspect, is more like the old CyberMaster), 1 tilt sensor, the same RGB LED and still need to figure if it has the piezzo or not. The new PF2 motor has also an encoder and the new sensor is a mix of a color sensor and a distance sensor. I think there probably will be made a LiPo battery like the one for the SmartHub.

If #775 gets closed by August we can use pybluez to talk with it ;)

[andypiper]

I've been poking at the BLE stack for Boost on Linux but I'm not familiar enough with reverse engineering the protocol to know what gatttool commands would work.

[JorgePe]

Great timing, I'm also expecting my BOOST tomorrow, Do you have Android with BLE? Instal Nordic nRF Connect for Mobile to see if some of those services have proper English names, which characteristics are read/write, etc.

[JorgePe]

Also look here: https://www.bluetooth.com/specifications/gatt/declarations

For instance, you found 3 Primary Services. You can also see that from output of 'char-desc', every handler with a UUID starting with 0x2800 (Primary Service Declarartion) marks the beginning of a Primary Service

Some characteristics UUID are already standards (see https://www.bluetooth.com/specifications/gatt/characteristics) and you can find some on your list, like 0x2A00 = Device Name

so if you read...

• handle 0x07 you should get your BOOST Hub name in ASCII or Unicode format,
• handle 0x09 you should get "Appearance" (like a class of the device)

Usual uuids are Name, Serial Number, Firmware Version, Battery Level...

[andypiper]

Thanks for the pointers - when I have another slot of time to play with this, I'll give those a try (and the doc is useful)

[JorgePe]

Got my BOOST today. It's not going to be easy without a sniffer, will have to take mine with me these holidays.

Except for "Device Name", LEGO put everything else in just one Characteristic. It is Readable, Writable and supports Notifications. With external motor connected to port A and sensor to port B, when I read it, I get 15 bytes

0F-00-04-3C-01-14-00-02-00-00-00-02-00-00-00

If I rotate a motor by hand or put my hand in front of the sensor I see no change at all so I probably have to write something first.

[JorgePe]

With current firmware, "Device Name" is handle 0x07:

handle: 0x0007, uuid: 00002a00-0000-1000-8000-00805f9b34fb

So we can read or write to it:

[00:16:53:A4:CD:7E][LE]> char-read-hnd 0x07
Characteristic value/descriptor: 4c 45 47 4f 20 4d 6f 76 65 20 48 75 62
"LEGO Move Hub"
[00:16:53:A4:CD:7E][LE]> char-write-cmd 0x07 4d79204d6f766520487562
[00:16:53:A4:CD:7E][LE]> char-read-hnd 0x07
Characteristic value/descriptor: 4d 79 20 4d 6f 76 65 20 48 75 62
"My Move Hub"

But as soon as I cycle power the BOOST firmware resets the Device Name to "LEGO Move Hub".

[JorgePe]

Working with ubertooth sniffer with "my" new laptop is not easy but I'm getting something.

So every seems to be handled by only one handler ("0x0e")

handle: 0x000e, uuid: 00001624-1212-efde-1623-785feabcd123

To change the RGB LED color we write "080081321151000n" to handle "0x0e" where "n" is a value between "0" and "A" with the same meaning as the 11 options we have on the LEGO BOOST App:

0 = none (off) 1 = pink 2 = purple 3 = blue 4 = light blue 5 = cyan? 6 = green 7 = yellow 8 = orange 9 = red A = white

So this shell script shows all colors in a loop:

#!/usr/bin/env bash
for (( ; ; ))
do
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510001
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510002
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510003
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510004
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510005
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510006
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510007
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510008
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510009
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=080081321151000A
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510000
  sleep 1
done

I will document my progress at my blog to don't pollute this issue any more. When/if I have something more decent will add a tutorial to ev3dev site like I did for WeDo 2.0. In a few days I hope to have at least a basic method to control the motors. Sensor is much more difficult, don't think I can get it without a code sample (for WeDo 2.0 I had some luck, there was an example at Microsoft site).

[JorgePe]

Working with ubertooth sniffer with "my" new laptop is not easy but I'm getting something.

So every seems to be handled by only one handler ("0x0e")

handle: 0x000e, uuid: 00001624-1212-efde-1623-785feabcd123

To change the RGB LED color we write "080081321151000n" to handle "0x0e" where "n" is a value between "0" and "A" with the same meaning as the 11 options we have on the LEGO BOOST App:

0 = none (off) 1 = pink 2 = purple 3 = blue 4 = light blue 5 = cyan? 6 = green 7 = yellow 8 = orange 9 = red A = white

So this shell script shows all colors in a loop:

#!/usr/bin/env bash
for (( ; ; ))
do
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510001
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510002
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510003
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510004
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510005
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510006
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510007
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510008
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510009
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=080081321151000A
  sleep 1
  gatttool -b 00:16:53:A4:CD:7E --char-write-req --handle=0x0e --value=0800813211510000
  sleep 1
done

I will document my progress at github BOOSTreveng to don't pollute this issue any more. When/if I have something more decent will add a tutorial to ev3dev site like I did for WeDo 2.0. In a few days I hope to have at least a basic method to control the motors. Sensor is much more difficult, don't think I can get it without a code sample (for WeDo 2.0 I had some luck, there was an example at Microsoft site).

[antonvh]

Great progress here! Can I contribute something in python? I would like to run ev3dev on my mac and control several boost hubs from there. Is that something that would fit in the ev3dev architecture? It's much like giving the ev3 brick some wireless boost slaves.

[JorgePe]

Yes you can! I'm still sniffing major functions, hope can read motor position this weekend, that would complete the basics, then will need to dedicate some time to more complex details. A driver would be great so we can have BOOST motors as we have WeDo 1 motors already.

[JorgePe]

Just an update: I started a python 3 library for BOOST Only a few control methods yet (LED color, motors timed) but give me time.

Unfortunately when starting sensor methods I found a problem: the way BOOST was implemented requires notifications. I've never really used notifications with pygattlib since they were not very well documented and WeDo 2.0 and a few other BLE devices I've been playing with can work without notifications.

python 3 version of pygattlib as some problems with notifications and I have segfaults each time I receive a notification from a sensor. Already created an issue at pygattlib but by the history of their issues I'm afraid it will take a while.

Since it works with python 2, I'm going to duplicate this library for it. It will not work on ev3dev (at least not together with the python-ev3dev package) but at least it can be used from a linux computer.

[antonvh]

Did you do this?

$ make PYTHON_VER=3 $ make install Op vr 1 sep. 2017 om 08:28 schreef Jorge Pereira notifications@github.com

Just an update: I started a python 3 library for BOOST https://github.com/JorgePe/pyb00st Only a few control methods yet (LED color, motors timed) but give me time.

Unfortunately when starting sensor methods I found a problem: the way BOOST was implemented requires notifications. I've never really used notifications with pygattlib since they were not very well documented and WeDo 2.0 and a few other BLE devices I've been playing with can work without notifications.

python 3 version of pygattlib as some problems with notifications and I have segfaults each time I receive a notification from a sensor. Already created an issue at pygattlib but by the history of their issues I'm afraid it will take a while.

Since it works with python 2, I'm going to duplicate this library for it. It will not work on ev3dev (at least not together with the python-ev3dev package) but at least it can be used from a linux computer.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ev3dev/ev3dev/issues/521#issuecomment-326501094, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVunOb_ZbGX4s1Z19jhl_Jgjnf4Qjvbks5sd6QpgaJpZM4HOBCt .

[JorgePe]

Yes. On my Ubuntu I also had to edit makefile to use boost_python-py35 instead of 34 but after make completes there is no install instruction so I have to run python3 setup.py install (and edit setup.py for boost_python-py35 also). There is a fix for this but is not on the source code yet. Source code available for download generates the same version I already had with pip/pip3

[JorgePe]

Update: turns out that WeDo 2.0 and BOOST are 2 sides of the same coin: Power Functions 2.0 As of today, we found out that the BOOST Move Hub firmware recognizes the 3 WeDO 2.0 PF2 devices (tilt sensor, distance sensor, motor) and we can now make use of it - that's more than the LEGO App can do for the moment. So there is a chance that future versions of the WeDo 2.0 SmartHub firmware can also work with the BOOST Interactive Motor (an encoded motor with an AutoID that includes at least a 2k2 resistor between pin 3 an pin 5). For MINDSTORMS, the future seems indeed PF2.0. LEGO Technic will not like it - do not support parallel devices, needs some "smartness" (WeDo 2.0 SmartHub and BOOST Move Hub) and have some latency... perhaps a third Hub, smarter than these two, is on the way... MINDSTORMS AD4?

[dlech]

I already knew that :wink: (there is a note on the LEGO Education website that says WeDo 2.0 == Power Functions 2.0 and that it will mostly likely be used for future MINDSTORMS as well).

I also suspect that with an adapter, the motors and sensors will work with the EV3 directly (at least with ev3dev). I don't have BOOST or WeDo 2.0, but it would just take someone with a logic analyzer to confirm this.

[JorgePe]

I like that suspicion :) will try with my own methods I read that note also. Everybody talked about that 2 years ago, but LEGO never really gave more information about that and PF 1 and EV3 kept selling... people got the hope that it was only for Education and maybe Technic.

[JorgePe]

Quick update: pyb00st reached beta stage as it is good enough for simple robots like this Line Follower:

https://youtu.be/2QysaaYmy9Q

It can be used with Linux (including ev3dev) with any common BT BLE controller and also with Windows (and probably also OSX) with a BlueGiga adapter like the BLED112.

I'm still learning python so don't expect perfection... but I'm pretty proud nevertheless :)

[JorgePe]

Just an update if any one comes here:

LEGO released the Powered Up line. It appears to be the final brand name of "Power Functions 2". The new LEGO trains sets include a smart hub with just 6xAAA batteries and two I/O ports, similar to the WeDo 2 Smart Hub. They also include a new train motor, essencially a Powered Up version of the Power Functions train motor. And they also include a standalone controller, a basic BLE replacement of the Power Functions IR Command.

WeDo 2 is not "Powered Up". It's more like a prototype but since it's firmware cannot be upgraded "over the air" so it will not work with recent devices like the motors and sensors that were released with BOOST. But the motors and sensors released with WeDo2 are Powered Up. The motor (a kind of Powered Up version of the Power Functions Medium Motor) works fine with BOOST and the new trains hub. Same happens with the Color+Distance sensor.

BOOST is also Powered Up but not marketed as such.

New sets are also being release, like a Batman car with same smart hub as the trains (and 2x WeDo 2 motors) and new DUPLO trains. The DUPLO trains will not be marketed as Powered Up... but they are.

The good part: Powered Up uses same BLE services/characteristics as BOOST. So it's easy to use previous code with just some minor changes.

ev3dev already works fine with Powered Up: current stretch snapshots include BlueZ and pybluez with gattlib. Have not tested python yet but command line gatttool from BlueZ works fine.

So expect some progress and news soon.

[dlech]

WeDo 2 is not "Powered Up". It's more like a prototype but since it's firmware cannot be upgraded "over the air" so it will not work with recent devices like the motors and sensors that were released with BOOST.

Maybe you should put this in table form. Which devices can have firmware upgraded and which cannot? Which sensors and motors work or do not work which which hub?

[JorgePe]

OK. But will wait a few weeks... some devices are supposed to show up this summer and I still don't know the official names of all.

But basically:

• WeDo 2 is not upgradable; BOOST and everything after (Powered Up) are
• WeDo 2 works with just WeDo 2 motors and WeDo 2 sensors; BOOST and everything after (Powered Up) work with every motors and sensors including WeDo2.

[dlech]

Thanks, I was wondering after reading your blog posts. :wink:

[JorgePe]

Don't create too high expectations... no Technic or MINDSTORMS versions yet (if ever), LEGO is still sensing people reactions almost one or two themes at each new version. But the DUPLO trains with an embedded color sensor and this new smart hub (common to trains and DC Heroes) are interesting. Not perfect, but interesting.

[JorgePe]

I also suspect that with an adapter, the motors and sensors will work with the EV3 directly (at least with ev3dev). I don't have BOOST or WeDo 2.0, but it would just take someone with a logic analyzer to confirm this.

@dlech I got a poor man's logic analyzer. Two in fact: a Bus Pirate and a BitScope. The BitScope almost does the job but the software doesn't allow to export the capture. But Bus Pirate allows redirection of the traffic to /dev/ttyUSB03 so I can watch it with a software like jpnevulator

So tonight I remembered your quote above, after finally catching something: at 57200 bps the BOOST Interactive Motor keeps sending what seem the encoder position in a 5 byte message:

A0 xx ww yy zz

The pinout is indeed similar to the EV3: 1 - M1 2 - M2 3 - GND 4 - VCC (3V3) 5 - ID1 / UART 6 - ID2 / UART

So we have 3V3 and 57200 bps... I will try to get more info next nights but if you have any sugestion to test that idea of compatibility with ev3dev I am listening :)

[dlech]

I would expect the baud rate to be 57600. 57200 is not a standard rate.

When the motor (or sensor) is first connected, is there a negotiation at 2400 baud?

The position feedback of this motor certainly won't work directly with an EV3 since we don't have UART on the output ports. It would have to be connected to both and input port and an output port (assuming it can handle 5V VCC).

[JorgePe]

Hmm, perhaps it is 57600 and my brain is fried. Too hot this August in Portugal.

I don't see traffic from the Hub to the motor. Not 100% sure (still trying to undertsand how to use this) but it really seems just one direction.

The first byte is not always A0 after all. It's A0 only when the motor is stopped. It seems to reflect both direction of rotation and speed. And the last byte is not always 0A also. Some sort of checksum perhaps.

I really need a decent PF2 extension cable to capture traffic with the sensors instead of the motor. But the female PLUG is a really problem to achieve.

[cbpmckinney]

I just got both of the Powered Up train sets, and have been messing with trying to get Jorge's library to work with them.

The first question is how to determine the MAC address for a given hub. Jorge's example code has 00:16:53:A4:CD:7E, and so my understanding is that 00:16:53 refers to LEGO, and A4:CD:7E is the part specific to Jorge's hub. Were you able to determine this from the hub itself, Jorge, or did you have to do some sniffing wizardry? I ask because inside the hub or controller is some information; my hub has IC: 3072A-28738, and my controller has 3072A-28739. I'm wondering if the A2873x at the end if each is the last three of the bluetooth MAC. Maybe that'd be too easy though!

So far I've managed to use a BT app to connect to the hub and successfully change the LED color, but no dice getting Jorge's test_connection.py to work on my Mac.

Edit: figured out most problems, but still no dice. Is it necessary to have a Bluetooth dongle, separate from the internal Bluetooth interface?

[JorgePe]

I use Nordic nRF Connect on my Android to scan for BLE devices and get the address. Or, in linux, 'hcitool lescan'

Sorry I don't have a Mac and I'm a little confused have been sniffing UART LEGO protocol all night... what 'test_connection.py' you refer?

[cbpmckinney]

Oh, sorry, the test_connection.py file from your pyb00st/examples collection.

Annoyingly the two BLE scanner apps I found for my iPhone can tell me lots, UUID etc., but nowhere do either of them state the Bluetooth MAC.

Edit: I had forgotten that iStumbler also does Bluetooth, and it gave me a MAC. However, I'm a bit suspicious of it because it doesn't have the LEGO ID (00:16:53). I'll try hcitool on a Raspberry Pi this week.

[cbpmckinney]

Just discovered that LEGO actually has two sets of OID's for Bluetooth:

00:16:53 LegoSyst LEGO System A/S IE Electronics Division 90:84:2B LegoSyst LEGO System A/S

I wonder if they use different ones for different regions. In any case, though, I think this means I've got a valid MAC and hopefully can get a connection to my RaspPi or EV3, and hopefully also the Mac.

[dlech]

I imagine that they used up the 16M addresses and had to get a new OUI.

Fun fact. These are not "MAC" addresses. MAC addresses are for NICs (i.e Ethernet). These addresses are "Bluetooth Device addresses" (BD address for short). BD addresses use the same EUI-48 format as MAC addresses, so they look the same.

[JorgePe]

Yes, the Powered Up hubs have a new OUI (BT "MAC" address) registered by LEGO. And the trains Handsets also use a different OUI (I think from TI). You can get a BLE session from the RPi, the EV3 (with a proper USB dongle), your computer or anything BLE compatible that can start a session to the Hub. Technically, even from another Powered Up hub (it is the Hub that connects to the Handset so it can simultaneously work as a "master" and as a "slave").

[JorgePe]

LEGO releasead a fisrt draft of the specs: https://lego.github.io/lego-ble-wireless-protocol-docs/ Some information already known but there is very interesting information about virtual ports and networking, not sure if totally useful for now but it promises.

[antonvh]

nice!

On 21 Dec 2018, at 10:47, Jorge Pereira notifications@github.com wrote:

LEGO releasead a fisrt draft of the specs: https://lego.github.io/lego-ble-wireless-protocol-docs/ https://lego.github.io/lego-ble-wireless-protocol-docs/ Some information already known but there is very interesting information about virtual ports and networking, not sure if totally useful for now but it promises.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ev3dev/ev3dev/issues/521#issuecomment-449336028, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVunFhUx2Eyug00eRenrtDSs-iCUeQJks5u7K4jgaJpZM4HOBCt.

[cbpmckinney]

Awesome, thanks for the note.

As it happens, I have a student who wants to do some independent work for the first half of the spring semester, and we’re planning to have him work on the train motors and ev3/computer control, along with maybe some examples/documentation.

-Colin

On Dec 21, 2018, at 03:47, Jorge Pereira notifications@github.com wrote:

LEGO releasead a fisrt draft of the specs: https://lego.github.io/lego-ble-wireless-protocol-docs/ https://lego.github.io/lego-ble-wireless-protocol-docs/ Some information already known but there is very interesting information about virtual ports and networking, not sure if totally useful for now but it promises.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ev3dev/ev3dev/issues/521#issuecomment-449336028, or mute the thread https://github.com/notifications/unsubscribe-auth/AotNdV_UR4Xt8nuUv6Bz76t8wdtM_-gfks5u7K4jgaJpZM4HOBCt.

[cbpmckinney]

An update for everyone: I'm working with a student and yesterday we were able to get Jorge's pyb00st code to successfully connect a Raspberry Pi + Edimax Bluetooth/Wifi dongle to the bluetooth train controllers, and change a light color. No luck yet on the motor control, but we're making some progress.