Toastie

Nice! Truly reminds me of M*A*S*H - Through early morning fog I see visions of the things to be ... Best Thorsten

This is truly breathtaking. Congratulations! And - as before - I simply admire how you turned your rather "not building boxes on wheels" comments ages ago into a "beautiful box with so many details that it may actually catch-up with steamers - and on wheels". Amazing. The color scheme is also very, very nice. Question: Did an actual FP7 with one B-unit attached pull the corresponding 5 meters of coaches or is it because of the power of (at least) two 9V motors? This is so great! Best Thorsten

Well, I am not the expert here, just learned from others. @Mr Hobbles is pretty much the one who knows it all and @Cosmik42 makes everything just work. As far as I understand, the hub does no longer send the virtual port ID when two identical devices are attached to the two I/O ports, now you have to ask for that one. It is always 0x10 on my hubs but I am requesting a pairing with "06 00 61 01 00 01". I the get the virtual ID as reply, which I then use with the "StartPower(Power1, Power2) sub command (02) "08 00 81 VirtualPortID 00 02 Power1 Power2". But you have to ask the experts for in-depth information! I just had some spare time riding an IC train from Hamburg to Düsseldorf Best Thorsten

@imurvai yes, it now works in full accord to the LWP3.0 document. See here (close to the end): Best, Thorsten

Just following this conversation (it is not just another "thread" - it is a true, very polite, and respectful >conversation<) says it all. There are some who express their views with more impetus, there are others who voice their view in a less strict way. Moderators, builders, visitors, actively responding members, others - all with contributions I want to read. Some apologize for their initial response, others follow up on their reactions. Does it get any better? The quality of this conversation alone says everything about EB. I believe that this conversation should be frontpaged. It would stand out. I just came here by accident. This is EB culture to its best. My 2 cents: In the very beginning, when I started to post on EB almost a decade ago, I had exactly the same feelings as @ProvenceTristram. Very little responses. But then, diving more into it - seeing the "speculation about if when where, should could would, this and that" >threads< with billions of entries, I decided to just ignore those and move on. Move on to learning. Yes, some folks have a lot to spend. I am very happy that they can do so! Not the point. I go to … the Technic forum and - learn. There are sheds, there are corners - it is unbelievable, what these folks construct. I will never ever be able to do that. But: I love to learn. Or simply enjoy. Mostly quietly. I visit many other forums - been to the new Mindstorms forum? Thread count really low BUT: For me the most interesting place - to learn. So all I am doing when posting is to (probably) let other people try what I did, modify what I did, or tell me, where I can improve. No response necessary. It is not about getting replies, it is all about sharing knowledge, fun, excitement, silly things, cool things, you name it. Pressing "Submit" is the moment of reward. It is a privilege to be able to do so. Your creations are - every single one - beyond believe for me. I cannot comprehend how you do that. Before you started this conversation, I was sure that you know that for yourself and don't care about replies at all. A comment from my side appeared always misplaced, taking into consideration my very limited virtual building abilities. All the best, Thorsten

Well, I don't really have/don't know how to get direct access to the Bluetooth stack on my laptop (w/ built-in radio) as I am using a Vb6 ActiveX control from /n_software. When scanning I can read out the RSSI level reported from the control for every device - upon connecting that stops. So I did that - and also used the Win10 BLE Explorer app. Both deliver (with high rate) RSSI level data, that jitter (a lot) around a mean value. When comparing that to RSSI data from the hub, these are much smoother (guess via averaging by the hubs firmware) and are in the same ballpark. As these data are apparently remotely reflecting the signal strength on a dB scale, the result is actually almost identical. There are some differences but that does really not matter. But as said, I need to get the RSSI levels from the hub, as I don't get them form my laptop directly, when connected to the BLE device. The levels are reported by the hub as rather smooth signed 8bit integers (I believe). What I do is putting a hub very close to my laptop and define that level as full reception level, which is around -40 dB , and then move it as far away as I can within the "environment" = my attic space with different types of obstacles in the line of sight (brick, wood, etc.) and define the smallest distance before disconnection occurs as minimum reception level. The latter changes when operating the devices in less densely packed spaces of course. I fully agree. It really does not make sense to report the current, as BLE is LE and presumably the highest current drawn is for the RGB LED lighting up when pressing a button on the remote. Best regards, Thorsten

I was assuming the same. And I believe it is like that. I can't find it for some reason (is it just me or are any of you getting sometimes fuzzy as well when browsing the document? It is getting better as I am getting used to the intrinsic logic - which is - from my point of view - simply brilliant. I like the approach they're using very much) , but somewhere in the LWP3 documentation the threshold for such events are/can be declared/defined. I believe I used a hub where the batteries were running low on purpose (as I could then test the little graphical things happening, e.g. when stalling a motor.). So the battery data on that one were changing gradually over time. I believe also that the RSSI level is sent out on a more regular schedule as that one is more critical with regard to running out of range. And maybe the RSSI raw signal is simply much more jittery so it appears as if the hub just sends them out more often. Thanks for your reply though. I really appreciate that. Stack stuff is working now - I don't miss barely any event type message now, even when running VB6 in full debug mode. All the best Thorsten

@Mr Hobbles Thank you very much! Quick question: After updating one of my 2I/O hubs to new firmware, I noticed that a) the battery level notification comes in immediately (after subscribing and requesting the update) but then b) I don't see any further updates. The RSSI level is (as before firmware update) sent out about every second, depending on BLE traffic. With the old firmware, the battery level was provided every ten seconds or so. I believe not notifying the battery level every 10 s is very reasonable to decrease BLE traffic, as the battery level simply won't change permanently within 10 s. In the even of e.g. stalling a motor, the over current alarm event is thrown - it does thus not make sense to monitor the (then) temporally decreasing voltage level as well with high temporal resolution. Is that so or do I screw up on reading out the hub notifications? (Reason for asking: I am rewriting my VB6 code so that the BLE value event "only" populates a stack with corresponding stack pointer change - but does not do any "data interpretation" as before. That is moved to a timer driven event routine, which processes the stack asynchronously. Well the value event is thrown asynchronously whereas the timer runs with fixed intervals of course. I just want to make sure that I don't miss any hub data. Attachment/detachment I/O events are very well captured. Monitoring the value event though just shows I/O and RSSI updates) Best wishes Thorsten

Hi @veezer! Don't The above link might have gone but not the item. Go to BrickLink, the Market Place, then Parts and search for "battery box". The 2I/O Hub is listed as such. Scroll down a bit, should be on the first or second page, depending on your settings. Starts ate about €14 ($16); when you need more (+10) than you will find shops offering them for about $20 each. The store locations are all "abroad" from your perspective, but if I were you, I'd give it a shot. US Customs may become curious - so maybe you can instruct the shops owners to print "gift" and/or "used devices" all over the package/package slip and have them removed any original LEGO packaging like plastic boxes etc. (Did that, worked well with German customs). In any case, I believe the total cost when ordering a couple of hubs (including extra import taxes when things go wrong, delivery) will be less than X times $50 each. Best Thorsten

Thank you @Tcm0! Is it the same with the other hubs as well? (Boost …) I believe the Spike Prime 6I/O hub has some memory, right? Does that one act autonomously? Thanks. Regards, Thorsten

This is really nice! I have a question: When you have programed, does the code (as "if then else") actually run on the hub, or does the code run on the smart device and that one is notified via events the hub throws and in turn sends out commands to the hub? In other words, is the hub acting autonomously (as the other PBricks like RCX and EV3) do? Best Thorsten

@Mr Hobbles (SORRY: Just found out I believe!!! Don't waste you time here) I have never used the virtual port before - so I am a bit confused of what to do to do so Updated the hub firmware with the help of my daughter's smart phone (only one hub, as I may screw up entirely …) Check. I understood on how to change from the 81/60 output command (just copied that from somewhere and never understood what was going on) to the 81/51 as documented for one output/motor/Hub LED etc. Works well. Check. Also 81/01 (01 = "N/A" in the LWP3 protocol document, right?) works well. I do get the appropriate messages from the hub (I only have the 2I/O version) when devices are attached/detached. From what you have posted before, I would like to try to combine both hub outputs: First send the combine command: 06 00 61 01 00 01 (is that correct? I believe now it is, there there is the port notification, right?) An output command to turn both motors on would be: 08 00 81 ?? 00 02 XX YY (XX = power 1, YY = power 2, ?? = PortID, is that correct? YES, from hub) My question is: How do I find out the PortID for the virtual port? Is there a reply from the hub when I connect both outputs? YES THERE IS Thank you very much in advance! Best regards, Thorsten

So just assume I am rather old and a little slow. I have a few questions: The lastest LPF2 documentation is the "LEGO Wireless Protocol 3.0.00 Doc v3.0.00 r17 documentation" (Dec 2018) right? I am trying to follow the LPF2 stuff on EB, but the Boost this and Move that, along with Spike here and Prime there, Hubs, PoweredUp and whatnot is (for me) getting tough. I don't have all these devices, just plain vanilla "Hub.No4s". TrainTech has several threads on that, Mindstorms as well, and there is Cosmik, who just fixes things over night when he is travelling and some of you guys were getting nervous. Is there a way to update Hub.No4's firmware (what is this box called correctly?) without using the stupid LEGO app? Reason: I don't have a smartphone (believe it or not, but the world is still spinning, I can read printed maps, Google maps, know what time it is, can do SMS on my steam-operated cell phone, know the protocol of TCP/IP, somehow managed to work with BLE … and frequently use Skype for Business to to talk to people quite far away). If not, then I'll ask my wife to download the stupid app, but this is not as it should be; I believe none of you guys are running your fantastic automated layouts from your cell phone ... Thanks for your help!!! Best wishes, Thorsten

Tough. But - well - it appears to be on the way. This is a very, very impressive (and expressive) building; building-wise as well as "story" wise. Thank you, @Insomnia Best, Thorsten

Wow. Simply wow. This is >really< nice. Thank you for sharing! Best, Thorsten

Well, that makes absolutely sense. I for myself take nay new features, particularly the electronic/electro-mechanic stuff and try to figure out what kind of new ways of letting LEGO models "do" something (automation, remote control, autonomous operations, etc.). So this is why I don't care about colors. Yes it is a toy, but I am also using LEGOs to create certainly "non-toy" things. I can see your point clearly. Thanks for letting me see that perspective as well! All the best Thorsten

Colors ... as in colors? I could not care less (I'm pretty much color blind and feel fortunate about that) - but >functionality< is what counts in the Technic Forum, isn't it? How many motors you guys are using for what you are doing are exposed to the extent that coloring issues may impose your builds adversely? Think about what can be done with these gadgets. And further: With all the building skills presented in this forum: Hiding wrong colors is the least issue of concern, I believe. At least this is what I have learned here. Lets get things rolling. Best Thorsten

Thank you very, very much for your reply! This is going to be really cool. With regard of 8/6 or whatever number of data lines: When 8 is appropriate for the most advanced sensor/actuator(with feedback) thingies: fine. Because this simply sets the stage. It then appears to be straight forward to downscale to an "LPF2 Smart Hub 2 I/O" BLE device port with (only) 6 lines. Yes, I can see that. Very nice! Best Thorsten

Yes and yes. To be honest: This is on of my "favorite" dreams (can't control my dreams, but I'd like to dream it). Best Thorsten

Truly: +1

+1 And even more: When carefully assembled (which means: Not necessarily following TLGs output of sets tailored towards a) apparently todays mainstream and b) maximizing revenue) all the new sets, as they are 100% compatible with pieces from the old sets, this can be very appealing. A space set of todays appearance can always be massaged into a set from the good ol'days. Provided you have the diverse bricks and plates at hand to do that. All the best, Thorsten

The question is though: Why do we need to buy a "sensor" for the breakout female sensor header and not a simple "break out cable"? Hmm. A Hub.No4 (@Mr Hobbles what is this device called appropriately in the LPF2 world?) has a 6 pin terminal. Don't know what the other BLE devices feature, and also no idea, what the EV3 port is composed of. Apparently a max. of 8 signal lines is what we need. Guess we better wait and see. I am very much excited! Best Thorsten

That is too bad (the facebook crap, not that you signed up!) - I won't sign up though as I don't do Facebook. For a number of reasons you were already mentioning. So I'll have to see what leaks is relayed to through to this place Best Thorsten

Yes, this is true. But not entirely. Ben Beneke has taught us that you can have 3 axles with flanged drivers. You need to use a split center axle which is spring loaded. And in addition flex-tube driving rods: http://www.brickshelf.com/cgi-bin/gallery.cgi?i=6602573 This is not appropriate for the EN - so I would go with the already mentioned blind wheels. All the best Thorsten

Thank you very much for these very valuable insights! I am learning a lot here. I do also believe that with the electronic circuitry available nowadays, much more flexible (and automatically detectable) I/O device attachment is realizable. Laptops detect whether or not a microphone or headphone is attached to the one jack available and so on. Plus with all the power of todays microprocessors/memory it is also firmware-wise readily doable. So from that perspective, I believe that everything in the new LPF2 etc pp devices will be compatible - at least to the event that nothing breaks. I was more referring to the old stuff being "made compatible" using converter cables with the new stuff. Even there are >a lot< of possibilities. Restricted by the PF2 plug … which is of course just a "clip" away. In that regard it may be rendered difficult to come up (with a variety) of 9V-PF2, PF-PF2. etc. ready to go converter cables. As said, I am using the PF2 LED light for the plug, solder a 6 pin socket header to it and have full access to the e.g. Hub.No4 I/O ports. I guess this is the same approach you are talking about - 8 pins are OK as well, depends on the intelligent device I guess. This is all very cool! Best regards, Thorsten