Toastie

100% agreed. It is just that I love BASIC so much. It is the only programming language, I managed to "understand" to the degree of feeling comfortable when using it. Logo simply made me nervous (seeing all these kids on the LEGO books and flyers, happily programming and me not getting it); C or C++ is always a wild ride for me ... pressing "compile" is generally: Close eyes, wait, prepare to open them again and hoping for a "successfully compiled" message ... So in essence, I just chickened out and do what I did for decades ... All the best, Thorsten

@maehw, now that the purists have chimed in (right, @evank and @alexGS? You guys are the best ...) it is time to move backward, didn't TCLogo show up years after BASIC? I have no clue what I need to do in that regard - why not just take it and then do with it what you want! Everything I post is per definition in the true public domain and can be used in every way people like to use it. When J. Pesos comes around and makes a billion dollars using my oh so brilliant ideas - so be it. Good for him, I cannot care less. In contrast, I'd be honored. With that set aside, I shall try to reply to some of your questions: Hmmm - could that be because any output buffer is writing something to the Arduino on startup? In fact, I do not see any such behavior, as I am also sending control words only when I need to, sometimes rapidly (in 9600 baud world) sequentially, or just one in a couple of seconds or minutes. So far, the Arduino never behaved badly ... The 1kHz rate of TCLogo has only two purposes, as far as I understood the code: 1) provide a versatile 1 ms timer by modifying the PIT registers and ISR vectors, and 2) enabling PWM of the outputs. There is no hardware PWM driver electronics inside interface A, every change to the outputs has to come from the inputs. Now, when you set the power for output A to 3 and then turn on output 3, the TCLogo program takes care of generating the PWM signature. It can do that for all 6 outputs; see reference below. And does all the other things, the Logo language can do ... I wrote a little BASIC program mimicking that behavior. It is way too slow, but does illustrate the approach. However, as I don't do any PWM, motors are either permanently turned on/off at any given time. With 1) TCLogo can nicely "count time" or provide frequency information; this is done within TCLogo during each timer interrupt by default (count 1 ms timer ticks). Here is more on that: https://www.eurobricks.com/forum/index.php?/forums/topic/192941-lego-interface-a-97509771-–-lego-technic-control-1-tc1-referenceideas-thread/&do=findComment&comment=3618487 Again, this never happened to me - I used this approach for testing (and just did it again): The Arduino always stupidly replies what I am sending. However, you need to apply a "signal" (GND or VCC) to the two inputs of the Arduino when no interface A is connected, otherwise they may respond to fingertip contact or other noise and then add 128 and/or 64 to your reply byte. When interface A is attached, this is rather unlikely, of course You said it: Serial is async and this way I can sort of "force" synchronization: BASIC writes 6 bit data to the output ports and this is replicated on the outputs of interface A. When these 6 bits are identical to the last 6 bits written, nothing changes on the outputs. Then I am reading all 8 bits back (which are naturally the 6 bit I just wrote as they are latched into 74LS373 of the 9771 card - or in case of the Arduino, into its output latches in addition to - and that is the idea, I get the two input bits (synchronously) back, as I am just waiting for the 1 byte Arduino reply. No reply = something is bad. Again: This never happened to me. Yes, it does: First write 6 bit to the 9771 card, parallel or serial port address, depending on TCLogo version, @alexGS has provided us with, then more or less immediately read back (there are only a couple of machine code instructions in between) 8 bit of data. The result is stored and thus available for TCLogo to a) count incremental ms and b) update sensor status on the same timescale. To be honest, I boldly copied that approach, however in my case for synchronization rather than 1 ms resolution. You don't need that: Just use the Arduino I/O pins: They fully mimic interface A without interface A attached. The latter is just an "amplifier" for the output signals and has some nice circuitry for the inputs. You can safely short the inputs when interface A is attached to the Ardunio for testing; a 4.5V touch sensor is a solid switch - open and close. The 9V touch sensors have an internal resistor of about 500 Ohm when closed (and some had even different resistances for recognition); 4.5V sensors have anything close to 0 Ohm. I do. However, writing 8 bit is a matter of about 1 ms at 9600 baud. And you don't need any buffer monitoring; there is only one byte present at a time at the UART, the most recently sent 6 bit + 2 additional new sensor bits. Of course, you can do it the way you describe - this is what interface B does: It sends out 19 byte frames of data at about 50Hz and your program has to either swallow that or will come up with a buffer overflow. You are right: The good old 8250 UART in the IBM PC/XT only had a 1 byte "buffer" which was simply overwritten, but program languages such as QBasic had interrupt controlled transmit buffers, which are prone to overflowing plus you need some sort of buffer control. Back in the days, that cost time; in modern environments this should be no problem at all, so you can have the Arduino crank out data at any rate you wish. I am just using all these old machines for programming (Sinclair, Atari, C64, TI99, IBM XT) and need to free some time for them to do more than monitoring the inputs :D Hope that helps! All the best, Thorsten

But wait - wasn't your machine an Apple clone? Ha! In the instructions that came with 9771, the LEGO folks are listing a (PC) BASIC program for interface A control To be (correct) or not to be (correct), that is the question. I generally tend to lean towards a little incorrect behavior ... :D Never take me seriously ... You all have fun!!! (so nice to know, that all 5 people are still here, I love it ...) All the best, Thorsten

Almost like 9V PF style CubicMotors from Tenka Best, Thorsten

Hello @maehw, WHAT A FIND!!! Wow. Daniel has so many "things" - it is incredible - and in the right "hands". I love his channel, his attitude, the things he brings across ... just wonderful. With regard to 5 1/4 floppies: My IBM XT has two of those - happy to be at service. Yeah, TLG and copyrights (of software on a medium, 99.X% of all inhabitants of Earth never heard about ... they'll make a fortune off the copyrights, I am sure, they are so smart) - forget it. As said ... Hey, welcome to the club. Just turn "the world" into ... 10 people. It always makes the difference for me. The world ... let them do their thing. I am all 10 people do care world. Or maybe 5. 5 really happy people on this planet make the difference, as they not only freak out for a second or minute, but their enthusiam and appreciation simply persists for a very(!) long time. Yes. Interface A is a (dumb) parallel port device responding to changes on its input lines. It is the LEGO #9771 parallel interface card taking care of things. The #9750 box is a 6 "lines" output "driver" and provides 2 input "lines". You have to read or listen to the 8 bit port (6 bit out latched/mirrored to the 8 bit data bus, and 2 bit as momentary status of the 2 sensors (on or off)). You can always asynchronosly read from and write to #9771 => #9750. I am using QBasic and it does seamlessly work with interface A using that approach. #9750 does not send out any data. It provides a "status" (along with #9771). Nothing overflows, as you are the one asking the port for its status. This is completely different for #9751 (interface B) - here you have to swallow with what the 19 byte data frames are telling you. #9750/#9771 are not responding; they change the 8 bit port signals, and you have to interrogate. The "writing before reading" approach synchronizes the two programs (in my case, DOS/QBasic <-> Arduino), i.e., they are "bolted together": Writing to the Arduino calls for an immediate reply, which I then read in turn into my QBasic program. This way, any programming overhead is essentially eliminated. QBasic is a bit on the slow side. Should the Arduino crank out data with lets say 1ms resolution, then indeed input buffer overflow will happen, as the program does other things as well ;) Well, I am not sure, what you are asking for ... What is happening on a DOS machine running, e.g., TC Logo is: The DOS ISR routines are manipulated such that the timer tick is 1 ms and at that frequency (1kHz) all 6 outputs are continuously (turned on/off) via ISR routines, depending on the software power setting. Thus, outputs do PWM at 125 Hz. Yes. What you need to do is supply +5V to pins 1 and/or 3 of the interface A port. This will then make a transistor inside happy to enable the opto couplers driving the 6 #9750 input data lines. Please feel free to ask more - I am one of the 5 people on this planet interested ... All the best, Thorsten P.S.: My interface A DOS/QBasic control program "Q9771_3" is here: https://bricksafe.com/pages/Toastie/qbasic-programs There is also a brief program description (PDF) as well as the .BAS and .EXE file. The QPWM_5.BAS program just illustrates, how the PWM is done within TCLogo.

System rocks Best, Thorsten

Hi @Bliss, oh wait! Now, this is nice information: I did not read about that anywhere! In other words, the non-zero condition of byte #1 in the 19 byte frame could be used for emergency like behavior, e.g., stop all outputs, right? And byte #2 of the frame is then identical to what they did on interface A: You always have the status of the outputs available. NICE!!! Now interface B is then really a modernized version of interface A: Both have a STOP button (physically stopping of all outputs of interface A and software information delivered in case of interface B - the interface still sends the full frame set of data back at the same speed, regardless of the blinking - I was wondering about that! Thank you for that information!) Both have inputs and outputs accepting different sensors (interface A touch and light/rotation and interface B touch, light, temp, rotation) Both have a permanently activated output for testing (4V on interface A and 9V on interface B) Interface B has of course more inputs and outputs than interface A, but the operational philosophy is essentially the same. With the exception that you always have to ask interface A for its sensor and output status, interface B delievers that information every so many ms. Plus, PWM signals have to be generated by the attached computer using interface A, whereas interface B is providing that on board. I thus changed my COM ISR code accordingly to: - SNIP - IF LOC(1) < 19 THEN RETURN 'record not complete; 2x18 (etc.) works as well IF ASC(INPUT$(1, #1)) <> 0 THEN 'red STOP button pressed once (LED blinks) flag.stop% = 1 'Turn off all outputs ELSE flag.stop% = 0 'resume normal output operation END IF OStatus% = ASC(INPUT$(1, #1)) 'bit encoded HGFEDCBA; 0=off, 1=on - SNIP - Works perfectly well! Again, thank you very much!!! Your post really clarified a lot of things. All the best, Thorsten

Hi @Bliss, very nice description of your work! Thank you very much! I am looking forward to seeing further progress on your side - I love ESPs as well. And they are very good for stand-alone automation tasks! Now, currently I do something similar (interface interface B :D with my rather modern laptop) but I try to make it such that the resulting "code" can run on an IBM XT or Win 98 (and below ;) machines. So my approach is using MS QBasic (1.1) or MS QuickBasic (4.5), the latter just to compile my program to COM/EXE files, the XT loves so much. Basic runs within DOSBox-X (not DOSBox though as a) the former is actively developed and b) runs rock solid as a "simple" Windows(64) app plus provides full and stable access to USB ports which then interface well with interface B). What I found through some multiple hour long stress tests is that there was (so far) no glitch at all regarding the serial link. I thus simply strip the two leading bytes and the last byte of the 19 byte frame. My interface B is also happy with receiving a "stay alive" character (any, as others have said) every three seconds. I just have two "interrupt" handlers: One is ON COM and the other ON TIMER; this then works like a charm for hours. I need to make the handler as fast as possible, as XT's are a bit on the slow side :D, thus it looks a bit weird, I guess. The main DO/LOOP runs "on its own" and just watches the IDproc array to decide what to do. IDproc content changes only when there is something new ... '---------------------------------------------------------------------------- 'Interrupt handlers '---------------------------------------------------------------------------- ComHandler: 'input# raw byte# raw byte pair# ' 1 15+16 7 ' 2 11+12 5 ' 3 7+ 8 3 ' 4 3+ 4 1 ' 5 17+18 8 ' 6 13+14 6 ' 7 9+10 4 ' 8 5+ 6 2 'Resolution of inputs = 10 bit for A/D; rotation sensor is different 'First byte = high 8 bit, bit 7+6 of second byte = low 2 bit IF LOC(1) < 19 THEN RETURN 'record not complete; 2x18 (etc.) work as well r$ = INPUT$(2, #1) 'dump first 2 zeros FOR x% = 1 TO 8 'read 8x2 data bytes and process them IF IStype(x%) = 5 THEN 'rot sensor data treatment 'IDraw(IDindex(%)) = XYZ ELSE 'all other sensor data treatment 'data are read from the head of COM buffer (new%), and stored in the 'respective sensor array data location 1-8, but only if there is a change new% = ASC(INPUT$(1, #1)) * 4 + ASC(INPUT$(1, #1)) / 64 IF new% <> IDraw(IDindex(x%)) THEN 'new<>old flag.new% = 1 ix% = IDindex(x%) 'save interpreter reading time IDraw(ix%) = new% 'store new data (as old) SELECT CASE IStype(x%) 'process data and store in IDproc CASE 1 'A/D - save data as is for display/programming IDproc(ix%) = IDraw(ix%) CASE 2 'TOUCH IF IDraw(ix%) < 1023 THEN IDproc(ix%) = 1 ELSE IDproc(ix%) = 0 END IF CASE 3 'LIGHT currently do nothing CASE 4 'TEMP currently do nothing END SELECT END IF END IF NEXT x% 'checksum check goes here r$ = INPUT$(1, #1) r$ = "" 'Dump checksum or check goes here RETURN KeepAlive: 'Send some char every 2s (official time) 'official value to be sent is &H2(?); any value works; CHR$() not required PRINT #1, 0; RETURN This is all very preliminary, but so far I will use this code to create a small text based "UI" and then come up with some programs for "robotics" or the like. Best, Thorsten

I believe this is the perfect place to post your very nice find (and fix)!!! There is essentially no other forum that fits any better, I believe. Would you know whether these motors also work within the enclosure of 4.5 "Technic" motors? These sell really cheap on EB, but I always lean towards fixing a suffering motor rather than dumping the entire assembly, just because it makes noises. Thank you very much and all the best, Thorsten

Well ... there is no hate, I guess. It is more - train fans are not ... that many. And (not many) x (possible highest train set price ever accepted) does not match their (F1 set price always accepted) x (so many). It is not hate nor rubbing. It is revenue. TLG has departed since long from any "fan" oriented ... which is, in a shark tank, a reasonable strategy for surviving. And making tons of money, of course. The fan oriented love thing only works, when there is no competition ... Best, Thorsten @Lyichir Seconds before my reply, I entirely agree with your assessment.

Aww, come on, flowers are beautiful! May I cite from one of my favorite movies? "Oddball : Why don't you knock it off with them negative waves? Why don't you dig how beautiful it is out here? Why don't you say something righteous and hopeful for a change?" Flowers also sell so much better ... TLG simply surfs the botanical revenue wave - you guys are the motor heads, come on, you like dirt, don't you? You will accept a lill' azure here and there, won't you? And blue pins? Color is ... beautiful. Oh my. Well, I am so happy that now there are >true alternative< companies out there, should TLG go down the toilet someday in the (near) future. I have my act together: Used, old school bricklinked or eBayed parts will more than suffice for me. "Like a true nature's child, we were born, born to be wild We can climb so high, I never wanna die" Rock on, Thorsten

wait, this should be added to the program: ThisReply% = (no-brainer AND LEGO) AND (Ducati AND fans) 'AND = logical and Best, Thorsten

Well - it all went well Just as a summary: Tom's C# exe (LEGOInterfaceB.exe) - runs flawlessly on Win11/64; needs a freshly powered CLI and freshly started LEGOInterfaceB.exe. On a second attempt connecting to the CLI, it says "wrong reply". Power down the CLI and restarting LEGOInterfaceB.exe does the trick. Anders Isaksson's Delphi exe (BrickLab.exe) runs flawlessly on Win11/64. TLG's Control Lab DOS software runs flawlessly within DOSBox-X. My absolute preference What to say, serial ports, particularly RS232, rule. BTW, the CLI has a PCB trace from pin 6 of the 9-pin DSub socket (DSR, data set ready) into the innards of the thing; this is not even mentioned in the corresponding CLI documents. Here, only pins 2, 3 (RX/TX), and 5 (GND) are referenced, as confirmed by many in this thread. I guess TLG wanted to make sure that as many as possible computers recognize that the CLI is always "ready", some hardware may check DSR. The RCX serial IR tower cable + RS232 1:1 gender changer (male/male) work fine. This cable is essentially a null modem cable. GND of the RS232 terminal and GND of the CLI power supply (9V, unregulated DC) are not connected, i.e., there is a complete electrical isolation of computer (RX/TX/GND/DSR) and CLI, as done in Interface A as well. A bit of an overkill, but who knows what teachers such as @JopieK come up with. Or me ... AND YES, I AM JOKING Next up: Testing on my Toshiba 4090 laptop and the IBM XT, the latter will most probably fail: 256 kByte of memory ... ctrlab.exe has become a memory monster - DOS making windows ... in 1993 ... All the best, Thorsten

Thank you very much for writing this up. It was (and still is) a great pleasure to read some passages of your text over again. I sure hope many people have read, are or will be reading your post. I did earlier this morning, then walked the dog, then had three coffees - and still think about your thoughts. I shall write more - I very much appreciate when people share personal deep thoughts on matters of this kind. There may be a "wider perspective" though - or maybe it is only a different view ... I need to assemble all my thoughts on this. By the way, this alone, making me think about complex matters, is something that makes me very happy. So thank you very much again! You wrote you started your "LEGO assembling career" (I bluntly call it that because you also wrote you never "moced", except in Stud.io) in late 2016. And now you are about to donate most of your collection. That is a time span of about 8 years - within a period, TLG makes ever-increasing tons of money by selling 18+ sets, along with these 1 piece per step instructions, resulting in boring cartoon-books rather than instructions; they are made for relaxing rather than thinking. I recently dragged out some older (< 1990) instructions and - well - I had to figure out where to put the 20+ pieces of one step. Which is so much more fun than attaching a "color coded" 2x2 plate to a highlighted place in Step 42 of 666. This alone may render a disassembled set, stashed away in some closet, a pile of plastic bricks. And many of such sets a burden in many regards. I am totally with you. From that perspective, essentially with everything! But let us widen the view of the camera a bit. I turn 63 early next year. I got my first LEGO set for Christmas in 1965. My parents never had the money to buy any larger sets, nor many. When my first LEGO world came to an end, I was 15 years old. At that time, my "collection" of bricks and plates (not sets, these were all atomized - in LEGO world only of course, where the H-atom analogue at that time was a 1x1 round plate) found space in a medium-sized plastic container. And for these 12 years I was "mocing". The necessity to come up with a dedicated word for "building on your own" - or "creating" - is a bit disturbing. But so is "googling", whatever. Languages develop over time. I missed out on Technic. I missed out on early LEGO electronics. Completely. Then, in 1998, shortly after our second daughter was born, I saw the LEGO light again: The RCX programmable brick - along with Technic ... Today, I am "immersed" in brick-built stuff in my home office. I am very lucky to have a wonderful family, an attic for me alone, I am writing this literally surrounded by plastic. Do I feel bad about plastic? Yes and no. Here are many of my own creations as well as display models - the latter mostly not from TLG, other companies can do much better, when it comes to display models. The thing though is: "Creating", "imagination", "construction", "vision", "trying and failing" (there is only one way to "learn": You need to fail and then succeed), "learning" ... this was, was LEGO was about back in the days. This has been said so many times here and elsewhere ... My last purchase of a LEGO set costing >$10 is years ago. MK, BB, Pantasy do get my money for (display) sets - and even this faded away. Today, I buy pieces only. Mainly old LEGO electronics and >old< Technic, the bricks and plates with holes in them . This is my view on the plastic around me. A bit of nostalgia, good memories, and endless hours of thinking and creating. With old LEGO stuff. All the best and make these children happy!!! Thorsten @Mylenium and @MAB: Gentlemen, I just read your posts; I am so thankful of beeing a memeber of this forum. It simply feels good reading such replies.

Heehee - me too! I am seriously colorblind, so all I see in your photograph are three different colors: There seems to be green (top right), gray (right) - and well - some shade of yellow I gave up on identifying any colors other than the "real" black, blue, green, red, yellow, light gray, light bluish gray, dark gray, dark bluish gray, and taataaa "white". The latter comes in a broad variety of "yellowed" states - which simply means: Could be white. I also decided that this makes my life much easier: There are apparently some issues TLG and other companies have with producing stuff with the same color in the same color. I don't believe in these rumors Best, Thorsten

@evank this is going to be >very< exciting! On another thought: Do you have an RS232 (serial) card on your Apple? I guess so - this would mean you can operate the CLI from that machine using Apple BASIC; maybe you have already done so. I am reserving some time between Christmas and New Years for a little coding using QBASIC for my IBM XT operating the CLI ... Best wishes, Thorsten

Hello @maehw, I believe this may be not that successful, but who knows. @evank did the scanning of the book, which, if I recall correctly, was sent to him by Helmut Albrecht, one of the authors. Back then, Helmut was high school teacher and later became Professor at the University of Education, Schwaebisch Gmuend. I have been in contact with Helmut last year and this year, a very nice individual. He tried to find stuff related to TC Controller and LEGO Technic Control in general - to no avail. They had issues with water damage to their building/s etc. Helmut also contacted Herbert Hödl - but again, all TC stuff they had (and that was a lot) seems to be lost. Herbert has retired since long, Helmut retired recently and has a long list of non-LEGO related activities. I then contacted LEGO dacta customer service and told them the entire story with reference to EB etc. They actually replied and told me to be patient, as they wanted to inquire at LEGO Archives in Denmark. Evan and I were particularly interested in the TC Controller software as well as PASCAL code implementation, as discussed in the reference book. TC Controller provides, as the LEGO Interface in combination with #9771 and TC Logo, PWM control. Well, what should I say: TLG decided that it is not possible to release any further information or even software from their archives due to patent and NDA regulations. Wow. That software is from <1990 ... about 35 years ago. And at that point, we "gave up" - if you have more success, please report here! All the best, Thorsten

If anyone, chances are @evank may know ... Best, Thorsten

I completely agree on this. I am in the same boat and used ESP32's and even Vroom boards for far less demanding tasks than yours - programmed using the Arduino IDE or the VS Code IDE with the platformio plugin. This is simply brilliant, @LabManager! Best wishes, Thorsten

Heehee - me too - this very morning! For €80 from a BL seller located in Northern Germany ... we'll see "what" actually arrives He camouflaged the interface as "electric programmable" - never ever expected it there, I mean, it is electric, but not programmable - only to realize that the "Code Pilot Bar Code Sheet, laminated, 2 sided (paper size A3)" is listed in that category as well. I guess I am too narrow-minded Well, I don't like to play with smart devices that much - born a couple of years before the ARPANET was invented, I like to play with 8- or 16-bit machines running QBASIC programs, I love CP/M and MS-DOS <4.0. Well, the programming is much more comfortable on a modern laptop with DOS emulation, but then I copy the programs to the real machines. So if all goes well, I shall code a QBASIC/QuickBASIC program for that beautiful machine ... and then run it on my IBM XT. As that one has no HD installed, the program length is a bit limited, but then 100kByte of compiled QuickBASIC code represents a sheer endless litany of code lines and subroutines This is going to be fun! All the best, Thorsten

Wow, how cool is this!!! Thank you very much for sharing and walking through the installation process, @BatteryPoweredBricks. Also, very nice video! And congratulations to @diegobaca - simply incredible work. I don't have an Interface B - these are for sure excellent pieces of LEGO engineering. Too bad, they forgot how to make such fantastic electronic devices All the best, Thorsten

Welcome to the club @maehw! Your diagram is marvelous - I can't find anything wrong. Thank you for your effort!!! Just recently I though trying the "modern computer link to 9750" with a Bluetooth-2-USB adapter, these HC-05 (or HC-06) thingies. Works like a charm. All you need in addition is an Arduino - this time I used a Pro Mini, which essentially is a Nano without USB port, as the HC-05 does that. I made an ugly socket to connect both - this way I can use them for other things as well. The Pro Mini gets nicely conditioned 9V from #9750; I just soldered two wires +9V and GND to unused pins 2 and 4 of the 20 pin socket of the Interface A - the Pro Mini has a 5V regulator on board and supplies that to the HC-05. The nice thing is: Wherever you place the #9750 box with the BT extension, you can access it from your computer, as the HC-05 just becomes another COM port visible in device manager BT after pairing. Then edit the DOSBox-X config file in the serial section, it all works: More here: https://bricksafe.com/pages/Toastie Will post that in the next weeks along with an updated QBASIC program. All the best and have fun! Thorsten

Lawsuits, the final frontier ... Well, I hope, truly hope, that The LEGO Company, or The LEGO Group, or LEGO, The One and Only, actually rolls out better sets than the competition does. That is all there is. Don't tell me about ethics and costs. Just get - dammit - better. And simply cut the cost saving crap arguments. Should these apply, well then, goodbye. TLG is not a religion, it is a for-profit, totally for profit oriented company. As any company is, in a for profit-oriented world. What a surprise. In this world, lawsuits >sometimes< work. Generally, simply being better, even if otherwise "unlawful" copying is happening, assures success. Just be better. And don't wine so much. Rock on, Thorsten

I know We collaborate with some of the folks making them. This dissolution is nevertheless a somewhat matter of (currently little) concern, as the stuff added dissolves within the battery to presumably - and in my world hopefully - something not causing any harm some years down the road. Or as they call it - in the long run . Well, we'll see ... so far, resurrection of apparently dead LiPos is of central concern in this discussion. Good night and all the best, Thorsten

That is all cool and nice, but this is for "many years storage". Not "6 months not used". However, 6 months without charging it from time to time and having a circuit that is constantly sucking current, well, will drain the LiPo on that timescale. It always depends on the circuit of course. Some need more than others. No idea what the BW sucks, when turned "off". Partial charging (well, better close to full, but not fully full ;) is one good thing to do when storing a LiPo. But the most important thing though is getting it off from any circuitry. In reasonably well-designed devices, actually "inside" reasonably well-designed LiPos, there is always a protection circuit preventing deep discharging, overloading etc. I just arbitrarily visited GitHub for some info: https://github.com/xlfe/conservative-lipo-protection. That's also (very small) electronics usually hidden under some wrapping foil around the otherwise ugly LiPo cells, but once the thing tripped due to deep discharging, you need to know how to resurrect it - and @Zerobricks is at it, I guess Best, Thorsten