Toastie

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

What to say? @Glenn Holland = insanely creative and breathtaking builds. I am always admiring your images. There is really just that, as I have no - absolutely no clue, how these locomotives you have literally replicated in LEGO world, can be crafted into bricks and plates like you do. Wow. Thank you so much for sharing on EB (so even I can enjoy your builds). All the best Thorsten

I'd say terrible? I am so with you. TLG wise, I am out for some time now (set-wise, not idea-wise), they just can't get their act together, as far as I am concerned. OK other than rip-off people. But then: I am old, and my assessment simply does not count. Should the younger people along with their parents enjoy this ... noise - good for them. What really gets me off the rails is the insane price tag imposed on these sets. 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

I totally agree. However with the right parts count and set design. There is no reason to just go more or less dead cheap on the part count limited design and implicitly blaming it on the tech. I mean the price tags for these sets are simply stellar. And the decision of not selling the "smart" brick separately, well, is telling. I am not saying that I don't understand the approach (compensating for the development cost). It is just - crazy expensive. I'll never get one of these sets simply because of the disparate price tag - consumer wise. Should people go for it - cool for TLG! Best regards 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

How on Earth could that happen ... Thanks for noticing and - all the best Thorsten

Also from my side: Thanks a lot, I did not know that. Just downloaded the package. All the best Thorsten

All good here as well.

So there are at least two of us! I do see and do it the exact same way you are choosing: Either I get the (as "Unobtanium categorized") items, such as 9771 for very low money + S&H of course, or I will take the "trail and error, error, error ... success!" route. OK, success may not be the final result, but for sure the learning curve took steep inclines! And that is all what counts. AI may be of help - or maybe not. I recently got so much nonsense regarding "reset button for a C64" from Google's AI - it was telling. Old and swiftly emerging stuff (back in the days, as the C64, Apple II, and other systems - heck, that was the >fun<!) seems not to be the realm of AI. I prefer the human brain guided search when it comes to old stuff. You know the arbitrary diversions, deep dives, just for fun searches. And yes, the "what I have at hand approach" is another rewarding experience. 3D printing? Sure. But maybe there is a scrap part somewhere? Buying the perfect fit part for some task? Sure. But maybe a used part, having the functionality, will do? With some mod, or apparently less nice look? Sure. However, it depends on perspective: Used parts generally look good to me ... Just keep posting what you are either struggling with or you have accomplished. Or you are searching for. I am in. All the best Thorsten

Hi Michael, that is a perfect write-up!!! Maybe one tiny little thing to add: Thermistors, as they are “stressed” chemical compounds (they need to chemically conduct current in contrast to metal wires, they simply push electrons through and thus may burn out, as nobody tells them hey, could be too much ;) - naturally “age”. First with time, second with stress. As do rechargeable batteries, for the same reason but due to a totally different chemistry. Thank you very much and all the best Thorsten