Toastie

"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

Dear All, quick update: passive #9751 sensor ports have a bias voltage of 5.0V. This will be the same for powered sensors during the sampling time of the internal A/D converter, as the same touch sensor applied to a passive (yellow) port gives exactly the same reading when pressed, as attached to an active (blue) port In addition, as speculated, the voltage scale of #9751 sensor ports is linear. Used a lab power supply to take some readings: The little deviation around 0V is because my power supply did not like the 5V bias voltage from the sensor port; it showed 0.02 V on its display, but that seems to be off a bit. A 9V lamp attached to the port (acting as "almost" short) gives a reading of 4, so we know a reading of 0 is very close to 0 V. The data point size in the diagram reflects experimental uncertainties. Furthermore, at 0.02 V applied (which is not exactly that, see above, it is a little more), the external power supply sinks 0.48 mA. In this case, the voltage drop across the internal #9750 resistor(s) is 4.98 V (or a little less), assuming the internal resistance of my meter is 0 Ohm, which is also not true. But all that does not matter: Simply taking the numbers as they are yields: R(internal) = U/I = 4.98V/0.48E-3A=10375 Ohm, or 10k, as speculated. Conclusion: #9751 sensor ports behave as RCX sensor ports do. Not that much of a surprise Best, Thorsten

Hi Jo, well, I simply wrongly assumed 2 stop bits, as I said in the little bit sheet. So I have to multiply my (rounded) 135 value with 11/10 = 1.1; this yields 148.5 ... Yeah, I blew it again. This is how I do initialize the COM port in QBASIC: OPEN ComPort$ + ":9600,N,8,1,CD0,CS0,DS0,OP0,RS,TB2048,RB2048" FOR RANDOM AS #1 Guess what, the 1 stands for 1 stop bit ... So I stand correct and will make the changes did change the text and also the bit sheet. Thank you very much for pointing that out!!! All the best, Thorsten

Hi Evan, wonderful video!!! Not only the new product is shown but all the alternatives as well! OK, the original is THE original ... and my favorite is OF COURSE the home brew card. And what the heck is going on with all these blue Technic bricks in the back? (I just got clearance from the higher authority here, to make a BL Xmas order, used stuff, of course ...). I'll get to see all that on Christmas Eve ... Anyway, looking forward to what the secrets are about!!! All the best, Thorsten

Dear all, I just wrote a summary of findings related to the serial data emitted by interface B (#9751), when different sensors are attached to the sensor ports. This is solely meant to be a reference and not any kind of new reporting. There are some minor new results below I did not find anywhere else, but this work is based on all the entries in this thread, as well as on data available on the web. Sensor ports of #9751 Sensor ports 1 – 4 (yellow) are passive analog inputs Sensor ports 5 – 8 (blue) are powered analog inputs; power is supplied, when A/D sampling is not active within #9751. Voltage supplied during powered state: 9V with a 15 mA current source (should the sensor ports of #9751 behave as RCX ports do, see corresponding circuit diagrams for powered RCX inputs here: https://brickshelf.com/cgi-bin/gallery.cgi?i=1067044, author Mark Bellis) The sensor port voltage range is 0 – 5V. Sensor port impedance/resistance is 10 kOhm internally tied to +5V for all sensor ports (when not in power delivery phase), should the sensor ports of #9751 behave as RCX ports do (see corresponding A/D reading vs. applied input port resistance here https://brickshelf.com/cgi-bin/gallery.cgi?i=1088015, author Mark Bellis). Note that the response to resistance change is highly non-linear (logarithmic abscissa scale used in the diagram). When no sensor is attached, the A/D reading “1023” corresponds to 5V. Short-circuiting the sensor port leads to an A/D value of “0” corresponding to 0V. However, the latter is not achievable with 9V touch sensors, as these have an internal resistance > 0 Ohm. There are different versions of touch sensors, in addition, they do age. The resistance of some of my touch sensors is about 500 – 1000 Ohm when tightly pressed. This results in an A/D response between “100” and “200”, which is in full accord with Marc Bellis’ findings for the RCX ports. When an external voltage is supplied to a #9751 sensor port (e.g., by an active sensor or any other suitable voltage source) in the range 0 – 5 V, it needs to have an internal resistance low enough to compete with the +5V/10kOhm internal pull up voltage supply to generate reasonable changes in the A/D converted data. Important: When doing so, pay attention to polarity!!! GND of the external voltage needs to be connected to 0V/GND of the sensor port. When the external voltage supply has a very low resistance (e.g., a laboratory 10A power supply), then the voltage to A/D value response is almost linear. Characteristics of the (serial) sensor data continuously emitted by #9751 The emitted data from #9751 regarding sensor readings are composed of 2 bytes (high byte first, low byte next, denoted as bytes “3” and “4” in the diagram below, corresponding to a 16 bit long word. Generally, there appear to be 2 data “segments” within the 16 bit word: Segment 1: First 10 bits = A/D converted “raw” value of the voltage present at the sensor input port shortly before serial data emission. When no sensor is attached: 5V internal pull up = “1023” = 1111 1111 11 (referenced as bits 3.7-3.0 and 4.7+4.6). Anything attached to a port with either a resistance or a voltage/current power supply in the range 0 – < 5V results in a smaller value. These values are completely independent of sensor used: All touch sensors produce almost the same A/D value returned, regardless of yellow (passive) or blue (powered) sensor port used. Active sensors naturally work only on blue (powered) sensor ports, as they need power (9V/max 16 mA, see above) to provide a voltage/current source at their output. Segment 2: Remaining 6 bits (referenced as bits 4.5 – 4.0) are encoded by the microcontroller of #9751 depending on states and changes or transitions occurring within the several A/D values sampled by the microcontroller between two 19 byte data emission cycles. They also depend on the order these transitions occur. This means changes from/to defined voltage levels are processed. They are done for all 8 inputs. #9751 does not know what type of sensor is attached to which port (I don’t believe is senses anything like “active sensor” or even more specific: “rotation sensor” or “light sensor”). The serial data emitted by #9751 simply need to be interpreted by the program controlling the interface: After several internal sensor “scan(s)”, #9751 always sends out the 10 “raw” A/D bits and the 6 “further processed” bits for each of the 8 sensor ports, in the format 2 bytes + 2x8=16 sensor bytes + 1 checksum byte. Attaching a (passive) touch sensor to an active sensor port does thus lead to rather “confusing” readings regarding bits 4.5 - 4.0: #9751 internally processes the raw A/D values it scanned several times during the period until a next 19 byte data emission cycle occurs. (All following data regarding the rotation sensor are taken from Philo’s website: https://www.philohome.com/sensors/legorot.htm). As an example, when input voltages transition from about 1.3V -> 3.3V, this is evaluated by #9751 as one rotation click (1/16th of a full turn) in clockwise (cw) direction. Thus, bit 4.0 = 1 (one click), 4.1 = 0, and 4.2 = 1 (cw). A rotation sensor always provides these voltage levels. When further transitions (3.3V -> 2.0V, 2.0V -> 4.5V) are detected, they remain (unequivocally) cw and are thus added up to a max. value of 3 (bits 4.0 and 4.1 = 1). This results in a max. resolution of 3 ticks x 50 data emissions/s = 150 ticks/s for rotation sensor counts. Higher rounds per second lead to data loss, as experimentally verified. Furthermore, this suggests that bits 4.0 – 4.2 make only “sense” when a rotation sensor is attached. However, they will also change when a light or touch sensor is attached, but they don’t mean anything valuable as certain light levels (and thus voltage level) transitions will cause arbitrary 4.0 to 4.2 bit changes. That leaves us with the 3 “processed” bits 4.5 – 4.3 for other sensors, i.e., the temperature, touch and light sensors; I believe back in the days (1993 onwards) no other active 9V sensors were available. I did some “bit masking” experiments and so on, and arrived at these conclusions: Temperature sensor: This seems to be a PTC-type sensor; the higher the temperature, the lower the resistance and thus lower the raw data value As there are no fast resistance transitions when the temperature changes, bits 4.5 – 4.0 have no real meaningful values. They do change though upon temperature change. In this context, "fast" is a change between "valid" states during the internal scans, #9751 performs between two serial data emission cycles. Touch sensor: In addition to the raw data value there is another bit, that does yield information: Bit 4.3 is 1 when the sensor is “open” (port LED off, high resistance) and 0 when “closed” (port LED on, low resistance) – and remains as such. In other words: The user control program has only to check this one bit for deciding “touch sensor closed” or “open”. Downside: The internal threshold and hysteresis of #9751 is (yet) not known. But we’ll find out! Secondly: Maybe threshold and hysteresis can be programmed into #9751 – who knows what other commands as reported are available. This needs also close inspection of the #9751 manuals! The RCX allowed such (powerful) manipulations Light sensor: Well, touch sensor behavior must be observed with all other sensors as well. And it does: Bit 4.3 is 1, when the light sensor’s A/D value is regarded by #9751 as “dark” = high resistance; the LED at the sensor port is off. It turns to 0, and remains there, when the A/D value is regarded at “bright”; resistance is low, LED is on. This behavior can be mimicked with a touch sensor, see above. Bits 4.5 and 4.4 represent numbers of transitions from bright to dark and dark to bright since last 19 data byte emission, encoded as 2 bit word (see rotation sensor). There is no direction bit, as the light sensor cannot provide such information. This also works with a touch sensor; however, the internal sensor scan time of the microcontroller inside #9751 is really short; it will certaily detect one "push" and report that (bit 4.4 = 1), but in the next data emission cycle, (most probably) this bit is 0 again, as only transitions are detected. The same holds true for the release transition. With a really "noisy" switch, the on/off jitter should lead to some bit 4.5 and 4.4 changes (e.g. bin 11 = dec 3) when the switch was ringing 3 time in a way that the on/off threshold and off/on threshold was three times crossed and the microcontroller's A/D converter caught that. Fun fact (I just read the microcontrollers data sheet more closely): The Siemens SAB 80C515 chip used as brain inside #9751 (an 8-bit CMOS microcontroller with factory mask-programmable ROM), features an 8-bit A/D converter with 8 multiplexed inputs - but wait - reports 10 bit A/D converted values. Huh??? Well, the A/D converter has programmable internal reference voltages; as far as I understand the data sheet, if a higher resolution than 8 bit is wanted, the thing makes a dual scan, first coarse and then, with adjusted reference voltages, a more precise scan in a narrowed voltage range. OK, maybe it is like that, I am not sure . But wait there is more, there always is, we’ll see … tonight a shall break out my lab power supply (yes, it is a power supply I will be snatching from the lab ) and see whether my "linear 0 - 5V scale" claim is true or not. Will report back here. Here is the updated little bit diagram for #9751 data traffic: All the best, Thorsten

@Bliss You are not alone I am also testing. Managed to get a QBasic program up and running, "servicing" all inputs and outputs (i.e., not only manual control, but full program control, e.g. setting the power of n outputs in parallel to on/off and all the other things). As far as I am sampling input data (19 byte@9600 baud), the rotation sensor is responding (naturally) with the lowest rate; counts swiftly "lose it" when rotating too fast. On the other hand, the rotation sensor bits 4.0 - 4.2 give you the direction and incremental count (max. 3 per 19 byte data frame sent + internal conversion rate). However, individual light or simple A/D conversion bits can change at the full 19 byte@9600 baud transmission rate, with no further internal conversion in the way. These bit changes are thus much faster reported than the 1/16th rotation increments. This also reflects the behavior of interface A, which just provided the digital level (bit) at its sensor ports; no direction provided, just the light/no light state, and the program had to sample these changes. More research underway, using your bit resolved information! Best wishes, Thorsten

Stream of pictures here (Firefox)

@Bliss Thank you very much for all these findings!!! I am particularly happy that the light sensor signal is A/D converted in the same way as the non-powered sensors. With these new findings, interface B's behavior is more and more like that of the RCX - which is, as far as I am concerned, the "follow-up" control device. On the RCX the threshold values (on, off, hysteresis) for sensors can be user defined/calibrated, which is extremely helpful. Very nice research results! All the best, Thorsten

Welcome to 7 wide train world The 6-wide scale is cool, the 7 wide (and yes, there is more, there always is) scale, is looking so much better (as far as >I< am concerned) would surely benefit. You don't, I do, but what the heck: So it is. We can build odd with even plates and pieces ... and we have the 1x1 and 1x3, even 2x3 plates. Best, Thorsten

@allanp Wow. I feel ... silence ... after reading your post - or better - your wonderful, powerful speech! I wish you were invited to a Billund dinner type event, with scheduled brief talks (not presentations) on "How does TLG do with Technic". You had to submit an abstract for your talk - it was a little vague - yes there would be some criticism, the reviewers said, but in the end, TLG would stand out, as they are the ones, who invented it. And then your speech takes off - in the end, you are jumping on a table close to the big guys: "Sorry, I am - NOT convinced". I am absolutely >not< joking or mocking. I truly believe that this kind of input would at least cause - silence and induce thinking. Whatever the outcome would be. I am not sure that they get this outstanding type of enthusiasm anymore. Thank you very much for sharing your thoughts - I enjoyed every word you wrote! Best regards, Thorsten

Does very well fit in (this is some heavy data bombarding, but scroll down to the customer's ages ;) summary the boomers (that's me!) - OK and then the coming folks - rock https://www.coolest-gadgets.com/lego-statistics/ And yes, this is just ONE website - but the data they show are partly from statista.com; and that site sucks (sometimes), as they (naturally) want you to pay for the interesting stuff ;) Oops, wait: Aluminum hat off . Best, Thorsten

And Alex S. pushed me so much during my "awakening" with regard to TC - and then Evan simply pushed me through ... these are all extremely nice and helpful guys. And there are more (there always are) of course ... As I said @maehw, "this particular" world is small, but one that I never want to leave ... Best wishes to you all Thorsten

Hmmm. We are opening Pandora's box, don't we? A couple of more discussion topics: Why do most many companies do their mass production in China? How large is the brain pool "they" can tap in? Or phrased differently: How many people are (still - China is of course "evolving", if not "there") willing to come up with brilliant technical solutions - for a toy? How "hungry" are people to thrive towards certain goals for a - let's call it still limited - salary? What else are these companies doing compared to what TLG does with regard to other activities? I have >no< clue. But when it comes to China, they literally kick butt everywhere. Not meant in a "positive" nor "negative" sense, just as an as cool as possible analysis (for me) of observations. They push every high-tech company on the other side of their world to their limits. Why not doing so in plastic brick fabrication? I am still thinking about your argument ... thank you for bringing it up! All the best, Thorsten

You nailed it And with them, because they make me happy and you guys as well! Have a nice evening! Best, Thorsten

Well, first, in a discussion like this, any viewpoint, assessment, perspective, argument, etc., is by definition a true personal thing. I as virtually all others here, don't know anything about what TLG does and why. Nothing. If my phrasing sounds like I am a TLG representative, then I am sorry, and I need to change that. I am one individual with personal opinions. What I like to do is throwing in such opinions, and I am generally waiting for flak from all sides. Call it criticism - or whatever the result of a discussion is. No one is explaining anything, it is a discussion. And a discussion literally lives through exchanging arguments. Should these sound offensive, OK, then I should begin each paragraph with "In my personal opinion", "after I thought about this", "may be", "... or not". I don't see that often here on EB, though, and secondly, for me this is the default. Hey, and if a TLG representative would bring some of my arguments, I'd simply faint. Summing up: Please accept my apologies for sounding like a smart a*s - I shall try better! All the best and here is to feeling good Thorsten

Money? It is costly to have smart designers think about smart things for a tiny fraction of TLG's total buyers crowd. And then the box art designers, the storage facilities or on demand pipe-lines, etc. etc. Just assume TLG has these consumer data: These four set do sell well. In parallel. In that case, I believe there will be more such cars on sale in parallel, as long as they sell. If one or more eventually underperform, out with them. That is the question - on a larger (global) scale, I doubt that. Otherwise, they would simply do it. Also, "plenty" is may be not enough, maybe they want the maximum possible. Maybe it is OK nowadays that it shows you "sort of" how it works - or even just pretends to show you how it works? When people buy such stuff at large - so be it ... I know this sounds all frustrating, but it should not: These (many!) people are happy. And (presumably very) few are not. What would you do in such a situation: Listen to the few? Crank out extra money to make the few happy? Yes, some would do, but not for long - one tough competitor and gone is the charity ... Best, Thorsten

But that is the thing: "True" Technic = "technic a couple of true technic nerds like" has migrated into "Display Technic" because TLG's decade long analyses have shown: Print "Technic" on the box, get rid of functional but "ugly" studs, use "premium" stuff licenses all over the place, make it big, adjust the mental effort of building it, and boom, the niche theme Technic sells. To the extent that more and more sets designed along these lines sell even better. Which simply mirrors (not causes) the changing Technic audience. If TLG had to compensate for their increasing operational costs (competition means more effort) by selling nerdy, functional machines - they'd pay a lot extra, as the numbers of "true LEGO technicians" has become so small, that on a logarithmic scale of 1 to 1E10 this number hardly shows up Arguing from a pure marketing perspective: Why pay extra for a smaller and smaller audience = market, when a much larger audience happily buys Technic display models? And as it seems, so far, regardless of price tag (not true: this is of course - and every serious company does that - carefully monitored as well: Test ballooning here and there, waiting for the market data, adjust accordingly. TLG has more than 6 decades of data at hand). Best regards, Thorsten

May I change the last three of your words to "some - actually rather few compared to TLG's audience - brilliant MOCers do". That is not only totally OK, I wish I could do that as well! Yeah, sometimes people with sufficient funds available for a hobby tend to overlook that aspect. Again, I wish I were in the same position, but so be it. I don't know about "changing populations" ... or "for looks", or "for functions" ... As others have posted: I do perceive the "Technic change" as 100% revenue/profit driven. Particularly in a world that - for TLG - has changed much more than any population has: Over the past decades of their 60+ years of selling their plastic product (yes, there are so many more system pieces, but they originate from the exact same idea and are made more or less in the same way), tough competition has build-up. Such a situation usually calls for changing gears. I believe TLG is simply targeting - or phrasing more politely - has identified, through decades of market analyses with ever-increasing powerful algorithms, a group of people, that are willing to spend >a lot< of money for just that: display models. The bigger, the better - for the same reason: maximizing profit. The larger the sets become the less suitable is System, which of course has in addition the 1960's touch to it, and throwing in just another gearbox is hardly possible. So even in this ("Technic") niche TLG can make some money, as apparently rich people, loving the expensive brands, who may not own a real Ferrari but now have a Ferrarili - with real technic inside! - on the wall, maybe tightly sealed in an equally expensive transparent case to save the Ferrarili from collecting dust. Once again: that is totally OK with me. I am happy when people are happy. But why not renaming "Technic" to "Model Team"? Well, "model" and "mold" are not that far away - "technic" sells better. I don't see any "degradation" in Technic - I just see how the plastic toy market evolves under changing conditions. And that is why I 100% revert to Technic with studs. The pieces are ubiquitously available for comparably "good" money, have the 1960 moldy touch to it (I am old). No new TLG sets >$10 for me anymore. I am still very happy though! All the best and have a nice day (or night ;) Thorsten

Hi Jo, been there; Anders' Delphi code (version 3, but version 1 is doing the same regarding sensor reading) as well as the information he lists on that page from 1994 (Newsgroups:rec.toys.lego, Andy Carol). However, on Tom's LGauge page (https://www.lgauge.com/technic/LEGOInterfaceB/9751.htm) there is a table that lists for the light sensor a different protocol (12 rightmost bits of a 2-byte sensor word = light data). But just looking at the non-used bits in the protocol I put into semi-graphical format above, I thought this could very well be. But I don't get it to work that way ... But thank you for your help! All the best, Thorsten P.S.: I am in touch with Tom; he said he will take a look into his C# code again, when he finds time - this is all so long ago. It could also be that there are different versions of interface B out there.

And after the mechanical treatment as described above (I am also a guy), I do a little "Kontakt 60" spray treatment to both, pin and socket, using a Q-tip swab (not directly spraying the contacts, just into the cap of the spray can and then soaking the cotton tip). Never use WD40! (https://www.reichelt.de/kontaktspray-kontakt-60-100-ml-oxid-und-sulfidloesend-kontakt-2010-p9462.html) Best, Thorsten

Dear LEGO interface B enthusiasts As said in a post above, I am playing with the interface B hooked up to DOS/QBasic or QuickBasic either on my laptop within DOSBox-X or on true DOS machines (Toshiba Satellite 4090 or IBM XT). So far all is good - on all machines the QBasic code runs flawlessly. However, I am a bit confused regarding the serial protocol, i.e., the information stored in the 19 byte data frames, #9751 cranks out at about 50 Hz. Or more precise: There seems to be contradictory information on the web ... Question is the following correct/complete? Does anybody have further information? I have a hard time believing that the white (=unused) bits are exactly that: Not used bits in the protocol. Byte #1 could be some sort of start byte with 6 zero bits leading but hey ... also, in byte 4 (6, 8, ...) bits 5-3 are not used OR there is more. For example, there is some information out there that the light sensor is sampled with 12 bit resolution (rightmost 12 bits) but that gives confusing results on my side. In addition, how should the hardware of interface B know which sensor is attached? Sure, I can tell my software which one it is, but the interface hardware does not, or does it? I can put a touch sensor on a blue powered or a yellow non-powered input: Same result. A light sensor needs power, so does not work on yellow inputs but on blue of course. Am I missing something, or is this "it"? As said, I am happy with that, but just want to make sure I don't drop data. Secondly: The A/D converted 4 voltage levels of the rotation sensor (depending on its internal rotor blade positions, see here: https://philohome.com/sensors/legorot.htm) are converted to the three lower bits of the second byte (of each powered = blue input); bit 2=direction of rotation, bits 1 and 0=number of rotation ticks since last frame was sent. 16 ticks=one full 360° turn. The other bits naturally don't mean much, as they represent the last analog value reafd from the rotation sensor. With two bits, the max. "changed ticks number" is 3. When we assume that the 19 byte frame repetition rate is 50 Hz = 50 s-1 (I read that somewhere ...) then the max. full 360° rounds per second of a rotation sensor that can be resolved are: 3*50/16 = 9 s-1 in other words about 10 Hz. Which is not that much, I must say; interface A does much better! OK, but does not know the direction of rotation. Is this what others observe as well? Thanks a lot in advance! Best regards, Thorsten

Easy: We make it - let's say 1 pm German time - that is 1 am in NZ and 7 am in New Jersey (I believe) - where is the problem? Best, Thorsten