Toastie

@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

Dear All, I was wondering myself. Posts here and elsewhere seem to suggest that the maximum number is adapter-specific. Which in turn suggests that all the memory consuming things in BLE communication (remembering all discovered services along with all data as UUIDs etc., all subscriptions to services etc. etc.) are actually stored/handled "on" the adapter. I have no idea whether or not this is even coming close. Here is a link you guys may have found long ago, just in case not. Answer #3 seems to go along that line: Link I am using the BL adapter built into my laptop (up-to-date Win10/64bit) and a BLE software stack (ActiveX control) from /n-software for VB6/32bit. I can tell my program to load 50 instances of the Client - it thinks a second about that - but it does so (creates all controls etc. pp). I have no idea though, whether or not all these clients would then communicate successfully: So far I have one hub and one remote. They are there though; even when telling client #50 to initiate the connection. Maybe this means anything to @Cosmik42? All the best, Thorsten

It would not work here, as LEGO is my hobby making me happy. And my wife as she sees it exactly that way. This is a wonderful - full of love - floral arrangement! I sure hope that the recipient recognizes not only the very special gift, but also the time and effort to create this wonderful LEGO model - for a loved person. Very, very, very nice. Best wishes to both of you, Thorsten

Oh my … so here is one - and here is the other. Bad quality though. Best Thorsten

Hi Duq, very nice work. I really like the RCX solution a lot. And of course the "non-invasive" mechanics!!! I made a version, which needs some invasive work: remove the both lids on the back, remove the lever. Drill a total of 8 small holes. Then use four 1 mm dia Nylon wires running in LEGO flex tube. All wires a thrown simultaneously by one PF-M motor into either all-cross or all-straight position within the faction of a second. Must have been don elsewhere so I did not post. Just in case here are two pics. Really nice work. I love this mechanism. All the best, Thorsten

This raises a question: Does the Hub or whatever BLE device you are playing with report the actual battery voltage? On generic consumer devices reporting "%" values, these are "%ages of capacity", not voltage. An alkaline battery showing 1.0 V under some very minor load (i.e. a volt meter) is almost dead. It can't deliver any significant current. Same holds true for rechargeables but at individual voltage levels. An NiMH cell with nominal 1.2 V fully charged voltage reading (it is more than that) is doing fine at 1.0 V clamp voltage under load. When the % reading should make any sense, one would need to know a) what type of battery is at work and b) what are their individual voltage/max. power (roughly U*Imax) characteristics. All I am saying is that 1.0 V for alkaline when free running is close to 0% capacity when under load. All the best, Thorsten

Yes and yes. It is an agony. Best Thorsten

Oh well, this is one way to "advertise". There are many others ...

>Happily<, it is running on Windows. Very happily. Believe me, I have heard that Windows is the worst kind of operating system in the world. When you ask the experts. I give you that. I do also believe that this is the case. But as an ordinary >dumb< user of MS software - it - works! Like a charm. I like it. Very much. All the best Thorsten That is a little harsh … It appears as if there are two worlds: Closer to the real world - as an everyday public (train) transportation commuter - it appears as if signals mean everything to the driver. In the world of LEGO trains, you can define sections as you wish. So both worlds need to come closer, I guess. All the best, Thorsten

Oh, absolutely ... … when people with the knowledge of @Cosmik42 are around (and - sure - a couple of others - but surely there are not that many, I bet), who spend endless ours in front of their computers, post updates on an almost daily basis, respond to requests within hours, give every iteration away for free … … yes, then it is just fine. But it does not happen that often … and has been the other way around too often. And then: I believe when I company cranks out BLE devices with the capabilities built into these devices as TLG does, they do also target a much more adult crowd, don't they? For pushing a train along, even a motor attached to a dumb battery box is too much. (One example (and there are so many and you know them as I do): The "latest" TLG PF protocol from years ago allowed 16 instead of 8 channels to be operated on. Any updates on that? Not that I know of …) Oh well. It all goes fine at the moment. Let us cross fingers. And I fully support and second @Giottistremarks above! Very well said. All the best, Thorsten