Toastie

Thank you, but it was >your< brilliant idea! I just assembled a couple of old/used pieces of electronics and cables lying around. Your version is 100% pure LEGO! Best Thorsten

@amine I just found an 8-pin ILD74 (double) opto coupler flying around here ... and quickly made this: It is rather small and works quite nicely (no power supply required). The part on the right of the diagram (+/- and 10kOhm) is just illustrating the pull-up resistor inside Interface B. No harm is caused when the 9V terminal is attached the wrong way around on an Interface B input; it just doesn't work ;) On my Interface B, the left contacts of the 9V terminals are + and the right are GND. The short 9V wire goes to any Control Center output (polarity does not matter), the long goes to an input of Interface B (yellow or blue), GND goes to both emitters of the two internal transistors of the ILD74 . This is absolutely straight forward, and there is nothing special - it is simply your idea, @amine, made with rather old resurrected electronics ;) The two internal LEDs of the ILD74 only light up, when the polarity is right - and they "protect themselves", as one is always conductive, so that the voltage drop across the non-conductive LED is such that it can easily deal with that. The resistor on the right in the photograph (and center in the diagram) determines the reading for forward (or reverse, depending on how the 9V LEGO wire is attached to the CCII output terminal). The other coupler output goes directly to the (+) input terminal of Interface B. As only either one can be on, or both are off, the reading for the Interface B input is unequivocally determined. Here is what I recorded in raw mode of any input: off: 1023 - forward: 10 - reverse: 108. As said, you can use other resistor values of course. There is one advantage: There is no latency. The moment you press a button on the CCII, the reading changes on Interface B. The ILD74 costs less than 1€, there are also quad couplers < €2. Virtually all the low power electronic opto couplers will work though. Three ILD74, six 1 kOhm resistors, and three 9V cables cut in half or made from scratch and you are good to go. You can simultaneously press buttons on CCII and the timing is pretty accurate. Just an idea! All the best Thorsten

Ha! I did not recall that - but you are right! Best Thorsten

So that requires either one color sensor for the three output channels + 3 colored light sources (could be 9V lamps w/ colored transparent bricks) + detection of the flashing for reverse or three light sensors + 3 standard 9V lamps + detection of the flashing for reverse. Is that what you are aiming for? Or do I have that wrong? How do you get the Control Center's outputs to flashing? All the best Thorsten

Yeah - and that is what Interface B is as well, however, >providing< the 8 input data constantly, where outputs are again H bridges. Now just out of curiosity: If you had soldered the header to the other side of the PCB, would have done the trick? Provided it is even "solderable" on that surface? Or are there further issues, when (theoretically) doing that? Best Thorsten

That's a brilliant idea! And you are right: Even the 9V train voltage controller will work this way. The good'ol opto-coupler principle. I shall try that with a couple of such couplers lying around (somewhere ^^)! That would be the el cheapo version - 4 opto couplers in one 16 pin DIL chip, maybe an LTV846 for 50 cent - or - the luxury version for €2.15 (https://www.roboter-bausatz.de/p/pc817-optokoppler-isolationsmodul-4-kanal-3-6-30-v-treiber-spannungswandler). I would then connect the LEDs in the couplers "antiparallel" (so that either one lights up when pressing fwd or rev), connect both the outputs in parallel to one Interface B input but with two different resistors (lets say one 330 Ohm in series and the other 2.2kOhm). What do you think? I do not really understand what you mean, but I am sure it works that way! Thanks a lot! Thorsten

Well, that issue was solved quickly! I love this place And welcome to EB, Scott! All the best Thorsten

Could it be that there were different cables for the Apples and for the IBMs? Or do these cables have the same product ID? Best Thorsten

Ribbon cable original LEGO (I know, it sounds like: Did you plug it in ... sorry for that)? I once managed to screw up when crimping the connector on ... Best Thorsten

I see - yes, TC Logo should do that. Hmm - sounds like a hardware issue then ... the different VIAs you puchased are all behaving in the same way, right? Best Thorsten

Merde. OK, just quickly: You do "initialize" the card (which is just poking the direction register of the 6522 VIA), correct? Otherwise, it does not really know what to do other than factory settings upon power up. Best Thorsten

@Bliss and @maehw the moment I have time to breathe, I am very happy to jump on all this. My problem is sort of looking (not yet trying) a moving target type thing. Just to be sure: Your web versions do naturally change over development time (which can surely be eternal ;) but I just use a browser (Chrome, correct?) and access the corresponding websites, and I am good to go. Is that true? Do any of you envision a downloadable "program" to use it web independently? Sorry for being such an ignorant. All the best and thank you for all your efforts!!! Thorsten

More than >5< years - I have been blind for more than 5 years ... and now I have seen the light!!! Wow - I am blown away. This is such a >perfect< mash-up of all the things, that the world saw, wanted to see, is and was dreaming of ... Atomic - much more atomic on a train is impossible!!! Steam - I love Thermodynamics, I simply love it. Particularly when the 1st and 2nd law are hit hard by reality; friction, chemistry with atoms not behaving, dirt ... but this Loco-Motive (as in Klaus Doldinger's Ataraxia album) looks so unbelievably perfect. It beats every "law" simply by its beauty and functionality. Man, what I miss out on. The "center" wheel/axis (whatever that is called, I am not good at counting propelled/non propelled axes, not do I know much of the vocabulary used when it comes to trains ...) - is that the drive unit, that uses the nuclear power heated steam? It also reminds me of the Swiss Crocodile, which is an electric locomotive, sure, but has a "remotely similar" propelling unit on each side of the cabin. Inspected that thing for a long time (family was not amused) in Sinsheim/Germany, where they have an original Swiss Crocodile on display). Another thing that comes to mind is Steam Punk. In all its glory; not the dark, original "theme" - rather the shiny, positive, forward-looking variety. But in this case no golden elements; that would literally destroy the fantastic look and feel of this train. Green, yellow and red - some gray, and black of course. These are my colors. And have an atonic touch! And then the so nicely designed "streamlining" in the front of the locomotive and on the tender - so absolutely perfectly contrasted and truly ripped away by the atomic (I guess?) elements/reactors, which replaced the boiler ... I am seeing that as the "technical dialogue of multiple worlds, cast in artwork". Wow. Truly inspirational. And one of the most beautiful machines I have seen built with bricks and plates. Thank you so much for sharing the last videos (which are way too short ;) - so I had the chance to catch up! All the best Thorsten

I totally agree. We also have the Community Forum, which has apparently a reach of next-to-zero. Which is - well frustrating to people posting there. To me, it is because it appears as if nobody is willing to look at the rim of the LEGO plate. I may be wrong. But it is there, and it seems bubbles remain to be bubbles. As it is anywhere, e.g., in science, every day's life: This is a LEGO forum, so don't go beyond. I really do respect this take. What I have learned through my entire research and teaching career though is: >Do< look beyond. Do go to the dark side. Try to learn. Labeling things as "knock offs" or whatever never leads and lead anywhere. When stuff is protected by law, fine. When that vanishes though (due to time ticking off), or "others" simply don't care, then get better, as your IP >was<. Living in the past always bites back. In other words: These "alternatives" can potentially invoke thinking - but, as per usual, there are these comfort zones. @Auroralampinen : Just go on and on. Maybe not in the Technic Forum, if the flak is really hitting you. We have the Community Forum, which is a marvel, when used appropriately! And finally: When someone ever explains to me, why the CaDA thread, i.e., the thread representing a non-LEGO, full-blown competitor Chinese brand is tolerated in the Technic forum with no "problem" at all, in contrast, praised here and there (which is totally fine with me!!!), I won't post any of this anymore. All the best Thorsten

Hehe - same here. I simply gave up. But that one was really easy, wasn't it? HS = Henry Shotter (you know the wizard stuff) and MF = Monster Flips, these cars that can flip over. This is how I read it . Have all a nice day Thorsten

What exactly does that mean? The Sypbots are using "the same" byte code protocol + heavy extensions as the RCX, aren't they? I am using BricxCC/NQC to program and interact with all the supported PBricks. PF is a completely separate protocol - the LEGOINO implementation of Cornelius Munz, running on ESPs and Arduinos, incorporates the entire PF protocol (I included in my ESP32 MulPI code). I never heard that Spybots do talk PF? Best Thorsten

Folks, are we still on target regarding this thread's topic title? As said, I believe I lost it somewhere, then came back on track with @Bliss' web solution. But now I am losing it again: Is an MQTT broker (I have no idea what it is good for, even after googling it) essential within the scope of controlling "old LEGO Control Interfaces"? Or is it more for controlling several serial (RS232, not RS485) devices, who don't have an address type thing out of the box, using one sort of master program? If so then this broker thing somehow routes the serial packets to the target recipient? Which is fine, but I was hoping more for modern programs running on current machines which are "controlling" (i.e., are the brain) the muscle devices (i.e., Interface A+B). I have a different take on PBricks (CodePilot, Cybermaster, RCX, Scout, Spybot, MicroScout, NXT, EV3): These are more than "simple" sensor data providers and output boosters, as Interface A+B are. They all have a brain that wants to do something on its own. Some are not the brightest candles on the cake, but are trying hard. Even Control Centers I and II have brain. And yes, all these can be simply controlled from one master program, heck, I am doing it ion my train layout, which features all but EV3 PBricks. However, the RCX', Scouts and NXTs just receive two byte LEGO messages (ID and command) and then act on their own by interpreting the messages. So back to my question: Is this the ultimate goal (making full use of PBrick capabilities) or does this work here focus more on "remote control" with sensor data feedback? Sorry for asking, too many things happening here on my side at the same time. All the best Thorsten

Well, if you were still enrolled, had visited my office, there were good chances I'd offered you a student job. All the best Thorsten Dam-ned. OK, I broke out my notebooks, the type with pages, I scribbled on. So what I did (apparently 2025-2-18, and man, I should improve my writing) is: Took a Ser2TTL adapter (w/o USB power supply port), wired the four lines VCC, RxD, TxD, and GND to an HC-05 BT2TTL adapter (1:1 = null modem). The RxD line, as the HC-05 is 3.3V, the Ser2TTL is 5V, using a 1kOhm resistor for safety reasons. Then used a 78L05 regulator to tap into the regulated 9V rail of the Interface B and provided the HC-05/Ser2TTL adapter with 5V. GND of the 9V Interface B supply = GND of the adapters. Best wishes Thorsten

Well, if you browse through Philo's site, you'll find this section: https://www.philohome.com/sensors/tempsensor.htm It is about how to make your own, but Philo found out which type is actually very close to how the original LEGO temp sensor behaves. I doubt TLG used PT100's or something similar, they tend to go cheap (but rather) reliable. Philo also suggests types of NTCs. Oh crap - Interface B gone again - that is very bad. I am just too busy right now with work stuff - it is the second round of exams (you take when the first try, well, somehow "failed". Or you want to improve. Generally, people becoming increasingly nervous as they have only three tries ... which I hate, exams are good for almost nothing, but that is my very personal view. I am powering my HC05/TTL2Ser converter also from the Interface B as power source, I need to find that stuff as well ... Best wishes, Thorsten

@Wapata Wow, that is quite the journey you have taken! And surely tracing a four layer PCB is quite the task, if possible at all with just a multimeter or small oscilloscope. At least the "legs" of the individual components should connect to something - if they are not some type of 3 pin SMD dual diodes, where they only used one diode (here is an example: https://ae.rsdelivers.com/product/nexperia/bav99215/nexperia-100-v-215-ma-diode-switching-3-pin-sot-23/1037576). I vaguely remember (but that could be wrong, need to check) that the IR tower of the RCX used a couple similar devices and one had only two pins attached(?). With regard to PMs: You need a post count >= 10 (again, not sure about the =, it is maybe > ;) and then you can PM around. So that will be enabled for you any time soon. LEGO sensors: All the 9V sensors usually used in conjunction with Interface B are fully compatible with RCX/9V Mindstorms sensors. In this regard, Philo's homepage is always a good start (https://www.philohome.com/tech.htm) - here you will also learn about powered vs. unpowered sensors, how to do that, what they do etc. I also had some luck with googling "LEGO RCX sensor circuit diagram" (picture search only) - that will lead to quite some old, but still functioning sites. Just let me know what you are looking for specifically and I can dig through my files, handwritten pages, and so on. Others here on EB have certainly also valuable information in this regard!!! All the best, Thorsten

Holly crap! I did not have the time to enjoy your code, dam-ned. It is "written exam time" - repeating in eternal motion every semester. You know, when the grandparents die like flies and horrible diseases break out Keeps me busy as I like as many students to pass at least. But: Does this mean, the "flow" of the program just continues after having "read" the blocks, leaving a timer active as a fire and forget "thingy" (as long as I do not cancel it)? Remotely comparable (maybe, I am just guessing) to hardware timers used back in the days (they never cared about further code after being triggered ). Or the timers I am using in RCX byte code (OK, translated into that by NQC)? Best Thorsten

Oh yes, congratulations! But what did I miss? There was this wrongly soldered tripod thingy - did you replace that? What actually made the Interface B come back to life? The Arduino soldered directly to the B's microcontroller? I am just curious. Best wishes, Thorsten

Have been rather busy the last month(s) - our annual mass spectrometry conference has closed its doors on Friday - was rushing back from Leipzig to make it for a birthday party - getting things into the clear, and now !focus! @Bliss I just read this thread from where I lost it - the moment I found "just go to this website" you had me. Learned a bit about "blockly" lost it again, but updated Chrome (I am a Firefox user as long as Firefox exists), installed the essential add-ons (Adblock, etc. pp) and shall try connecting my Interface B (which connects via HC-05 + TTL2SER to my Win11 laptop). I have the feeling that this will be pure fun! I can do all that with DOSBox-X + QBasic, but when it comes to "programming" Interface B in QBasic, a lot of care has to be taken as I need to capture the serial port data along with keeping program control clean - in - well - one Basic program. I am not interested in controlling multiple B's, as I haven't envisioned any stationary >programmable< robotics device having 8 inputs + outputs. Turning things on/off in response to pressing buttons is one thing (and I do that differently in my LEGO world, using RCX driven "electro-mechanical" devices for example). After all, Interface B is a sensor data reporter and light/motor driver, which is principally the same thing Interface A does. The software on the computer does it all, in contrast to the PBricks, which are meant to run autonomously after programming. And here is, where your approach really excels. I know: LOGO is under the hood of the LEGO software, but I am struggling with LOGO a lot. Particularly when mixed with visual controls as in the LEGO software for Interface B. I got somewhat familiar with the (visual) LEGO software for the NXT brick (using all sorts of 3rd party sensors/extension, some were my own), but when I wrote (ok, "wired") more "complex" programs, it became difficult there as well, as the IDE was maybe not expecting such "long" programs. I am really excited - I believe your approach is the way to go, "Interface B software-wise". All the best Thorsten

That's the thing, isn't it? I don't favor the plain average approach though. There should be a "time elapsed from first exposure" (temporally resolved) related study, as you like a paper coming out ;) Best Thorsten

Ha! Time to brag :D I have 11 1.0's Of which are 8 in service: 3 serve 18 switch points on my train layout (using mechanical multiplexers), 2 manage some lights, 1 operates a bridge (otherwise I can't get into a storage room up here) and 2 operate - well - 2 trains (these are post-PUp PID (or PPP) speed controlled trains ;) There is also 1 Scout operating 6 MicroScouts (via optical fibers) operating 6 additional switch points and another Scout operating 3 MicroScouts (again via optical fibers) operating 3 more switch points. It takes about half an hour to switch all these PBricks on :D They are all equipped with NiMH batteries and pickup power from the 9V track, which is permanently powered with a 15V DC laptop power supply. Which in turn means that I don't have to replace batteries every so many months Control is via Laptop/VB6 (yes, VB6 ) and MulPI, which among other things uses the plain vanilla RCX messaging protocol to send out - well messages to the Scouts and RCX' using simple 433 MHz OOK transceivers I made. MulPI also uses the PowerFunctions and PoweredUp communication channels (it has an ESP32 Vroom board under the hood - these are simply >crazy<. And already soo old ;) And just for fun, I can also control the lights up here as they are controlled by InterTechno 433 MHz wireless switches, which were hip after WW2 - no - it was after Y2k. Trans-blue = Spybots, old-grey = Cybermasters - they are all very handsome and readily programmable with NQC or more comfortably with BricxCC, which uses NQC. I also have a couple of those beauties. And you can get them for cheap - I guess, because documentation back then was no so enlightening ;) and they are sort of limited in general usage due to their built-in motors. Autonomous robots were meant to be powered by them. But: I will find duties for these as well. I just need more time. Less than 3 years and I'll be on permanent vacation Y'all have fun! Best Thorsten