just a bit more sense now

(And I really must be crazy to stay up late doing this)

At 115200 there is also a pattern (and why did I start with 57600?)

00 00 00 00 00 00 00 54 22 00 10 20 B9 
D8 00 00 00 00 00 00 00 00 27
D8 00 00 00 00 00 00 00 00 27
D8 00 00 00 00 00 00 00 00 27
D8 00 00 00 00 00 00 00 00 27
...

First position notification says ’08 00 45 01 00 00 00 00′ so the encoder is at zero.

Sending 5x the command to turn 1 degree I get 3 position changes:

08 00 45 01 01 00 00 00 
08 00 45 01 04 00 00 00 
08 00 45 01 05 00 00 00

(1º, 4º and 5º)

and a decent capture:

D8 00 00 00 00 00 00 00 00 27
D8 00 01 00 00 00 00 00 00 26
D8 00 02 00 00 00 00 00 00 25
D8 00 02 00 00 00 00 00 00 25 
D8 07 03 00 00 00 00 00 00 23
D8 07 04 00 00 00 00 00 00 24
D8 03 05 00 00 00 00 00 00 21
D8 03 05 00 00 00 00 00 00 21
D8 00 05 00 00 00 00 00 00 22
D8 00 05 00 00 00 00 00 00 22
D8 00 05 00 00 00 00 00 00 22

So clearly the 3rd byte is the position (but passing through 2º and 3º seems to have been ignored by the Hub) and the 2nd byte is related to the speed and direction of the rotation.

Now the 1st and last byte: 27 is the ones’ complement of D8

And probably this isn’t the right algorithm but it works at 4 am: if we calculate ‘S’ as the XOR of all payload bytes, the last byte is 27 – S.

Now I ‘just’ need to understand the first bytes received after power up:

00 00 00 00 00 00 00 54 22 00 10 20 B9

It must be the announcement that complements the AutoID…. but does it have some kind of meaning?

Ideas?

Spock was correct

And at 57200 57600 bps a pattern at last!!!

So I put Bus Pirate capturing traffic between the LEGO BOOST Hub and the BOOT motor (the one with the encoder that LEGO calls “Interactive Motor“) at 57200.

I ran my serial sniffer:

jpnevulator --ascii --tty /dev/ttyUSB3 --read

I power up the Hub with the motor attached (to port C, not sure if important).

And a pattern of 6 bytes appears:

0A EF EF 00 A0

Where ‘0A’ and ‘A0’ seem “start” and “end” of a message and ‘EF EF 00’ the payload. Or something completely different, like the Monty Python would say.

I connect to the Hub with gatttool in interactive mode and activate notifications and motor readings and then send a command to turn just 1 degree:

char-write-req 0x0f 0100
char-write-req 0x0e 0a004101020100000001
char-write-req 0x0e 0E018101110B0100000064647F03

no events return from the motor but something flows between the Hub and the motor and then the pattern returns:

0A EF EF 00 A0

Thats good! Because I knew that 1 degree is not enough to generate a new position notification (usually 4 to 6 commands are needed) and the payload didn’t change.

1 more command to turn 1 degree. Same

1 more. Same.

1 more. Same. I already sent the same command 4 times.

No 1 more command and a notification is received. And the pattern changes to

0A 00 00 00 A0

There was an increase! But not by +1..

Now I move the axle myself a bit and the payload changes to ’01 00 00′.

I move again backwards so the payload changes back to ’00 00 00′.

Now I send again the same ‘turn 1 degree’ command 5 times… and I get a position change notification and the payload increased to ’01 00 00′ as expected.

So the payload is the encoder position in degrees. 3 bytes, reverted (or little endian).

Edited: spoke too early. 5 bytes message yes, payload related to encoder position yes, payload meaning not so simple.

Not enough yet to use the motor on other systems (like an Arduino or an Ev3) but it is a start. And a drop of wisdom on a hot night after a very pleasant day with family at water sliding park.

Powered Up AutoID’s

Notes to myself:

AutoID’s:

  • Train Motor:
    • pin 5 shorted to 4 (VCC)
    • pin 6 shorted to 3 (GND)
  • M Motor:
    • 2k2 between pin 3 (GND) and pin 5
    • pin 6 shorted to 3 (GND)
  • Lights (needs confirmation):
    • 2k2 between pin 3 (GND) and pin 5
  • Tacho Motor (needs confirmation):
    • 2k2 between pin 3 (GND) and 4 (VCC)
    • 2M2 between pin 3 (GND) and 5
    • 2M2 between pin 3 (GND) and 6
    • 2M2 between pin 4 (VCC) and 5
    • 2M2 between pin 4 (VCC) and 6
  • WeDo 2.0 Motion Sensor:
    • 2k2 between pin 3 (GND) and 4 (VCC)
    • 135k between pin 3 (GND) and 5
    • 135k between pin 3 (GND) and 6
    • 135k between pin 4 (VCC) and 5
    • 135k between pin 4 (VCC) and 6
  • WeDo 2.0 Tilt Sensor:
    • 2k2 between pin 3 (GND) and 4 (VCC)
    • 135k between pin 3 (GND) and 5
    • 135k between pin 3 (GND) and 6
    • 135k between pin 4 (VCC) and 5
    • 135k between pin 4 (VCC) and 5

On the Tacho Motor the 2.2 MΩ measured between both GND and VCC and pin 5 and pin 6 make me think on a voltage divider but values are high. Also the 2.2 kΩ between GND and VCC puzzles me (other devices don’t have it).

The WeDo 2.0 Motion Sensor also has 2k2 between GND and VCC. Hmm… the same with the WeDo 2.0 Tilt sensor. But not the BOOST Color&Distance Sensor (11k).

The two WeDo 2.0 sensors (Motion and Tilt) have same measured resistance. So the AutoID ought to be completed by the protocol.

Also:

VCC is 3.3V

The Powered Up Smoke Engine

I will now explain how to connect a smoke engine to the Powered Up Hub – a method that can be used for several type of electric or electronic devices, not just a smoke generator.

First we need to remember the pinout. I show here the female plug on the hub, it’s easier to see the pins:

Powered Up female connector

Thanks to JopieK who opened up is PUP Train Motor for the good of science we already know the names given to each pin by LEGO:

1 – M1
2 – M2
3 – GND
4 – VCC
5 – ID1
6 – ID2

These are the names from the Train Motor side, not necessarily from the Hub side (some of us suspect that pin 5 and pin 6 combine Analog Input and UART functions). For this post purpose these names are enough.

So to emulate a PUP Train Motor we just need to short ID1 to VCC and ID2 to GND and use the M1 and M2 pins:

Powered Up cable hack – train

So I used a PF2 available cable (don’t ask) and stripped the insulation off, joined wire 3 to wire 6 and wire 4 to wire 5 and soldered these two junctions:

Powered Up cable with Train Motor AutoID

Then used heat shrinking tube to isolate these junctions:

The two remaining wires can now be used to control anything we want with a PWM signal of  near 9 Volt (from M1 to M2 or M2 to M1, depending on the direction we choose for the “train motor”). This is the same signal of Power Functions so if we want to connect a LEGO PF motor we just need to connect these two wires to C1 and C2 of a PF connector.

But I want to use a Seuthe Nr. 99 smoke generator for H0 scale trains:

This little device operates with a voltage between 8 and 14 Volt and consuming around 140 mA. My previous experiments with PF revealed that I would need more than just 8V so direct attaching it to a PF cable wasn’t enough, I needed a boost circuit to raise voltage a bit – I used a small circuit and trimmed it to ~11.2 V.

It worked quite well with my PF version of the BR80 so I just reused the circuit, replacing the PF cable with this PUP cable:

Final cable

The circuit is very simple, just a small rectifier bridge and a pre-assembled small boost circuit (Pololu Adjustable Boost Regulator 4-25V, item #799):

The rectifier bridge’s function is to prevent damage to the boost circuit that don’t work with negative voltages when we reverse the direction of the “motor train”.

So how does it work?

Since we are using the same AutoID of the PUP Train Motor, the Hub will notice it as such when we connect this PUP Smoke Engine. So if we use a PUP Handset we just need to press + or – button a few times until the “train motor” receives enough voltage for the boost circuit to work and heats the Seuthe to produce smoke. Same if we use the LEGO App… unfortunately with my BR80 the App doesn’t work because the PUP M motor is not accepted as a valid train motor.

So I made my own ‘Gatto Negro’ App.

 

Smoke generator for LEGO Powered Up Train

A few months ago I have made my own version of Holger Matthes’ BR80. It was not a full replica because I didn’t have all the pieces required so I had to improvise. I also opted for an all-black version instead of a black+red combination.

I decided I needed a steam engine after some experiments with a MINDSTORMS EV3 setup with a train turntable, two rail switches and a pseudo train with SBrick and RFID:

After I added a mechanism to disengage the train engine from the cargo wagon I decided I needed a steam engine since modern trains don’t need the turntable to operate.

As the SBrick had 4 outputs and I was only using 2 for the motor and the lights I wonder what else could I add to it. Choosed two extra functions that would look good on a LUG exhibition:

  • a smoke engine
  • a horn

The initial project was dismantled but I’m now returning to it with a MILS-based layout to use in larger dioramas with other PLUG fellows:

Currently the turntable and the rail switches are still manually operated but at least I now have a steam engine. With real smoke:

This is ‘Gatto Negro’. It means ‘Black Catt’, I’m using the extra ‘T’ because in Bluetooth Low Energy jargon ‘GATT’ means ‘General Attributes’ and I’ve been using a lot the linux command ‘gatttool’ to quickly test my BLE devices.

Of course ‘Gatto Negro’ is also BLE – it uses the new LEGO Powered Up hub and the PUP version of the LEGO Medium motor instead of the Power Functions IR Receiver, LiPo battery and M motor.

Unfortunately with the current firmware of the PUP Hub using a M motor isn’t the best option: the remote BLE Handset doesn’t hold the speed setting so we have to control the train with short or long button presses, always at full speed. Same happens with current LEGO App because LEGO programmers decided that only a train motor should be used for trains (each PUP device has an unique AutoID and the App was made to use train motors with train controls and non-train motors with car controls).

So I made my own ‘Gatto Negro’ aplication, with MIT AI2.

Next posts I’ll write about the smoke generator and the App.

Qi charger – more details

So I found a 2.4A USB charger:

Carregador Parede 2Hix 4*Usb (2*2.4A+2*1.0A) Preto

Already tried a 3A model but it was a dual USB port and no info about each port limit, I suspect it is 1.5A for each.

So I started charging my EV3 again, with ev3dev running. But removed the USB hub and the CRS 4.0 dongle, left just the Edimax wi-fi dongle. Also disconnected 2 large EV3 motors I had:

162666

163 mA (43 mA less than previous attempts)

Is started from last night “full” charge with same Qi emitter and receiver (but EV3 OFF), 7.23 Volt

7232133

After 45 minutes it charged to 0.1 V more (7330466). After that it slowed down but still charge up to 7350466 exactly 1h57m after.

Then it started to behave strangely again, discharging to 7262466 after another 35 minutes. Then it stayed there for the next 20 minutes.

Both RED and GREEN lights are ON (EV3 battery). And the Qi devices seem  coupled.

7.26V is just 0.03V more than last night “full” charge result. Perhaps it is the best I can get with the boost circuit’s output trimmed to 9.02V.

If that’s the limit, then using a better USB charger and/or reducing EV3 current consumption by 43 mA helped. But it still isn’t enough for a mobile robot, adding a couple of motors and sensors will raise consumption above the nearby threshold and the robot will just discharge slower until it shuts down.

I wish the EV3 had a Real Time Clock and wake up function. Crazy ideas accepted 🙂

Issues with wireless charger

Had been struggling with my wireless charger.

Turns out that with the EV3 ON it never charges. It starts, gets a few decimals of Volt and then it starts discharging.

The EV3 battery LEDs are both ON (RED and GREEN, meaning it is charging). Battery level, according to

cat /sys/class/power_supply/lego-ev3-battery/voltage_now

is 6912400 so 6.9 Volt

The Qi emitter is using a 2A USB charger. The LED shows it is coupled with the Qi receiver. For the first 15 minutes or so it charges a bit but no more that 0.1V… then it starts discharging. After 3 hours, the ev3dev turns itself OFF.

Tried a different Qi emitter. Also a few different USB chargers. The Qi emitter gets hot. Sometimes one of them blinks, I thought it was a coupling problem but now I think it is an overcurrent or thermal protection…

Not sure about the efficiency of this Qi couple and also not sure about the efficiency of the boost circuit… I suspect that I need more than 2A through the emitter to get a full charge and they can’t handle it more than a few minutes and then they “throttle” current.

I trimmed the boost circuit to give 9.02 V instead of 10.02 V. Less voltage should mean more current available but didn’t notice any effect.

Last night I left the battery charging  with EV3 off (it had not enough charge for ev3dev to keep running) . This morning the GREEN light was ON and the RED was off so it charged. Turning EV3 ON it reported

7263733

So the battery is not quite full charged but much better than what I get with EV3 ON.

With a small 4-port USB hub, an Edimax wi-fi dongle and a CSR 4.0 BT/BLE dongle the ev3dev reports 208 mA

cat /sys/class/power_supply/lego-ev3-battery/current-now
20800

I plan to get a current meter and watch consumption with several dummy loads. Perhaps I can tune my gadget a bit but I think I’ll have to find a better Qi receiver (and probably also a better Qi emitter).

So, for now, Juan’s idea of using this for charging an autonomous Ev3 robot is paused. The better we can do is bringing the robot to the charging point and turn it OFF to let it charge. But someone has to go there to turn it ON again after charging is complete.

New version of python-ev3dev available

python-ev3dev v2 available in beta (just for stretch)

The highlights include:

  • New classes are available for coordinating motors: ev3dev2.motor.MotorSet, ev3dev2.motor.MoveTank, ev3dev2.motor.MoveSteering, and ev3dev2.motor.MoveJoystick.
  • Classes representing a variety of motor speed units are available and accepted by many of the motor interfaces: see our docs to learn more.
  • Friendlier interfaces for operating motors and sensors: check out ev3dev2.motor.Motor.on_for_rotations and the other on_for_* methods on motors.
  • Easier interactivity via buttons: each button now has wait_for_pressed, wait_for_released and wait_for_bump
  • Improved ev3dev2.sound.Sound and ev3dev2.display.Display interfaces
  • New color conversion methods in ev3dev2.sensor.lego.ColorSensor

Broadcom-based USB BLE dongle

Found my BT BLE dongle with the Broadcom chipset.

It’s a “Targus Bluetooth v4.0 Dual-mode Dongle ACB75A” that is sold at Staples.

dmesg:

usb 1-1: new full-speed USB device number 9 using xhci_hcd
usb 1-1: New USB device found, idVendor=0a5c, idProduct=21e8
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: BCM20702A0
usb 1-1: Manufacturer: Broadcom Corp
usb 1-1: SerialNumber: 5CF370878D54
Bluetooth: hci1: BCM: chip id 63
Bluetooth: hci1: BCM: features 0x07
Bluetooth: hci1: BCM20702A
Bluetooth: hci1: BCM20702A1 (001.002.014) build 0000
bluetooth hci1: Direct firmware load for brcm/BCM20702A1-0a5c-21e8.hcd failed with error -2
Bluetooth: hci1: BCM: Patch brcm/BCM20702A1-0a5c-21e8.hcd not found

hciconfig:

hci1:	Type: Primary  Bus: USB
	BD Address: 5C:F3:70:87:8D:54  ACL MTU: 1021:8  SCO MTU: 64:1
	UP RUNNING 
	RX bytes:1052 acl:0 sco:0 events:63 errors:0
	TX bytes:4898 acl:0 sco:0 commands:63 errors:0
	Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
	Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
	Link policy: RSWITCH SNIFF 
	Link mode: SLAVE ACCEPT 
	Name: 'xxxx'
	Class: 0x1c010c
	Service Classes: Rendering, Capturing, Object Transfer
	Device Class: Computer, Laptop
	HCI Version: 4.0 (0x6)  Revision: 0x1000
	LMP Version: 4.0 (0x6)  Subversion: 0x220e
	Manufacturer: Broadcom Corporation (15)

so it’s a Broadcom BCM20702A chipset and my Ubuntu doesn’t find the firmware needed. It still works without firmware but I went after it.

This site helped:

wget https://s3.amazonaws.com/plugable/bin/fw-0a5c_21e8.hcd
sudo cp fw-0a5c_21e8.hcd /lib/firmware/brcm/BCM20702A1-0a5c-21e8.hcd

I got my script working with 6 LEGO BLE devices. And 7. And even 8:

But latency isn’t great (with 8 I had to decrease the loop period from 1 second to 0.25 to prevent connection drops and even send the initial command twice to the Handset to hold the session) so even if it supports 14 sessions I doubt that we can make good use of 14 LEGO LPF2 hubs with just one dongle.

To reduce latency we can add more dongles. But even so, when a command takes 0.2 to 0.3 seconds to complete before we can send the next one, it’s hardly interesting for robotics. A Powered Up based robot will require a real autonomous device, able to read its own sensors and react on the fly, not with half a second round trip delay to the “brain”.

Also tried the script without the firmware. It works but with a few “connect error: Function not implemented (38)”.

And also re-tried the Cambridge CSR 4.0. It clearly states that it can’t handle the sixth: “connect error: Too many links (31)”