Britannia Builder

I completely agree with you, I had the same problem with Defender and the 'hacktool' in the thread that you linked to. Defender is absolutely right to keep objecting to it. RM should at the very least offer the option of an installation without this component. They should also host their downloads on an HTTPS server. Even I now have a secure server for my personal britanniabuilder.com website - it came as part of the hosting package. Regards, John

I've now reported it as a bug. Regards, John

I've now experimented a bit further and satisfied myself that this is indeed a bug in Railmaster, as Ray said in his post above after monitoring the DCC messages. When F28 is used as the first function button press for a loco in an RM session, the F28 button turns green but AFC is not turned on in the decoder. If any other function, either spot or on/off, is used beforehand, F28 then works on its first press. Using the stop or throttle buttons beforehand didn't avoid the problem for me, contrary to what gilbo2 experienced with the Elite. After getting F28 synchronised and then turning it off for all my 5 TXS locos, I then closed and restarted RM without turning off the eLink track power. The F28 problem then recurred for each loco, proving that it's the initial state of RM rather than the decoder that causes the problem. It's a strange bug because RM knows nothing of the meaning of F28, but it looks as though RM is failing to initialise its internal state of F28 correctly before sending the DCC message, but using any other function button has the side effect of correctly initialising F28. This side effect is understandable because the DCC function messages send the on/off state of a whole contiguous group of functions, eg F20-F28, when any function button is pressed. We'll have to wait and see whether this bug got reported and fixed for the next release. Anyway it's no big deal - just toot the horn before turning on F28! Regards, John

I originally posted this problem back in April last year, and it's still there. I use eLink rather than Elite with RM. I haven't experienced the problem that gilbo2 describes, of stop or throttle controls turning off AFC. I've got into the habit of turning on some other on/off function first when first using a loco during a running session (eg lights, or coal shovelling), and F28 then works correctly at the first press and the green button stays in synch with the action. If I forget to do this and the F28 green button does get out of sync, I can correct it by pressing a spot sound button and then quickly pressing F28 while RM is tied up with the sound (it ignores any other command for about 3 seconds while the sound is playing, which at least in my experience is a long-standing 'feature' of RM). I'm struggling to understand how this can be purely a bug in RM, since all other on/off functions work correctly at the first press and RM doesn't understand the meaning of F28 and surely treats it the same as any other on/off function. Regards, John

I know that you said that you'd splayed the decoder pins slightly to ensure good contact, but poor contact here still seems to me the most likely cause of the problem. A high resistance here would drop the voltage to the decoder when the motor tries to draw current. This issue has been mentioned several times before, and someone said that it took several attempts to get good contact. The four corner pins are the ones that carry the current. A genuine overcurrent from a faulty motor would activate the safety mechanism to cut the motor power, but still leave bluetooth and sound active. Regards, John

Steven, the TXS decoders are still being sold in boxes that say on the front in bold print 'Tri-Mode - Functions with .... DC Controllers'. This has clearly turned out not to be the case. In view of this I think you should be entitled to expect Hornby to replace or refund your decoder, and I've no doubt that they will if you ask them. You should not be expected to trawl forums or online user manuals before switching the device on. To follow up the microwave analogy, it's as though the microwave said on the box 'You can dry your cat in this'! Regards, John

Thanks Steve. It would be good to know how the overcurrent protection works - what current triggers it and over what time measurement, and how it gets reset. Is the advice in the app to reload the profile a red herring, and it just resets after a suitable period of power off? I thought about whether F28 would put an additional load on the decoder with the sounds starting, but in fact F28 only caused 1 overcurrent out of 4 recalibrations, whereas F0 caused the overcurrent on the one time that it was used directly. It could be that the F28 sounds divert a bit of power away from the motor drive, and hence slightly reduce the protected motor current? It's clearly right on the limit of the overcurrent protection. I agree that autocalibration is useful, and I've used it many times previously without problems, but I wonder why it needs to use maximum motor voltage? Surely the back emf characteristics of the motor could be determined with a lower voltage? Regards, John

I tried the decoder again this morning and it has magically recovered after a good night's sleep! Very strange, after a complete power down for 5 minutes yesterday didn't clear the overcurrent condition, and nor did a profile reload or a CV8 reset. I shall never use autocalibration again after this experience. Applying maximum voltage to a stationary motor just seems too vicious. @LTSR, I can't do a stall test because I don't have a DC controller, and from reading up about it stall testing does seem to risk damaging the motor unless done very briefly. If I were to remove the decoder again I could check the resistance across the motor drive wires on the decoder socket, which would presumably give the stall current by Ohm's law. Regards, John

I tried it again, with pretty disastrous results. I started by autocalibrating with F28, and it worked! I tried a couple of times more to be certain, and ran the loco successfully, and then I thought I'd better try using F0, and it failed with the overcurrent. I'm sure that this is nothing to do with F28 versus F0, but just some randomness in the overcurrent mechanism. So following Steve's advice I powered off the track for at least 5 minutes (the loco has no power bank) and I rebooted the iPad, but this unfortunately didn't clear the overcurrent. The loco responds to sounds and makes chuffing noises but the motor doesn't turn. So I reloaded the profile, which cleared the original fault yesterday, but even this didn't clear it this time. Is there anything else I can try before sending the decoder back? Edit: I've also now tried a CV8 reset, and that doesn't help. Regards, John

I'd be happy to do more tests to pin this problem down, and I can certainly change my Railmaster setup to allow me to trigger F0 directly, although I've used F28 successfully many times before with other locos. I think the interesting test would be whether a lower setting for VHigh would remove the overcurrent, and if so how high a voltage it could tolerate. The main barrier to doing this is the apparent need to reload the profile and then reset all the customised CVs in order to clear the overcurrent error shown in the app. This just too tedious to contemplate! Is there any other proven way of clearing the error? Regards, John

Yes I thought about using the Britannia profile but that is 2 cylinder rather than 3, and the Tornado does have decent chime whistles on F3, like the DoG. The only very minor gripe is that AFC uses F2 whistles as its moving-off sound - in an ideal world AFC could be set up to use F3 instead of F2. I've always used F28 to turn on F0 and hence trigger autocalibration, because I have F28 and not F0 on my set of 6 Railmaster small-throttle buttons. It does work, as proven by the overcurrent! Regards, John

I did trigger the autocalibration from DCC (Railmaster) after setting CV149 to 0 in the app, by turning on F28 (which also turns on F0). This is how I've always done it. The loco didn't even twitch, which suggests that the overcurrent triggered instantly. I haven't tried it again because reloading the profile gets rather tedious. I suppose my hope of a DoG TXS profile was rather optimistic. Regards, John

Daedalus, I've now installed the Bluetooth LE Scanner on my Samsung phone and it does show the full addresses of my decoders, so thanks for that. Useful information for anyone encountering this problem in the future. Rob, it seems very strange that you have such a variety of values in digits 7 and 8 when all 5 of mine, bought from different retailers at different times, have 00. Are yours perhaps from a different pre-production batch? Regards, John

I fitted a new 8-TXS decoder yesterday, my 5th, and encountered this request for a reset code - the first time I've seen this. Powering everything down didn't resolve it. I used my Samsung mobile to find the Bluetooth id but it was shown in the form HM7000_xxxx - I couldn't see a way of getting the full 12 character code. Daedalus mentions above that the code is of the form A4C138xxxxxx, which leaves the 7th and 8th characters to be determined - but I saw that they were 00 on all my other decoders, so I tried A4C13800xxxx and that worked. Regards, John

I installed an 8-TXS decoder in my 8P Duke of Gloucester TTS loco yesterday. This is the last of my steam locos to be upgraded, and I did so mainly in order to get the better chuff rate and the AFC sounds, despite the fact that there's no DoG sound file as yet. I used the Tornado profile, which has 3 cylinders and a decent chime whistle similar to the DoG. Perhaps Hornby will migrate the DoG TTS sound profile in due course - its sounds are very good. The installation went well, although I had to reset the decoder with the Bluetooth password at the outset. However, when I came to run the auto-calibration, the loco did not move and I found that the overcurrent warning was showing in the app. I reloaded the profile as advised in the app, although I wonder if this was strictly necessary. The loco then ran well, but I didn't try autocalibration again. I wonder if the decoder's overcurrent detection is too sensitive? Autocalibration seems to apply instant maximum voltage to the stationary motor, which will draw a much higher momentary current than normal acceleration from a standstill. I suppose it's possible that there's a genuine fault with the loco, but it's only a few years old and not heavily used so that seems unlikely. The overcurrent protection could at least reset itself in a user friendly way when the high current draw has been cleared. Regards, John

I don't think the Class 47 TXS horn sounds are very good - after temporarily downloading them to another TXS diesel loco to compare them with the TTS decoder in my Class 47, I decide to stick with TTS on the 47. Regards, John

Funny that you mention telescopes - I'm just in the process of recommissioning my 5" reflector to show my grandsons the moons of Jupiter, and awaiting a spare part to get the tracking motor working again. Hopefully no PID control will be needed to follow Jupiter! Regards, John

I've experimented a bit more with the PID settings. Anything above single digits for P and I seems to give good results. I've settled on 40/30/0. I detect uneven running by watching the last 2 or 3 wagons of a 7 wagon rake and seeing if the couplings rhythmically tighten and slacken at low speeds - the motion of the loco itself always looks smooth. I couldn't detect any effect from the D factor, so left it at zero. The beauty of the app CV editor is that it's possible to set the train running at the desired speed for testing and then adjust the CVs on the fly and instantly see the effect of each change - it would be hopeless trying to do this using the DCC programming track. Regards, John

I've read the manual and it does give a very good explanation of the PID feedback mechanism, but no real guidance as to typical values. I was surprised that the values that seem to work for me are so far from the defaults, and I just wondered what others had found. Incidentally I would have tried the PA control factors before resorting to PID, but the explanation of CV150-152 on page 116 of the manual is not very enlightening. Has anyone had success with these? Regards, John

I have a Bachmann 3MT Tank loco with 8-TXS decoder running the Black 5 profile (V2). I've set a complex speed curve which gives pretty good chuff synchronisation at low speeds, and as a result I tend to run it more often at low speeds. I've noticed that sometimes when pulling a modest load of 7 wagons at low speed it slows down noticeably, almost to a standstill, when negotiating curves, points or gradients. This is probably at a voltage setting of just 3-5 on the speed curve. I had run the auto calibration prior to setting the complex speed curve. Running at medium and high speeds is fine. I thought at first this was a mechanical problem and spent some time fiddling with the loco, oiling the motor bearings etc, to no effect. It then occurred to me that it might be a problem with the back emf control, so yesterday I bit the bullet and switched to PID motor control (CV 149=1). With the default PID values of 4,8,1 this immediately cured the slowing down under load, but the motion at low speeds seemed a bit jittery. After tinkering with low values of P,I,D to no great effect, in frustration I swiped the CV sliders to the right to give P of about 90 and I of about 40. It then ran very smoothly! So it appears that the jittery motion is caused by too little back EMF correction rather than too much, which had been my first assumption - ie the motor strays too far from the desired speed before the correction kicks in. I just wondered what experience others have had of PID setting, and what typical values might be? Regards, John

I've used the TXS ABC braking successfully with Railmaster/eLink. I used 4 diodes in one direction and one in the other, as in the schematic earlier in this thread. I set it to detect on both rails and stop in a constant distance with autoreverse and all works well - the constant braking distance is fixed under V2. It seems to me very unlikely that your DCC controller would make a difference, since the ABC is activated just by the diodes and the decoder, and doesn't require any command from the controller. I suppose there could be some difference in the waveform or the absolute voltages, but that seems unlikely. So I would agree that your decoder does seem to be faulty and worth returning to Hornby for checking. Regards, John

I must confess that I didn't actually try running it under DCC (Railmaster), but I have now done so, and it works with address 1024. I've also now tried re-loading the V2 profile for my Tornado with the long address still set to 1024, and the loco then failed to respond under DCC, as you discovered. I then examined the CVs by refreshing from the decoder to the app. The address CVs had all been reset to default values - CV1 to 3, CVs 17 and 18 to 192/100, and CV29 to 2. This explains why it didn't respond. I then reset the long address to 1024 by retyping this in the app data screen, and it all worked again. So it looks as though you can recover the DCC operation after the profile update simply by rekeying the long address in the app data screen. What puzzles me is that I'm sure I didn't have to do this with my short addresses after updating the profiles, but in this latest case the short address did also get reset to 3. Regards, John

I hadn't previously tried using long addresses, but out of interest I changed the address of one of my locos from 2 to 1024 (to simplify the binary arithmetic) via the app. The app CV editor then showed the correct values in CVs 17, 18 and 29. I then refreshed the app CV screen to see what had been written to the decoder, and the values were still correct. So is this long address problem related specifically to updating the profile of a loco which has a long address set (I noted that the profile update doesn't seem to overwrite an existing short address, which was a bit of a welcome surprise given that it resets all other CVs to default values), or is it an intermittent problem of long address setting in the app more generally? Regards, John

I had something similar yesterday. Downloading the new profiles appeared not to overwrite the DCC address in CV1, even though the other CVs were reset to the defaults for the profile, so the locos still worked under DCC - except in one case out of 4, where the DCC didn't respond and I think I fixed this by resetting the DCC address in the app. Very strange. Regards, John

I think that would be a great improvement. There are 6 horn functions in the Class 47 TTS decoder and they could replace either the F2 or F3 TSX sounds. I've decided not to upgrade my Class 47 TTS until the TSX sounds are improved. Regards, John