Support for sending IR signals from colordistancesensor

[kebe67]

As far as I am able to see, the mode for sending IR signals from the colordistance sensor to the older Power Functions receivers is not supported in the library. Would it be possible to get support for this in some way?

[mutesplash]

That looks like IR Tx Mode 7. You don't happen to have any documentation on that or part numbers it's supposed to interop with?

[mutesplash]

https://www.philohome.com/pf/LEGO_Power_Functions_RC_v120.pdf

Hm, it looks like maybe you stuff everything between start and stop into two bytes and send that. Unfortunately I have none of the LPF (LPF1?) devices to just throw junk at it and see what happens.

[kebe67]

The documentation you found is the correct one. It exists in three versions, each representing a different firmware for the IR receiver. They all use the same two bytes for the protocol but there are different possibilities within those two bytes. However, I am a bit unsure on where the LIRC checksum is calculated. I've heard that the sensor calculates the LIRC by itself but since this was in the context of the Lego Powered Up app, I am not sure if it is actually the sensor, the hub or the app that does it. I would assume you have some inside access to information (and LPF hardware) from Lego, since Build HAT has been referred to as a partnership with Lego. The part number for the Power Functions IR receiver is 8884. In addition you would need a battery box (8881) and at least one motor (preferably two), e.g. the 8883 M-motor.

In regard of how to implement the functionality I see that there is a difference between the Lego Powered Up app and Pybricks, where the Powered Up app lets you set the 12 first bits of the two bytes (the last 4 is the LIRC) directly, while Pybricks has implemented an object that defines output, motor direction etc as separate parameters. I would prefer the Lego way, since this give access to the whole protocol, not just a few selected functions.

[mutesplash]

I'm just an enthusiast but @chrisruk works for RPi. I haven't found a three-piece LPF1 testing setup for well under $100 on bricklink yet, though.

If you're comfortable testing out a fork, I can work up something to set those 12 bits and you can run it and see what happens. I can only make sure the sensor isn't reporting errors when I send the data to it.

[mutesplash]

Or maybe he did 😅 , it's been a while!

[chrisruk]

@kebe67 I'm afraid I don't have a power function receiver to test reception with.

@mutesplash yeah I have moved to another company.

[mutesplash]

@kebe67 I borrowed some hardware to test this out soon

[mutesplash]

@kebe67 Got the motor to move! So it's possible, I just don't quite have it figured out

[mutesplash]

I have combo PWM mode working reliably on what appears to be V1 hardware on the receiver with the 6116239 battery box driving motor 6000564. Mode 7's format details that it takes 5 nibbles, the first two taken up by the default header for write1() specifying which mode (7) to write to (0xC7). The nibbles seem to be sent in inverted order, with nibble 1 being last, padded by zeros in the upper bits. You don't have to calculate LRC; BuildHAT or the sensor itself seems to do that for you.

Philo noted that there's a bug in V1, which would explain why trying to follow the documentation produced maddening results, especially since I tried to implement that mode first. I will see if a friend has V2 in their extensive library of parts.

I want to get a few more modes working before I submit a PR.

[mutesplash]

@grega Thoughts on getting this merged?

[grega]

@mutesplash done 👍 thanks for your work on this!

I'll publish a new release shortly... Published 0.7.0