ShowDCC - un "sniffer" pt. DCC

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Revin acum si cu analiza semnalului DCC generat de centrala digitala DIY NanoX a lui Paco [cu NanoX_nozero_4MHz_120111.HEX] http://usuaris.tinet.cat/fmco/nanox_en.html :

Proaspat pornita, surpriza: similar centralei Roco, NanoX transmite continuu pachete 'idle'. De remarcat un preambul de sincronizare ceva mai lung - similar Piko de data asta (22biti vs. 15biti).



Conectez la centrala un MMaus si rotesc butonul de viteza: centrala incepe sa transmita, catre decodorul cu adresa 57, pachete de viteza in 128 trepte, precum si pachete de functii F0-F12 intercalate cu cate 2-3 pachete 'idle' in succesiunea viteza - grup1 - viteza - grup2 - viteza - grup2bis.



Cresc numarul de locomotive comandate si din nou surpriza: pachetele 'idle' continua sa fie transmise. Se observa gruparea comenzilor de acelasi tip catre toate decodoarele (din nou similar Piko) spre deosebire de Roco care grupeaza comenzi de tip diferit catre acelasi decodor.



Crescand numarul locomotivelor comandate simultan la maximul suportat de centrala (16), pachetele 'idle' se raresc, dar nu dispar de tot (ciudat, intrucat nu transmit informatie utila si nu fac decat sa mareasca nejustificat delay-ul comenzilor).



A venit si randul comenzilor catre decodoarele accesorii (macazuri, semafoare). Iarasi similar centralei Piko, transmiterea acestora are loc atat timp cat este tinuta apasata tasta respectiva, cu diminuarea corespunzatoare a refresh-ului locomotivelor.



De apreciat: NanoX permite setarea modului de adresare a decodoarelor accesorii, fie 0-511 (NMRA, Roco), fie 1-512 (Piko, Lenz, ShowDCC, Rocrail) :aplauze:

La final, si un mic "-": analizand forma de unda, se observa un segment asimetric de 0,25mS ce precede fiecare preambul. Fara a avea vreun 'efect advers' sesizabil, apare totusi o componenta continua DC = 0,47V suprapusa peste semnalul DCC.

 

sogard_2003

Well-Known Member
Trenulist
19 Ianuarie 2016
3.617
66
Bucuresti
LOCATION
Bucuresti
Din cate imi aduc aminte un decodor este programat astfel incat sa nu ia in considerare semnalele mai mici de 2v, componenta continua in cazul asta nefiind luata in considerare de microcontroller.

legat de faptul ca poti comanda cu centrala pana la 16 locomotive vreau sa imi explici mai pe indelete chestia. eu presupun ca se limiteaza datorita frecventei mici.

Oricum ca idee e destul de complicat sa "tii frau" la 16 locomotive deodata chiar si cu calculatorul.
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Nu este vorba de un semnal mic - semnalul DCC are 16V; componenta continua apare din asimetria celor 2 alternante ale semnalului (banuiesc ca este vorba de o 'scapare' de programare a .hex file-ului. I-am scris lui Paco dar inca nu am primit raspuns.

Legat de nr. maxim de locomotive, problema sta in felul urmator:

Comunicarea de date intre centrala si locomotiva, este supusa intrinsec pierderilor de date (roti/sine murdare, macazuri...). De aceea, pt. a evita posibilitatea pierderii unei comenzi, NMRA recomanda transmiterea continua a pachetelor ce descriu starea unei locomotive (viteza + functii) = 'refresh'.

In mod evident, cu cat sunt mai multe locomotive controlate simultan, cu atat refresh-ul lor se face mai rar. Pierderea unui pachet destinat inseamna un delay pana la urmatorul retransmis (timp in care se face refresh-ul celorlalte decodoare) ceea ce induce latente intre comenzile date si executia lor efectiva.

Valori mari ale latentelor pot face controlul ineficient si creste riscul accidentelor; de aceea unii producatori limiteaza nr. de locomotive pt. care se face refresh. (de ex. Piko 12, NanoX 16, Roco nelimitat cred).

O noua locomotiva comandata o va 'scoate' din lista pe cea mai veche; in absenta refresh-ului, decodorul va comanda automat 'stop' dupa 1 sec. De aceea este important sa se evite comanda simultana a mai multor locomotive decat este capabila centrala sa faca refresh.

In cazul expozitiilor mari, nu exista o singura centrala care controleaza zeci de locomotive pe intregul traseu, ci mai multe 'creiere' fiecare cu zone alocate (eventual subdivizate intre diferite boostere) si cu un software care stie sa faca legaturi intre centrale. (de ex. Rocrail :aplauze: )
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Analizand in detaliu bitii transmisi de centrala NanoX, au rezultat urmatoarele valori de refresh:

o singura locomotiva controlata la un moment dat:
functii = 7x pe secunda, viteza = 21x pe secunda;

5 locomotive controlate simultan (maximul rezonabil fara utilizare boostere):
functii = 3x pe secunda, viteza = 9x pe secunda;

16 locomotive controlate simultan (maximul absolut):
functii = 5x in 4 secunde, viteza = 3,7x pe secunda.

Pt. primele doua situatii valorile sunt excelente; in ultimul caz poate sa apara un delay de maxim 1 secunda intre comanda de aprindere a unei functii si executia sa efectiva. (sau 0,3 secunde pt. modificari de viteza - desi mica, asta poate insemna 3-4 cm variatie de oprire la semafor)

Per total cifrele sunt foarte bune; in ecuatie mai intervin si factori ce tin de mecanica locomotivelor, curatenie roti / sine, in conditii optime existand oricum o variatie de ± 1cm in oprirea la semafor.
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Nu imi dau seama exact de ce, dar vad ca in ultima vreme ShowDCC NU se mai intelege bine cu placile de sunet moderne (integrate in placa de baza). Posibil sa fie vreo problema de timing a softului care decodeaza in timp real forma de unda captata de acestea; cert este insa faptul ca ShowDCC afiseaza mult 'garbage', peste jumatate dintre pachetele DCC nefiind intelese.

Nemultumit de situatie, m-am gandit la o noua abordare - digitala - a problemei, care sa reuseasca afisarea fara erori a tuturor pachetelor DCC. Asa s-a nascut :

DCC Sniffer ver.2



Schema este relativ simpla, dar contine 2 PIC-uri, fiecare cu propriul firmware. Primul PIC (12F629) detecteaza pachetele DCC si extrage cei 3-6 bytes pe care ii transmite, impreuna cu informatii despre preambulul de sincronizare, catre cel de-al 2-lea PIC. Transmiterea este seriala, cu 100.000 baud.

Al 2-lea PIC (16F690) decodeaza bytes-ii primiti si ii traduce (in masura in care stie) in text 'in clar' pe care il transmite catre convertorul COM-USB (placuta rosie) si apoi la PC unde sunt afisate de Hyperterminal. Transmiterea este seriala, cu 225.000 baud (-2,3% fata de 230.400) 8-N-1. In acest mod, am reusit afisarea 100% fara erori a pachetelor DCC.



Montajul nu are nevoie de alimentare separata, preluand curent direct de la sine, consumul fiind mic ~30mA. Modulul COM-USB se alimenteaza direct din portul USB. Recomand folosirea modulelor bazate pe chipul FT232.

La apasarea micro-switch-ului, un numar de 256 de pachete DCC sunt detectate, decodate si afisate in Hyperterminal; tinerea apasata a butonului asigura monitorizarea continua a semnalului DCC. Totusi, 256 de pachete detectate fara erori sunt mai mult decat suficiente, acoperind ~2 secunde, rata de repetitie a pachetelor (refresh-ul) fiind mult mai mare (vezi postarile anterioare).

Hyperterminal-ul din Windows afiseaza datele in 3 coloane: prima coloana contine numarul de biti ai preambulului de sincronizare, a 2-a coloana contine cei 3-6 bytes ai pachetului DCC in format hexa, iar a 3-a coloana contine semnificatia pachetului. Primele 2 coloane sunt afisate permanent, a 3-a doar daca pachetul este 'inteles' de decodor. Standardul NMRA fiind destul de 'stufos', m-am axat pe decodarea pachetelor uzuale, de operare curenta, fiind excluse din start cele pt. 'service mode' sau 'consist'. In functie de timp, voi adauga si alte tipuri de pachete.

DCC Sniffer afiseaza urmatoarele tipuri de pachete DCC:

- comenzi catre locomotive (adresa scurta 0-127) sunt afisate ca "Loco" + adresa din 3 cifre (zerourile initiale fiind inlocuite de ".")
- comenzi de deplasare in 28 trepte de viteza sunt afisate ca "S" + viteza din 2 cifre + "F" pt. directia inainte, sau "R" pt. directia inapoi.
- comenzi de activare functii grup1 (F0-F4) sunt afisate ca [FX1234], functiile 'stinse' fiind afisate ca "-". (X este de fapt steluta)
- comenzi de activare functii grup2 (F5-F8 ) sunt afisate ca [F'5678], functiile 'stinse' fiind afisate ca "-".
- comenzi de activare functii grup2bis (F9-F12) sunt afisate ca [F"9ABC], functiile 'stinse' fiind afisate ca "-".


In imaginea din dreapta de mai sus, locomotiva cu adresa 96 se deplaseaza inapoi, cu viteza maxima si are toate functiile F0-F12 activate.

Comenzile catre functii >F12 nu sunt implementate, intrucat sunt rar folosite si nu beneficiaza de refresh. (nu sunt repetate de centrala)

- comenzi de deplasare in 126 trepte de viteza sunt afisate ca "S" + viteza din 3 cifre + "F" pt. directia inainte, sau "R" pt. directia inapoi.


In exemplu, locomotiva cu adresa 50 se deplaseaza inainte, cu viteza 72 (din 126). Se observa ca pachetul de viteza este format din 4 bytes, in timp ce pachetele de functii pt. aceeasi locomotiva (toate stinse) sunt formate din cate 3 bytes.

- comenzi catre locomotive (adresa lunga 0-10239) sunt afisate ca "Loco" + adresa din 5 cifre (zerourile initiale fiind inlocuite de ".")


Comenzile catre locomotive cu adresa lunga sunt formate din 4 bytes atat pt. viteza (28 trepte) cat si pt. functii. Locomotiva cu adresa 9999 se deplaseaza inapoi, cu viteza 21 (din 28 ).


In exemplul de mai sus locomotiva cu adresa 3000 se deplaseaza inainte, cu viteza 112 (din 128). Comanda de viteza este formata din 5 bytes, in timp ce comenzile functii au cate 4 bytes.

- comenzi catre accesorii (1 - 2048) sunt afisate ca "Acc" + adresa din 4 cifre + "to closed" pt. linia directa, sau "to thrown" pt. linia abatuta. Comenzile au 3 bytes.



- comenzi de modificare CV in mod POM (programming on main)


Comanda de scriere a valorii 125 in CV100 al locomotivei cu adresa 9999. Comanda contine 6 bytes :!: este repetata si urmata apoi de 6 pachete idle, pt. a da timp decodorului sa o execute.

Fisierele necesare programarii celor 2 PIC-uri pot fi descarcate de aici:
http://www.mediafire.com/download/10lo2514c9kawim/DCC_sniffer_I.asm
http://www.mediafire.com/download/okedpv61d14xb6m/DCC_sniffer_I.HEX
http://www.mediafire.com/download/2hz5awl2x690kc3/DCC_sniffer_II.asm
http://www.mediafire.com/download/jx8yhizn1n90xxs/DCC_sniffer_II.HEX
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Intrucat exista centrale digitale care transmit repetat si comenzi pt. functii >12 am introdus, la cererea publicului :wink: , doua noi definitii:
- 'F;' pt. functiile F13-F20, unde functiile aprinse apar ca literele D-K si
- 'F:' pt. functiile F21-F28, unde functiile aprinse apar ca literele L-S.


Locomotiva cu adresa 3 stationeaza, directia inainte si are functiile F0-F12 stinse si F13-F28 aprinse. Comenzile pt. functiile 13 - 28 sunt pe 4 bytes.


Locomotiva cu adresa 1234 stationeaza, directia inainte si are toate functiile F0-F28 aprinse. Comenzile pt. adresa lunga sunt pe 5 bytes. Nu imi dau seama de ce centrala (ESU LokProgrammer) transmite de 2 ori la rand comanda pt. F21-F28. :?:


Aici unele functii sunt aprinse 'pe sarite', mai precis F0, F2, F4, F5, F7, F10, F12, F13, F15, F18, F20, F21, F23, F26, F28.

Noul firmware poate fi descarcat de aici:
http://www.mediafire.com/download/bdz2nyhcczjtrxy/DCC_sniffer_II_v2.asm
http://www.mediafire.com/download/r6jjck11464j06h/DCC_sniffer_II_v2.HEX
 

strofo

Active Member
29 Februarie 2012
96
11
Ploiesti / Bucuresti
LOCATION
Ploiesti / Bucuresti
Ca de obicei o munca f frumos documentata, dificila si frumos dusa la capat. Bravo :lol: :aplauze:

Insa sunt ca de obicei cautator de nod in papura. :D Am avut si eu de aface cu un astfel de sniffer (tot home-made), indeosebi cu zona de error rate.

1. Cum se modifica error rate-ul atunci cand rulezi 2 loco pe circuit (si rulaj, nu numai comenzi)? Ce centrala folosesti? La mine, cu Piko a urcat si la 5% DCC loss.
2. De ce nu ai folosit baudrate-ul standard? Nu regasesc valorile tale in http://wormfood.net/avrbaudcalc.php , sincer la PIC nu prea stiu cum sa citesc valorile (http://www.nicksoft.info/el/calc/?ac=spbrg&submitted=1&mcu=PIC12F1840&Fosc=12.000&FoscMul=1000000&FoscAutoSelector=0&MaxBaudRateError=1) insa mi se par erorile fabulos de mici.
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Salut si multumesc pt. aprecieri !

1. Rularea unor locomotive NU ar trebui sa afecteze forma de unda a semnalului DCC pana la a-l face neinteligibil. Contactul sniffer-ului fiind prin 'crocodili', nu exista pierderi iar decodarea este perfecta, fara erori. Analizeaza cu un osciloscop si vezi daca nu ai 'overshot-uri' sau 'ringing'. De asemenea, sa nu uitam de tensiunea de alimentare a centralei, care este necesar sa fie stabilizata la 15V.

Totusi, stiu ca centrala Piko foloseste 'zero stretching' care nu convine multor decodoare (inclusiv ShowDCC). Este posibil ca sniffer-ul folosit de tine sa intre in aceasta categorie. Eu am 'maritat' de mult centrala Piko si nu mai am cum sa o testez acum cu noul DCC Sniffer, dar presupun ca ar functiona OK, deoarece detectia bitilor DCC se face simplu (<77uS = 1; >77uS = 0) deci o durata 'alungita' a lui '0' nu ar trebui sa puna probleme.

2. In ceea ce priveste comunicatia seriala, am vrut sa experimentez cu generarea si receptia semnalului prin soft, deci nu hardware, prin EUSART. Comunicatia dintre cele 2 PIC-uri se face la 100.000 baud intrucat este usor de generat la 4MHz, respectiv de receptionat la 8MHz. De altfel, PIC12F629 nu are circuit EUSART.

Mai departe, dupa decodare, transmisia catre PC se face cu viteza maxima pe care o suporta PIC16F690, respectiv 225.000 baud, prin alterarea cu +12,5% a oscilatorului intern. (8MHz -> 9MHz). Aceasta viteza este cu 2,3% mai mica decat 230.400 baud, viteza standard. In aceste conditii, nu exista nici un fel de erori de comunicatie, din cate stiu, transmiterea seriala suportand usor diferente de ~5% intre vitezele de transmisie / receptie.
 

strofo

Active Member
29 Februarie 2012
96
11
Ploiesti / Bucuresti
LOCATION
Ploiesti / Bucuresti
Meriti felicitarile, stiu cata munca se depune la asa ceva :)

Erorile de care pomeneam au fost obtinute atunci cand am folosit punctul cel mai nefavorabil de colectare: minim 1.5m distanta de input centrala, cel putin 2 macaze pana la colectare, cel putin 2-3 locomotive pe parcurs (intre input si crocodili de colectare), toate locomotivele mergand f incet (speed = 3-5/128). Cu o locomotiva erorile puteau fi neglijate, de obicei nu apareau atunci cand loco era sub 0.5 metrii, insa nu am obtinut niciodata 100% semnal ok. Daca pui un osciloscop o sa vezi ca semnalul nu e tocmai ideal si in general e determinat de viteza locomotivelor (cu cat e mai mica, cu atat distorsionarea este mai mare) ;)

In legatura cu erorile de seriala nu stiu ce sa zic, eu am mai avut surprize, insa in general sub 3% ar trebui sa fie oki.
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Uite aici http://forum.lokomotiv.ro/modules.php?name=Forums&file=viewtopic&t=6813&start=0 cateva capturi ale ecranului osciloscopului in diverse situatii.
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
DCC Sniffer v3.0 este versiunea SMD a interfetei. Pt. optimizarea spatiului, placuta adaptorului COM-USB este montata deasupra circuitului principal:



Schema electrica a suferit si ea cateva modificari:



Intrarea prin optocuplor asigurara separarea galvanica a traseului dioramei fata de calculator, montajul alimentandu-se acum direct din portul USB. LED-ul 2 se aprinde odata cu conectarea la sine si asigura si protectia ledului din cuplor la alternantele negative ale semnalului DCC; prezenta si detectarea corecta a pachetelor DCC fiind semnalizata prin sclipirea LED-ului 1.



Comunicarea cu PC-ul este acum bidirectionala, montajul asteptand tastarea unei cifre de la 0 - 9 in locul apasarii butonului. Ulterior, interfata va decoda si afisa un numar de (256 x tasta apasata) pachete DCC. Apasand tasta 0, vor fi afisate 10 x 256 = 2560 pachete (ce reprezinta ~20 secunde de semnal).

Cei care vor sa realizeze montajul pot descarca proiectul, creat in EAGLE 5.4.0, aici:
http://www.mediafire.com/download/8cvsxyc2ppam967/DCC_sniffer_3.1.sch
http://www.mediafire.com/download/f7vx3mer00g4g4g/DCC_sniffer_3.1.brd

iar pt. programarea celor 2 PIC-uri folositi:
http://www.mediafire.com/download/dpqxm3bdnzcat01/DCC_sniffer_v3_I.asm
http://www.mediafire.com/download/8op78vllwlr4k2n/DCC_sniffer_v3_I.HEX
http://www.mediafire.com/download/qso846zxt7xlcw3/DCC_sniffer_v3_II.asm
http://www.mediafire.com/download/hbts96qty6evtna/DCC_sniffer_v3_II.HEX
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Foarte corecta observatia ! Nu am vrut insa sa schimb prea multe fata de versiunea precedenta, iar pinii folositi au fost alesi pe ratiuni de design mai degraba; in plus, sa programezi comunicatia seriala prin soft este 'so much fun' ! :D
 

strofo

Active Member
29 Februarie 2012
96
11
Ploiesti / Bucuresti
LOCATION
Ploiesti / Bucuresti
:D mai ales daca o faci in assembler. spor la heckarit :D incearca totusi MPLab, o sa-ti placa.

am si eu un proiect trenulistic in care folosesc seriala in halfduplex insa pentru o comunicatie multipunct. eu am avut ceva erori cand "vorbeau" doua puncte deodata.
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
Chiar MPLAB IDE v8.00 folosesc.

Erata:
Din graba, un mic bug s-a strecurat in rutina de citire a tastaturii PC: oricare tasta era acceptata si transformata intr-un nr. de la 0 la 7 (0 fiind 10).
Descarcati varianta corectata aici:
http://www.mediafire.com/download/qso846zxt7xlcw3/DCC_sniffer_v3_II.asm
http://www.mediafire.com/download/hbts96qty6evtna/DCC_sniffer_v3_II.HEX
 

strofo

Active Member
29 Februarie 2012
96
11
Ploiesti / Bucuresti
LOCATION
Ploiesti / Bucuresti
Mersi mult LiviuM, am dat un ochi si e f interesant ce au facut acolo. Scuze dac daca o sa-ti poluez postul.

Eu ma refeream la o comunicatie seriala RXTX hardware peste care am pus un circuit (deci tot hardware) care comunta in half-duplex. Adica asa: http://hackaday.com/2014/01/13/software-half-duplex-uart-for-avrs/

Digitrax e ceva mai evoluat, are un protocol (e prima data cand vad o specificatie de-a lui) peste comunicatie prin care face o mica corectie (si mai e vorba si de 24V).
In varianta mea, toate punctele sunt pullup (insa la 5V): practic cine vrea sa comunice trebuie sa traga voltajul asta la masa (GND) pentru a trimite 1 si sa-l lase sus pentru a trimite 0. Pentru ca nu avem corectie si nici CSMA (carrier sense), daca se apucau 2 puncte sa vorbeasca, orice bit de 1 suprascria/masca mesajul celorlalte puncte.

OFFTOPIC: inca mai cautam un al 3lea membru in echipa pentru a finaliza proiectul, deci daca esti interesat de programare de microcontrolere si/sau android/windows, electronica, DCC dau detalii pe PM :lol:
 

LiviuM

Well-Known Member
Trenulist
11 Martie 2011
397
0
Ce faceti voi e destul de similar Loconetului. Tot asa merg si ei, cu o sursa de curent care tine busul sus si cu open colectori care trag la masa pentru 0. Ce au in plus e "arbitrajul".

Referitor la colaborare, nici nu sunt prea priceput, nici nu prea am timp pentru ca sunt deja bagat in mai multe proiecte. Probabil prea multe, ca nici unul nu apuca finalizarea.
Modelistice ar fi:
http://forum.rocrail.net/viewtopic.php?f=11&t=3754
http://forum.rocrail.net/viewtopic.php?f=11&t=3878
http://forum.rocrail.net/viewtopic.php?f=11&t=5804
https://github.com/lmmeng/rfid2ln
Daca ti se pare ceva interesant pe acolo, poti folosi/poti intreba linistit.

Cum tot timpul ma intereseaza "noutatile", poti posta detaliile "necomerciale" ale proiectului.

Succes,
Liviu

PS Sorry dac!
 

dac

Well-Known Member
Trenulist
15 Septembrie 2007
1.340
81
Bucuresti
LOCATION
Bucuresti
O noua definitie adaugata sniffer-ului: 'Reset Packet'



Aceste pachete sunt transmise de centrala imediat dupa punerea sub tensiune (deci usor de pierdut) si au drept scop resetarea (duh!) decodoarelor (viteza zero, functii oprite).

Conform NMRA, centrala trebuie sa transmita initial minim 20 pachete 'Reset' urmate de minim 10 pachete 'Idle'. Roco Multumaus transmite 23 pachete 'Reset'; NanoX transmite 31 pachete 'Reset'.

Astfel, decodoarele fac distinctie intre intreruperile accidentale ale tensiunii (sine murdare, macaze, etc.) care nu sunt urmate evident de pachete 'Reset' si deci decodorul poate continua cu viteza si functiile active, si respectiv initializarea centralei, cand locomotivele stau mai bine linistite.

Firmware-ul se poate descarca de aici:
http://www.mediafire.com/download/h4n74kfz6370tff/DCC_sniffer_v3a_II.HEX
http://www.mediafire.com/download/centv9ngxbhwzlf/DCC_sniffer_v3a_II.asm