Toastie

Good point. Changed the title - better? Best Thorsten

Plus €4,95 for S&H in the EU of course ... should you order 1001 other things they offer (and there are soooo many ), the €4,95 S&H remain €4,95. Best, Thorsten

That is so true. However, I will never understand, why the mix of Technic and System is not appropriate. I mean, I slick super car does not look like having been under machine gun fire with blue bullets still sticking in the metal - they are absolutely smooth on the outside, but totally technical on the inside. Same thing for the typewriter ... full of nifty mechanics on the inside; smooth surfaces on the outside. Even back then, the folks making these things spent a lot of time on giving it a nice hull - rather than screwing together some sheet metal case with lots of extra holes ... after all, such a thing is an office machine. But this is just me. I believe you want to go full Technic because you want it all Technic - and that is totally cool. Best, Thorsten

I'd do the same thing, and yes, the deteriorating process is slow. Months, maybe even years. The "residual" silicone "oil" (when all the lower boiling components have evaporated over time) becomes more or less a grease and in the end plain yuck. Did that once in the past (unfortunately, on many of my 9V switch points) and it ended up badly. Literally "washed" them with ample of petroleum ether, what a mess, but it worked. There may be superior silicon oils out there, but I will never do that again, regardless what the container says. Best, Thorsten

Not when using a mix of 9V and RC rails or 12V rails with some stretch of powered center lines, power pickup, and a bridge rectifier. The LEGO LiPo easily navigates the constantly changing power charging situations. Best, Thorsten

Dear All, I’ve decided to open this thread for creating a repository (for myself). Quite often I struggle to find my own EB content – yes, EB has some search and other nifty features, but for some reason I am not good at using them. I find my stuff usually through a Google search. Well, instead I “collect” links to my threads and sometimes content I share in other threads right here, in one original post. Comments are welcome, of course! Now this can certainly be considered cross-posting, necro-bumping, as well as click-baiting - all in one. It is meant to be none of that, just that: A personal collection. I hope this is OK. Before beginning populating this thread, I shall ask @Milan and @Jim for permission to do so! Have all a very nice day! All the best, Thorsten

That's interesting. I mean, Philo's setup is quite solid - maybe TLG changed the innards of the motors over time? Best, Thorsten

Well, according to Philo's LEGO 9V motor comparison page, they have very similar properties, torque-wise as well as speed-wise. Actually, the PUp-L motor seems to perform a little better than the XL version, particularly with respect to torque, and this is what matters in @Mantarri's case, isn't it? No idea other than for building purposes (more connection points???) why TLG made these two versions. Maybe they found a better motor during PUp production? Did the XL motor come to market earlier than the L motor? Whatever, I'd say the L-motor should do fine in this case. Best, Thorsten

@Gunners TekZone Thank you very much for your kind words! Well, the $$$ situation here is also tight, but more or less due to strict regulations from the higher authorities . Which is OK; otherwise this place would be - well, you know what I mean. I was very lucky to find a few vintage machines (an IBM XT, several Atari's, C64) a little over two years ago in a storage room of my group at the university - the students cleaning out that room for other purposes were ready to dump them ... but then I spotted the beauties and almost fainted. There was so much more wonderful stuff from the 1980's - to the joy of my wife. Well, at home I have an attic, where I am allowed to do what I like to do as long as it does not interfere with normal life in the house . With regard to a DOS emulator: I strongly suggest DOSBox-X. It has been under vigorous development (and still improves with regard to issues, I never ever have heard off, see their wiki and GitHub page, but has reached a stage that is simply incredible. The "-X" is important, as DOSBox is - as far as I read - leaned more towards DOS games, whereas DOSBox-X tries to get as close to vintage hardware as possible: https://dosbox-x.com/ On modern machines, e.g. Win11/64bit, communication with the outside world is via COM (serial) ports; a USB to serial adapter is all you need. It runs as a Win (etc.) application, no re-booting or dual boot or whatever required. The DOS "file system" is just another folder on your computer and behaves as such: Copy/paste files from any location etc. QBASIC is a matter of 1 file (QBASIC.EXE) of 190 kByte length;) plus the 128 kByte long help file QBASIC.HLP. The same holds true for QuickBASIC and so on and so forth. I have TurboPascal and TurboC running, VisualBasic for DOS of course, and all the original LEGO software, other fellows here on EB (particularly @evank) have archived, which is ready to go: https://archive.org/details/@magicratandbarefootgirl Oh well, nothing for the younger generations I believe, but so much fun for the elderly All the best, Thorsten

Happy New Year! How cool is this!!! I am totally in love ... this is the way to go on modern machines! Simply wonderful. Congratulations!!! Well, this is a coincidence, the moment I noticed your update via EB email notification, I uploaded my (crappy as always ;) video on YouTube. Nothing special, just a demo that a DOS computer can handle the Interface B running QBASIC/QuickBASIC from about 3+ decades ago as well, in both direct and program control. This is what drives me: Controlling old hardware with old machines, using old software, because I am old . Here is the link to the BAS file: https://bricksafe.com/files/Toastie/lego-interface-b-9751/Q9751_3.BAS Here is the link to the EXE file: https://bricksafe.com/files/Toastie/lego-interface-b-9751/Q9751_3.EXE They will change over time, but retain the name/link. Here is a (stupid as ever) YouTube video, showing, what you can do (and what not ;) All the best, Thorsten

These two people are one of a kind: They have the vision of getting that speeder up and running again. It will be a lot of work, but it seems to be feasible: The paint seems to be still in good condition; rust and other adverse aging may be less severe as thought upon first inspection! Just imagine, the speeder is put in reverse and slowly moves out of the foliage ... I can so see that ... Thank you very much for sharing, @XG BC, this is a true marvel. All the best, Thorsten

So they sell the app without the hardware? Happy New Year and all the best, Thorsten

Now, this is what I call a Eurobricks 2025 train opener! This train is fantastic - the color alone makes me jump up and down. All these details at 6 wide ... crazy ... crazily nice and so well done. Well, what to expect from a master builder: Only the best. And then the video - 0:46: I don't know, but ... these hands look somehow familiar. Hmmm. 0:17: These look like they would nicely cook on a patio grill as well! The Norwegians know what they are doing with their carriages. And the Chef, wait: ... I don't know, but I have the feeling I know the fella. It seems he travels a lot. Now he is in Norway. I bet he makes really nice black and strong coffee ... Congratulations on a wonderful January 1st 2025 train, Emanuele! All the very best, Thorsten

Just out of curiosity: Why are you using plastic bricks at all for this kind of speed/load? I can see the versatility of building with so many different parts available through many plastic bricks outlets ;) but doesn't that simply stress all pieces above any (plastic) limit? Nevertheless, I love this. I am all mixing together what makes fun Not on this scale, but e.g. electronics wise or when it comes to making enclosures for electronics and so on ... Dremels are my friends I truly enjoy seeing your progress here! All the best, Thorsten

Dear all, as you guys know, I am one of the diehards (along with @alexGS, @evank, @LH4PI, and, well "so and so" many others) actually programming (in contrast to modern coding), uhm, BASIC. Or LOGO. Or AppleSoft BASIC. In my case, QBasic 1.1, QuickBasic 4.5, and yes, I have QBX (QuickBasic 7.1), Visual Basic for DOS etc ... they all use the same GUI, which I am familiar with since 1987 ... VB6 is my Windows programming language, phased out in 2000(?) ... Now that DOSBox-X has evolved into a rock-solid DOS emulator, still under vigorous further development, I am fully back into programming using BASIC. My goal is always to run compiled DOS EXE/COM programs on my 1985 IBM XT (without hard disk, but with GoTek "card" ;) This is just to remind you why an old fart is still posting such crap in this thread, when people like @Bliss are unleashing the full suite of today's coding environments! Which I >highly< appreciate!!! This is the way to go. Simple as that. Nevertheless, I am going to post my QBasic program for 9751 on BrickSafe, as I did for 9750 and Control Center I/II. I am so happy that all these wonders of LEGO electronics are happily listening to a language which was back in the day designed for the masses (me!). Here is just an example of a user program called from within my QBasic program (and this is, what I use to run robots and machines): SUB UserProgramB OutputPower O.A + O.B, 0 UPWaitForAnyKey OutputOn O.A + O.B FOR i% = 0 TO 7 OutputPower O.B, i% Delay .1 NEXT i% UPMessage ("Turn rotation sensor until clicks > 20") ClearCounter 8 DO: LOOP UNTIL IDProc(8, ROTCLICKS) > 20 OutputStop O.A + O.B, O.FLOAT END SUB And you have the full power of QBasic at your fingertips, no mouse required All the best, I am looking forward to what comes up here!!! Thorsten Ha! Hahaha! Same here! It is so much fun, isn't it, when others guide you with their code? As I said in my last post: Bliss simply "showed" me, in his/her code, what to use for doing a stop with float. This is the power of open source. Unfortunately, I am too dumb to do any GitHub stuff (nor is it warranted); as soon as my QBasic/DOS crap is ready to go, I'll post that on BrickSafe. No installation routines, just a plain .BAS program and a compiled .EXE (for DOS!) file All the best and let's kick this thread where it belongs: Top three posts in Technic (...) Thorsten

@Bliss Fantastic work!!! I downloaded your Zip file earlier in the day. The application works very nicely, as @Gunners TekZone has already posted. Very cool. I am really happy that Interface B software gets full up-to-date support (from users of course, TLG can't do that anymore - they are frying other fish ... Furthermore, I looked a bit into your code to finally figure out what was wrong with my stopping the motor using float. They always stopped with break; I simply used a wrong opcode. Thank you very much!!! I also take the freedom of "suggesting" (nothing else!) a little change to your program: What I display in my QBasic program is the last rotation direction, as long as it stays the same. In your approach, the cw/ccw textbox briefly shows 1 then returns swiftly to zero, at least I believe so. Other than that: Nice(!!!) interface. With regard to the interface "looks": I am a bit on the functionality side and would not necessarily change the software form to match with the interface "form". As far as I am concerned, you can unleash the power of interface B only in programming mode. Pointing with the mouse or using hotkeys is fine, but naturally limited to changing the properties of one output at a time. Which is totally OK in manual mode. However, turning 4 outputs on at the same time or clearing rapidly counters is only possible in programming mode. So: I'd leave the interface as is or better orient the layout along programming rather than manual control options. Well, just my 2 cents and personal view! All the best and keep on the good work! Thorsten

Hi Jo, you are right of course, however, this is what I got when attaching my rather powerful regulated power supply to the input ports. At 4.8V, readings maxed out at 1023. There is of course an experimental margin of error; at least with what I am doing, which can be done much better. I am rounding off after the first voltage digit, as this is all what my power supply shows. Then I can turn the voltage dial back and forth a bit; the number on the power supply display stays the same. Also, the reported A/D numbers are not LSB-stable. The wire I used to connect the power supply to the 9V inputs is a 4.5/9V hybrid. The contacts on my interface B box have not yet have had a full deoxidation = reduction clean - the A/D reading depends a bit on how I clip the 9V terminal onto the sensor input, and so on. And then there is this 10kOhm resistor inside #9751 that the external active sensor has to fight. All in all, there will be quite some overall error - students in my lab courses literally love it when I ask them to calculate the error propagation ... Not the point though: With all these errors, everything is still working without glitch: The counters count up/down with no error, even when counting to several hundred and comparing the revolutions. I guess there is quite some tolerance inside #9751 firmware - so my reported values may be still good for orientation. Thanks again for your interest - I really appreciate your comments and checking!!! All the best, Thorsten

How cool is this! Nicely done. So I guess I shall open my Interface B once again! When you pull off the top cover, all the "snap-in" type connectors need to come off. Is it tough to get all of them back on when reassembling? Best, Thorsten

Great work @Gunners TekZone! How did you actually find the faulty resistor? I have some issues with output A of my #9751 box: It turns on for a few seconds when told so, but then goes off again. Turning it off then back on repeats the behavior. All other outputs are fine. Must be something in the driver circuit, I guess? And thank you for your Windows programs, @Bliss! I am currently "stress testing" my Interface B with my own QBasic program running within DOSBox-X. Here is a preliminary screenshot: This program builds on the QBasic interrupt controls ON COM and ON TIMER along with some further interrupt control during text output; the entire screen output is text based and thus rather fast, even when emulating a DOS PC system with a 286 processor running at 25MHz in full QBasic 1.1 interpreter mode. Compiled to a DOS3.3 compatible stand alone EXE using QuickBasic 4.5, which results in a less than 70kByte long file, it runs very smoothly and allows close monitoring of the inputs and outputs, as well as running simple user programs for parallel operation of the outputs etc. As #9751 simply does not know which sensor is attached to any of its inputs, I decided to monitor all available input data (according to the "bit sheet" posted further above). These are the data in the 4th and 5th screen row in the picture above: Either raw data (A/D), transitions (0-1 + 1-0 are counted up) or rotation clicks (counted up/down - 16 per sensor revolution), plus rotation sensor direction (the +/- signs directly right to the data field) and finally sensor open/close. Outputs are all controllable in parallel, for manual control just hit the 1–8 buttons: Toggling means hit once = on, twice = off; press and hold means "as long as you press a button" it is on; used the well known and stone old DOS 0x60 "trick" (access to the keyboard shift register) to get rid of the keyboard delay and repetition hassle: DO DEF SEG = 0 'absolute adresses 0-65535 for PEEK/POKE POKE &H41A, PEEK(&H41C) 'POKE tail byte to head byte of keyboard buffer = clear buffer DEF SEG 'return to default program data segment LOOP WHILE INP(&H60) < 128 'loop until key is released SHIFT + 1–8 reverses the output direction; in manual mode, you can navigate to the corresponding output using the keyboard arrow keys, then hit "+" or "-" to increase/decrease power. The same procedure is used to change the displayed input data format (or the sensor type, but this is irrelevant and just for reminding me, which sensor is attached to any of the 8 inputs). Using this QBasic program, I believe in having found some further information on the behavior of #9751: Outputs: Byte 2 in the 19 byte frame is not providing permanent information of the status of the outputs, but is rather delivering an acknowledgement from #9751: The outputs turned on with a command sent (for either one or more outputs) is acknowledged in the next sent frame as 8-bit coded (output H = bit 7, A= bit 0); the corresponding bit is 1 for each output turned on (regardless of power setting). During arrival of the next frame, all bits are 0 again. Inputs: The rotation sensor thresholds for the "four states" per 1/4 clockwise revolution are 1023/784/354/536 A/D units corresponding to 4.8/3.7/1.7/2.5 Volt. I simply watched the A/D values when slowly turning the rotation sensor axle clockwise and used my A/D counts to voltage diagram also shown above for conversion. On each transition between these values, e.g., from 1023 to 784 = cw, the rotation direction bit4.2 changes accordingly (to 1) and then the increments since last frame (bits 4.0 and 4.1) can be accurately added or subtracted to a software counter. A transition from 536 to 354 results in an immediate rotation direction bit change to 0 = ccw and so on. The rotation direction bit is always "0" for (passive) inputs 1–4. The open/close bit4.3 is behaving a bit more sophisticated than I previously thought: It changes from open (1) to close (0) upon a transition from a higher A/D value to a lower - this seems to be around 200 A/D counts. Similarly, it changes from close to open the other way around. Should this really be the case, I can see why they did that: Transitions on e.g. light sensors can then be monitored with much more flexibility: Expose the sensor a light source considered bright, then make sure that a dark state is about 200 A/D counts below that reference, and you can react accordingly without any programming efforts on the controlling computer side, as #9751 does that for you with bit4.3! All the best, Thorsten

We also miss the various individual cars, locomotives, buildings ... a train theme is so much more than a programmable fancy electronics system consisting of a) a reiteration of freight trains and b) of 1/2 high-speed passenger trains. Entire 1 and 1/2 trains, that is. I have and still have my fun with PUp; but I am getting tired of it ... mostly because in my world of LEGO, true remote control or wireless access is not required. I like to wire a nicely flexible cable to a motor ... It's my personal view/world only. And yes, I get it: Train is a niche theme, PUp can be used across themes, if you don't get it, MOC it, and so on and so forth. Best, Thorsten

You nailed it. Here is to feeling good! Yeah, they were in Germany as well, and I was there - played the vinyl uncountable times. There is so much more "in it" ... All the best, Thorsten

"There are unsmiling faces and bright plastic chains, and a wheel in perpetual motion" ... Who knows, what TLG comes up with - maybe a PUp extension, new cool PUp devices speaking the LWP3 protocol - and maybe something entirely new. They have done it in the past, they will do it again. To improve, of course! There were the 4.5V, 12V, 9V systems. Then came PF and then PUp. Along with all the cool non-compatible plugs and sockets for NXTs and the like. 2 wires, then 4 wires, even 6 ... all these control lines to make them devices smarter than ever. Well, I am about to throwing out all the PF and PUp stuff. It was really a nice experience! Cool functions, lots of things to learn. But actually - in more than 60 years, I actually never fully exploited even the 4.5V system. Recently got myself a Code Pilot controller for next to nothing. This thing understands and speaks the VLL protocol, has 9V sockets and ... sorry, I am telling you guys what you always knew; old fart's nostalgia. TLG is putting up another smoke screen? That seems to be part of their business. So be it. I go full Boomer stuff. "Only used LEGO is good LEGO", says Thomas Panke; I tend to agree more and more. And then: There is BL, eBay, etc. pp.; don't worry, used PUp is good PUp. It will be there for decades. After decades, other decades will come. All the best, Thorsten

Hi Jo, thank you very much for your thoughts!!! Well, I guess I can clarify a few things: Yes, but 130us is the minimum time. I initially thought something "jitters", but that is nonsense: There are 130us sampling and 260us sampling times (i.e. I see on the oscilloscope the trace going from 7.5V to 5V and back with rather sharp slopes for 130/260 us). Need to verify that because I just thought, it is my crappy experiment ... but this is real. I don't know (yet) how often the 130us sampling window width switches to 260us. This is further supported by the frequency reading of the scope: It fluctuated between 230 and 300 Hz for the sampling rate. So 300 Hz is definitely an upper limit, calculated by the scope for tow or more consecutive 130us windows or the like ... again, need to look into that. Yes, I am pretty sure that is the case. However, for the rotation sensor data creation (bit 2 + 1,0), 4 voltages are evaluated; for all other sensors bits 5,4 + 3 are set upon crossing the same threshold voltage (or maybe two; one for 0->1 and one for 1->0 = hysteresis, will find that out using the power supply). EDIT: There definitely is a hysteresis: Bit 3 goes from 1 to 0 (from "open" to "close") much earlier than returning from 0 to 1 (from "close" to "open"). I love QBasic I am still "coding" my QBasic program, but upon some logical ANDing and bit shifting it becomes clearer: When banging a 4.5V touch sensor really hard into the seat (these sensors produce a bold short = are real on/off switches), the on/off bit as well as the #"transitions since last frame" change only once and then again when releasing the switch. Pressing the switch smoothly, everything becomes a bit nervous as ringing sets in: The on/off bit - well - goes on and off and then remains steady; the #transitions count goes up-to 20 and more, depending on how slowly I press. The rotation sensor bits also change, but of course in a meaningless manner. I used a) my multimeter (on DC voltage) directly attached with a custom 9V cable to one of the active sensor inputs and b) my oscilloscope (it is a low-cost type), as I thought the sampling "drop" may cause some lower reading) - again it said 7.5V when not sampling and 2.5V for the sampling voltage drop to 5V. Again, thank you very much! All the best, Thorsten

Hi Lars, thank you very much for your kind words, but this is a collective effort - I am just writing things up, many others have already reported ... in addition to a few things, that may not have been reported, but the net is wide - and so deep ... Best regards, Thorsten

Dear all, more timing and some other data on #9751: A serial port buffer is filled with 8192 bytes in about 9.6 +/- 0.2 s (used my QBasic program and watched for IF LOC(1) > 8191 THEN STOP with a 8192 long serial input buffer, did not read anything, just waited for the program stop along with my cell phone timer. Took a few replicates ... this is absolutely not elegant but quick ... In other words, 8191/19 = 431 19 byte long data frames are emitted in 9.6 s = 45 frames per second. Every 22 ms such a frame arrives. One 19 byte data frame is (see above) 20 ms long. #9751 samples the input ports for 130 us every 3.3 ms (used my very low profile digital oscilloscope). Within 130 us, all 8 inputs of #9751 can be sampled, as the total sampling/conversion time for the microcontroller's ADC is 13 us (as per data sheet). 3.3 ms x 3 = roughly 10 ms are required for a 3 bit increment in the internal "counters" for the light and rotation sensors. During sampling, the input port voltage is 5.0 V (10k internal pull-up resistor, see my last post), the remaining time it is 7.5 V for active sensor "charging". When "shorting" an active input with a 9V lamp, it "glows" a little; "shortening" it with a current meter results in a current of 15.9 mA which is the max. current provided by each input of #9751, as was reported by Mark Bellis for the RCX inputs. That's it for the moment maybe @Bliss, @BrickTronic or anyone else of course may want to check my calculations/assumptions? I tend to screw up such things regulary ... Best, Thorsten