Toastie

This! ... ... is exactly what I meant with "planning on taking it further". I believe David was interpreting my phrase as "more additions to this section", but I was just thinking about publishing in print, as a real book, at some time. I know this is totally old school, but when I look at my library of such "real LEGO related books", and the way I "work" with these - yeah, it does "work" (for me, at least) as a true, never-fading reference library. Because these books exist in my real universe. Reverting to online or copied PDFs, I stored ... somewhere ... on my computer ... they are ... mostly fading away, are sort of gone. Oh, digging them out again, when attempting to clean up my computer, is always, well, nice - and not so nice, as I feel bad about forgetting them ... Simply looking at my physical book library, they are >there<. And I may just grab one for fun. And learn ... Well, I am old. And I bet others have a totally different take on this. Which is totally fine with me! All the best, Thorsten

Hi Evan, yeah - the speech synthesizer has this 74LS138, which decodes only 2 out of 8 outputs (6 are ... not used, what a crime!) and has one freely available output selection input (C), when you free it from ground (that is another crime, actually; I believe with good lawyers, you have a case here ) - and then you don't need any further address decoding hardware. This simply means you don't need to tap into the (almost full range 16-bit) address bus, which would add a painful soldering frenzy, just look at #9771 ... And the speech synthesizer still synthesizes CALL SAY("TEXAS INSTRUMENTS") without glitch Best, Thorsten

I find this extremely useful Congratulations David! What a nice book and read - chapter 2 is my absolute favorite!!! And of course the reference section in chapter 7 - and of course everything else. But 2.15 is a blast. Do you mind, if I take some of your text and illustrations for my Introduction to Thermodynamics class(es)? And for discussion sections? With full reference to your name, book address (will that be sort of permanent or are you planning on taking it further?), and affiliation as found in the Afterword section? (I'm at the University of Wuppertal, where I am playing the head of the Physical and Theoretical Chemistry group) Wow, this is a true masterpiece: Very (!) nicely organized, helpful examples and illustrations ... And then the wonderful theoretical discussion culminates in an LEGO instruction ... so nice. Thank you very much for this truly marvelous publication! With very best regards, Thorsten

This is really cool, congratulations! Could it be, that this version is balanced in the exact right way? The circuit cube isn't really heavy, but may add a little more weight on the back - but no so much that is tips backwards when climbing, and has enough traction for the downgrades ... or is the train well-balanced? As @Hod Carrier said: This is a lot of fun to watch! Best wishes, Thorsten

"There are unsmiling faces in fetters and chains On a wheel in perpetual motion" Don't know - maybe Alan Parsons also plays with LEGO - although - at the days of that album, LEGO was still LEGO. By the way, 20000 parts of 1000 different types - exactly the same happened to me. I do have quite a number of Technic parts from the good old days, particularly of the type with studs ... but when my storage box count for Technic parts exceeded a critical number, I called it quits. I am now playing with LEGO Technic Control stuff from the mid/late 1980s, assemble vintage computers I dreamt of or had back then, and like Danish beer (a lot) - weirdo, I know. But yes, these are the two sides of the same coin; new parts = new nifty mechanisms, particularly for purists - at the expense of needing to buy new sets - just for these parts. Which is ... a wheel in perpetual motion. And maybe a perpetual motion machine of the fourth kind .... I, too, like drilling and gluing ABS ... Best, Thorsten

Thank you very much for your comment - I never expected such a reply, and I really appreciate that! To be honest: I have no clue, how you guys are making all these Technic wonders presented in this forum - but I do skim, read, and mostly admire the pictures shown or discussions going on here. All the best, Thorsten

@evank Hi Evan, all I just posted in the CADA Technic forum an (almost) full report on getting a TI99/4A controlling LEGO Technic Control Interface A (#9750). Yes, the post will drown to oblivion in no time, but who cares. I just had a couple of hours in my attic upstairs to compose the post - my wife had her neighborhood birthday party today, I was in charge of preparing the infrastructure, such as additional tables on the patio, sunscreens (it was sunny hot in this region of the Earth), and (oh my) making a dish of tomato/mozzarella with a leave of garden grown basil in between every serving ... that is as far as it can possibly go here, dish-wise ... BUT: I can do the cocktails. That was my premium assignment tonight: Only the first round, though, and then I was allowed to disappear ... So again, this may be considered cross posting, ashes on my head: Here is the link: I need to make a video proof; so far all I have is this: The prototype bread board version, operating 6 LEDs and two inputs that fully mimic the hardware of the Interface A (#9750). The video shows that the synthesizer module I used for the hack is still operative and at the same time can talk/listen to #9750 using BASIC for coding. In that video, I am using TI Extended BASIC along with a 32k expansion board to operate both devices, the speech synthesizer and #9750; controlling #9750 also works with TI BASIC and the mini memory module inserted, that has to be "video proven". EDIT: I have more, there always is: Video (of the crappy type but) showing that the 99er can still talk and control #9750: All the best, and hack the planet, Thorsten

Dear all, this is what I came up with recently (focus is on the lower right ...): Executive Summary In this project, a 1981 TI99/4A is connected via its speech synthesizer module to Technic Control Interface A from 1986/7 using a simple bidirectional 8-bit latch parallel port interface comprised of two 74LS373 TTL ICs from the same era No address decoding required, instead, the PCB in the synthesizer is slightly modified and all required lines (D0 – D7), LR#, LW#, WE#, GND, +5V are wired to the empty upper compartment of the synthesizer module Direct access from TI BASIC (1979; mini memory module required) or TI Extended BASIC (1981; XB module required as well as a 32k memory expansion module) The interface is in full compliance with Evan Koblentz’ challenge, announced earlier here on EB as well as on his website, see below. A preliminary video showing the TI99/4A + synthesizer module in action is here: It shows my prototype board (which is now on perfboard in the TI's synthesizer module). In action means, there is speech synthesis and parallel output to 6 LEDs and 2 TTL inputs (which go directly 1:1 to #9750). I hate taking videos, as I constantly screw up, but will try to make a somewhat decent one … EDIT: Video ^^ is on Youtube: And here is the full boring story: During a trip to the US (SoCal) in May/June this year, I “accidentally” ;) googled “TI99” … … so here we go again: Motivated by Evan’s 9750 EuroBricks hacking challenge, I tried to get my 1982 dream computer TI99/4A in touch with TLG’s LEGO Interface A (#9750), what else to do with it ;) And yes, my posts in this regard may be annoying, but so are super cars. Or Cada stuff, BuWizz problems, ++$600 sets – of course >only< to me. Here is to feeling good! The TI99/4A is “beautifully weird” and a very nicely designed system, I fell totally in love with. I have these feelings after thorough studies of corresponding circuit diagrams and inspecting the main board myself. I had no idea what the story was back in the days; I did not know why TI entered the home computer frenzy ship in 1979 with the TI99/4 and abandoned it in late 1983, when they stopped manufacturing the TI99/4A, nor that 16-bit TMS9900 processors existed, and that the TI could speak … I do know now and it is truly a breathtaking story. Also the “inner logic” of the TI99 around the CPU is almost bizarre, but when diving deeper, it really is a very cool approach, descending from the concepts of making mini computers. As said, I never had one, nor saw one in reality before early summer 2024. Evan’s challenge rules are hack computers from 1992 and earlier, that were not endorsed by TLG to operate LEGO Technic Control Interface A #9750 (endorsed were: IBM PC, Apple ][, BBC Micro, Commodore C64, Philips P2000) only use contemporary hardware components up-to 1992; only use emulators on modern machines, but with no additional features other than available up-to 1992. This 1992 threshold originates from TLG’s release of their Interface B in 1993, which changed “everything”, details are on Evan’s website (https://www.brickhacks.com/2.php) For my very own purpose, I added a 4th rule: The Interface A must be operated with the BASIC language that came with the respective computer The latter is just my personal rule, as it a) makes it much easier to write programs for operating #9750 in contrast to using assembly; b) virtually all BASIC dialects have almost identical instruction sets, particularly PEEK, POKE, and or IN(), OUT, to get access to the hardware components of the system; c) assembly, which is a way more powerful language, both in terms of code execution speed and hardware accessibility, is mostly specific to CPUs due to their different internal hardware structure, as are the accompanying assemblers, linkers, and other software. I do speak Zilog Z80 assembly, but I had a hard time getting used to Intel’s 8086/8 assembly, and for Motorola’s 68000 (used in my Atari 1040 ST and others), I simply lost it. For the 99er, with its Texas Instrument TMS9900 CPU, everything is once again largely different … and I simply don’t have the time to learn all this stuff … well not yet ;) OK, enough story telling: What is the cheapest and appropriate hardware approach (cf. challenge rule 2) for getting parallel access to the 6 output and 2 input lines of #9750 in TI BASIC? Well – none! That was it, story was over. Why? Because TI BASIC (from 1979) does not have a POKE, nor an OUT or equivalent command. You can PEEK around, but no, no POKE. Back in the days, there may have been good reasons for that … But wait, there is more (there always is) … there is TI Extended BASIC, released in 1981 as ROM cartridge. And bingo, now we’ve got CALL LOAD (address, byte), which is the equivalent to POKE address, byte … but only when you have the 32k memory extension attached as well ... or if you have the TI mini memory cartridge, which also adds CALL LOAD to your commands, but without any other needs. I was lucky enough, to purchase an original TI mini memory cartridge for €40 from a >very< nice individual living in Berlin! Thank you very much again, Daniel!!! So I was all set, original hardware wise. On to hacking … it took me a while to figure out the “inner logic” of the address decoding within the console, particularly because the TMS9900 processor is a true 16-bit CPU! When interacting with peripherals though, the 8-bit world is back, by doing … things, I still don’t understand. All I know for sure is: The TI99 uses an 8-bit wide data bus to talk to its speech synthesizer box, an add-on that came with my machine. And that CALL LOAD and CALL PEEK have direct access to this thing, i.e., its memory mapped address space: One can read data from the synthesizer at address 0x9000 and write to it at address 0x9400. So the documents say. With some further study of the circuit diagrams of the console as well as the speech module and most importantly, this website (http://www.unige.ch/medecine/nouspikel/ti99/titech.htm), which is an invaluable resource, I finally came up with these ideas: Use the speech synthesizer box as enclosure for my “TI 9750 interface” in the way, TI originally planned it: Slide-in hardware speech extensions into the upper compartment. Well, the upper compartment with that little door is empty, nor are there any sockets; in other words, TI never released anything that may slide in there. The circuit board with the synthesizer’s electronics is located in the lower compartment. I read that TI planned to extend the speech capabilities of the synthesizer with additional “speech ROM modules”, but before they actually made that happen, they found out a way more flexible approach using software … so no one wanted to book that room up there in the synthesizer, but me. As the full I/O bus including all address, data, and control lines of the TI console are fed through (and also into) the speech synthesizer’s PCB, everything is available within the synthesizer box; no reason to hack the console. When you attach the speech module to the console, the I/O bus is replicated on its other side, and more peripherals can be attached (parallel/serial interfaces, disk controllers, modems, etc. pp.). There is one exception: the +5V line is not, as the power consumption of the different additional original TI hardware extensions was simply too high for the console’s power supply. However, when you only want to power a modern 32k memory extension, just solder a wire from one side of the synthesizer PCB to the other. I did that. So, here’s the plan: Circuit diagram of some of the address decoding sections of the TI console and synthesizer module (blue boxes), and my added two 8-bit transparent D-latches (74LS373) interfacing to #9750, along with a 4 x NOR gate 74LS02 TTL chip. Note that only one NOR gate is used. Here are the console and synthesizer circuit diagrams I used for my project. The former is actually a large collection of diagrams of the TI console and some peripherals. The weird CON notation is just describing my wires going from the PCB into the upper (empty) compartment of the synthesizer module. Address decoding in the TI99/synthesizer system (useful for hacking …) The logic of the IBM PC/#9771 combo has been described before, and is summarized (again ) in the hidden section below, where the corresponding TMS9900 CPU lines are used for the description. The thing is: The TMS9900 has no IOREQ# equivalent; all I/O access is via memory mapping (which may be wrong: I simply have no clue, how this A15/CRU stuff works, and most importantly how I would invoke/apply/use it from BASIC. Furthermore, there is no RAMCS# or ROMCS# input as on the ZX computers, which is really useful on systems with unresolved address space. The TI99 is no exception in this regard – out of the box, its address space is not fully resolved, see below. With reference to the above circuit diagram, I figured out a rather simple route to make use of the present address decoding hardware in the console and synthesizer module for additional memory mapped hardware, without screwing up the system – and without using assembly. In essence, I am hacking the synthesizer module, there are no changes to the console. The minor hardware change, without compromising the functionality of the synthesizer(!) is: A cut of one trace on the synthesizer’s PCB: Remove GND from pin 3 (C input) of U3 = 3-to-8 decoder 74LS138. And then connect this pin to address line A14[A1]: Note on usage of weird notation A14[A1]: For some reason, the TI engineers back in the days decided to use a different notation for their address and data bus lines: In contrast to every other vendor, TI denotes the most significant address bit as A0, and the least significant bit as A15. This is exactly the other way around in all other computer systems known to me. The same holds true for the data bus. I am thus using the notation A15[A0], where the bracketed bit denoting what it is outside of TI universe. Here is how the address decoding for the synthesizer works in the original configuration (you can read much more about that here): The speech synthesizer chip TMS5220 has, among many other things, two inputs, RS# (L = CPU reads data from synthesizer) and WS# (L = CPU writes data to synthesizer). Both cannot be L at the same time; thus there is a dedicated read address and a write address, respectively. These signals are generated by U3 = 74LS138 (3-to-8 decoder) in the synthesizer – this chip selects only two outputs: Q2# and Q3#. No other Q# outputs are used – in other words they are free! The output enable dependencies for U3 are: A15[A0] = H; RESET# = H (which is always the case when there is no trouble). The inputs A and B (C is bolted to GND = L) select the active output Q#: Possible combinations in the original configuration are: Table 1: “-“ = not connected/no function; SBE = speech block enable; RS#: read from speech chip; WS# write to speech chip. Note, that A5 = [A10] in the non-TI world. That’s it; Q#4 – Q#7 cannot be addressed, as input C is always L. And here comes the hack: Remove input C from GND = L, and hook it up to A14[A1]. This is all and changes the output selection to: Table 2: LR# = LEGO 9750 read; LR# = LEGO 9750 write, my fancy addition of synonyms … Now we need to have a look at the address decoding inside the TI99 console; on pin 2 of the I/O port, the above mentioned SBE signal is provided, which indicates CPU wants to address/access the synthesizer module. The NAND gate U506b in the console “combines” the outputs Q4# and Q5# of U505 (74LS138 3-to-8 decoder) generating the SBE signal: When either one of the output is selected (= L), SBE = H. When none are selected (= H), SBE = L; and finally both cannot be selected. Regarding the enable inputs of U505: Q4# of U504 (again a 74LS138) needs to be selected = L and A15[A0] needs to be L. The third enable input is active H; the NAND gate U506a combines A5[A10] and DBIN in the following manner (DBIN = H indicates a read data request from the CPU): When the CPU has issued such a request, DBIN = H and thus A5[A10] needs to be L, otherwise the outputs of U505 are disabled (are all = H). When DBIN = L, A5[A10] needs to be H for a write data request. The outputs Q4# or Q5# are selected, when A3[A12] = H, A4[A11] = L, and A5[A10] = L for read and H for write, see above. Finally, for selection of Q4# = L on U504, MEMEN# (memory accesses enable) needs to be L, A0[A15] = H, A1[A14] = L, and A2[A13] = L. All this results in the following table for read/write access to my interface connecting the TI99 to #9750, preserving full access to the speech synthesizer: Table 3: X = L or H, thus the addresses are mirrored (i.e., are not fully decoded) every 4 times in the address range shown in the last column. Using this approach, we now have two (+ all mirror!) new addresses: 0x9002 for reading data from the LEGO #9750 interface and 0x9402 for writing data to the interface. As DBIN is already tied into the address decoding logic, C and OC# of the corresponding 74LS373 input latch (IC1 in the circuit diagram above) are both connected to Q6# of U3 = LR#. For the 74LS373 output latch (IC2), we need a positive signal on the C input, which is “composed” using Q7# of U3 = LW# AND WE# (write enable) from the I/O bus of the TI99. This is done with the 4 x NOR gate 74LS02 chip, but only IC3a is used. NOR gates behave as AND gates in negative logic, so LW# NOR WE# = H, that’s exactly what we need: Only when both inputs are L, the gate output is H, in all other cases L. The 74LS373s are wired as in the #9771 card for the IBM and many other simple 8-bit I/O solutions from back in the days. I used it for my ZX and Amstrad interfaces as well. Lastly, PEEKing and POKEing in TI BASIC is again a little different than for the computer systems I played with: In the address range 0x0000 – 0x7FFF (0 – 32767) it works as “everywhere”, e.g.: CALL PEEK (32767,variable). Above that address range (and the speech synthesizer’s addresses are located above 32767), one needs to subtract 0x10000 (65536) from the address you wish to PEEK/POKE: CALL LOAD (-27646,0) is equivalent to POKE 37890,0 (which is 0x9402, our write address for #9750). If we want to read data from #9750, we need address 0x9002, which is 36866; subtracting 65536 yields -28670 and thus CALL PEEK (-28670,variable) is used in TI and Extended TI BASIC programs to do that. If you like to read more about this approach, here is one source. And finally, here are some pictures: Above: Disassembled synthesizer module Above: CON lines soldered to freely accessible soldering spots. Yellow wires = D0-D7, white = WE#, yellow/white = LR#, yellow/green = LW#, whatever color (I am color blind) = A14[A1], red = +5V, black = GND. Missing: WE# - I simply forgot that line on first try and almost gave up, because nothing worked as intended. Then, when walking our dog, it just occured to me ... when you want to write data, you need to tell your chippies so ... Above: Perfbord attached to the connector, the top white connector was glued to the 12 others; this is the missing WE# line The left 10 x 2 pins attach to the Interface A with the original cable. Above: Synthesizer module. Bottom connector: Replicated I/O port of the console - this is where my 32k expansion attaches to and is also powered from. Top left: Connector for Interface A and 74LS02 trying to figure out, what's going on ... Above: Synthesizer module attached to console, with interface for #9750 extension under the hood and original LEGO cable for connecting to #9750 attached ... In summary, we can add another computer system from the 1980’s, which was not endorsed by TLG, to @evank's challenge (and https://www.brickhacks.com/2.php); The TI99/4A. All the best, Thorsten P.S.: Will try to make a video proof soon!!! Done

How cool is that! I still have these "train wash" pieces and never figured out, how to use them. In my rather limited space available, I need to do that in a curve; that means the two brushes need to move a little further, but: Seems to be doable! Thank you very much for sharing! Best, Thorsten

This. If it does have hiccups of this kind in drive motor operation, then I suspect it will be much more adversely affect the servo motor "simulation" mode, as it is unforgiving. When driving, it may be somewhat OK, but when steering (and thus relying on each click to be processed >fast<) things quickly get screwed up. So this strongly suggests that indeed, as you wrote, the click-processing is too slow, as it needs to be near real-time. From my limited BLE programming experience (/nsoftware BLE stack in Windows11/VB6), I also saw that data are not lost when storing them immediately when the corresponding event is firing, this was with the 2 and 4 port LEGO PUp hubs. However, the processing response time depends on how much the system has to do in addition to just doing that. And rapid steering data changes are most critical. And this is certainly a good idea, particularly for steering! Very interesting, as this suggests there are hardware issues as well: The moment, the servo control routine inside the BuWizz misses one or more clicks form the hall sensors inside the PUp tacho motors due to noise on the data line caused by "bad" contacts, things may rapidly end with a crash into a wall ... If bending the contacts is meant by @shroomzofdoom, then in addition also the application of sprays like "Kontakt 60" (and not WD40!) may improve the situation. I'd apply it to both motor plug and BuWizz sockets. This method actually reanimated the electronics of my e-bike; the display said motor is behaving badly (i.e. needs replacement due to miscalibrated torque sensors inside the motor = $800). Removing all cables from their sockets and dousing both plugs and sockets repeatedly with Kontakt 60 spay (each time with removal of the surplus, I had purchased the bigger can), and thoroughly plugging everything back in saved me $(800 - 23) = $767. Here is the good stuff: https://www.voelkner.de/products/495038/Kontakt-Chemie-KONTAKT-60-KONTAKT-WL-Kontaktreiniger-1-Set.html And here is what went terribly wrong: I did >not< claim the $767 at the finacial headquaters here in the house - I was just too happy to have my bike back alive. After a few days, such claims are not considered valid anymore Best, Thorsten

Those who can read have a clear advantage ...

Ooops, then the BuWizz is the sole problem, good to know. Thank you for clarifying! Best, Thorsten

So LEGO hubs have principally comparable problems, right? It is worse with BuWizz, but essentally using a PUp L motor (tacho motor) as servo is not necessarily the best solution; it would have been much better to have real PUp servo motors, isn't it? Best, Thorsten

Oh, sorry, missed that. But this "not going back accurately to 90°" thing still does happen to some extent? Best, Thorsten

Ah - which could simply mean, that the hub missed some of the "clicks" from the motor when rotating. Phew, accurately getting each click is a rather tough task, particularly when so many clicks are coming in! Such errors easily build up; when the controller believes the motor is at the 90° (center) position, but it actually is not (caused by these missed pulses from the hall sensors and motor power was still delivered by the hub until it believes, the motor is at the 90° position) then the next steering command all the way to an end stop in the direction of previous error will certainly introduce the next error, because the motor is at a final hard stop, but the logic inside the hub is not ... This should result in some interesting behavior (OK, others find disastrous ). Well, don't use a tacho motor for a servo task - or use really fast and reliable electronics combined with smart software, when using a tacho as servo motor. So does this erroneous behavior happen with the LEGO hubs as well, when tacho motors serve as servos? Best, Thorsten

I watched that video again (as I don't have PF servos); at 0:54 you clearly see that 0°/90°/180° are hardware "coded" into the motor as the copper "trace" is cut at these positions. I also believe in seeing a potentiometer at 0:57 in the front part of the servo, lying in the little bowl. So this seems to be a classical DC servo motor, where the PWM signature is translated inside the motor's electronics to the corresponding power feed to the motor. A PUp L motor does not have all these "servo things" (dedicated electronics, no software), all the smart stuff has to be done with firmware/software, per PUp data communication motor <-> "hub" = controller. And I believe this is where things can definitely go wrong. The resolution of the encoder inside in PUp tacho motors is 1° = 360 clicks per full revolution = 180 clicks per half circle. This is a rather "fine grid" and calculations of the "error" between set point = position of the (software) dial and the actual position of the (calibrated) motor, are done by the hub's firmware. For a tacho motor (which is not primarily intended to function as a servo) calibration is of course necessary, because it does not know "where it is" when it is powered on, in contrast to a hardware servo, as it has the potentiometer telling it, where it is ... As far as I know, there is no hardware "zero" position, I may be wrong though. So yes, this erroneous behavior of the PUp L motor on the BuWizzes using servo mode seems to be a firmware/software problem. Best, Thorsten

Well, this seems to be a copper-type rail he is cleaning, providing continuity to other parts of the servo rather than providing a proportional response to the angle, as a potentiometer would. Oh, I just realized that this is a LEGO PF servo motor - there is zero intelligence in the PF receivers other than providing PWM signals from power levels 1 to 7, if I am not mistaken. So all the "work" is done inside the servo motor electronics. When you go to PoweredUp tacho motors, all you get is a signal back from the motor - and I believe it is clicks/rotation or something the hall sensors provide. From that info, the controller has to do all the (PWM control) work. So when the BuWizz glitches when using LEGO tacho motors like the PUp L motor, it appears to me that there is something wrong in the software/firmware of the controller. Again, I learned that the hard way, when I programmed PID control into the RCX. The 16/revolution resolution (hey, does that sound nice or what?) was sometimes causing some "spikes"; but moreover, the BuWizz has to do so many more things/second when running wild off-grid competitions, as a train requires. Just gussing here, others may know much more! Best, Thorsten

Hey, no problem!!! Asking tough questions like this one is a) rather refreshing to me and b) one of the more relevant reasons for the existence of an educated, well maintained forum that Eurobricks is. As I have hardly ever worked with servos, nor do I have a BuWizz and such, but believe in knowing their principle of operation of servos, I have multiple questions :D What is the feedback mechanism in the servo motor(s) used with the BuWizz device? Are these PUp tacho motors? These are not servo motors but rather motors delivering a digital signal back to a controller (e.g., BuWizz) mainly for PID rotation control (constant speed of the controlled axle) as well as pulse counting control for reaching exact stopping destinations, which is what you want to accomplish, right? When using the BuWizz in that "servo mode", does the motor rotate at constant rpm (no load) to the final destination, and then suddenly stops? Or does it do that smoothly? In other words, does it slowly accelerate, then rotates at constant rpm, then decelerates and stops at the final position? Again, with no load, just freely running. Now when using PUp motors, you have a fairly high resolution for one 360° rotation; the RCX rotation sensor had 16 steps per turn (https://www.philohome.com/sensors/legorot.htm) I believe PUp motors have a much better resolution; in this reference 1° (https://bricks.stackexchange.com/questions/16395/difference-between-the-simple-medium-linear-motor-45303-and-the-medium-line). You are absolutely right: The higher the rotation resolution, the better are the results. When the controller has to do many other things than paying attention to the numbers (clicks of the rotation sensor), then things go easily out of control. I have no clue, though, how much intelligence is inside the PUp motors in this regard. Do they just feed back pulses? Do they process the pulses? I believe @Philo knows so much more on these issues! We'll see, the forum has been summoned All the best, Thorsten

Yes, you are absolutely right - I simply thought "textbook" - in most examples, there is one wire split into branches with different resistances. Sorry for the confusion, and thank you for clearing that up! All the best, Thorsten

Well, sort of - in an ideal case, the current is the same in all cables. The problem with "older" or better, less conductive cables, is that they a) act as series resistors in the common line (reducing the voltage and thus current further down) and b) power dissipation in these is higher than in better conducting cables, as the generated electrical power is proportional to the resistance: P = I^2 R. Best, Thorsten

Essentially yes! Sort of, yes: The cables attached to each other in parallel, provided they have "good" contact pins (i.e., they are not significantly corroded, "Kontakt 60" spray is a good choice for cleaning them in addition to wiping them several times after spraying them), do represent one "wire pair" to which all the lamps are attached. The current flowing in this "wire pair" is what they need to handle. When adding one lamp, the current flowing through that lamp adds to the total current flowing in the entire wire pair (I), provided by the power supply. This additional current flowing through that added lamp is determined by its resistance R. The total resistance of all lamps decreases with each lamp added according to: 1/R(total) = 1/R(lamp 1) + 1/R(lamp 2) + ... 1/R(lamp n). The current flowing in such a circuit is I = U/R, where U is the voltage of the supply, in this case 12V. The units are Volt (V) for U, Amperes (A) for I, and Ohm for R. Example: Let us assume, the resistance of a lamp is 100 Ohm (which it is not, just for the sake of clarity). At U = 12V, the current flowing through that one lamp is I = U/R = 12V/100 Ohm = 0.12 A. Putting two lamps in parallel leads to = 1/R = 1/100 Ohm + 1/100 Ohm = 0.02 1/Ohm and this to R = 50 Ohm. So the current doubles: I = 12V/50 Ohm = 0.24 A. For three lamps you get R=33.3 Ohm and I = 0.36 A - so each lamp adds 0.12 A to the total current flowing. There is of course a limit (that I don't know, but could do some rough calculations) to having lamps in parallel on one power supply: a) how much current can the supply deliver and b) how much current can 12V LEGO cables handle before they get "warm". And these are all "ideal case" numbers, the reality may look a bit different, but in this case not that much. Best, Thorsten

Well, each lamp is directly (i.e. via the LEGO cable connection) connected to the transformer; this is usually called they are "connected in parallel". A serial connection would be when transformer output_1 would go to lamp_1_in, lamp_1_out would go to lamp_2_in and so forth and finally lamp_n_out would go to transformer output_2. See for example here: https://www.allaboutcircuits.com/textbook/direct-current/chpt-5/what-are-series-and-parallel-circuits/. You can replace the resistors used in these example with 12V Lego lamps and the battery used with 12V LEGO transformer. All the best, Thorsten

Was that your code or part of it they used? I hope so! All the best, Thorsten

You could ;) but what you want to do is "chaining" them in "parallel" For example only, like this: In principle, you can chain a lot of 12V light bricks that way - it all depends on the 12V P-supply's capability (= how many amperes it can deliver). And of course on the 12V cables (i.e. their resistance, but they are doing quite well in this regard). Just try it out! Best and good luck, Thorsten

Well, you know what? I don't care whether a random bot, a random AI (whoohoo), or simply Google randomly pops in here with an - as it appears - relevant question, at least to some here. I certainly don't learn anything from the OP's question - but I do from educated replies, discussions, ideas, fears, projections, conclusions - from the (I guess) human forum members. Whether an AI learns from this thread - so be it! Google essentially learns from every click I make. Do I care? No, I just use Google. Should they use me, well, that is the game, isn't it - nothing comes for free. And when it seems feasible, I use AI. Use as in: To my research group's benefit. I simply like to engage in discussions relevant to what is actually happening now or may (or not) happen in the future. On a "level" I don't find that often anywhere else in this virtual social world; others may do and also know better places. I don't. Well, I do happen to have other means for such discussions as well - in human worlds. In conclusion: Why should I want to wake up? This is a so conscious and well alert discussion of humans, thanks to the AI's question. Think about it ... Best, Thorsten