Search the Community
Showing results for tags 'pbricks'.
Found 1 result
Toastie posted a topic in LEGO Train TechDear All, since 2001 I am working on this: LEGO train layout control from one single computer (trains, switch points, light, bridges, …) using as much as possible original LEGO hard- and software. Still WIP but getting close. Most of the LEGO stuff used here is – since long – not officially available anymore. But LEGO is LEGO and lasts forever … and now I am close to getting it all to work. This project has survived Win98, QBASIC, WinXP, VB6 (well not true, still using it, see below …). And as sPy pointed out correctly in his reply on my PF RF hack, all this is building on stone-old electronics hardware. But: All this stuff is still available today. BrickLink is very close to LEGO heaven, I believe. And because nobody really cares anymore about RCX’ or MicroScouts – they have become dead cheap. I recently ordered RCX’ 1.0 with power jack for less than $20 each. These are the best PBricks ever made by TLC … imho, of course. There are many powerful and elegant solutions for controlling PF operated trains as well as track/track side-related functions such as remote switch operation, lighting, train detection, and much more. Most of these are based on home-built (as for example the myriads of wonderful Arduino-based solutions) or third party commercial devices, e.g. SBrick, 4DBrix/nControl, PFx Brick, and increasingly more. And this is wonderful. This post is just another one in this line. The difference is that I tried to use exclusively original LEGO stuff. Based on IR communication, it works perfectly well, but only within a range of about 1 m, which is not that good for train/track control ... So there was “only” one but significant modification required: Changing from IR to RF communication. This post illustrated how to do that. And if you don’t want to break into your PF receiver at all but just an add-on, this works also perfectly well, but is somewhat more elaborate. The ultimate goal of this project is to control diverse LEGO devices (PF, RC-train, RCX, NXT, Scout, MicroScout, Spybotics) from one device. In my case from a program running on my computer. However this could also be any device that can generate LEGO Mindstorms IR messages (which were introduced with the RCX, as far as I know), for example: A computer with one of the LEGO IR Towers attached, running the Bricx Command Center (BricxCC) software, A computer with one of the LEGO IR Towers attached, running any other program, which has access to the LEGO IR Towers; this includes the various programming environments and languages such as NQC, RobotC, or any custom program that has access to either a serial port for the serial tower or the LEGO drivers for the USB tower. (Note that on 64 bit platforms, the USB tower does not work anymore, since TLC never updated the required driver for the tower. In that case the stone old serial tower attached to a RS232-to-USB converter has to be used and accessed via a free COM port, preferentially in the COM1 … COM8 range. Works like a charm. Some people have trouble to get BricxCC or the original RXC 2.0 Mindstorms software communicate with the RCX only caused by the missing driver. Some revert back to 32-bit or even Win98 … not necessary!) Any of the RCX, Scout, or Spybotics, NXT(+IR Link Sensor) PBricks, Any learning remote, that was trained with any of the above means of generating LEGO Mindstorms messages; I am usually using BricxCC for programming. For testing purposes on my train layout, the programmed learning remote is very handsome: On my home-office style train layout (yes, I do work here as well), there are currently running/installed 8 PF trains 1 RC train 2 RCX controlled trains In addition to 2 RCX switch controllers (one serving 7 switch points using PF M motors, the other 12) 2 Scout switch controllers (one serving 3 switch points using 3 MicroScouts, the other 7) 1 Scout train bridge controller, see below 2 RCX light controllers with 3 outputs each, see below Each of the PBricks (RCX, Scout, NXT) have their own "personal" ID they recognize and respond to; the PF and RC trains are handled by the NXT PBrick (equipped with the IR Link sensor from HiTechnic) serving as central “PF/RC-train communications hub”. The NXT recognizes a total of 3 (RC) + 8 (PF) = 11 ID’s and maps these to the 3 RC and 8 PF channels: The NXT is operated with standard LEGO firmware (V1.31) and the LEGO NXT-G software environment is used for programming. Unfortunately the IR Link sensor has a very limited communication range, far less than any other IR light emitting LEGO device. This was one more reason for me – other than wanting no line of sight operation – to switch to RF. I have thus placed one of my IRRF transceivers (big words for not much, this is just what I am calling them) right in front of the IR Link sensor, which sends out every 38kHz modulated IR light it detects into RF space and listens for any 433 MHz signals in half duplex mode on a first come first serve basis: If IR light is detected then RF is sent out – if RF is detected IR is sent out. Both channels are dynamically mutually “blocked”; when an IR message is sent out it will continue to do so until finished, the same holds true for RF. Here is an overall schematic of the RF connectivity and direction of signals. In case of PBricks (NXT, RCX, Scout, Spybot) bi-directional half-duplex communication is possible (but not required), thus the IRRF transceivers come in handy. In other words: The addressed PBrick may reply with “OK”, “Did not recognize the payload”, or “I am busy”. In case of NXT to PF or RC-train, just uni-directional communication without any feedback is possible. The NXT-G program running on the NXT PBrick equipped with the HiTechnic IR Link sensor is is available on my university account. This navigates you to a folder , which contains the entire program. It is divided into the main program “RCPF_Control_14” and several “MyBlocks”. This structure is entirely owing to the limitations of the LEGO NXT-G software GUI. One could readily program (“tie together” is better phrasing) this is one block – but the GUI freaks out when exceeding a couple of nested loops. Putting these into individual MyBlocks circumvents this problem. The compiler readily generates the correct output code – “regardless” (I found no limits) of number of MyBlocks nested or called. This is the workflow on the entire layout: Essentially, one supplies an address byte plus a payload byte consecutively as two LEGO messages within let’s say 2 seconds; that is easily manageable with the programmed remote. When programs send out the two messages, the time between ID and payload byte can be much shorter, in the 100 ms range. The two bytes are each encoded according to the “LEGO Mindstorms IR message” protocol. Prepare 2 messages: Address as LEGO IR message + payload as LEGO IR message: Send these messages consecutively out into RF space: Any “intelligent” device equipped with an RF receiver will recognize its own address, listen for the payload and act appropriately. Example: RCX1 has address 192. We issue the sequence “message 192” + “message 8”. RCX1 will now do what “8” means within its own program running. Another example: NXT1 recognizes all addresses between 194 and 205. Let us say, 194 to 202 are mapped to PF trains 1 to 8, and 203 to 205 to RC train devices 1 to 3. That would cover the regular PF and RC address space. NXT1 senses address 194 and payload “-5”. It then uses the IR Link to send out the PF single pin command “PF channel 1A motor power -5” into RF space. Which lets the corresponding PF train equipped with an RF receiver “go reverse at power level 5”. And “205 + 4” will then get RC train #3 on forward level 4. The device addressed acknowledges the reception of the messages by sending out “OK” or any kind of error message (e.g., “I am busy”) to the caller. When using one-way communication, e.g. the handheld remote control, that acknowledgement goes of course unheard – when running a program with IR tower that could be recognized by the program and acted on (simply resending the message or wait and then resend and so on). Using the PF single pin command lets the PF receiver “jump” to the respective power level; when it was at 0 = stop, sending “7” would bang the motors full forward. This is handled by the NXT program as well: It slowly increases the power level with programmable delays between the steps. This results in a more “realistic” train behavior. The LEGO RC train protocol just allows the commands “increase” (+1), “decrease” (-1), “stop” (0) on a scale of -7 to +7. The PF protocol allows the increase (+1)/decrease (-1) scheme as well, however, a control program may lose “track” when such a command issued was not received properly, since there is no feedback. When all three available RF frequencies 315, 418, and 433 MHz are used, 8 x 3 = 24 PF devices can be controlled with a total of 12 PF receivers. That is not including the change of the “address space”-bit in the PF protocol, which would double this number to 48. Any other track or trackside devices to be remotely controlled with PBricks works of course as well; here is an RCX turning on/off the light in the light house or the diffuse and changing light in a scary tunnel not shown (yet). Or a Scout letting a bridge go up or down and reporting the bridge status to the host control program. Switch drives hooked up to an RCX or Scout based brick-built “switch drive controller” may also recognize the address + payload sequence and act appropriately: “RCX2, put switch #5 in branch position”. See list of my controlled stuff above. In summary: You can control PF, RC, RCX trains and RCX, Scout, Spybot operated switches or other devices with an almost pure LEGO solution. Up next: Build switch drives and controllers solely from LEGO bricks + Scout, RCX or Spybot PBricks and then program them using LEGO software. (Sorry for the long post) Best regards, Thorsten