STG

I've run the 159, 170 and 395 on 2nd radius. The 395 looked the most realistic - the 158 and 170s have longer carriage lengths so can overhang a lot more. From my experience, the 170s and 158s do sound slightly pushed when going over just 2nd radius (although that's probably because I've put correct b-to-b on the wheels rather than the factory default). One issue with the 395s is a lack of traction - they rely on one motor bogie, whereas on the 170s and 158s have all-wheel drive on the motor coach (not sure what the new 158s are like). Many have added weights to the 395s and removed traction tyres for much better results. I'm pretty sure modern multiple units in general don't have buffers between the coaches, so it will be not buffer locking, but mainly the couplings that might be a hindrance (I had a few issues with the default 158 coupling on the older models, so swapped it out easily)

Are you sure this train is not DCC Fitted? I've had this issue in the past with a Bachmann DCC Fitted Class 150 (I didn't know it was fitted - 2nd hand). It had completely no response, lights off, until nearly full power, exactly as you say. The Decoder manual for these decoders I think mentions that they should not be used with these types of controllers. Well it certainly puzzled me for a while given that the train shouldn't have been DCC Fitted. I was also using the basic Hornby controller at that point. However, if there is any buzz or lights come on before it shoots off, it is likely to be a drive issue as suggested above.

I've tried these decoders, bought one and fitted it to a locomotive. They generally have very jerky performance compared to other decoders, particularly at slow speed. I swapped the decoder into a locomotive which had a higher motor starting voltage, which meant the jerkiness was less noticeable since it seemed to fade out at higher power

I just got wheel replacements which did not require traction tyres. In my opinion it runs nicer without them as well unless you want it to go up a gradient

Hmm, maybe. I don't know anyone else with the model but I would have thought if it was a bad one, at least one of the units with electronics would have some form of socket. My layout's DCC. I can say that I did wire a socket into the train since there was none present. Its a relatively easy conversion given the solder connection points on the PCB. Many of the social media posts have been good. I think since a more-detailed model was available most with existing DCC layouts went for the detailed version (which had a socket), hence not may actually needed to use the railroad version on DCC

Sorry if I was a bit vague. The Detailed model has the headlights as follows: [TOP HEADLIGHT] [left HEAD ONLY] [right HEAD ONLY] where top headlight was incorrectly placed on some earlier illutstrations of the set; top headlight being emitted from the cheaper model. No rear reversing lights.

The cheaper version of the Javelin certainly misses: an extra coach (comes with only 1 coach whereas more expensive version comes with 2)headlights and rear lightsA cheaper motor (very jumpy, drives me crazy)Not DCC Ready as stated wrongly by some catalogs, in fact the cheaper train is analog with no socket

Before I forget, my favourite tkinter tool is the tkinter.messagebox: Imported via and then for information dialogs and for error dialogs These use the default dialog box settings for the computer in use, and add a nice touch compared to bland tkinter typical light-grey windows and a few lines of text. (also tkinter.filedialog may be useful for opening items such as train rosters, or mimic panels)

I used tkinter, but personally find it hard to make it look nice, and some of the features have limitations, ie. for some features your code has to generate and execute code through the program itself, although this sort of complexity would only be seen in programs coded for generic use, not for use on a particular railway unless complex. Also, I found programs coded for generic use, although worked, required more user input for simple tasks, so hardcoding would be less time-consuming for the operator. Experimenting ended my up with 5 prototypes, and conclusions: Don't code it generic or it'll consume operator timeGoogle TTS is the most similar TTS for announcements in real lifeA similar screen used in the train-tech smart screen can be found online for use with RPis

Hi, Do you have any more details that you could share. Okay, I have 3 separate raspberry Pis, some jobs can be merged into 1 to reduce the number of Pis Needed: RPi no.1 - Controls JMRI WiThrottle Interface, with small screen and keyboard for changing roster etcRPi no.2 - Controls Signals and Points via relays connected to GPIO pins. Pin output is controlled via a python program on the Pi, listening, and a separate program on a control computer, which connects to the Pi accross the wifi.RPi no.3 (optional) - Announcements - Python program once again connects to control computer, trains are scheduled from this computer, to be announced, and also are placed on a mini-screen next to the operator.Code Length: >1000 Lines Code Diffculty: Moderate (easier if control device runs a text-based interfase rather than a GUI) Programming with JMRI - I have looked into this, although it runs on Jython, which is not my favourite programming language ever, and the documentation is sparse. Potential Sensors could be used to interlock and automate signals

I use a raspberry pi with JMRI. I find it easier than arduino because of the potential to plug in a screen and edit JMRI settings as you go (also because I use the RPi for automated announcements)

I had an issue with my 156, where the factory fitted wire between the motor and the PCB caught, and could prevent the bogie from turning, and eventually lead to the wire pulling out (a simple rewire solved this). If not, b-to-b is the solution most likely.

/media/tinymce_upload/221ade77d44880fe7e94577a4f588af4.jpg Just found this on a quick search - you can see the spring quite clearly so I hope this should shed some light on where it should attach.

I prefer using a raspberry pi with relays to control points and signals. I find it much easier than designing a PCB because when the layout is changed it doesn't take much rewiring, and not a massive hardware change. This gives me an executeable app on the main control device which connects to the raspberry pi, the app communicating and displaying a virtual mimic board. I find DCC equipment expensive, and since I could program it seemed a good project.

I think it was the February 2020 edition which included the building of such a layout.