UltraViolet

Eurobricks Vassals
  • Content Count

    58
  • Joined

  • Last visited

About UltraViolet

Spam Prevention

  • What is favorite LEGO theme? (we need this info to prevent spam)
    Trains
  • Which LEGO set did you recently purchase or build?
    21002-1 Empire State Building

Profile Information

  • Gender
    Female

Extra

  • Country
    Canada

Recent Profile Visitors

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

  1. I'm aware PUp is bluetooth. I'm only distinguishing between the two 'vintage' IR protocols. My subsequent mention of PUp only pertains to the ability to send commands from a PUp sensor element to allow controlling PU from PUp.
  2. Having only used PF myself, I'm wondering if anyone knows if the "new" PF protocol was designed in such a way that it would not cause interference in the same play space with the "old" IR protocol, whether or not this had anything to do with subsequent feature additions? Can they coexist if transmitting simultaneously? Also, I know the ability to send PF commands was made available in PUp, but would the equivalent code theoretically be possible to support the earlier IR protocol?
  3. UltraViolet

    Circuit Cubes

    Take note that both types of Circuit Cubes motors are not rated to handle full voltage from a standard PF source. Operating them at 9V would likely burn out the coils very quickly, and even the lower voltage PF rechargeable battery box would be unsafe. Here are the specifications I received from John Schuster at Circuit Cubes in response to my questions about the smaller motor: "The motors in the Cubit (2x4 stud pattern, 2 bricks tall) operate at 3-6 VDC. RPM about 160 at 4.2 VDC no load. Approximately 5.5 N.cm torque." Now that said, I found that the PF IR receiver operates perfectly fine from a lower than normal supply voltage. These motors worked great at all speed steps from the PF IR receiver when hooked up to a custom power supply with a suitably lower maximum voltage. In my case, I used a cheap and readily available adjustable voltage step-up board sourced through eBay to operate at 5 to 6V from an 18650 lithium cell (any format of standard 3.6-4.2 volt lithium cell will do, so choose what physically fits best in you build). This step-up board maintains precisely the voltage you set no matter the remaining capacity of the lithium cell. The bonus of this board is that by adjusting the maximum voltage output, you can tune the performance of the motor to your needs if the maximum voltage is too fast for your application. If you want to use a PF battery box, you'd have to install dummy cells as spacers in place of two of the AA or AAA batteries so your total max voltage would be 6V. (Be careful if you're in the habit of using non-rechargeable type lithium AA or AAA cells because they often put out higher than 1.5V at full capacity.) So long as you respect the 6V maximum supply voltage, you should do no harm.
  4. UltraViolet

    Powered Up 'M' Motors?

    Consider also whether you need high speed ability or low speed torque. I will cite a build of my own only as an example of the concept, since in my case I was using the original 9V train motors. I am constructing a 3-bogie, modern multi-segment tram model. For the sake of cost I tried to get away with using two motors and one un-powered brick-built bogie. While two of these motors certainly can deliver a fair amount of torque, the internal gearing is optimized for high speed. The two motors had much difficulty smoothly starting at low speed and maintaining consistent slow speed, particularly through curves. In the end I rebuilt the un-powered section to take a third motor, and the resulting behavior is much better, considering my need for this model to always operate at relatively low speeds. (As a side note, some of the 9V train motors are inconsistent in speed and in the required voltage to get the rotor spinning in the motor, so I've tested a number of them to find the better ones for this application.) Had I been building my own drives using separate motors and gears, low speed optimization would most certainly not have been a problem, but complexity and fragility potentially would have been. I've experimented with quite a few different drive designs and found that each motor type has an optimal gearing where there is a balance of speed and starting torque. Each combination will suit different build situations depending on what you want to accomplish in terms of weight/speed/starting torque/size/battery load/run time/hub max capacity/build strength, etc.
  5. Thank-you very much for that link to the motor teardown. The information presented there leads me to believe two things. The first phase of the motor update where the motor actually is fighting the shaft lock more than likely checks for valid calibration of the reference point for the hall effect sensor versus the completely random field alignment of the ring magnet from where it was placed during production. The magnet has four teeth on it to keep it in a fixed alignment with the output shaft, but the receiving teeth on the shaft allow somewhere around 22 possible relative angular positions versus the shaft zero-angle mark, and there is no starting point of reference physically - the relationship between the magnet and the sensor must be uniquely calibrated. The second, longer, phase of the motor update, if and when it occurs, very likely writes this calibration data to the microcontroller chip if it had differed from saved data but may also send a revised version of the microcontroller firmware. It would be very interesting to know if and how this affects other motors or even sensors in the whole Powered Up family, and how it is handled in the various software packages. What would be the implications after the Mindstorms software is dropped from support/availability? It would also be nice to know why the motor update has to be performed after a hub firmware update, where I can only guess that if the new hub firmware contains an updated motor microcontroller firmware, the software insists on checking the motors to see if they need this update applied also - the zero-point calibration seems to be done no matter what as insurance that it is correct. I would have to think that the calibration data would need to be retrieved from the motor first before being injected into the microcontroller firmware file before it is written back to the microcontroller. Every new motor I've seen came with the zero-angle mark sitting at zero already, implying that all motors go through an initial calibration at the factory when they are first programmed and tested on the production line so that they at least have a good chance of functioning right when fresh out of the box/bag. I do try to keep all my batteries maintenance charged on a regular basis, no matter the chemistry. The same thing applies back to lead-acid batteries (non-LEGO devices) - They will often become unsalvageable if not periodically topped up. I have a large number of AA/AAA/9V lithium batteries with built-in USB charging and constant voltage circuit. The internal circuit bleeds the lithium cell over time, so I have to keep them regularly refreshed. Interestingly, the much newer production ones that have USB-C connector are worse for bleed than the older ones I have with micro-USB. I would recommend the Beston brand ones to anyone interested, although you'll likely have to order them through Aliexpress or similar. Just bear in mind that I found the physical length of this brand for AA/AAA out of tolerance - They are ever so slightly too long physically, which makes them very tight when inserted in battery housings. Other than that issue, they've been great.
  6. When the process was running on my four motors, all of them spent the same brief amount of time trying to fight against the required shaft locking device, but it was the time period following this when the motor was not trying to turn any more that was significantly longer for two of them to reach the end of the progress bar. I would really like to know exactly what it was doing during this phase and what communication is actually taking place with the hub. Is this process unique to this hub and these gray motors, considering the above mention that the Spike app never does it at all? The motor update screen won't acknowledge the presence of anything but the regular gray motors. I wish more of the tech info was properly documented. By the way, I just received a spare yellow battery, and yes, it is identical to the original Mindstorms hub battery in every way, right down to all of the text printed on it. It is relieving to know I have options now. This also means I wouldn't be quite so concerned about opening one battery to rebuild it should it fail.
  7. Thank-you for the suggestion about the education market dealers. This was very helpful to point me in the right direction. I have found a couple online stores based within about an hours' driving distance from where I live who carry the Spike battery. They also carry a lot of the other Spike Prime series parts individually. Additionally, there are many other item categories unrelated to LEGO they carry which also may be of use to me in my other hobbies, so big plus there. In case anyone in Canada is interested, they are http://spectrumed.ca and http://studica.ca - Studica even sells a large selection of CNC machines!
  8. Within the past month I bought separately the Mindstorms hub and four gray motors, just to make sure I had them in my collection before they became unobtanium or prohibitively expensive. Like every other hub I have, I immediately connected the hub to the software to make sure its firmware was up to date, both to ensure it worked with the current software version and also to make sure it was updated in the case that it becomes impossible after the software is discontinued. Then it asked to update the motors. I can understand calibrating the zero point on the shaft rotation, but what does "Updating the motors" actually imply? Two of the motors completed the process within a few seconds, but the other two took significantly longer. What was the difference? They were all bought brand new at the same time directly from the LEGO Store. Do these motors actually have an updateable firmware inside them? Does this process have any effect on compatibility with other hubs and software, updated or not? This also only affected the gray motors, as the one motor I have which is color-matched to the hub was ignored by the update process. I don't like when software performs operations that don't fully explain themselves. Is the update check and download performed entirely locally to your computer, or does it have to check a remote server over the internet every time? Will this process continue to work in the future after the software is discontinued if I buy additional hubs/motors on the secondhand market? LEGO seems to be implying that this hub and motor will be completely abandoned in software/firmware support, even though they have indicated that everything else in the Powered Up ecosystem will eventually be migrated to the Powered Up app. I guess we will only learn the hard way if this becomes true by their actions rather than any formal public statements, but it would be nice to have an open line of communication about this. This is an awfully expensive piece of hardware to end up possibly being 'bricked'. There's nothing stopping them from dropping support for any other hardware either, before Powered Up reaches its final state. (I know about PyBricks, but unless it will allow duplicating the original programs and functions without going to coding school, I'm not very interested. The "Remote BlaBla" project however is quite intriguing to me, and hopefully full/near-full function can be extended to the Mindstorms hub.) I tried to ask LEGO Support the simple question if replacement batteries were available and orderable for this hub, and if not if the battery for the Spike Large Hub would be a drop-in replacement (I assume "Yes"), and if it was available to order as a fallback. Eventually these batteries will fail, possibly ballooning too and ruining even the battery casing in the process, so it would have been nice to know what their commitment was to replacements. LEGO refused to directly answer my questions, instead dancing around them and suggesting if I had a defective battery then I could ship it back to them and they would inspect and test it before considering supplying another one as a sort of warrantee replacement. The new Spike Small Hub has separate additional batteries available openly for purchase on the LEGO Store, but for the two large hubs nothing and no honest answer. Apparently if I want an extra battery even just for additional run time, my only option is to buy a complete new hub for a small fortune. (The resale market is of little help, as postal regulations prevent most methods of shipping lithium batteries from most other countries to Canada unless perhaps you have some kind of business import registration. Oddly, I can get almost anything shipped from China without issue, but nearly anywhere else gets stonewall blocked by Customs.) If anyone has any concrete answers to anything I've been rambling on about here, it would be greatly appreciated.
  9. As this topic relates to a project that will be on rails, I figured I would ask the question here. I am attempting to script a seemingly basic function on the PFx Brick, but can't for the life of me understand why it doesn't work. The scenario involves two LEDs - one is green and gets turned on immediately at power up (via a separate startup action), and the other is red. The action I'm trying to script is when a remote control button (or joystick) is pressed and held, that action runs a script that turns off the green LED and turns on the red LED. When the button is released, another script reverses the LEDs so green is again on and red is again off. The script code for when the button is pressed is as follows: light 1 off light 2 on The script code for when the button is released is as follows: light 1 on light 2 off The first line of each script file will work properly, so one light turns on and off as expected. The second lines, however, never do anything, and the order of the two lines makes no difference. I noted in the documentation that in the case of "event" commands, multiple actions may be triggered, but each type of action can only be called once inside the statement. While I'm not using "event" commands, is this still why multiple "light" commands get ignored? This shouldn't be the case according to the limited script code examples I've seen. I've also noted that the script files are only recognized as scripts by the PFx application if they have a ".txt" file extension, which is at odds with the documentation that says the extension should be ".pfx". If I have to make this work in a one line command, the only thing I can think of is to cheat with the RGB color LED command, as that would affect multiple output pins simultaneously.
  10. UltraViolet

    Powered Up - A tear down...

    It took a little while before I could ask my dad about IBM, but the answer I can give you is that he was primarily working with financial data processing services. In the early days of his career this goes all the way back to the era of punched cards in the 60's, as well as sending/receiving reel-to-reel tape data across the country over phone lines long before most people even knew the concept of a modem. (Likely wasn't even 300 baud.) I will move any further discussion to the other thread after this.
  11. UltraViolet

    [WIP] Lego monorails. [Custom Rail Systems (CRS)]

    As far as I know, the Wuppertal system is the only one of its kind in operation. The Memphis Suspension Railway is similar but cable-driven and not a full-fledged transit service. I think there's also a mountain incline railway like this using cable-haul. Most suspended monorails use a hollow box-beam with rubber-tired bogies travelling inside, with the train connected to the bogies through a slot in the bottom of the box structure. www.monorails.org is THE site to visit if you want to read up on everything monorail. Now what I'd really like to see is someone attempt to model the Lockheed Monorail as found on the defunct Himeji Monorail line. It's essentially a Lartigue configuration attached to an elevated concrete beam, but marketed as a brand-new space-age invention.
  12. I don't think there is a complete detail image of the "Space2310 Bogie" remaining anywhere online now. Perhaps someone using this design could show it with the wheels and side-frame removed from one side. (I understand how to build it now, but it took some time to figure it out. I don't have one assembled at the moment though.) It would be nice to see a dedicated bogie thread, whether for 4-wide or everything else combined. The examples are so scattered all over the place, and many images are no longer available. I'd love to have such a thread even just as a place to throw around ideas for inspiration and discussion. Some people are better at bogies/mechanisms, while some are better at the rest of the model building. Put the two together and it will likely help many people out. I myself have created some compact bogie test designs with no specific model in mind to put them in, done simply as a technical challenge and a foundation to expand on. I'd happily share them to see what others might do with them, and how they might be improved upon.
  13. The specific compound movement and acceleration curve created by the combination of the big gears and levers, while simultaneously being driven from multiple points in the mechanism, is top-level genius! I love GBC, but find this type of thought process completely beyond my ability and imagination. I am merely a humble spectator.
  14. UltraViolet

    Powered Up - A tear down...

    I found this today: Boost programming block decoder | Brickset: LEGO set guide and database It mentions an official so called "crib sheet" for the Boost coding blocks, which for some reason was only given out by request if you contacted LEGO Customer Service: http://uploads.brickset.com/docs/legoboostcoding.pdf This sort of thing would have helped me out loads in starting out with the Powered Up app, as the majority of blocks are the same, and the descriptions are simple. The great irony with Boost, however, is that for the sake of entry level learning, there are a large number of what I would call 'macro' blocks which perform predefined functions that for the most part are fairly clear what they imply. While this would be very useful for novices, or just playing around with a prototype build, none of these are offered in Powered Up, although if you knew the content of these macros you could 're-build' them as custom blocks I suppose. But you can't know the content because they don't tell you, nor offer any examples. The PDF document ends at a page which appears to show the document was unfinished, and that they intended to eventually publish some code examples. Perhaps this was why they would only give it out when a customer called in confused. In any case, how hard would it have been to make a portion of this document viewable in the Powered Up app, or to put a question mark button or hover text help on each block icon? The posting on Brickset about this was from 2017, but we're now in 2021 and apparently nothing has yet changed. I installed the Boost app just to take a quick look at it. You can't do anything at all with it unless it sees a Boost Hub connected, so unfortunately (for now) only the 'crib sheet' will be of much assistance to me. I might consider buying the set for one of my nephews though.
  15. UltraViolet

    largest drivers on Lego track

    Well, there was this video: Crossover Madness LEGO train - TRIXBRIX - YouTube Things get crazy at around 1:30 mark. Something about this creeps me out!