Mr Hobbles

Eurobricks Knights
  • Content Count

    693
  • Joined

  • Last visited

About Mr Hobbles

Spam Prevention

  • What is favorite LEGO theme? (we need this info to prevent spam)
    City
  • Which LEGO set did you recently purchase or build?
    Winter Village Fire Station

Contact Methods

  • Website URL
    http://

Profile Information

  • Location
    San Francisco, California

Extra

  • Country
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Mr Hobbles

    Trains and Ideas

    I don’t think they care much about the third party market. I think it’s more the simple fact that Lego trains don’t sell, so why bother investing in designing a new track system.
  2. Mr Hobbles

    Trains and Ideas

    There was an interview with Jamie Berard, Design Manager at Lego, which stated simply: 1. Trains themselves don't sell as well as they like, outside of your basic City trains. 2. To make a Creator Expert train sell, it needs to be tied in with something else to give it appeal. See Hogwarts Express, Winter Village Train and Disney Train. Here's is the interview: https://www.bricksforbricks.com/blog/2019/3/13/so-thats-why-we-havent-seen-more-creator-expert-trains
  3. Mr Hobbles

    Programming Technic Control+ hub

    There is no official Lego app programming for Control+...yet, though we have been told it is coming as part of the Powered Up app eventually. You can program all Powered Up hubs (including Control+) with third party solutions in the meantime, if you know how to code. Here's my library, there are others I've seen, including some in Python. https://github.com/nathankellenicki/node-poweredup/
  4. Mr Hobbles

    Powered Up - A tear down...

    There’s no such command as far as I know, but the motor is already capable of acting like a sensor. When you send it a command to move, it can also keep reporting back how far it’s moved in degrees. So one way to do what you’re proposing is to activate the motor for X seconds. Assuming it gets blocked at some point while doing that, time will run out and the motor will stop trying to move. By recording the rotation notifications you can tell how far it’s moved.
  5. Mr Hobbles

    Price per Piece - An outdated idea?

    So, firstly, yes, PPP is silly, for the reasons you mention. Size of parts, size of packaging, shipment costs, molds, etc. But, you mention 42099 and 42100. 42099 and 42100 are interesting cases, and probably only comparable to sets that came out in 2009-2011 during the introduction of Power Functions. 42099 and 42100 are flagship models designed to showcase the power of Powered UP in technic models through Control+. As a result, at this early stage, the cost of the set has to include: 1. The cost of the ABS plastic that went into them (weight/quantity). 2. The cost of new molds for those parts. 3. Additional new materials for the new components - PCB's, chipsets, metal, wires, etc. 4. The new supply chain requirements for those parts. 5. The cost of developing the new apps, and firmware for the electronics components. 6. Recouping the costs for 2-4 in a reasonable timeframe. The sixth one is important. A business functions by return-on-investment, and that time period is not indefinite. They can't say "we can spend this much up front because we think we'll get it back over time" like Power Functions, because at this point they have no measure of whether Powered UP will be a success yet. They may be forced to replace it in a couple of years time due to people not liking it. They'll have had to make the same decisions at the start of Power Functions too. We know Lego typically works in 3 year blocks from previous experience through themes, products, etc. If it hasn't turned out to be succesful by whatever internal measures they have in place by year 2, they've typically had no qualms in calling it quits by the end of year 3. This means that they'll have likely worked out amortizing the cost over 3 years. No doubt, as Powered UP sticks around for longer the cost of parts will come down as they did for Power Functions, and future sets 3+ years out will be perceived as better value for money - the costs of hardware, firmware and app development will come down as most of the work will have been done, and they'll be able to focus on charging for material and production.
  6. Mr Hobbles

    Powered Up - A tear down...

    Bang bang like the PUP and Boost motors when used with a paired physical remote control. From an app or custom software it can operate however you want.
  7. Mr Hobbles

    [APP] BrickController2

    Hmm interesting. As mentioned this differs from the behaviour I see, but indeed, it could be that its using a different subset of commands from the AbsolutePosition commands noted already in the documentation. I have a BTLE sniffer that I'm planning to use in the next few days to try and get some more commands, so we'll see what that comes up with. Will let us know if there are additional commands its using for absolute 0 or if its using a combination of the existing commands.
  8. Mr Hobbles

    [APP] BrickController2

    I think you can block it on one side because only one side is required to know where the center is. For example the app knows (because it is designed for 42099) how many degrees it should be able to move in any direction. So if it knows it should be able to move 75 to the left from forward, and it only manages to move 35, then forward must be an offset of 40, regardless of the other side. The 0/90/180/270 theory doesn't match up with my testing. For example, when I send the PresetEncoder command I'm able to reset the internal absolute zero to wherever the motor is at the time, and then I can use GoToAbsolutePosition to move to any position relative to whereever I set it, and not just within 90 degree increments. Also when I use the hub with my other code, GoToAbsolutePositon moves from the position where first turned on, regardless what the actual position is.
  9. Mr Hobbles

    Powered Up - A tear down...

    Well, for lack of a better place to discuss this stuff, I've been working with the Control+ stuff and adding support to node_poweredup. :) Here's what I've discovered: 1. For the first time, the hubs internal tilt sensor supports X/Y AND Z axis. The inbuilt accelerometer works nicely too and is a seperate sensor that reports acceleration. 2. There's an internal temperature sensor. It reports in degrees c. Mine reports about 28c while running, so I'm guessing this is CPU temperature. 3. The new motors allow you to specify an absolute position to move to. HOWEVER, there is NO absolute zero coded in. Absolute zero is whatever the position is when first turned on. I sniffed the BTLE comms between the Control+ app and the hub when playing with 42099 and it's really interesting. It does a little calibration dance where it moves the wheels as far left as possible then as far right (until blocked by the models superstructure), then measures the actual travel. Using these numbers it can determine where absolute zero should be. It then moves the motor to that position, then send a command to the hub telling it to "reset" the absolute zero position to there. 4. The new Control+ motors work fine on the PUP Hub and the WeDo 2.0 Smart Hub. However while they are recognised by the Boost Move Hub, they refuse to work, and instead send error notifications back. Perhaps a firmware update is required? Still investigating.
  10. Mr Hobbles

    [APP] BrickController2

    Just to note, I discovered when adding support to my library that there is no such thing as absolute zero on these motors. Absolute zero becomes whatever the motor is positioned at when the hub is first turned on, so marking it with a sharpie won't help. The way it calibrates when you use 42099 with the Control+ app is that it does a little calibration dance - first it moves the wheels as far to the left as possible (until blocked by the rest of the structure), and measures how far it actually moved. Then it does the same to the right. Using this, it determines how many degrees it should adjust to face forward. It then adjusts the motor to face forward, then sends a command to the hub to "reset" its internal idea of zero to whereever this forward position is. Any third party controller or app will need to do something similar when connecting to your MOC.
  11. Mr Hobbles

    Powered Up - A tear down...

    Thanks, and looks like you're making good progress! I have a query for you actually. :) Up until now I've ignored the reported RSSI values as most Bluetooth stacks report the RSSI level from the BLE central device (ie. my laptop). Have you noticed a big difference between the peripheral reported RSSI and that? This came into the forefront of my mind as I recently discovered one of the things that's been bugging me about the Powered Up remote. On most LPF2 hubs, ports 0x3b is voltage and 0x3c is current. But on the remote, 0x3c is RSSI. They don't seem to bother with current reporting on the remote, which makes sense as with no physical ports, it's not gonna fluctuate much.
  12. Mr Hobbles

    Powered Up - A tear down...

    I haven't actually tested it in a while, but I always assumed it only sent out a new value when the value changed? I could be wrong though.
  13. Mr Hobbles

    Powered Up - A tear down...

    :) Glad you worked it out. You might have noticed that the "reply" is actually the same message we got in the old firmware, that was automatically sent when the firmware automatically created the virtual port. So you can look for that message with the same code on both firmwares. And if you send the virtual port formation message on the old firmware you get an error reply, but nothing bad happens. So my backwards compatible solution is to send the virtual port formation message regardless, and just parse the reply the same on both.
  14. And WeDo 2.0 motors and sensors. It supports the whole LPF2 range currently.
  15. Mr Hobbles

    Powered Up - A tear down...

    Yes, my library supports it, and there's no firmware update necessary. I have a compatibility table on the readme - https://github.com/nathankellenicki/node-poweredup The WeDo 2.0 hub successfully reports the motor as type 38. I can control it by speed, and I can get rotation notifications from the hub when I turn the motor by hand. The only thing that either doesn't work, or I haven't figured out how to make work, is to rotate the motor by a specific angle. This may be due to a lack of a DirectWrite mode in the limited protocol the WeDo 2.0 hub supports. Or if it has it, I haven't discovered it yet. Currently the Boost motor and sensor _partially work_, and the train motor and LED's fully work. The LFP2 protocol is quite well designed - the hub doesn't really need to do anything special to support different motors and sensors. Most of the logic is up to the controlling smart device/app.