At 02:49 PM 5/1/96 +1000, you wrote:
>

[snip]

>How?
>----

Based on my command station work with DCC and PICs, I think it can be done
quite simply.  The timing is from the zero crossings.  Use the DCC signal
and set up the PIC to interrupt on port B change.  Use the timer to time the
time between interrupts.  Check the time and see if it is a one or a zero.
The code to decode the packet is pretty straight forward.  I wrote a tool in
C to test my command station implimentation.  I uses times from the MPSIM
trace file and determines if the timing is correct for the DCC signal.  It
is just a development tool but I am willing to send it to you "as is" to
show how I detected packets.  There are probably some improvements needed
but it is basically a decoder (Note that the time limits used are for the
command station, not the decoder since it is testing the command station).
I think you could do this with a 4MHz 16C84.

>Wish I knew. Can it be done at all? My usual ploy for reading bitstreams is to
>have a periodic interrupt to sample the input. I do RS 232 using this method
>with an interrupt rate of 104 us for 1200 baud input. To sample a 52us signal,
>say 2 times, would give about 25 steps @ 4MHz or 60 steps @ 10MHz. The first is
>just too difficult for me and the second is daunting.

Agreed.
>A counter/capture would
>have been great but 16C84 cousins have already been ruled out.

Agreed!!!

>A Port B
>interrupt may be a problem due to noise(?). One way around this could be a
>40 us interrupt that enables the Port B interrupt. The Port B interrupt
>disables itself and sets
>off the time again. This will give the main loop quiet periods to get on
>with life in general.

I think this is the most likely solution.  I am not sure that noise is a
problem.  Some test would tell but this is the first approach I would take.
Another solution to the noise would be to "filter" the DCC signal with
software.  i.e. ignore polarity shifts that are smaller than the DCC 1's
time.  I still think with a +- 12VDC (or more I use +-18VDC) signal, that
noise on the zero crossing should be rare.  The protocol recommends
repeating packets as frequently as possible so it may not be a problem at all.

>There remains the option of a loop timed just
>right which also does PWM. How difficult would this be? Are there any other
>options I haven't considered? Don't tell me a device to run toy trains is too
>much for a PIC or any general purpose micro to handle :-)
>

The complexity of the timed loop and syncing with the command station
(streached zeros, timing tolerances etc) could be hard.

>Misc
>----
>The damn things are cheap(AU$50?) and getting cheaper :-) So why build it?
>Because
>it is there. Because you can change the software to keep it up to date with new
>packets. Because you can implement special requirements. Because using PICs
>is fun.

All very good reasons.

>
>Decoders for driving accessories don't have size restrictions and may have more
>options for implementation.

This may be the first thing to build, then use what you learn to build the
loco decoder.  BTW I bought a decoder for $29.95 (US) to test my command
station.  It may be a little large to put into an N scale loco though.

>
>The other missing bit is the control station. This could be a PC driving a PIC.
>This, again, is a lesser problem and is solvable. It is also the most expensive
>part of a DCC setup and is more easily justified on economic grounds.
>

I am working this part of the problem and have a workable solution. (As I
described via direct e-mail to you).

Regards,

Norm