If ...

....

Oh dear Greg, in the nicest possible way am going to agree and say you sure didnt. High as a kite or April 1 ?

CHeers, Simon

Reply to
simon
Loading thread data ...

My calender says 7th June and I'm definitely not high! (well, I had a glass of Chateau Cardboard Rosee with my dinner last night)

Feel free to put my description into more precise technical terms, but the date and general direction is correct.

Regards, Greg.P.

Reply to
Greg Procter

Sorry, thought you must be taking the p*ss with " binary... Since then it has been extended to trinary" The rest was interesting. Cheers, Simon

Reply to
simon

No. That's my not very technical understanding of reading the technical background. Lenz used Motorola(?) ICs developed for garage door openers and the like. The output of the sender IC was in trinary but he limited it to binary output.

Reply to
Greg Procter

No confusion, DCC is binary. Normal ("two digit") addresses are 0 (broadcast) and 1 - 127 which are transmitted in the first byte of the packet. Extended ("4 digit") need two bytes but do not allow the full range up to 65535 that you might expect.

MBQ

Reply to
manatbandq

There were a number of early DCC systems including Astrac, the "motorola" system and Zero-1 but NMRA DCC was never based on garage door opener chips.

MBQ

Reply to
manatbandq

Astrac was a frequency control system. Zero-1 was digital but used SCR/thyristor motor output which is half-wave.

I've built DCC decoders using garage door opener chips.

Reply to
Greg Procter

I don't know when Herr Lenz first started development, obviously before

1978. The problem with a "standard" is that it tends to hang around long after the reason for it's inception is forgotten.
Reply to
Greg Procter

Just to clarify that. If the first bit of the address byte is 0, then the next 7 bits give the address, 1-127 ( as already said - 0 = all devices )

If the first bit is 1, then extended addressing is enabled, and the remaining bits together with bits from a second 8 bits provide the address. This instantly limits things to 32767, but in fact there are three extended modes, giving 9 bits of address for a basic accessory decoder or 11 bits for an extended accessory decoder. The second bit is always 0 for these two modes, and the basic accessory decoder just uses the remaining 4 bits of the second byte as command data, while the extended one has extra bytes of data.

This leaves the '11' value for the first two bits and only 16384 'extended addresses' but even there only 9984 are for Multifunction decoders. The rest are reserved for further expansion ;)

In any case if you have a layout that needs all of the addresses then I think we would all be around to play with it :)

Reply to
Lester Caine

That's interesting, I hadn't appreciated it was that old! That would exlpain why they didn't just use CAN for the bus (cheap as chips). I have to say it seems a bit daft adopting such an old standard.

Richard

Reply to
beamendsltd

"BeamEnds" wrote

Where did I mention eBay? The decoders were bought from a Hornby retailer.

John.

Reply to
John Turner

Well now I know how old the standard is I'm not surprised it's a bit of a mess! DCC2 anyone?

Richard

Reply to
beamendsltd

Indeed, a major drawback of proprietry standards, or ex ones. The automotive world put itself through hoops before realising open, or at least public, standards are a much better idea - as did the computer world (where would we be without ARPAnet?). I can't help thinking that DCC is going to reach a "crisis" point sometime in the near future and get re-invented (CAN sounds good)- and all the current efforts will have been wasted.

Richard

Reply to
beamendsltd

NMRA DCC?

MBQ

Reply to
manatbandq

I think we need to distinguish here between a simple control system that can provide several Amps of power and control over a pair of tracks, and a control system that links multiple units together via a multi core cable.

DCC is an elegant solution to the first and irrelevant to the second.

I think the thing here is that the second you add a control cable that does not involve the power aspect then there is no need to bother with the restrictions of DCC, so perhaps a DCC2 is appropriate, but as a non-mobile comms standard, keeping DCC for controlling vehicles on the track?

Reply to
Lester Caine

OK, I tried to keep things simple. Unfortunately, your clarification isn't quite correct. The extended address range for multifunction (loco) decoders uses the range 192 - 231 (C0 - E7 hex) in the first byte of the packet. This is concatenated with the second byte to give a range 49152 - 59391 (C000 - E7FF hex). The two most significant bits can be discarded and the extended address range is, thus, 0 - 10239 (0000 - 27FF hex). This is usually restricted to 0 - 9999 as "4 digit".

MBQ

Reply to
manatbandq

Your right - I should have used the hexadecimal calculator :) There are 40 256 blocks not 39. In any case I was just trying to show why the much restricted address range even though it's two bytes.

Reply to
Lester Caine

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Richard

Reply to
beamendsltd

There's no cables needed - CAN is a 2-wire bus (usually has 4 in most applications, but only for reduandancy as such a use is considered at least mission critical, if not safety critical) and is suprememly immune to noise (i.e. dodgy contact with rails) etc, plus it is well understood (it's used just about everywhere - including UK 12" to the foot), decoders are two a penney and have built in sort circuit, over-voltage and reverse voltage protection, and it works down to

6.5V (or similar, it was a while ago I used it) if it has to.

Richard

Reply to
beamendsltd

Well, I never had them certified by the NMRA, but the design was the one published by Elektor Electronics about 15 years ago. (Ma-Lenz system) The original Ma-Lenz system was a small protocol change to allow compatibility with the Ma impulse reversing system, which has nil effect on accessory decoders.

Regards, Greg.P.

Reply to
Greg Procter

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.