issue Elite - R8247 - Tortoise point not changing polarity

[JohnUSA]

Hi Chris,

Your note:

Remember that if using the 'Elite Menu Acc Address', you need to enter Address 5 and not Group Address 2 for the second R8247. See my earlier reply above for details.

 

 

I'm aware of that, learned that some time ago when I read the manual page 58 and 59, I validated by reading PAD2 address and got 0002 returned representing the 4 addresses 5-8.  I use Address 0005. or 6 thru 8 when programming and testing all 4 ports.

[Chrissaf]

You're on the ball John .... so many others get really confused by Group Addressing vs direct Normal Addressing, which is why I highlighted it in my replies.

[96RAF]

Did we bottom out on the revision state of each PAD John.

[JohnUSA]

Hi RAF96.  Lets say making slow progress.

I have the Elite and five PADs sitting on my desk away from the layout

 

Took the elite with nothing attached and reset it to factory settings per the reset instructions in the manual

Then taking one PAD at a time directly hooked up to the Elite prog outlets I first set then back to factory settings CV0008=8 and then read the CV0007 setting to get the PAD version.

 

The first PAD which I call PAD1 was originally programmed for group 1 being addresses 1 thru 4.  With both your feed back had this working with all 4 ports driving the point motors.  The final change I made to get them working was to set CV1 to 1 signifying group 1 addresses 1 thru 4.  Now the interesting difference of PAD 1 to PAD 2 thru 5 is that PAD1 has the version CV0007 = 121, the other 4 PADs all have CV0007 = 134.

 

So my question is what does version 121 mean? Also as it's the first PAD is there any relationship of future PADs being added to a "base" PAD that has a strange version number.

 

I have stopped at this point, based on your feed back regarding PAD1 I will then reprogram PAD1 and PAD2 to see what happens.

 

Note for Chris, Going back many years I was in IT, I designed complex financial systems before packages were available, I had a team of programmers that I helped them debug programs and I wrote all the system documentation.  So used to reading manuals, code and testing etc.  My downfall is now I'm retired and near to 70 years young my brain is failing me and was hoping to get into Dcc as it was supposedly easier to set up!  LOL

[Chrissaf]

I'll hand the lead on this over to Rob [RAF96] as he has direct access to the R8247 developers within Hornby, whereas I am just a 'user'. My background was in IT too, but dealing with the TCP/IP Router networking side. I would design and price up the networks to meet customer stated objectives and write the technical sections in our Sales responses to customer ITTs [invitations to Tender].

[96RAF]

Talking from the top of my head - 121 may be the very old R8216 Point Decoder, which could only be set to pulse not always on.

 

There is no problem mixing and matching new and old versions as long as you are not trying to cross fertilise across V2.0 PADs where it is possible to use fairly complex grouped or extended port addressing.

 

I have an old R8216 that cannot be updated, and tomorrow I will dig an Elite out with good Prog output and read CV7 for you. I will also dig out my notes on the main PC and see what I observed during testing of V2.0.

 

I will also flag this thread back to Hornby for further comment.

 

In the meantime put the dodgy PAD to one side and press on with the others. It may be that particular unit is faulty.

[JohnUSA]

RAF96.  FYI My order # H00328482 April 17th 2020 was for the elite and 4 PADs.  Without a lot of digging can't recall if the other one was direct or via other vendor.

 

However it's odd that PAD1 being version 121 was the one I got working.  I will now just make use of the others, will ensure all at factory settings and start with programming for group 1 etc.

[JohnUSA]

RAF96 set up a pad version code 134, reset to factory settings, programmed for address 0001 CV3 thru CV 6 = 0 which is the only CV that has to be changed for address 0001 to drive continuous feed on the number 1 port outlet on the PAD.   Also validated CV1 = 1, CV33=0.  I didn't program the other ports.

Unplugged the elite, swapped wires to the track outlet.  Result was on plugging in the elite the switch automatically fired throwing the arm to one side in this case it was on the right and it moved to the left.  Tried changing direction using the control switches, could hear the motor try but the arm didn't move remained on the left.

 

I tried to manually move it back but it's under control and could not be moved.  I detached the wires directly from the motor.  I then manually moved it to the right.  On attaching the feed again nothing occured.  I pressed the control 1 to drive to the left, the switch worked moving it to the left.  But can't change back.  I also did the same test but started with the arm on the left.  It remained on the left couldn't get it to go to the right.

 

Swapped the wires around at the motor, nothing happened on attaching, pressed control 1 showing left arrow, the motor drove the arm to the right. 

 

So from the above test I conclude the feed is continuous.  But the polarity is not being changed.  I replaced the 3 wire to 2 wire adaptor from DccConcepts that is built to enable polarity to be changed with a new one to ensure I hadn't damaged the one being used in previous tests

 

Using a multi meter I checked the power at various connections.  Forgive me electrical stuff is not my strong point, even how to read a multi meter.  LOL

 

At the track connection into the PAD get a reading of about 17.  Then checking the output at port 1 I only get one reading placing the probes on the +   -  screws about 25.  At the switch motor the reading is about 20.

 

Like your idea of using led lights to test various connections, don't have that capability yet.

 

Hope all above doesn't confuse.

[96RAF]

@John

From what you have reported the PAD has set to continuous and is responding to throw commands and is setting the associated floating port to switched negative, hence completing the circuit with the positive C terminal and moving the motor in the selected direction. What it will not do as Chris explained way back is drive the motor in each direction directly. It has to go through the 3-2 wire adaptor to get the polarity switch. By swapping the PAD output physically you have proven the adaptor. Without checking the actual port side poutputs we cannot be sure the PAD is outputting to both directions.

 

Maybe Chris can chip in again whilst I wait for input back from Hornby.

 

Aside...

Noddy guide to using a multi-meter. Plug the probe leads into the holes associated with the reading tou want to make. Usually Common (black) and V/A/Ω (red). Lets stick to voltage measuring for now. For the checks you are doing set the dial to DC Volts range 20 or more. AC Volts shows with a wavy line (~) and DC Volts shows as a solid line with a dotted line below it (...) is the best I can do on a keyboard but it is drawn upside down.

 

Track voltage into the PAD is DCC and should be about 15vAC. Note the reading is on the AC Volts range.

 

Output across the PAD C and +/- terminals is selective as switched and should be 12-14vDC. Note the reading is on the DC Volts range and you should measure that with the 3-2 wire adaptor removed. Select the other direction and measure across the C and other port terminal.

 

If required you can check each port address +/- terminal in turn noting that all C terminals are ganged to common internally.

 

Chris can advise on what DC Voltage to expect at the motor with the 3-2 wire adaptor connected.

 

Setting up some leds as test lights is easy. Any two legged led with a 1K ohm resistor attached to one leg. Plug the anode leg into the C terminal and the cathode leg into the + and - terminals in turn. Two leds makes it easier as you can do both port outputs at once, or if you can get hold of a common anode 3 legged led then the centre leg goes to C and the outer legs each with a resistor in series go the + and - terminals. Note common cathode leds are contra-polarity for this job, you need common anode. If you cannot solder then you can easily rig leds and resistors into a piece of choc-bloc terminal strip. A whole row of them could be connected to each port of the PAD.

[Chrissaf]

Just to recap on a few of the points as requested by Rob..

 

Point 1).

When measuring the DC voltages on the 3 terminals of the decoder ports. You must take the measurement between the C terminal (red lead of the multimeter plugged into the V DC range socket) and one or other of the + & - terminals (black lead of the multimeter plugged into the Common socket). + & - do not represent polarity, both terminals are either floating or pulled down to the zero volt rail (negative) by a FET (a special type of power switching transistor).

 

The + & - terminals are what they call floating voltages and if you try to measure a voltage directly across the + & - terminals you might get very strange reading values, particularly if nothing is wired to those three terminals and there is no load to suppress the floating voltages. A floating voltage requires a load in order to read a valid reading.

 

This is effectively what I drew in my sketch on Page 2 of this thread.

 

All output port measurements must be taken relative to the decoder C terminal.

 

Point 2).

If for whatever reason, the output of the decoder ports are still being pulsed and not 'always on'. The default pulse width is 100ms. The measuring latency of a digital multimeter is significantly longer than 100ms. Thus, even if the DC voltage pulse is there, it is very unlikely to register on a digital meter. On an analogue meter, one would expect to see only a kick in the analogue meter needle before returning to zero.

 

However, that said. The movement of the Tortoise arm [but always to one direction] could be as a result that the length of the pulse has been changed from the default 100ms to something longer say a few seconds. The R8247 supports a configurable pulse length up to 25.5 seconds. Or some other strange electrical situation is at play here ... see edit.

 

EDIT: This Tortoise arm movement, wasn't that what you reported in your original post. It may have something to do with the internal CDU capacitors charging up [clutching at straws comment] having an internal effect on the output FET semi-conductors

 

To obtain confirmation that a pulse or 'always on' is present, a bulb or better still an LED in series with a 1,000 Ohm current limiting resistor can be used. The latency of the LED in particularly is micro-seconds, so will instantly flash with a pulse of 100ms. If the pulse is longer than 100ms or 'always on', the LED test will clearly show up what is actually happening on the decoder before the 3 wire adaptor is attached.

 

What you are ideally looking for in an LED test. Is that one of the two LEDs wired across a decoder port lights up, and when the port is operated the first LED goes out and the other LED comes on. Note that initially, you might have to operate the port in both directions to get the decoder synchronised before you see the above observation.

 

[Wiring as below]

[ Decoder + terminal  to LED 1 negative side plus LED 1 positive side to resistor to Decoder C terminal to resistor to LED 2 positive side plus LED 2 negative side to Decoder - terminal ]

 

But note that an LED is polarity sensitive. The positive side of the LED must be connected towards the decoder C terminal. On a standard round LED, the positive side is the longer of the two legs. The 1,000 Ohm resistor can go either side of the LED, it just has to be somewhere in series. The boxed [ R ] in my drawing on Page 2 of this thread can be used to represent the two components, the LED and the Resistor for testing purposes and replicates the [Wiring Text Description] above.

 

Point 3).

Voltages...... The 'Always On' voltage specified in the R8247 manual states that 14 volts DC is the nominal voltage. This is what should be measured when the port output is truly 'always on' and after the internal CDU has discharged. As previously stated, you will not be able to get a 14 volt DC reading on a digital multimeter when the output is a 100ms pulse, the voltage is not there long enough to fully register within the meter.

 

When the 3 to 2 wire adaptor is added to the circuit, there will be a slight voltage drop across the switching power transistors of the adaptor circuit plus a silicon diode which is also part of the 3 wire adaptor. Looking at the adaptor circuit diagram, I estimate the voltage drop to be a nominal 1.8 volts. Thus, the resultant DC 'always on' voltage appearing across the Tortoise motor terminals should be a nominal 12 volts give or take 0.5 volts or so.

 

Which, of course, should reverse polarity when the port is operated by the DCC controller.

[JohnUSA]

Thanks guys, you both are very patient and great detailed feed back.  Looks like I need to get to grips with the tracing of electric flow thru the setup one step at a time, and get the LEDs set up couple this with more knowledge using multi meters!   You really can teach an old dog new tricks.

[96RAF]

I may not get a reply from Hornby until Monday now, especially if they wanted to check your order reference to see what was sent.

 

I checked my PADs today. The R8247s I updated to version 2.0 are all returning value 135 for CV7. Value 134 seems likely to be for PAD version 1.0 but I still need to dig out my files to check. I thought I had one that wouldn’t update that I could ask but its hiding somewhere elusive for now.

 

The old R8216 can only be interogated in Reg programming mode, not Direct programming mode and does not return a value for CV7, so I guess it is write only.

 

[JohnUSA]

Chris, I took a step back.  I just set up the PAD version 121.  Reset to factory settings being group 1 with addresses 1 thru 4.  I hooked up two switch motors on channel 1 and 2, addresses 0001 and 0002.

 

Validated the factory settings by reading CV1 = 0001, CV33 = XXX, CV3 thru CV6 = 0001

 

The only settings required to be changed were CV3 thru CV6 (being the four channels/addresses) from default setting of 0001 to 000 allowing for continuous feed.  It worked fine, played around with both switch motors all good.  However note CV33 = xxx.  assume this means doesn't exist in the old PAD version.

 

Replaced PAD version 121 with a version 134.  Reset to factory settings being group 1 with addresses 1 thru 4.  I hooked up two switch motors on channel 1 and 2.  Updated the initial group 1 address to group 0005 addresses 5 thru 8 then updated CV3 thru 5 from 1 to 0.

Validated the settings by reading CV1 = 0002, CV33 = 0000, CV3 thru CV6 = 0000

 

Making progress, address 5 didn't work correctly the switch fired but arm didn't move.  However address 6 worked fine.  I checked CV3 was correctly set as that relates to address 5 

 

So I think you should hold fire until I have diagnosed this further by adding all four motors to a PAD to see if all work or not.  And test all other PADs. Potentially a PAD issue?  all my testing prior to today was always using the base address, i.e. 1 or 5 etc.

 

[Chrissaf]

Perhaps swapping the 3 wire to 2 wire adaptor on Ports 5 and 6 and then see if Port 5 now works and 6 doesn't would be a good diagnostic step to take. It may be the Port 5  3 wire to 2 wire adaptor that is faulty.

 

Standard diagnostic testing procedure is to substitute components and see which component the fault follows.

[JohnUSA]

Hooked up 4 x 3-2 wire adaptors and switch motors and proved PAD 2 version 134 address 5 fires one way only, all other addresses work fine.  I also simply swapped the 3-2 wire adaptors and switch motors from 6 to 5 and 5 to 6 to eliminate possible issues with the adaptor/wire/switch motors.  Address 5 still not working, address 6 working fine based on using all gear that was attached to 5.

 

Replaced PAD 2 addresses 5-8, with a new PAD 3 addresses 9-12 all worked fine.  This confirms that my PAD 2 address 5 is faulty.  Will validate 2 more pads later.

 

Its just my (our) missfortune that I happened to pick up the faulty unit as the first version 134 to work with as well as focused on only using the first channel that's faulty for intial testing before expanding to other channels and other units.

 

I feel bad to have put both Chris and yourself thru the support effort which I greatly appreciate.  However on the plus side I have learned a lot.

 

However I obviously was supplied PADs that are not the latest versions along with one that appears to be faulty.  Not happy about that.

 

[Chrissaf]

It does look conclusively to my mind that PAD2 port 1 [address 5] is faulty and I totally agree with your latest test results. And it does look like you will now be making significant progress.

 

I feel bad to have put both Chris and yourself thru the support effort which I greatly appreciate.  However on the plus side I have learned a lot.

 

We all learn from these long 'ping pong' dialogues. Prior to this thread, I had not looked at the details of the Version 2 PAD. All my R8247s are version 1. So my learning experience has been from this thread to get an appreciation of CV33 and what it does in a Version 2 PAD [R8247].

 

I too, learn far more from trying to resolve an issue compared to something that goes right frist time.

 

Just more out of curiosity rather than anything else. But I find Tortoise motors physically very large and can be difficult to mount directly under the baseboard where point operating bars of multiple points are in very close proximity. I don't know about the States, but they are also comparatively expensive in the UK to buy and although previously in the past have been high on people's purchasing wanted lists are steadily loosing favour over here. They hardly ever get a mention on the forum these days.

 

So what made you choose Tortoise motors over alternative 'slow action' point operating solutions that are available. DCC Concept iP Digital point motors for example have an integrated decoder and do away with the need for an external PAD like the R8247.

[JohnUSA]

Hi Chris, reason for using tortoise.  lack of knowledge and lack of research before jumping in.  Only found DccConcepts because of this issue also now working with Dcctrainautomation.  As only just started the first section of my plan may have a complete rethink.  Will put down the cost to date as learning/training fees.  LOL

[JohnUSA]

Based on your question re tortoise did a little research, video is old may not reflect currrent models.

 

[Chrissaf]

For information. The Cobalt in that video is basically the original Analogue Cobalt. The video dates from 2017.

 

The currently available Cobalt iP Digital on the other hand, is similar to the video Cobalt but has an integrated DCC decoder.

[JohnUSA]

Hi RAF96, sorry for late update but just finished validating the final two PAD's.  As previously noted I'm not happy that my order for the Elite and four PAD's included not just the old version of the PADs but also a faulty one.

 

Before I contact Hornby support directly you mentioned you were in contact with Hornby regarding this issue related to my order # H00328482 April 17th 2020 which they supplied all old versions vs the new version.  Did you get any feed back?

 

Again appreciate your support and efforts.  I still can't believe the odds of my initial testing being based on one faulty port out of what was available i.e. 4 PADs x 4 ports.

[96RAF]

Hastened John.

Rob