Toastie

I don't know whether or not this is of any interest in this context: My BLEClient (VB6) crashes when I press the power button on the handheld (only the handheld) when connected. No subscriptions, just a connection. But this may be just my very own problem. On the other hand, only the handheld's power button does that. Best, Thorsten

I think you can make them even smaller in footprint/minimize parts used - can't tell from the "photograph" (did not watch the video yet): A while ago, I shared this link; it contains a number of similar drives using different motors. There are 4 png graphics files with the mpd's. The design principle (using 3 technic axles on two 1x4 technic bricks (with 3 holes) to confine the rotation angle) is an ingenious design by Ben Coifman. It was shown in RailBricks issue 9 as Reverse Engineering Challenge and revealed in issue 12. I just played with the design, reducing the brick count. There are >30 on my layout. Driven by PF, technic varieties, and MicroScout motors. Best Thorsten

Yes, I can see that. I don't hear anything from TLG other than what is officially available and even there I am not well informed. Maybe I should thus be a little more careful when phrasing things However (there is always a however when it starts like this, isn't there?), what happened to plain vanilla "thinking"? Just plain, straight thinking? When wanting to create a PF reversing loop, you have to be at least a little creative. It's not that easy to do. You also need quite some components. And then: When the stuff breaks, you broke it. It is your fault. What happend to that line of thinking? I fried 9V switch point(s) myself - easily done with a reversing loop. It said on the instructions: >>>DON'T<<< do it. Then instructions may get lost or "thinking" evaporates into nowhere and then you literally can see the meltdown on the point. But: I was thinking: You (as in "me" and not "you") >idiot<. I never thought: This is all TLG's fault. It was mine. Oh well, times change, I know. And I can surely see what you are saying. In 1980 there were two 12V train plugs for "the kids" - and most of them (including me) didn't blow 12V stuff to heaven although it was much easier with the 12V/2A power supply back then. But yes: Today is today and not 1980. This is interesting though. When any 9V power supply can create shocks it is not a 9V power supply anymore. The safe rating for not getting DC voltage shocks goes up to 42V. So maybe the power supply was faulty. But then: We can start suing TLG when they sell power supplies, e.g. for recharging: They may break. The chances are next to nothing, but the nothing is not zero. Thus, when they want to be on the safe side: Batteries only. But even then: Batteries may start to leak. When you swallow the amount of leaked stuff from lets say 1 PuP hub and 1 PuP remote (=10) batteries, its gonna be nasty. So better no batteries in PuP stuff. Which means no PuP stuff. I know. This is not funny. It is meant to read funny (but it is not). I do really see what you are saying. Everyday when I wake up I just am wondering, why did I survive the years I was a kid. Best wishes, Thorsten

@Mr Hobbles: Even that does not work on any of my four hubs. The notification reply is: [0x05, 0x00, 0x05, 0x81, 0x06] Does that mean anything to you? Thanks and best regards, Thorsten

That is very exciting. Particularly because it does not create that significant amount of BLE traffic. Looking forward to read your updated document! Well - as Mr Hobbles said: The LWP documentation does not document all the commands very well. the 0x60 command isn't even mentioned. Same here. My Hubs No. 4 don't do anything when using the "advanced" LWP protocol message byte coding (I believe). I am using the MS Bluetooth Explorer for that, which does a fairly good job (at least I believe) ... All the best, Thorsten

@Mr Hobbles: Thank you very very much! I was rather frustrated when I could sort of handle the properties of the characteristic using the LPW document but virtually none of the output messages. May I ask one more question: In @Cosmik42's software, upon releasing the power slider, the train motor(s) begin to accelerate for a certain amount of time and the slowly reach the final power setting. It appears as if this is what the LWP section 3.27.3. "Output Sub Command - SetAccTime (Time, ProfileNo) [0x05]" and section 3.27.4. "Output Sub Command - SetDecTime (Time, ProfileNo) [0x06]". This is a very nice feature particularly for trains. Is that implemented in the Hub. No4 as well? Or is a rapid succession of plain [0x60] messages from the client required to do that? Thanks a lot in advance! Best regards, Thorsten

I really do see and share your point. It is/was/will be my criticism regarding TLGs >support< (and not the actual release) of electronic hardware. Not the brick stuff. I am 57 years old. I do have (OK refurbished but still with original parts - almost all) my first train set form 1965 on a shelf. Bricks from 2019 attach to the bricks from 1965. This is incredible and almost unprecedented in the world we are living in. So TLG achieved something that no other profit driven (toy) company has, as far as I know. There are AEG ovens and Bauknecht washing machines (I am German) and all have become Whirlpool devices - but they still do run and they are supported. It is a pain in the butt to get support, but in the end it works out. When you are >persistent< and call them again and again. In the world of electronics things are a little different. But: I still can order 74XX chips, when I try really hard. I may even have to salvage old stuff (believe it or not, we tore down a mass spec from 2001 today - was worth 0.5 Mio back then - and I found tons of 74XX chips inside. On sockets - so these will find their way in to my drawers. And believe me, my grad students believe that I am from another world - and old world). What I want to say is: TLG produced extremely well designed and powerful electronic devices over the decades. Code Pilot, the RCX (1998), Scout, MicroScout, NXT, EV3, Boost, PuP (PF2) stuff … And: When you try really hard - THAT IS THE BAD PART (TLG DO YOU HEAR ME?) - you can all of this stuff get to work. It is up to you though. I have said it before here on EB: I am a VB6 totally amateur programmer. VB - Oh my God 6. It was officially depreciated by MS in 2002. Give or take a couple of years. But: It still works. Was a lot of work, but it works. And it works with the new BLE stuff from TLG. It is not about a stupid handheld or even more stupid App TLG gives us. It s about finding out how it works, take steps to conserve that functionality and make it sustainable. What I find so … no words here … that the "community" and individuals have to do that. TLG is sailing on - they will come up with something even more sophisticated any time soon. Simply to cash in. They will put incompatible connectors onto these devices. Simply to cash in. It is all about money. Within all that money world though they can hire smart people. Endless numbers of smart people. The PuP BLE stuff >is< cool. Really. But you need to discover that yourself. Because TLG in all their glory and arrogance don't do that for and with us. They release a cryptic document here and there - and then tech-gurus know how to read it - and share that knowledge. And that is the difference: They do, here on EB and elsewhere. So, in conclusion: I would like to join @andythenorth's challenge and throw in another €50 (chances are that I may not make it till then …): Yes, when you really want, BLE will be in you world then. All the best, Thorsten

Dear all, I need a little help in further understanding the BLE protocol stuff. What I did so far was using @treczoks documentation (which is my preferred reference) for getting access to the PuP Hub/Handheld. In first instance I am using the "Bluetooth LE Explorer" "App" from the MS store - it comes for free. Works very well. After connecting and discovery etc. and having access to the "00001624 -1212-EFDE-1623-785FEABCD123" characteristic I writing the value: 0A 00 81 00 00 which is the first "fixed length part" as referenced in the official LWP 3.0 documentation. These bytes mean: (1) Message length (0x0A) - (2) as of now always 0x00 (3) Port Putput Command (0x81) - (4) I/O port - (5) startup and completion byte (encoded as bit field ssss cccc = 0000 0000 for "buffer as necessary" and "no action"). So far all is well. But then @treczoks states: (byte 6) "Always 60, like the 51 for the RGB LEDs. If you change this, the command will not be executed." And that is true. Regardless of what I tried: 60 or nothing happens. Nowhere in the LWP 3.0 documentation "60" appears as any valid op-code or the like. Further, the sequence following "60", which is: (7) 00 (?) - (8) Speed byte (I understood the encoding) - (9) ?? and (10) ?? need to be there or nothing happens. In total the byte message "0A 00 81 00 00 60 00 XX 00 00" sets the motor on port A to power XX. That is cool. But why??? When following step by step the LWP 3.0 document this isn't even implemented??? Also: There is this "51" subcommand that works on he handheld but apparently not at all on the hub. I know that I am not comprehending what is going on. @Cosmik42's software uses the "3.27.3. Output Sub Command - SetAccTime (Time, ProfileNo) [0x05]" (right? the motors smoothly accelerate to the final power setting in your software - is this the mode you are using?) But without the (undocumented) 0x60 byte#6 I am not getting anywhere. Any help is appreciated! Best Thorsten

Sorry - the handle part is handled by my client control (It "discovers" the handles and assigns "IDs" for it - these contain the 000b and 000e part as well … did not know that these were handles. As said, I guess they made this contrl for dummies) But: Nice that is works! Best Thorsten

@MajorAlvega: And this is all what counts, isn't. I like this attitude the most. It is my way of thinking with regard to Life, the Universe, and Everything. All the best and have a very nice day! Thosten

Yes, I can see that! And I believe that. Just because we had a serious and lively discussion about "OS total failures" in my group (there are a few hardcore programmers - mention Microsoft, and it begins - the volcano eruption type of discussion …). I like to trigger that from time to time, just for fun. It >always< works. The ActiveX BLE control for VB6 I am using (from /n_software) does behave very, very nicely though. I do only own 4 real "Hub No.4" and one remote. The control (implemented as control array in my VB6 programs), i.e. a dedicated instance for each Hub/Handset/BLE server, works like a charm. Just for fun I extended the control array to 50 and told BLEClient(50) to connect to one of the hubs (by letting BLEClient(0) scan for mac addresses, let it catch the one for this hub and then pass this info to client #50). At least it appears as if the Win10/64 bit OS along with this ActiveX control for VB6 does do a decent job. It may also be that with more than 5 BLE servers actually present (and not just the control array producing the 50 instances) that this all goes belly up. So far though, things are looking very good - despite the fact that this is all Microsoft stuff. @Cosmik42 is doing his superb programming in C# … and his software is beyond believe, IMHO. I cannot imagine how much traffic his software produces - and it simply works. Have my copy of his software here for sure, learning from that as much as I can. So. I have to admit: I do like Microsoft stuff. Which puts me into a bad position, I know. Never really learned anything else - because there was no need. Did CP/M and MP/M in the 80's, Unix/5 in the 90's, played with Z80's and 80XX families on machine code level, loved the Sinclair ZX81/Spectrum "computers" (I still have them - but the analog TV sets are dying out …) and then came Win3.11 onto my radar screen. And Word and Excel (and all this horror software, I know) in the late 90's. I am still using it today. Since 20 years … and now they gave me an ActiveX control for VB6 and I just drift on through programming heaven … before December 2018 I did not know that BLE even exists. As of today, 4 BLE Hubs automatically connect to my VB6 train control program, which is additionally handling 10 PF, RC, and RCX controlled trains, and 30 switch points. And this is Microsoft Windows crap. No that bad, I'd say. Why did I write up all this? Don't even know. Maybe it was todays discussion. I am not affiliated with Microsoft at all. None. I am a chemist All the best Thorsten

Oh I see! Thank you very much. Now, would it be than OK to not crank out the posted requests at highest possible speed but in a more controlled manner? For example, it does not make sense to change the power setting within ms as the device (lets say a hub) propelling e.g. train did not even have the chance to accelerate the vehicle to the new setting. I am just curious about the overhead traffic generated with acknowledgements - this has to be somehow handled in the BLE stack/dongle whatever, right? Best Thorsten

Hi @Lok24 again - I don't want to be the smart guy here - others will know much better!!! Although I did not run into the exact same problem to the extent that things fried up, the response to violently sliding a VB6 slider control from min to max value became rather slow, when having 4 hubs connected and doing that swiftly on all 4 hubs. With one hub connected, it was all good. What alleviated the situation a lot was a) telling my BLE client to minimize logging to the minimum amount (basically none) and b) using the "post" instead of the "write" method. Writing means - as far as I understood - that the server is transparently acknowledging each write. You can actually see that when logging is turned on: Each successful "write" is throwing the log message event "successfully wrote to characteristic …". Posting to a characteristic just sends out the request to the server and that's it. So when you generate a lot of bidirectional traffic, all the overhead may slow down things to the extent of freezing??? Dunno could be, could also be garbage. When you want to keep track of these swiftly repeated power changes (0.2 s = 5/s), you could post these and then explicitly ask the server after lets say every 2 seconds, whether things are OK or not. Oh well - just began to understand a couple of things and I am already doing as if I would by a wise guy … which is not the case at all. All the best and good luck! Thorsten

@Lok24 As said before: I am a total amateur, just beginning to get my head around BLE communication in general and LEGO BLE protocol in particular. And well - this is running on 18 years old VB6 as you know. What worked for me was write to the only characteristic relevant for Hub specific things: "0x04 0x00 0x02 0x01". The first three bytes are comprising the "common message header" (cf. section 3.1 of the official LEGO BLE protocol documentation) (1) length of message in #bytes when it is shorter than 127 bytes in total, here = 0x04 bytes (2) always 0x00 (may change in future releases), (3) Message Type, which is here of type "hub action" = 0x02 and then the actual action (cf. section 3.6.2) "switch off hub" = 0x01 Is that what you were asking for? Best Thorsten

That is making me feel so much better - if QuickBasic would still be around and knowing how to get through to the hardware, I'd use that … and I always thought that I am alone in world of power programmers. Very nice!!! Best Thorsten

The idea: Brilliant! The rendition: Brilliant! The photograph (or is it a render? Nowadays I can't tell anymore) - I believe it is a photograph - brilliant! Ann they all laugh … cool. Best Thorsten

And >that< is the limitation ... The LEGO BLE protocol allows to do so many things software-wise. @Cosmik42's software allows you to do so many things without changing hardware! Yes, when you want to use the LEGO BLE remote: This is the way to go. Very nice and clean hardware solution. In case you don't want to knife-in to the hardware: TLG has built it into the LEGO BLE protocol! Let @Cosmik42 know and I am sure he finds a solution. I have my own BLE Client software (running on VB6, don't laugh) and yes it is possible. All the best Thorsten

Yes. And yes again. Very nicely phrased @Redimus! Best Thorsten

Yes, better be careful! But: "... we want to keep you around": I believe this is phrased a little from the top. I believe that @Cosmik42 is making a true change here. So many folks (including me!) have tried to get around the limitations of 4.5V/9V/12V/RC/PF. Arduinos everywhere, 4DBrix WiFi, SBricks, BuBizz, and so on and so forth. Documenting that we were in desparate search for custom solutions. Now all of a sudden - and believe me, I am sure that TLG did >not< foresee that, @Cosmik42's software makes a >complete< difference. For one, there is this "turn-on-server - client recognizes it" thing, evaluating who is there and what can be accomplished. For two there is a full blown custom programming environment. We as a group together would be encouraged, happy, promoted, proud, if @Cosmik42 continues to drive this forward. Because he >is< we. It makes a very big difference to me. And: TLG better pays very, very close attention to this. Not the f*ing legal department. No. The innovation and future development department. I hope they copy. As for a name of the software: How about "The PF2 Software Integration Project"? I' d say >proudly< leave out the TLG Logo/Name/Legal fuss. Everyone interested will know what is going on. All the best, Thorsten

Dear all, oh yes - I believe @Cosmik42 can add virtually every BT/BLE device to the list of devices supported by his fantastic software. What I would like to suggest: Where are we heading with all this? Get a million of devices supported and then what? @Lok24 is full into autonomic workflows; in contrast, a device with a zillion control buttons wants to interact directly with the BLD devices. Or with workflows. As of now all BLE servers can talk to the client, the client does all the work and the serves do just that: Serve. Is there a plan or is this just going ballistic? It is fine with me when a software can do it all, but then it may quickly become cumbersome to work with it, depending on your personal needs. Oh well, just my 2 cents. All the best, Thorsten

Very, very nice! On another thought: When the EV3 PBrick is "just" reading color sensors - then a PuP Hub, connected to @Cosmik42's software (see TrainTech Forum) should do the same, right? Because then the size of the train could be >much< smaller. When the EV3 does other more autonomous things, than that will of course not work. All the best, Thorsten

Same here, BrickLink has the 2-port hubs (and ample of them) for less than $20. Best Thorsten

Now we are talking business. Simply because this means integration of really >intelligent< bricks. That is my world - as in "distributed intelligence" So far the whole BLE stuff means to me: Report to the client and the client tells the server what to do. OK, WeDo hubs may be different, I have not the faintest idea, I don't have one, but only stupid "Hubs No.4". So there is a furious amount of wireless traffic to do "the works". This is very nice, but not how things work today: There is mostly at least a bit of intelligence in the servers. If not an unbelievable amount. With an EV3, NXT, or RCX - a lot. Sure, the RCX is nothing compared to the EV3, but so much better than any Hub.No4. And: BT integrations of EV3 is fine - but then NXT should be in reach as well! Both are talking plain vanilla BT over serial protocol, right? I know that the EV3 is the latest and hottest in Mindstorms, but just because of that it means next to >nothing< to me. I'll get one anytime soon, (just to have them all - the LEGO PBricks that is). The NXT though talks to a HiTechnic (formerly fully TLG supported) IR Link "sensor". That in turn talks the RC Train, PF, and RCX protocol. In other words, the moment an NXT is supported, you can control all your PF and RC trains as well. There is one downside: The IR link range is 50 cm or so. However: Here I described how to mod original PF-IR into PF-RF. The latter is very simple OOK direct 1:1 IR protocol translation. Runs on 433 MHz and will not interfere with any BT/BLE communication (and Here is described how the NXT controls PF as well as RC trains). So from that perspective, @Cosmik42's software is not only serving all the BT (NXT, EV3) and BLE (PuP stuff) peripherals, but the whole shoo bang (PF, RC, RCX, Scout, MicroScout). And this is what I call the idea of LEGO. Not only brick-wise, but also electronic stuff wise. That would be so cool - this is my ultimate goal. I have 4.5V/12V trains equipped with PF receivers hooked up to RF, 9V trains, RC trains, and now BLE (PuP) trains. My point is: TLG makes a >fuss> about all that backward compatibility with regard to their ABS bricks. And that IS amazing. I have my 323 train from 1964 still here. It is like that. But with regard to doing the same with any electronic devices, TLG >miserably failed<. IMHO only of course. All the best, Thorsten

Hee hee, I love this. Oh, white is regarded as color - as in a mix of colors. Black though is "nothing". When there are reflections, black is not black but the color reflected by the surface - which is not black …

Well, black is even no color at all, so it is OK when the detector is confused . Don't take me seriously though … Best wishes Thorsten