Forenkling af DCC SPI kredsløbet.

Så er jeg endelig flyttet ind og har alt i orden - ok, det sidste er en løgn, der er flyttekasser overalt, intet er hængt op på væggene, TVet er ikke tilsluttet, ... men man skal jo også have lidt tid til at rode med noget sjovere. Så jeg fortsætter nu hvor jeg slap for lang tid siden i min sidste blog post.

For nu at slå det helt fast fra starten: Det jeg laver her er IKKE den letteste måde at få et DCC signal (køb en Intellibox, SPROG, whatever). Det er heller ikke den billigste måde at få et DCC signal fra en Raspberry pi. F. eks. ville den her med in Arduino clone og motorshield fra Kina formegentlig være langt lettere og billigere. Men jeg finder det nu engang interessant og afslappende at sidde og nørkle med at lave det selv ud af relativt simple komponenter.

Sidst jeg var igang havde jeg brygget følgende kredsløb sammen på mit breadboard:

og det virkede egentlig fint nok. Men det bruger en del IC'ere. For eksempel er der brugt en 74HC32N bare for at få et enkelt OR gate. Naturligvis kan det godt være at de rasterende or gates kan bruges senere, men... det bliver stadig til en del forbindelse der skal laves.

Jeg har også set lidt på RailCom. For at genere et Railcom cutoff i DCC signalet skal der bruges en timing på 29ųs istedet for de 58ųs der ellers bruges i DCC. Mit tidligere kredsløb er baseret på en timer med en 116ųs klok - altså 58ųs høj/lav tid. Hvis jeg istedet kører en 58ųs klok, så skifter den mellem høj og lav hvert 29ųs, giver det noget der kan bruges til at time cutoff. Og da jeg har en ekstra gate op min 74HC74 D flip-flop kan jeg køre 58ųs klokken igennem en klok devider og få den 116ųs klok jeg bruge tidligere - men den ekstra bonus at jeg nu er garanteret en 50% "duty cycle", ikke de 50.3% jeg havde tidligere. :) 

Jeg er allerede gået bort fra RailCom support igen - Programming on Main kunne være meget nyttigt en gang imellem, men ikke nok til at jeg vil lave boostere etc mere komplicerede. Resten af RailCom's features er ikke noget der giver nogen nytte i mit tilfælde.

Men mens jeg rodede med tanken om en 58ųs klok gik det ret åbenlyse op for mig - det er kun "raising edge" der har betydning for en D-flip flop, så der er egentlig ingen grund til at lave en edge detection pulse. Så det eneste jeg egentlig har brug for er at bruge 58ųs klok når der sendes 1, og 116ųs når der sendes 0.

Så jeg kom frem til følgende kredsløb:

Nederst til venstre er det den sædvanlige 555 timer, nu sat op til 58ųs - og et potentiometer er tilføjet så den kan justeres præcist. Jeg har stadig en duty cycle tæt på 50% - det er ikke nødvendigt, men det skader ikke.

Nederst til højre er den D-flip-flop der generere 116ųs klokken,

Øverst til højre er der en 74hc4053 der kan multiplexe/demultiplexe to signaler. Den får de to kloks som input, og så vælger den 58ųs eller 116ųs klokken alt efter om der skal sendes 1 eller 0 (PACKAGE_IN).

Den sidste D-flip-flop genererer så DCC signalet ud fra den valgte klok.

Det giver følgende resultat:

Channel 0 er 58ųs klokken. Channel 1 er 116ųs klokken. Channel 2 er den klok der er valgt alt efter input bitten. Ca 1/3 inde skiftes den fra at sende 0 til at sende 1. Channel 3 er DCC outputtet der ser ud som det skal.

Man kan dog godt få en lidt mere uheldig timing i skiftet, som der vises her:

Input skifter her fra 1 til 0, og i channel 4 genereres der et forkert output - både den lave del af DCC 1 or den efterfølgende høje del af 0 bitten bliver for kort.

Der er to problemer her: For det første skiftes der output bit mens den ene klok er høj mens den anden er lav. Dette giver en ekstra raising edge der får DCC signalet til at skifte for hurtigt. Det er derfor den lave del af 1 bitten bliver for kort.

For det andet skiftes der fra 1 til 0 midt inde i en cycle på 116ųs klokken. Jeg har mærkeret de cycles der egentlig skulle generere henholdsvis 0 bitten og 1 bitten med hvidt i Channel 0 og Channel 1. Der er sammenfald og det korrekte signal kan ikke genereres.

Men heldigvis korrigerer kredsløbet sig selv når dette sker. Lad os sige at signalet 1010 skal genereres og vi får startet "uheldigt". Jeg har ikke kredsløbet klar til at generere sådan et input endnu, så det her er et tanke experiment - ignorer at Channel 3 og 4 ikke viser signalet.

Som allerede beskrevet viser de hvide markeringer hvilke cycles kredsløbet bruger til at generere de første to bits - med et forkert resultat. Men de efterfølgende cycles (mærkeret med gult) er allerede korrekte.I de cycles der er mærkeret med gul (og alle efterfølgende cycles) vil DCC signalets raising edge altid komme når både 58ųs og 116ųs klokken er høj. Og da jeg planlægger at bruge DCC signalets raising edge som klok i et shift register der indeholder kommandoen der skal sendes, betyder det at jeg altid vil skifte mellem 58ųs og 116ųs klokken når de begge er høje. Skiftert mellem de to klokke kan derfor udføres uden "støj på linien".

Så kredsløbet vil automatisk bringe sig selv ind i den konfiguration der genererer det rette DCC signal efter den første 0 bit, selv hvis det får startet "forkert".