Toastie

That seems to be a good one - although the other adapter you were actually using also sounded not too bad. I'd go for it - should it not work, you can use it for other troubleshooting purposes as it has these LEDs which will help a lot! Good luck! Best Thorsten

Thanks a million!!! I really, really appreciate it! All the best, Thorsten

Yeah. And it will run on Cubic stuff, and, and, and ... I have no clue how you do all that on that scale. Crazy. Nice. Incredible. I love the critter.I may ... steal this design ... for Köf work on my LEGO world. Thank you very much for sharing!!! All the best - and greetings to a world far, far away - of what I could possibly accomplish - ever!!! Thorsten

This of course all begins even earlier as 1986 - I have a DACTA printed catalog from Germany (1986) I shared with @evank - this is about sets culminating around the LEGO interface A, debuting a year later (1987) in Germany. Are you going to cover that as well (or have you already)? All the best - I am very much looking forward to what comes up here!!! Thorsten

Some more findings others may have already figured out! The 4-byte header behaves a bit weird - so far ;) For sure, the two "0x00" are just arbitrary numbers - any will work, tested. This seems to hint to some temporal check, the PIC does? This represents a 2x (1 start + 8 data + 1 parity + 1 stop bit) delay at 2400 Baud, if I am not mistaken, @BrickTronic is much better than I on this. The first byte may be FE or 3E - the same holds true for the fourth byte; they also can be both 3E. There may be other combinations that work. Have not checked any further, but again, this may hint to a temporal measurement, the PIC does. This needs close inspection of the bit train coming in, with some focus on MSB/LSB and slopes. When working with PICs and Baud rate timing, I did the same thing ages ago: Detect any kind of "slope", count-up some variable, check again for H/L after some time. If not matching correct Baud rate data pattern, ignore. I love this kind of "tracing" ... All the best Thorsten

Hi Chris, CM PBrick and RF Tower back on the desk. Win11 64bit running BricxCC Ver. 3.3. build 3.3.8.9 (March 15, 2011), USB2Ser adapter on COM1. Original LEGO seral cable (= 9 wire null modem cable, just checked again, serial always needs close attention ;) #71793, wiring is: 1 nc.; 2-> 3; 3->2; 4->4; 5->5; 6 nc; 7->8; 8->7; 9 nc. This is a plain vanilla bare bone D-sub 9 null modem cable with RX and TX, CTS and RTS crossed, GND and DTR straight through, 1/6/9 not connected. This is not a full hardware handshake mull modem cable, where DTR (4) is wired to DSR (6) and CD (1)! With BricxCC running, I made the following observations: Select "Port = COM1", "Brick Type = Cybermaster", and "OK" leads to blinking on both sides and connection is readily established. All controls work. Same as above, but with a full hardware handshake null modem cable. Works as well. Same as above, but replaced the LEGO (null) modem cable with my own, here just RX/TX (2/3) and GND (5) are connected: Both, tower and PBrick blink upon connect request, but message "Can't find brick" shows up. This leads me to the suggestion that your USB2Ser adapter may be the culprit? As long as you have no connection with BricxCC, I guess programming your own code will be fairly difficult. Best Thorsten Heehee - yes, I guess this is good advice! See above ;) your message came in when I pressed “submit reply” I also just used HTerm to send "FE 00 00 FF 59 A6 05 FA 5E A1" to get a sound - works nicely and yes only once as on the RCX and other PBricks, then you have to "toggle". Messages (msg or msgz) go through without doing that, at least on the RCX.

Hi Chris, what version of windows? On what COM port are you running the USB2Ser adapter? EDIT: I am asking about the COM port used, because I ran into the same issue ("can't find ...") although brick and tower were both there and on and working, when having the adapter on a COM port > COM8. Now this could be my outdated version of BricxCC - I'll have to check. On the other hand, the flashing on the PBrick is indeed encouraging. However, if you can't get it to work with BricxCC then it may become really difficult ... Any terminal program should also so the trick; I am using HTerm for that purpose, but others just laughed at me (boomer here) when mentioning that. Later today, I shall break out my CM PBricks and see whether I can get it to work again. Best Thorsten

Nice solution! Did you also consider wiring the nasty 6-wire PUp cable to the motor, so that it does turn nicely? Or do you want to go with a 9V motor and custom cable? Best Thorsten

Wow, that is really nice information! Thanks a lot! First, in the table in this document: https://fccid.io/NPI71846/Operational-Description/12-23748 section 1.1, the header is described as being FF 00 00 FF, whereas in the text the first header byte is described as FE. Hmmm ... Second, I don't understand how the tower checks for the correct Baud rate other than sensing a certain time delay, if at all? In the table, it says for the first header byte "TX oscillator starts up" and "PIC synchs + receiver enables". I guess, these two always start up when something goes high (= start bit, RS232 side) and then some timing checks for some H or L period? FE is 254 = H startbit + HLLL LLLL + odd parity and L stop bit (on the RS232 level side); there would not be much of a difference timing-wise when receiving "FF" as H startbit + LLLL LLLL + odd parity and L stop bit, would it? Also, two 00 are following, which seem to be just for "stabilizing" everything. With the next FF = fourth header byte, everything should be synched, and "synched bit banging" may start ... On the IR tower, 55 FF 00 was used to “burn in” the IR LEDs after being off for some time; these bytes are not checked in the tower nor on the RCX, as far as I remember, as the 55 maybe crippled ... the FF and 00 gave rather stable signals and then synching was also pretty much safely done. Very interesting! When Chris has made a connection to his CM unit, he can clarify the FE/FF confusion! EDIT: In section 1.5 in the above referenced document, it says D2 (green LED) indicates when data are transmitted. So, I guess, at least the RF circuitry is fired-up in Chris' experiments? All the best Thorsten

Ho Jo, Chris, wow, nice find - I was searching for the schematics of the RF tower forever! I am using 2 types of USB2Serial converters, both work. One is operating the lines with about +/-5V, the other with +/-9V and they both work fine with the RF tower. The RTS/CTS bridge (also present in the RCX IR tower) is briefly tested by LEGO software (for RCX and SCOUT) upon startup; if CTS is not mirroring an RTS pulse generated by the software, it says "No Tower". My own program for the IR tower just use RX/TX/GND, as the IR tower is totally dumb; >whatever< arrives on the tower RX line is cranked out as 38 kHz modulated IR light. The RF tower seems to behaving similarly, but I am not an electronics expert, not even an apprentice - you can read the schematics as if they were clear text Jo, right? EDIT: The tower LED responds to input ("blinking") - doesn't that mean, data come through? Best Thorsten

Hi Chris, this is all a bit weird, but I also struggle a bit with your code, as the frames you are sending appear longer, as I would expect. I'd send rather direct codes (e.g., beep or motor on - the default power setting of the motors is 7 after "booting up" the PBrick) - then you don't need to wait for replies and can check whether the unit receives RF frames and executes them correctly. There were similar issues discussed in one of the threads Carsten pointed you to; direct commands worked, programming not. Do direct commands work in your case? Best Thorsten

Hi Chris, I need to get back to my notes (yes, written notes by me in scratch books made of paper ) - but this all seems to be reasonable/doable. I am a bit busy right now - just go on trying, I'll throw in what I can during the next few days. Right now, I am installing highly reflecting stainless steel sheets (outside) on my attic windows - this has an incredible effect on temperature up there :D Best Thorsten

Did you make a little jig/frame for the motor to get fixed and then used the “hammer” approach? This has been shown/suggested in some other forums as well as YT videos; the central idea is to force the axles down by repeated short, forcefully impact (with e.g. using a hammer), so that this cracks the glue linkage you can't reach when using a knife. If you have, then I would not know what else to do, if you haven't, I am happy to take a photograph of my jig (stolen from the web and simplified), which I successfully used a couple of days ago. No prying necessary ... Best Thorsten

Hi Chris, 1) what are you sending via the serial port at 2) what Baud rate/data bits/parity setting? About the protocol(s): The close to hardware protocol is 2400 baud, 8 data bits, odd parity. Null modem cable is fine. The close to software protocol is "LEGO byte code", as used by LEGO software for the RCX, SCOUT, Spybots, Cybermaster programmable bricks (PBricks), as well as by NQC/BricxCC. There is nice documentation about that - maybe I can dig that up (again ;) @Carsten Svendsen has referenced a thread that maybe helpful, here is another one - go to the RCX etc. section further down: LEGO byte code is essentially an opcode sometimes followed by data bytes. These individual bytes are wrapped with some more byte (called 3-byte preamble, then data byte, complement of data byte etc. etc. As said, this protocol is the same for the referenced PBricks above. Any chance you can run BricxCC/NQC on your Mac? In that case, you would have full access to the Cybermaster (CM) PBrick (direct control and programming). The NQC documentation tells you all about LEGO byte codes and which one are available on the CM. Best regards and good luck! Thorsten

Did TLG ever "use" the ppp as some sort of figure of merit? I don't think so. Isn't it that TLG (naturally and aggressively) just asks for whatever they believe is most profitable for them? We have long departed from a company that “cares”. It feels, just that, it feels as if there was such a notion, in a galaxy, far, far away. I believe the quote should read "LEGO fans should forget ...", or am I mistaken? Best Thorsten

Well ... YES! This is simply beyond belief. Yeah ... yeah ... Man. You simply rock. Looking very, very much forward to any kind of any further updates! All the best Thorsten

There is hope - we are two. I never thought that TLG would finally lose me entirely: No - zero - LEGO sets since three years (and counting) anymore, after believing in the Gods of ABS Bricks since 1965 (OK, with dark age). And it doesn't even hurt with all these alternatives around ... Best wishes Thorsten

That is TOTALLY illegal Actually, it is so illegal that I simply love it! Have fun and all the best Thorsten

@Sven J If this news was not worth bumping this thread, nothing is worth bumping any thread!!! Very nice find and thank you very much! All the best Thorsten

Isn't happening ... soon - but is it really dead? Sorry to hear about your setback; you were so close. Take any time and then maybe - in the future - you decide to revisit this nice project? I sure hope so! All the best Thorsten

*sigh* - there simply are no stupid questions! There may be stupid replies or reactions - hope the reply below makes any sense. I recently (= two days ago) opened up one of my two (black) 12V train motors. This was one of the variety with the holes for receiving the center wheels. The motor came a couple of years ago from France along with the 7740 locomotive and carriages. Very nicely seasoned light gray slopes - I love it. I just was curious to check on its internal condition, as it was just doing fine. My 7740 is retrofitted with a PF receiver and 10 NiMH AA rechargeables, as I have a mixed 4.5V, 12V (blue and gray), RC=PF, and of course ample of powered 9V track. As far as I can tell, the metal inside is die-cast aluminum for the two large brackets, copper/brass type alloys for the electrical contacts and worm gear, as well as the usual non-lead metals for the motor and rails contacts. You should be fine. All the best and good luck, Thorsten

Devoted to vehicles, of which are mostly cars, isn't it? These are certainly technical devices, though ... But doesn't that reflect to some extent the distributions of thread themes in this forum, taking into account that it is the "LEGO Technic, Mindstorms, Model Team and Scale Modeling" forum? Did not do any analysis yet, but it would be fun to see some sot of statistics. Best Thorsten

I love this. For some reason, I also love Maxwell's equations, although I am a chemist Cool thread! All the best Thorsten

Yeah. And that's for end consumers ... well, “good” for us nerds. Best Thorsten

Hmmm - the Mould King crane comes with a dedicated remote, doesn't it? No idea what's in there, but an ESP32 would be kind of an overkill, with one of those as brain you can control an Apollo command module and lunar lander, fly to the moon, and safely return to Earth. On the other hand, an ESP32 WROOM board sells for $2.49 on Ali - and they make profit ... Best, Thorsten