Toastie

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

I am totally lost And this is due to my lack of knowing anything about Python (well sort of, I guess, I get the Python idea, have it installed, but whatever I try, it tells me I am dumb) but certainly because I simply can't follow the libraries, includes, and whatnot required for getting this up and running. Rock on dudes, I revert to QBasic/DOS3.3/DOSBox-X. Have fun and make it happen! All the best Thorsten

Yes, this is what I thought. You need to come up with a program on the CL monitoring three inputs “simultaneously”. When you press the buttons on the CC the CL monitoring routines will notice that, and then you need to record these key presses = sensor input changes along with the time they were pressed on the CL. And then you can play them back on the CL. Best Thorsten

@amine It works! I just tested it with a simple voltage divider (2 resistors) and a 12V power supply. You can use the 3 outputs of CCI/II to "program" CL, once you know how capturing of A/D values on the CL software works. My QBasic program does decode these data, as it reads out the raw A/D values provided by the CL interface (the CL protocol provides raw 6 bits = 0 to 1023). I have no clue how to get the LEGO CL >software< (I am running Control Lab for DOS) recognizing any such raw A/D values; my understanding is, that either touch sensors and/or temp sensors can be used on the yellow = passive sensor inputs and these data are converted internally by the CL software to "ON/OFF" or "°C/°F". You may well convert °C/°F data back into raw data (0 ... 1023), of course. Maybe there is another way in CL software to tell it: Use the plain A/D data. What happens with this simple setup is: When pressing any "fwd" key (upper red button or yellow disc N/E), a reading <600 is recorded by CL, when pressing any "rev" keys (lower red button, S/W), the emitted data are somewhere between 800 and 900, and when no key is pressed it is 1023. These numbers are all raw sensor data, as provided by the CL interface. If you want more details, I am happy to provide them, here or via personal messaging. For this approach you need a) a cheap, but stabilized 12V DC power supply, b) 3x1kOhm + 3x330 Ohm resistors (covering all three CCI/II outputs), and c) a bit of soldering or a solderless mini breadboard. All the best Thorsten

That is >really< cool!!! Now, I personally (it is just me!) would like to get this into the clear. Your IDE, as a main goal, is designed to >control< the various LEGO PBricks and interfaces from, well, the IDE, right? Or do you also want to universally program the PBricks and interfaces? Interfaces would be A and B, right? PBricks would be CodePilot, MicroScout, Cybermaster, RCX, Scout, correct? NXT and EV3, as well as Spike/PUp are more or less up to date or do you want to include these as well? The interfaces are essentially stationary and act as remotely controlled devices, in addition delivering input data, whereas the PBricks are designed to operate autonomously = run programs to respond to sensor data on their own. In other words: Your IDE is designed to do two principal things: a) run programs on the interface controlling device and b) provide means of downloading programs to the different PBrick targets. Is this the goal? Very interesting project!!! All the best Thorsten

Hmm - that seems to be a bug? When I use either TCLogo within the DOSBox-X emulator or directly on my IBM XT with 9771 card, I don't get that error. At least not, when I type "tto 1" then "on" and then "tto 0" and "on" in direct mode. Does this lead to the error you mentioned in your post? Best Thorsten