retrotecchie

I'll hack if I have to (I took a Dremmel to a couple of PF straight track sections to make a crossover...) and that is a quite tidy solution for the upper lights on the Cargo train!

I call it PUP as I think that is what LEGO have sold us....

For the electronics engineers out there, please note that VCC is NOT 9v (or 7.2v if you use rechargeables) but actually 3.3v, which is the microcontroller operating voltage and not the battery voltage. You cannot use these 'power' lines to drive anything heavy as they appear to be only intended for providing a Logic 1 or Logic 0 reference for the ID pins or possibly powering low voltage, low current peripherals such as sensors. With PF, you can just pull the full battery voltage from the +V and GND pins up to the current limit (0.8A) of the battery box. I have stripped a set of PUP lights so I can use the PUP ports with a breakout cable (also a PUP>PF adapter) for my testing and experimenting. I have posted a circuit diagram of the PUP lights in 2018 Train Tech if anyone is interested. Not very different from the PF lights, except the resistor values are lower (510R instead of 4K7). This did make me think that the LEDs are driven at 3.3v by the H-Bridge drivers rather than the full motor voltage (and that output voltage is somehow dependent on ID codes), but my PWM signals on M1/M2 (C1/C2 in PF notation) appear to scope out at full battery voltage. PF lights are somewhat brighter on full tilt than the new PUP ones.

Aha..... Those pins on PUP. Disregard the annotations 9v and 0v. I just cribbed the SmartHub image from the Powered Up Tear-down thread. When powered on and paired, the two power pins provide only around 3.3v and 0v (GND), regardless of whether you use AAA alkalines (9v) or AAA NiMH (7.2v), so these are not pins that can be used for powering anything meaty (unlike the PF battery boxes), but are operating at (what I assume is) the microcontroller's actual operating voltage. I would also imagine that they are also current limited by the 3.3v regulator. I did try shorting them for a couple of seconds and that seemed to have no permanent adverse effect...the NiMH batteries didn't go bang, but the hub did power down! That is to say, they are only there to provide logic level signals for the ID pins, or to power other small 3.3v devices such as the colour/distance sensor or other PUP input devices. The C1/C2 lines operate at nigh on full battery voltage as they are outputs from the H-bridge driver chip. This could make a PUP hub to PF cable conversion easy enough (the ID logic is handled at the PUP end), but going the other way (PF to PUP) won't be an issue as PF devices only really need the C1/C2 wires. If you remove the 2.2k resistor from PF lights, they are no longer identifiable by WeDo, but still work perfectly with PF. I hope that clarifies things a little?!

Try these circuits for signals or for reversible head/tail lights. Change resistor values to 4.7k for PF versions. For head/tail lights, a 3mm bicolour 2pin LED can be used. For signals, use a conventional red and green 3mm LED, but wire them with opposite polarities so with the direction set one way, the red LED illuminates and the other way, the green LED illuminates. Multiple signals can be parallel wired up to a limit of around 20 LEDs per output. The PWM frequency is around 10kHz, so you shouldn't see any noticeable flicker even only illuminating on each half cycle, so to speak.

Internally, the PUP lights are virtually identical to the PF equivalent. Two resistors (series resistors for the LEDs - 510 ohm by the looks of it), two smoothing capacitiors, a bridge rectifier and a small resistor (2.2k) for ID. A little smaller than the PF components, so values are a little harder to read on the capacitors, but I can't see anything particularly special about the lights. The series resistors in PF were 4.7k rather than 510 ohm, but when measured with a light-meter and run at full tilt, the PF ones are a tad brighter, using 7.2v of fully charged NiMh cells in each case. I'm not particularly impressed, especially as they are significantly more expensive than the PF items. ID1 (pin 5) is pulled down to Gnd by the 2.2k resistor, ID2 (pin 6) is unconnected and the 9v line (pin 4) is not used. Now, I'm assuming that the ID pins in the Smarthub have high value pull-up resistors so that an externally floating pin (as ID2 above) shows as a logic 1 and a low value resistor is used as a pull down to Gnd to signal a Logic 0. Obviously in a train motor, the pins are hard-wired (ID1 to 9v and ID2 to Gnd) so the ID logic for the motors and the lights appears to be reversed (Lights=x10 and Motor=x01). Anyway, I'm possibly just going to open up a train motor to play with the ID's, or chop a PUP connector off the spare lights and hook it to my breakout board as the PCB in the lights is just way too fiddly to work with. I have found another subtle difference between PF and PUP. If you set an output on PF (lights, train motor, etc.) then the output state is maintained until another IR command is received. For instance, if you start up a train motor on (say) speed 4 and then disconnect the PF motor from the receiver, when you reconnect the motor it will operate again at the last set speed. The same with lights - they will come on at whatever power level the channel was last set to. On PUP, disconnecting any load will automatically shut off the output of the port. Re-attach the lights or motor and the default state is off. It can be assumed then that checking the state of the ID pins is a continuous process and the ID isn't simply scanned at power on time. In that respect, the SmartHub Port is more 'intelligent' than the 'set and forget' output of the PF receiver. Another part of my experimentation with my breakout board will be to try and change ID states 'on the fly' with lights or motors operating and see what effect that has on things.

OK, I now have PUP lights for my two trains, and it has all gone pear-shaped again. Having finally persuaded my PUP to 'play ball' and get both trains working from one controller, the lights have ballsed it all up again. On one controller, I have the Cargo Train motor on Port A and the Passenger Train motor on Port B so I can operate both trains from the same PUP controller. The only way to connect the lights in a train, as it stands, is to plug the lights into the other port on the Smart Hub. Only, with the new connectors you cannot piggy back two sets of lights...you are limited to one, so it's headlights only...no tail lights or carriage lights. But....with the controller paired to the two trains, Port A controls the motor of one train, but brings the lights on on the other train, and vice versa! The 'fix' is to unpair the controllers from the trains and have a separate controller per train, with Port A controlling the motor and Port B controlling the lights, or one controller but the two trains on different colours, necessitating button presses on the controller green button in order to swap between trains. Not at all elegant, and kind of defeating the point of having multi-channel control. I can also confirm that the lights indeed work by stepping the brightness up and down rather than a binary on or off, so it seems at first glance that the lights are simply using the same C1/C2 pins to drive them with PWM as with the existing PF lights. The 'emergency stop' (red button) will dunk the lights instantly, but to put them on, you have no choice but to ramp the brightness up in steps. Perhaps messing with the ID wiring may have a bearing on their operation? I shall endeavour to find out. Obviously, PF allows you to stack multiple devices so you can have a motor and one (or more) sets of lights running from the same output. So in that respect, PUP is (thus far) a retrograde step. Time to get the soldering iron out and get down to work! I see no reason at all why a PUP to PF cable (with the ID pins hard wired to identify the load as a 'train motor') can't drive a motor and lights in exactly the same way as PF allows stacking of devices. The Passenger Train is intended to have lights fitted, as the two front headlights are fitted to studs with holes in the nose-cone and the brick immediately behind this was clearly intended to accept the PUP LEDs. The Cargo train is a little more tricky as all the 'lights' are fitted to blind bricks, without any method of locating any LED's without changing a few bricks about, as Yodah has done. Ideally the Cargo Train locomotive would also require 8 LEDs (4 sets of lights) if you wanted to illuminate all the available lighting positions (two at the bottom front and the two over the cabs). Certainly not possible without reaching for the soldering iron!

I just fitted a PF connector onto a 7.2v NiMh charger and snap that onto the standard 88000 battery box, with AAA rechargeables. You can pretty much charge in situ. With my old 4.5v battery tenders, I just built a pack out of NiMh AA cells that sit inside the tender and fitted a 2.1mm power plug into them so I can just plug them in to a charger. The old 4.5v trains run ok with 3 cells (3.6v), but go like stink if you make a 4.8v pack!

Mine are on their way. Despite a couple of items on my order being out of stock and telling me they would ship everything together in a week's time, they have shipped the lights (arriving Monday) and the other parts will be shipped separately. One set of lights for the passenger train, one set of lights for the cargo train and one set of lights to cannibalise and dissect for 'research purposes'.

Looks like he is using a slightly modified SATA cable to plug into the hub in some of the videos.

Motor on Port A, Lights (only one set) on Port B. You will need to use both channels on the controller, one for speed and one for illumination. If, as has been mentioned, the smartphone app just turns the lights full on or full off when the train is moving, then that is a slightly different proposition. I know years ago when my cousin played with HO scale Hornby trains, he had carriage illumination that stayed on even when the train was static. He used the Zero One controllers which keep a permanent DC on the tracks and just superimpose digital (DCC) control signals onto the rails. I have ordered some PUP lights but they won't be with me for about ten days as some of the other items on my order are back-order until August 23rd and they are dispatching the whole lot once everything is in stock. One question I want to know (and maybe someone has already looked at this?) is whether the 9v DC on the 6-wire PUP cable is permanently live (as in a direct connection to the battery) or switched live (as in, live when the hub is on and paired). I have already made up a quick hand-wired PCB with six pins to attach to the PUP cable and plug (when I get my set or lights to hack) and some 9v/0v pins and C1/C2 pins. I have added some headers which will allow me to set various combinations (00,01,10 or 11) on the ID pins, plus a few LEDs to monitor the lines. Once I have the lights (I really don't want to chop a PUP motor just yet) and can hook it all up, I'll post some pictures and my findings. Watch this space! The plan is to make a 'universal breakout connector' which should work as a PUP to PF interface plus maybe allow a few other, as yet unknown, tricks to happen.

sed6...100 VIP points is better than a kick in the cojones. Incidentally, the train front ( Element 6226707 Design number 37493) is now available on Bricks and Pieces (GBP 3.78 here in the UK) as are most of the other parts so if you wanted to make a custom dummy 'engine' (locomotive, auxilliary control car, missing 'end' - whatever you care to call it) then it should now be possible. Motors are not available, but you would probably only need to make up a dummy one anyway. Then again, you already have a free motor...

Lucky I have one then! I know the S@H website (UK) limits both sets to five per customer and (judging by the number of PUP kits appearing on Ebay) it seems that a lot of the trains are being bought by folks just parting them out. In which case, a 'complete' train with original box and instructions, kept as shipped, might well be a bit of a rarity before too long, seeing as not that many people are overly impressed with the trains themselves. I wonder how many 60197 sets are just being bought for the extra carriages, the loco fitted with a dummy motor bogey and the train turned into a double-ender and the second set of PUP gear being offloaded? I also wonder how many folks have, like me, put the PUP to one side and retrofitted the trains with cheap PF gear?

Same as the 2x2 brick in the middle of the PF lights, I suspect. The series resistors for the LEDs themselves, a bridge rectifier (so the lights come on no matter what the polarity of the C1/C2 PWM signals), smoothing capacitors so the LEDs don't flicker plus maybe another resistor or two for the ID signals. Apparently the existing PF lights have an ID resistor incorporated so they can be recognised by We Do. I have decided to get a set of new lights just so I can hack off the 6 pin connector and make myself a custom cable, possibly terminated with a conventional 6 pin Molex header. That way, I can experiment with different motor and lights wiring and see how easy it is to come up with some other options. One idea I had was to bypass the rectifier so I have an output to the LED's that changes polarity, and to then use a bi-coloured (white/red - they are available) LED in place of the white one. The idea being, with the polarity in one direction, the LED lights up white and in the opposite direction they light up red. That way, the lights at each end of a train can change from headlights to tail lights depending on the direction of the train. Another thought was for trackside signalling. Instead of using a bi-colour LED, use discreet green and red LEDs so that for one polarity, a red signal will illuminate. Reverse the polarity and the red goes out and the green comes on. If the lights ID allows simple on-off switching, then this would work a treat. We know the train motors draw around 200mA and the PF LED lights draw around 4mA, so it should be eminently possible to wire up multiple signals from the output of one hub. I have already done the above with Power Functions, as well as hacking the wiring on a PF receiver to allow powering from an old 4.5v battery tender and driving a 4.5v LEGO motor as fitted to something like a 7720 or my even older 171. I have also hacked a PF receiver so that the C1 and C2 outputs power the centre rails on my old grey 12v track with the 7745 High Speed 12v train. The 12v motor works beautifully with the PWM control signals and I would imagine that the 9v system would work equally as well, subject to the limit of one train per circuit. Of course, the PF system will work at any voltage up to around 14v, and as low as 3.2v - I run 4.5v trains with 3x NiMH cells for 3.6v. I'm not sure how safe the PUP is to drive at higher voltages than 9v. Much to do and, although I have had a long career in both software and hardware, my main interests have always been hardware and interfacing, I plan to have a good play with the electronics to see what can be screwed with.

64% more expensive than the PF originals...