| |
The LEGO company just released a document detailing the complete protocol used
by Power Functions RC receiver.
I host the document on my Power Functions
presentation page.
As you can see this opens up a new world of possibilities...
Philo
Here below is the announcement:
Last year we introduced a range of products using our new electronic building
system: LEGO Power Functions. This new electronic building system will open up a
lot of possibilities now and in the future.
One of the new things we offer now is modular remote control. In the process of
designing the Power Functions RC system we did a mapping of different RC
functionalities. This mapping formed the basis of the Power Functions RC
protocol and most of this is built into the Power Functions RC Receiver.
The RC Handset launched now provides direct ‘bang-bang’ control, but the RC
Receiver supports much more functionality like PWM speed control and single pin
operation.
Now that the Power Functions elements are available at the LEGO Shop online we
have decided to release the Power Functions RC protocol as open source.
Please feel free to use any information from the protocol document for personal,
non-commercial use only, provided you keep intact copyright, trademarks and
other proprietary rights of the LEGO Company - have fun.
Gaute Munch
Technology Product Manager
LEGO Company
|
|
| |
In lugnet.general, Philippe Hurbain wrote:
| |
The LEGO company just released a document detailing the complete protocol
used by Power Functions RC receiver.
I host the document on my Power Functions
presentation page.
As you can see this opens up a new world of possibilities...
Philo
|
This is great news indeed, thank you for posting.
Has anyone tried the rc train remote on a power function reciver to see if it
uses the single output pwm control signals? If not, hopefully the new RC train
system will be compatible.
It also looks like with the right signals, and a bit of tweeking of the wiring,
you could control a train motor speed and direction on one port, as well as two
0v/9v outputs on another. I didn’t see a way in the document to turn bothe
control lines to 9v, but they can bothe or individually be set to 0v!
Does anyone know how much current the control lines can supply/sink?
Mat
|
|
| |
> I didn't see a way in the document to
> turn bothe control lines to 9v, but they can bothe or individually be set to
> 0v!
Either single pin modes allow to set each output to 1 (9V) or 0 (0V).
>
> Does anyone know how much current the control lines can supply/sink?
See the drive datasheet: http://www.philohome.com/nxtpwr/lb1836M.pdf
Current can reach 1A peak, continuous value is lower (500-600mA) especially if
both outputs are heavily loaded at the same time.
Philo
|
|
| |
In lugnet.technic, Mathew Clayson wrote:
> > As you can see this opens up a new world of possibilities...
>
> Has anyone tried the rc train remote on a power function
> reciver to see if it uses the single output pwm control
> signals? If not, hopefully the new RC train system will be
> compatible.
I'd be very interested in that experiment (using a Hobby train RC on the PW
Receiver) as well, but this does answer a number of questions for trains. For
instance, tunnels and large layout out of line-of-sight on the RC should now be
possible. You could run a large number of trains (more than four, or perhaps
eight) as long as you were OK with only commanding them in a small "control
zone". and the ability to set the pin power individually makes accessories
(lights, horns) easy to control... and with two independent motors, something
like an engine with a coupler/uncoupler or a working crane becomes a
possibility, all controlled by a single RC unit.
For robotics, this is even more interesting. No more busy Loops to keep
commanding the PF receiver to prevent it from timing out! I'm also wondering if
with a custom cable you could run three motors (set pin one to 0V (ground), and
use that as a common ground for three small motors, with hot leads on pins 2, 3,
& 4). You could certainly use it to control some LEDs. But it's the existence of
the PWM and no timeout abilities that have me most intrigued. Like Chris
mentioned in a different (with a 1.0 RCX controling these new modes), watching
the Bulldozer or other large Technic creations crawling around under PWM would
be a vast improvement.
Now, now to get all this in an NXT-G blocks :).
--
Brian Davis
|
|
| |
Brian Davis wrote:
> In lugnet.technic, Mathew Clayson wrote:
>
> > > As you can see this opens up a new world of possibilities...
> > Has anyone tried the rc train remote on a power function
> > reciver to see if it uses the single output pwm control
> > signals? If not, hopefully the new RC train system will be
> > compatible.
>
> I'd be very interested in that experiment (using a Hobby train RC on the PW
> Receiver)
I did this experiment a while ago, I just presumed everyone else has as
well.
The Short answer is NO. I could not get the new IR train to control the
PF receivers either at full on, or with PWM.
My IR train, and PF gear are 100% incompatible.
I've posted a YouTube Video showing both at the same time, not being
affected by either remote, as well, I ran the 2 transmitters at the same
time, and the respective device worked flawlessly.
http://www.youtube.com/watch?v=pgnndCPK1Z8
Chris
|
|
| |
In lugnet.general, Philippe Hurbain wrote:
| |
The LEGO company just released a document detailing the complete protocol
used by Power Functions RC receiver.
I host the document on my Power Functions
presentation page.
As you can see this opens up a new world of possibilities...
Philo
|
Absolutely excellent news! Downloaded and printing...
|
|
| |
In lugnet.general, Philippe Hurbain wrote:
| |
The LEGO company just released a document detailing the complete protocol
used by Power Functions RC receiver.
I host the document on my Power Functions
presentation page.
|
On page 13 it shows the transmit time slots. Giving each channel a unique
stagger for repeats certainly helps avoid collisions, but I’m confused as to why
they have a transmit hold off. If person A is on channel 1, and person B is on
channel 2, they aren’t going to hit the buttons simultaneously anyway, so I
don’t see how having a channel specific hold-off does anything useful at all for
collision avoidance.
|
|
| |
In lugnet.general, Philippe Hurbain wrote:
| |
The LEGO company just released a document detailing the complete protocol
used by Power Functions RC receiver.
I host the document on my Power Functions
presentation page.
As you can see this opens up a new world of possibilities...
Philo
|
I just tried the new commands with a home-made NXT-controlled IR remote. I was
able to get them to work without a problem. I verified the single-output PWM
mode, which starts a motor at a given power level, in which it stays
indefinitely (until you send a break or float command, or turn off the battery
power to the receiver.
Sivan
|
|
| |
In lugnet.general, Sivan Toledo wrote:
| |
In lugnet.general, Philippe Hurbain wrote:
| |
The LEGO company just released a document detailing the complete protocol
used by Power Functions RC receiver.
I host the document on my Power Functions
presentation page.
As you can see this opens up a new world of possibilities...
Philo
|
I just tried the new commands with a home-made NXT-controlled IR remote. I
was able to get them to work without a problem. I verified the single-output
PWM mode, which starts a motor at a given power level, in which it stays
indefinitely (until you send a break or float command, or turn off the
battery power to the receiver.
Sivan
|
Very good. Have you done experiments to map the power level settings to RPM? I
am guessing that each of the 7 steps sets literally a power level (PWM width)
and not a speed. Have you done experiments under load to see what happens to the
speed at each power level as you increase load? Keeping the speed constant
would require back-EMF measurement so I doubt that it is included, but, hey,
maybe there is a nice surprise in there.
|
|
| |
In lugnet.technic, Chris Magno wrote:
> Brian Davis wrote:
> > I'd be very interested in that experiment (using a Hobby train RC on the PW
> > Receiver)
> The Short answer is NO. I could not get the new IR train to control the
> PF receivers either at full on, or with PWM.
>
> My IR train, and PF gear are 100% incompatible.
It looks like the PF IR receiver will be very useful for train control and other
continuous duty applications. But the only remote available is for intermittent
operation. So the only LEGO option to running in PWM/continuous duty is to use
a RCX or NXT brick, with a RCX remote or blue-tooth remote to control it.
And I'm assuming that a new PF IR train remote will only have a single continues
motor control, with perhaps a light, and "other" intermittent output.
How difficult would it be to implement the PF protocols in a handheld IR remote
using programmable chip like a PIC or PICAXE? A replacement pc board for the
current PF or train remote, or the Krana remote would be nice.
Would a programmable(not universal) "TV" remote be able to learn codes from a
RCX?
Mat Clayson
|
|
| |
In lugnet.general, Philippe Hurbain wrote:
>
> The LEGO company just released a document detailing the complete protocol
> used by Power Functions RC receiver.
In collaboration with Jason Railton I have modified/extended the NBC and NXC API
functions for the HiTechnic iRLink device in support of the newly documented
Power Function modes as well as the R/C Train IR protocol. I uploaded a new
test_release zip to the BricxCC page with NBC and BricxCC executable updates
with these new API functions included in the compiler and BricxCC syntax
highlighter/code completion support for NBC and NXC programs. These updates
will be in the next beta release of NBC/NXC and the next official BricxCC
release.
http://bricxcc.sourceforge.net/test_release.zip
The old HTPowerFunctionCommand API function is gone. It is replaced by the new
HTPFComboDirect function.
All the new NXC functions are listed below. For NBC the status is returned via
an additional parameter but otherwise the function signatures are identical.
HTPFComboDirect(port, channel, outa, outb)
HTPFSinglePin(port, channel, out, pin, func, bContinuous)
HTPFSingleOutputCST(port, channel, out, func)
HTPFSingleOutputPWM(port, channel, out, func)
HTPFComboPWM(port, channel, outa, outb)
HTPFTrain(port, channel, func)
HTIRTrain(port, channel, func)
HTPFRawOutput(port, nibble0, nibble1, nibble2)
HTPFRepeat(port, count, delay)
The HTPFRepeat function allows you to send the previous command again in a loop
count number of times with a wait of delay milliseconds between each
transmission.
The following constants are HTPFComboDirect output commands.
#define HTPF_CMD_STOP 0
#define HTPF_CMD_FWD 1
#define HTPF_CMD_REV 2
#define HTPF_CMD_BRAKE 3
For all Power Function API calls you can use the channel constants shown here:
#define HTPF_CHANNEL_1 0
#define HTPF_CHANNEL_2 1
#define HTPF_CHANNEL_3 2
#define HTPF_CHANNEL_4 3
These power function mode constants are used internally by the API functions
listed above.
#define PF_MODE_TRAIN 0
#define PF_MODE_COMBO_DIRECT 1
#define PF_MODE_SINGLE_PIN_CONT 2
#define PF_MODE_SINGLE_PIN_TIME 3
#define PF_MODE_COMBO_PWM 4
#define PF_MODE_SINGLE_OUTPUT_PWM 4
#define PF_MODE_SINGLE_OUTPUT_CST 6
When calling either HTIRTrain (for use with R/C Train receivers) or HTPFTrain
(for use with the Power Function receiver) you should use one of these four
train functions. The "unused" mode 0 in the Power Function receiver operates
identically to the standard R/C Train IR receiver with respect to controlling
the attached motor/light.
#define TRAIN_FUNC_STOP 0
#define TRAIN_FUNC_INCR_SPEED 1
#define TRAIN_FUNC_DECR_SPEED 2
#define TRAIN_FUNC_TOGGLE_LIGHT 4
The HTIRTrain function uses a different IR protocol than the HTPFTrain function
and the receiver interprets channel #3 as ALL so you should use these channel
constants instead of the Power Function-specific channel constants when calling
HTIRTrain.
#define TRAIN_CHANNEL_1 0
#define TRAIN_CHANNEL_2 1
#define TRAIN_CHANNEL_3 2
#define TRAIN_CHANNEL_ALL 3
For SingleOutput and SinglePin power function modes you should use these output
constants.
#define PF_OUT_A 0
#define PF_OUT_B 1
Use the pin constants with the SinglePin function listed above.
#define PF_PIN_C1 0
#define PF_PIN_C2 1
These constants are SinglePin operation which can be used with the HTPFSinglePin
function listed above.
#define PF_FUNC_NOCHANGE 0
#define PF_FUNC_CLEAR 1
#define PF_FUNC_SET 2
#define PF_FUNC_TOGGLE 3
The SingleOutputCST API function uses these func constants:
#define PF_CST_CLEAR1_CLEAR2 0
#define PF_CST_SET1_CLEAR2 1
#define PF_CST_CLEAR1_SET2 2
#define PF_CST_SET1_SET2 3
#define PF_CST_INCREMENT_PWM 4
#define PF_CST_DECREMENT_PWM 5
#define PF_CST_FULL_FWD 6
#define PF_CST_FULL_REV 7
#define PF_CST_TOGGLE_DIR 8
The SingleOutputPWM and ComboPWM API functions both use these constants for
specifying the speed and direction of the motor(s).
#define PF_PWM_FLOAT 0
#define PF_PWM_FWD1 1
#define PF_PWM_FWD2 2
#define PF_PWM_FWD3 3
#define PF_PWM_FWD4 4
#define PF_PWM_FWD5 5
#define PF_PWM_FWD6 6
#define PF_PWM_FWD7 7
#define PF_PWM_BRAKE 8
#define PF_PWM_REV7 9
#define PF_PWM_REV6 10
#define PF_PWM_REV5 11
#define PF_PWM_REV4 12
#define PF_PWM_REV3 13
#define PF_PWM_REV2 14
#define PF_PWM_REV1 15
|
|
| |
In lugnet.technic, Brian Davis wrote:
> (...) For
> instance, tunnels and large layout out of line-of-sight on the RC should now be
> possible. You could run a large number of trains (more than four, or perhaps
> eight) as long as you were OK with only commanding them in a small "control
> zone".
Here's my fantasy: implementing prototypical ATC (Automatic Train Control)
signalling with sensors (e.g. counting coupler magnets, as the best functional
equivalent to axle counters) at block boundaries to detect block occupancy, and
IR beacons at signal locations to stop trains if/when necessary. Control would
happen with NXTs. For simple operations (automatic stop and start at signals)
one could devise simple microcontroller-based beacons that broadcast a "go"
signal (a given speed step and direction) when given an input and a "stop"
(speed 0) signal otherwise.
I'll try this out some day if I manage to gather up enough LEGO. For the time
being, I'll keep dreaming... (My trains are the eighties grey-rail 12 V type...)
Followups set to .trains.
--
Juhana Siren
|
|
| |
In lugnet.general, John Hansen wrote:
> In lugnet.general, Philippe Hurbain wrote:
> >
> > The LEGO company just released a document detailing the complete protocol
> > used by Power Functions RC receiver.
>
> In collaboration with Jason Railton I have modified/extended the NBC and NXC API
> functions for the HiTechnic iRLink device in support of the newly documented
> Power Function modes as well as the R/C Train IR protocol. I uploaded a new
> test_release zip to the BricxCC page with NBC and BricxCC executable updates
> with these new API functions included in the compiler and BricxCC syntax
> highlighter/code completion support for NBC and NXC programs. These updates
> will be in the next beta release of NBC/NXC and the next official BricxCC
> release.
<snip>
Nicely done John!
Is there a tentative timeframe when NQC for the RCX will be updated to support
IR to the LEGO powerfunctions?
Dave K
|
|
| |
In lugnet.general, David Koudys wrote:
> In lugnet.general, John Hansen wrote:
> > In lugnet.general, Philippe Hurbain wrote:
> > >
> > > The LEGO company just released a document detailing the complete protocol
> > > used by Power Functions RC receiver.
> >
> > In collaboration with Jason Railton I have modified/extended the NBC and NXC API
> > functions for the HiTechnic iRLink device in support of the newly documented
> > Power Function modes as well as the R/C Train IR protocol. I uploaded a new
> > test_release zip to the BricxCC page with NBC and BricxCC executable updates
> > with these new API functions included in the compiler and BricxCC syntax
> > highlighter/code completion support for NBC and NXC programs. These updates
> > will be in the next beta release of NBC/NXC and the next official BricxCC
> > release.
>
>
> <snip>
>
> Nicely done John!
>
> Is there a tentative timeframe when NQC for the RCX will be updated to support
> IR to the LEGO powerfunctions?
>
> Dave K
I doubt that's possible - a bytecode program just can't run fast enough to do
the timing for the IR commands, on either brick. The NXT can only manage it
because it sends them over a slow comms link to a HiTechnic IRLink sensor, then
that handles the actual transmission. The only way the RCX could do it with
it's built-in IR LED is to code the functions into a replacement firmware, as
with Bob Kojima's BrickOS example:
http://news.lugnet.com/general/?n=54443
Jason R
|
|
| |
In lugnet.general, Jason J Railton wrote:
<snip>
> I doubt that's possible - a bytecode program just can't run fast enough to do
> the timing for the IR commands, on either brick. The NXT can only manage it
> because it sends them over a slow comms link to a HiTechnic IRLink sensor, then
> that handles the actual transmission. The only way the RCX could do it with
> it's built-in IR LED is to code the functions into a replacement firmware, as
> with Bob Kojima's BrickOS example:
>
> http://news.lugnet.com/general/?n=54443
>
> Jason R
I'm runnign Dick Swan's alternate firmware that he sent me a while back.
Dave K
|
|
| |
In lugnet.general, David Koudys wrote:
> I'm runnign Dick Swan's alternate firmware that he sent me a while back.
>
> Dave K
Dick Swan's replacement RCX firmware also does not support directly manipulating
the IR led and it doesn't support microsecond timing control. Both of these
features would be required in order to send the IR messages to a Power Function
or R/C train receiver. The only way RCX firmwares that are VM-based could
support emitting PF IR streams is if some setting in the UART area of the
firmware could be tweaked to emit bytes in a PF-compatible mode. To the best of
my knowledge this is not possible in either the standard RCX firmware or in
Dick's RCX-compatible firmware. John Barnes or Michael Barrett Anderson
(amongst others) would probably know for certain.
John Hansen
|
|
| |
In lugnet.general, John Hansen wrote:
> In lugnet.general, David Koudys wrote:
> > I'm runnign Dick Swan's alternate firmware that he sent me a while back.
> >
> > Dave K
>
> Dick Swan's replacement RCX firmware also does not support directly manipulating
> the IR led and it doesn't support microsecond timing control. Both of these
> features would be required in order to send the IR messages to a Power Function
rats!
> or R/C train receiver. The only way RCX firmwares that are VM-based could
> support emitting PF IR streams is if some setting in the UART area of the
> firmware could be tweaked to emit bytes in a PF-compatible mode. To the best of
> my knowledge this is not possible in either the standard RCX firmware or in
> Dick's RCX-compatible firmware. John Barnes or Michael Barrett Anderson
> (amongst others) would probably know for certain.
>
> John Hansen
Thanks for the heads up, John
Looks like I really have to start brushing up on my NXT 'bot building now.
Dave K
|
|
| |
In lugnet.general, John Hansen wrote:
> In lugnet.general, Philippe Hurbain wrote:
> >
> > The LEGO company just released a document detailing the complete protocol
> > used by Power Functions RC receiver.
>
> In collaboration with Jason Railton I have modified/extended the NBC and NXC API
> functions for the HiTechnic iRLink device in support of the newly documented
> Power Function modes as well as the R/C Train IR protocol. I uploaded a new
> test_release zip to the BricxCC page with NBC and BricxCC executable updates
> with these new API functions included in the compiler and BricxCC syntax
> highlighter/code completion support for NBC and NXC programs. These updates
> will be in the next beta release of NBC/NXC and the next official BricxCC
> release.
>
> http://bricxcc.sourceforge.net/test_release.zip
Many thanks John and Jason for your work on this. I am a comparative newbie to
NXC programming but I have my NXT working like a PF IR remote handset now that I
set up the sensor correctly!
NXC has given me the programming environment to replace the VB that I used with
my RCX (an NXT has no ActiveX control file so it could not use VB). The 'C' is
returning to me from my university days!
With your HTPF commands and a few modded leads (the bottom right one here:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=2963520 ) to cascade a few IR
receivers, an NXT could now control up to 128 motors or 256 LEDs (like this:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=2957469 ) from one sensor port!
Could the NXC/NBC commands be extended to allow the IR Link sensor to receive PF
IR commands from a PF handset and convert them to PF channel, Motor A and Motor
B output variables (so that an NXT could act like a PF IR receiver)?
That would allow an NXT robot to interact with other PF robots in pack hunting
and other automatic machine activities, where motors move PF IR handset levers
like this: http://www.brickshelf.com/cgi-bin/gallery.cgi?i=2391291
I suppose a receive function would put the data into one variable, so perhaps a
long integer of the 16-bit IR message would do, allowing the programmer to pick
bits out by ANDing.
Mark
|
|
| |
In lugnet.general, John Hansen wrote:
> In lugnet.general, Philippe Hurbain wrote:
> >
> > The LEGO company just released a document detailing the complete protocol
> > used by Power Functions RC receiver.
>
> In collaboration with Jason Railton I have modified/extended the NBC and NXC API
> functions for the HiTechnic iRLink device in support of the newly documented
> Power Function modes as well as the R/C Train IR protocol. I uploaded a new
> test_release zip to the BricxCC page with NBC and BricxCC executable updates
> with these new API functions included in the compiler and BricxCC syntax
> highlighter/code completion support for NBC and NXC programs. These updates
> will be in the next beta release of NBC/NXC and the next official BricxCC
> release.
>
> http://bricxcc.sourceforge.net/test_release.zip
Many thanks John and Jason for your work on this. I have been using the NXC
functions to control PF IR receivers from my NXT.
TLG has just released the following information:
"We have been testing the LPF RC Receiver today and discovered an error in the
RC Receiver firmware or chip masking. A register is not adressable. It affects
all the set, clear and toggle commands for single pins....and only these
commands.
We will do an update of the chip mask at some point (not too far into the
future). At that point it will be corrected."
This means that these commands will not yet work as advertised:
> HTPFSinglePin(port, channel, out, pin, func, bContinuous)
> HTPFSingleOutputCST(port, channel, out, func)
> HTPFSingleOutputPWM(port, channel, out, func)
The HTPFSingleOutputCST commands affected are only the Set/Clear C1/C2 ones. My
own experiments confirm that the others (inc/dec PWM, full power and toggle
direction) work well.
Mark
|
|
|
