Toastie

So nice - update worked with one mouse click! Regarding Control Center I/II (CC): Essentially it is a "closed" Siemens 680X microcontroller driven three 9V output (with no sensor inputs) device, which is recording output activation/deactivation sequences including the pauses in between. There are two programming slots and a total of some 50 steps. It has two keys A/B for output A (fwd/rev) and a yellow dial type button, which can activate any two outputs B/C in fwd/rev direction. @amine had the really cool idea of using CC's three outputs (ABC) connected to any three 9751 inputs as some sort of "key pad", and then record these key sequences. This way, 9751 is mimicking CC, but with way more programming steps available, in addition to program storage. CC can only hold one or two programs internally. Here is one thread on EB, there is so much more out there! @amine's case is special - but nicely aligning with the idea of using old LEGO programmable devices with either old or modern computers. Best Thorsten

@Bliss it IS really like that. It took me about 30 min from "installing" your standalone version (it is really just clicking on "download" on your website and double-click the newly crated desktop shortcut icon), connect to Interface B (which was a mouse click), getting familiar with the environment, left/right mouse buttons, the gear icon, trash bin, and - beginning programming! As said, I looked into the Control Lab (DOS) software - this must have been a blast (and for me still is today) back in the 1990's, as it creates a graphical UI and unleashes the programming power of Logo. However, the Logo program control flow was hard to grasp - for me that is. Interface B (9751) is "just" an 8-channel output driver and an 8-channel sensor (raw and encoded) data provider. So is - partly - Interface A (9750). The big difference is that 9751 spits out the sensor data, like it or not, an 9750 wants to be polled. And of course serial vs parallel is another big challange on vintage machines. In other words: Computer control of 9751 (for me) was so far reading input data and pressing buttons to operate the outputs using QBasic. The real power of any input/output device is the "controller" in between. Which is in case of 9751 and 9750 the connected computer. And which is different for PBricks, as they want to be programmed to take over the controller task. This has now totally changed, as I can use 9751 as a controlled (via your software) device. That is so unbelievably cool. I believe it is the right way to do! This is how it is done elsewhere. The user can decide, when the UI/program needs to breathe! There should maybe a hint in doing so. But I have crashed so many programs on Arduinos and ESPs simply by cutting off their breathing ... That would make things easier, as this is a frequently encountered situation, when working with raw input data. I am aware that "automated" on/off values are making things easier, but there are so many hardware issues that may happen: Touch sensor contacts simply age. Never to the extent that they don't work anymore, but to the extent that built-in software thresholds for on/off with hysteresis shift so much, that they seem not working anymore. This is why I prefer the raw data ("value" in your code) mode for sensors whenever feasible. It is more flexible. I am testing like a maniac - as I am simply so positively fired up! I added the good old "Sensor_2_old" variable (as I do in so many of my QBasic programs to avoid loop execution if not required): If var_old != var then var_old = var do something using var (or var_old) else wait some time endif This reduces traffic on the serial bus (output data) - which may not be any issue on modern computers but frequently is on vintage machines ... Yes and yes. The BT adapter is a simple HC05 + TTL to serial adapter duo (out of 3 that I am using with my LEGO interfaces in addition to a BOLUTEK BT to serial adapter) - they are all nicely lining up in the "connect" dialogue window of your Blockly UI. It is so easy to connect to any of them!!! You know, they are certainly not sufficient, but what should I say: I really believe that I am dreaming! All the best and thank you very much for creating this programming environment Thorsten

Or use two CCs - that would be cool as well! Best Thorsten

@Bliss For me, this is a dream coming true!!! For the very first time, I have successfully "programmed" Interface B - and this was done using your Blockly app, which I downloaded an hour ago as per your instructions. So far I have just trying things out with LEGO's Control Lab software without getting anywhere - the learning curve there is rather steep - for me. I am also simply not good with Logo ... something in my brain refuses to grasp the logic. Well I guess more frequent programming hours and Logo will become logic as well; after all, all programming languages share at least some of the same logic However, the principle logic behind your Blockly code just connected directly to my brain ... I will have a lot to learn, but this is fun. It is just amazing when realizing how elegant and easy it is to get it going! Instead of generating a "Hello world" printout or having the program count from one to one hundred, I made a very simple program, that monitors input B of 9751 and then turns on/off the outputs B and F (as they are in one "column"). In fact, I was doing that using my Control Center II (CC, red output operated by keys A and B) connected with my lill opto coupler interface as briefly described here (this is @amine's idea!): This is "My First 9751 Program" using your code - please bear with me, it is certainly horrible, but it works: This program turns on/off 9751's outputs B and F depending on the raw data value at input 2: When I press button A on Control Center (CC), 9751's output B is turned on, and F off. Button B on CC turns output B on 9751 off and output F on. No button pressed on CC = both outputs B/F on 9751 off. I do visualize this with 9V lamps, this is why I use two 9751 outputs (B is for fwd, F for rev). This is not necessary when "recording" CC key sequences; this is what @amine is looking for, I believe: Storing longer than 50 or so programming steps for a CC model operated with 9751, but using the CC as keypad with is nice big yellow dial and two A/B buttons. @amine you'll love this, it works like a charm! @Bliss For now only one question: When I do not include the "wait 0.001" seconds at the end of the "repeat while true" loop, the program stalls at once. This is absolutely normal behavior, right? With that delay, the response of pressing buttons A/B on CC and B/F lights going on/off on 9751 is almost immediately, this is so impressive!!! The input data have to be received over the BT serial line, processed, and the response has to be sent back over the same connection! Wow. Thank you very much for sharing this phenomenal achievement!!! All the best Thorsten

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