Loco Address 63 operates accessory decoders

[Petery]

Have found that if a loco is programmed with address 63 any Hornby accessory decoders operate Port 1 and no other point control is possible until Elite is powered off and back on.

Happens with 2 different Elite controllers on 2 completely seperated layouts. My layout uses 2 R8247 decoders and they both fire Port 1. Mates layout uses multiple R8247 decoders and they also operate Port 1 then lock up.  His layout has Elite, Select and an ECOS controller all working together and the problem also occurs with just theECOS controller running the layout.

Loco address 62 or 64 have no problems, things work as expected.  Elite controller is running Ver 1.44 firmware.

Is this problem universal or just Hornby software/firmware/hardware?

[Petery]

Should add that problem occurs when throttle is operated on loco address 63. If no throttle command given the system operates normally. 

[96RAF]

Are all Elites running v1.44.

What are rev states of Select and Ecos.

R8247 lock up after port 1 is operated is a known bug associated with Select v1.1 only.

[96RAF]

I have hooked up an R8216 Acc Decoder (Group 1 allocated addresses 1-4) and an R8247 PAD (albeit updated to v2.0 - Group 3 allocated addresses 9-16 for 8 port mode use) on my test board driving solenoid points and signal lamps.

 

My Elite is at v1.45 and Select Walkabout is hooked up at v1.6.

 

Acc Decoders work OK and there is no lock up after port 1 is used. I presume you mean port 1 regardless of address as you talk about multiple R8247s.

 

No accessories work from the Select as my points/signal addresses are set outwith the allowable Select points range.

 

Selecting Loco 63 has no affect on points. Operating point 63 from the Walkabout Select has no effect as I have no Accessory Decoder set on that range. Throttling up Loco 63 on the Elite has no further affect on the points.

 

I am unable to confirm your fault with the data provided, but it is possible the revision state of your other kit may have an effect, especially if the Select is v1.1 (start up 11-30-03).

 

You say the problem is also there when the Ecos is working stand alone (presumably when working in concert with the Hornby controllers it is in Sniffer Mode) which infers that the problem is a step away from the Elite. I see there is a post on another forum talking to an Ecos working in concert with RM which tends to concurr my thoughts about this.

 

Until we get more info then I am afraid we are stalled.

 

 

[Petery]

The spam limit is annoying!

My Elite is running Ver 1.44.  I do not have Select units, but my mate does.

R8247 Accessory Decoders programmed to operate points 1 to 4 then 5 to 8.

My layout works as it says on the tin, until I program loco address 63 and operate the throttle thereby causing acc decoder 1, port 1 and acc decoder 2 port 1 to operate And blocking any further operations of either acc decoder. Power on reboot of Elite is only way to restore normality. 

Mates layout does the same thing irrespective of which controller he uses. His EcOS, Elite and Selects work via the EcOS sniffer cable to the Elite and then via Hornby expressnet to Selects.  Not sure what version he’s running in the ECOS or Selects but his Elite is Ver 1.44. 

Is it possible to update the firmware of the R8247’s?

[96RAF]

@Petery

Your initial posting limit is only for the first 24 hours, then you can post as often as you like.

 

Thanks for the additional info. I will flag that to Hornby, which may help in any investigation.

 

It is possible to update the firmware of R8247s to v2.0 but I do not think Hornby has announced that update service yet. You could ask HCC. What you can try in the meantime is a reset of the R8247, which will put the port addresses back to default (1-4) and mean reprogramming the second one back to its Group 2 port addresses (5-8). Same technique as for a loco decoder simply write value 8 to CV8.

 

For my testing I didn’t have an actual loco programmed to address 63, I just selected it on the Elite. I could plug a decoder into my ESU test rig and give it address 63 just to see if an actual load makes any difference.

 

The ‘mechanics’ behind R8247 lockout is described here (scroll down to known faults). 

http://www.halton96th.org.uk/page16.html

It is possible that there is a similar trigger from a different source putting the R8247 into the same ‘flutter’ induced fault mode.

 

Can your mate induce the same fault if he uses RM rather than the controllers direct.

[Petery]

@RAF96

thanks for the help so far.  I’ll speak to my mate about running things with Railmaster to see what happens. 

Read your page on the known fault and that sounds very similar to the problem we have encountered. 

Anyway, what would model trains be without some head scratching?

ill read up on the R8247 update and see what occurs. 

[96RAF]

The manual covering both versions is here...

https://www.hornby.com/uk-en/downloads/view/download/item/2212

 

Let the forum know how you get on with a PAD reset as that will put its ducks in a row again to give us a known start point. Then record your button pressing actions after that until and if the fault returns. A bit of a pest but all very necessary to get to the bottom of this.

[Petery]

Morning RAF96.

I have a 3rd PAD, brand new that will be a test bunny as well.  I have no idea if its  a Version 2 as there no obvious indication on the box.  When I read the Version CV it comes back with 121.

You say its possible to update to aVer 2 but there's nothing on Hornby site that seems of use. Would you have some insight that you are willing to pass on?

As for PAD #3, I did basioc programming this morning following the normal instructions in the box including the setting Port 1 to a 60mS pulse.  I then carried out the 8 in CV8 reset and that did indeed reset it to defaults on the port output to 1mS or if you like CV515-518 read 001.

I've printed off the manual from Hornby and we'll have a play, when I get home from my train club this afternoon.:-) 

[96RAF]

That is correct Petery value 121 is version 1 and v2.0 will return value 135.

If your third PAD was V2.0 the box would have a prominent sticker showing this...

/media/tinymce_upload/ea3e23a98e50f09fdac11e8dcc23b798.png

 

With regard to updates, v1.0 PADS (R8247 only - not R8216 as it is pulse only) can be updated but it would have to be by return to works same as for the Select update as the PAD has no way to connect directly to a PC to use an installer.

 

At the time Hornby said the Service Department wasn’t set up to do this nor had the details or costs of any such campaign been addressed. The pandemic then intervened and my guess is many such follow on projects were furloughed along with the staff.

 

The Select updates were never campaigned on the website and it was only by dint of forum discussion that the update facility became apparent.

 

I suggest a call to HCC to ask if the Service Department can and will do the update the PAD to v2.0 yet and if so at what cost. They may not know about it yet though if the tasking is stalled.

[Petery]

Evening all,  thank you for the response Raf96.  Given that I’m in Australia the desire to send decoders back to Merry England doesn’t float my boat so I’ll stay with what I have. 

i did manage to fit 2 leds to port 1 of test PAD and when the loco 63 fault is created one of the leds lights up then pulses. Tomorrow I plan to make up more led test sets for the remaining ports to find out what happens. Yes, I did install a resistor in the circuit. 

To be continued. 

[96RAF]

Yes being in OZ does male you think twice about posting things to UK.

 

That pulsing fits in with the induced fault theory as the PAD capacitors flatten and it goes into flutter.

Obviously at v1.0 your PAD can only light one led or the other, not both at once.

It will be interesting to see if the other ports are disabled but I guess they will be until a power down or reset.

 

Is this PAD operating stand alone or is it hooked to the track with loco 63. Does the fault still occur if you take loco 63 off track but operate it as a phantom. If only when on track that would point to the actual loco being the trigger, although you said previously there is no fault if its on adjacent addresses 62 or 64. Can you confirm that is the same loco on those addresses or different locos.

 

This fault is normally induced by an external problem, which can be as simple as a derail causing a short if your points are rigged from the track signal.

[Petery]

Hello Raf96,

well, I tried all sorts of combinations of loco addresses PAD addressing this morning all without success.  Use 63 loco address, turn the Elites knob and everything goes to poo.  Power on reset the only way to recover operations of the points  

My loco 63 is a phantom as I’m not changing an existing loco just to change it back.  Therefore I’m believing the fault to lie within the V1 PAD firmware.  Prove me wrong Hornby

[96RAF]

OK Petery.

 

Further investigation obviously required, although v1.0 has been around for an awful long time. We can only assume no one has ever tripped over the fault by use of loco address 63 before until now.

 

Listen out, but it may go quiet for a while.

[96RAF]

@Petery

I can probably revert the programming of firmware of one of my v2.0 R8247s to v1.0 if I can locate the hex file, as I have the necessary kit and know-how to do it.

/media/tinymce_upload/c154ff9ed6faf49d15fdac0e5f319a02.jpg

If I can replicate the Loco 63 induced fault then it will add weight to the investigation that has been suggested to Hornby. Stay tuned.