Jakie dcc piko/roco do makiety

[r-mik]

domyślnie odświeża do F28

Domyślnie do F12. Swoimi wypowiedziami potwierdzasz, że

Masz rację znam DR5000 tylko ze zdjęcia na opakowaniu

Nic dodać, nic ująć.

Eleastyczność ustawień DR5000 jest wśród centralek wyjątkowa.

Trzeba "tylko" wiedzieć jakie są konsekwencje tych zmian, a wątpię abyś je znał.

Pokaż, gdzie jest napisane, że DR5000 obsłuży 100 adresów w jednej chwili bo prawa fizyki zaprzeczają temu. 100x20-30ms, daje pakiet do lokomotywy co 2-3sekundy. Ile przejedzie lokomotywa przez 3 sekundy? A jak pakiet bedzie miał błedna CRC to przez 6 sekund? W DR5000 trochę można ugrać wyłączając cykliczne wysyłanie pakietów stanu F5-F7 i F8-F12 ale wiesz jakie to będzie miało konsekwencje? Chyba tylko mój dekoder pozwala na pracę bez cyklicznych pakietów F5+. Dodatkowo można troszeczkę zyskać włączając preambułę na mniej niż domyślne 14 pakietów tyle, że.... No właśnie, co może się stać? Wiesz? Inny problem, to ponad 100 przeważnie oznacza adresowanie długie, wiesz jakie są tego konsekwencje? Wątpię.

 

[PiotrK]

Cieszę się, że jesteś źródłem nieomylnej wiedzy, a my tylko pokazujemy swoja głupotę. - bo przecież nic nie wiemy...

Chyba tylko mój dekoder pozwala na pracę bez cyklicznych pakietów F5+.

A możesz wskazać, który konkretnie komercyjny dekoder tego nie potrafi? Choć w to nie uwierzysz, ale ja takiego nie znam.

Dodatkowo można troszeczkę zyskać włączając preambułę na mniej niż domyślne 14 pakietów tyle, że....

Po raz kolejny apeluje o precyzję wypowiedzi. Preambuła w DCC nie składa się z pakietów, tylko bitów i to ona poprzedza właściwą zawartość pakietu.

Kolega lubi również różne teoretyczne obliczenia i są one w większości słuszne. Widać jednak, że brak koledze doświadczenia z użytkowaniem realnej dużej makiety i stąd biorą się poruszane tu teoretyczne problemy (szczególne niezwykle związane z tematem tego wątku).

Sugeruję wybrać się kiedyś na spotkanie gdzie taka jest tworzona i zobaczyć jakie są realne problemy. Jazda paroma lokomotywami w kółku nie daje prawdziwego obrazu.

 

[r-mik]

Kolega lubi również różne teoretyczne obliczenia i są one w większości słuszne.

Matematyka nie kłamie.
Szybkość transmisji DCC to ok 10kb/s czyli 1KB/s. Najkrótsza ramka to 3 bajty, adresowanie długie 4 bajty. Łatwo wyliczyć, że na sekundę można wysłać 250-300 ramek ale ramki są przeplatane: prędkość, F0-F3, F4-F7, F8-F12. Przepływność spada więc ok 4-krotnie co daje 62 ramki na sekundę. Przy 30 loko daje to (jeśli nie ma błędów) 2 ramki na sekundę.

Dekoder przygotowałem do tego aby nie potrzebował cyklicznych ramek F5+ (zrobie testy ZIMO i napiszę czy pozwala na taka pracę, ale kiedyś nie pozwalał). Rozpatruje tez aby nie potrzebował F0+.
Do kompletu potrzeba centralak, dlatego w założeniach mam aby wywalć (opjonalnie) F4-F12 aby zwiększyć przepływność 2 razy. Zamiast 30 loko mam 60. Jak by wywalić F0-F4 to zyskuję jeszcze więcej.

Praca grupowa nie wypaliła, co było dla mnie "oczywistą oczywistością" ale wygląda na to, że powstała trójca, która zbuduje centralkę, manipulator ale najpierw mniejszy dekoder z możliwością wgrywania dźwięków przez użytkownika. To oczywiście potrwa. Dekodery, które dotychczas powstały, po bezpłatnym upgrade będą miały możliwość wgrywania dźwięków. Upgrade można zrobić samemu programatorem za 14zł.
Który producent oferuje tak tani programator?

 

[PiotrK]

Matematyka nie kłamie.
Szybkość transmisji DCC to ok 10kb/s czyli 1KB/s. Najkrótsza ramka to 3 bajty, adresowanie długie 4 bajty. Łatwo wyliczyć, że na sekundę można wysłać 250-300 ramek ale ramki są przeplatane: prędkość, F0-F3, F4-F7, F8-F12. Przepływność spada więc ok 4-krotnie co daje 62 ramki na sekundę. Przy 30 loko daje to (jeśli nie ma błędów) 2 ramki na sekundę.

Rozumiem, że według tych wyliczeń, dekoder otrzymywałby przy takich założeniach jeden adresowany do siebie pakiet co 0,5 sekundy.

Niestety te rozważania teoretycznie nie uwzględniają sposobu działania central. Pakiety dla jednej lokomotywy nie są wysyłano jeden po drugim, ale przeplatane. Stąd należy oczekiwać, że przy podanych założeniach do dekodera będą kierowane pakiety co około 0,125 sekundy. W praktyce może czas być ten krótszy ze względu na zastosowane algorytmy zarządzania slotami.
Przedstawione przez kolegę obliczenia są więc słuszne, ale tylko w przypadku, gdy rozważamy częstość wysyłania do określonego dekodera pakietu jednego typu.

Kolega nie stara się wypowiadać precyzyjnie stąd było moje stwierdzenie:

Kolega lubi również różne teoretyczne obliczenia i są one w większości słuszne.

Ma kolega racje, matematyka nie kłamie, tylko wynik i ich interpretacja zależy od przyjętych założeń wstępnych.
Niepełne lub błędne dane wejściowe dają odpowiednio przybliżone lub błędne wyniki.

Dekoder przygotowałem do tego aby nie potrzebował cyklicznych ramek F5+ (zrobie testy ZIMO i napiszę czy pozwala na taka pracę, ale kiedyś nie pozwalał). Rozpatruje tez aby nie potrzebował F0+.

Czekamy na wyniki testów dekodera ZIMO, proponuje przetestować też i inne np. różne dekodery ESU.
Ciekawe co oznacza w przypadku dekodera ZIMO, określenie że "kiedyś nie pozwalał"? Czym to się objawiało?

Dekoder przygotowałem do tego aby nie potrzebował cyklicznych ramek F5+ (...) Rozpatruje tez aby nie potrzebował F0+.

Uważam, że akurat to nie jest w dekoderze potrzebne, bo i bez tego powinien pracować poprawnie.

I jeszcze raz powtarzam do poprawnej pracy dekodera nie jest potrzebne cykliczne powtarzanie pakietów.
Do czasu zaniku zasilania dekoder będzie realizował ustawienia z ostatnio odebranych pakietów.
Powtarzanie wysyłanych pakietów podnosi za to pewność działania całego systemu.

Oczywiście kolega słusznie uzna, że się nie znam, bo przecież skąd miałbym to wiedzieć...

 

[r-mik]

akiety dla jednej lokomotywy nie są wysyłano jeden po drugim, ale przeplatane.

Tak, przeplatane:
- Prędkość i kierunek.
- F0-F4.
- F5-F7.
- F8-F12.
Tak więc pakiet o prędkości dochodzi co czwarty raz.

W praktyce może czas być ten krótszy ze względu na zastosowane algorytmy zarządzania slotami.

O ile takie zarządzanie istnieje to ratuje sytuację, bo awaryjny stop może być nadany zamiast np F5-F7. Nie każda centralka inteligentnie wysyła pakiety, np popularny w śród amatorów NanoX PACO (nie wiem jak najnowsza wersja) czyli w opisywanej przeze mnie centralce RailBox http://forum.modelarstwo.info/threads/centralka-railbox-wmouse.50854/. W NanoX problem został 'rozwiązany" przez ograniczenie liczby aktywnych dekoderów do 8 (w nowszej wersji do 16, może tam jakas inteligencja jest).
Zbadanie czy centralka wysyła pakiety inteligentnie czy w kółko to samo nie jest takie trudne do zrobienia (przy 8 lokomotywach było banalnie proste, wystarczył oscyloskop) ale czy forumowiczów takie testy interesują? Jeśli tak, mogę je zrobić.

Ciekawe co oznacza w przypadku dekodera ZIMO, określenie że "kiedyś nie pozwalał"? Czym to się objawiało?

Ustawiał domyślne stany (wyłączone) wyjść mimo, że w centralce były włączone. W moim dekoderze wyjścia ustawią się w stan jaki był przed wyłączeniem zasilania (można to zmienić).

o poprawnej pracy dekodera nie jest potrzebne cykliczne powtarzanie pakietów.
Do czasu zaniku zasilania dekoder będzie realizował ustawienia z ostatnio odebranych pakietów.

O ile nie ma błedów transmisji jest ok. Im więcej lokomotyw tym większe problemy. Nie przez przypadek pakiety do akcesoriów i do dekoderów pakiety F13+, wysyłane są najczęściej 5 razy (w DR5000 można to ustawić).

 

[r-mik]

Nie napisałem jeszcze o "małym" problemie związanym z CRC. łatwo policzyć, że szanse na nie wykrycie błędu to 1:256. Przy ciągłej transmisji o przepływności ok 10kHz, o ile pamięć mnie nie myli, błąd może pojawić się co ok 2-3 sekundy ale dotyczy to sytuacji gdzie nie ma dużych zakłóceń. Teoretycznie raz na 8-12 minut pojawi się błąd, który nie zostanie wykryty. Gdy uruchamiałem dekoder na stanowisku testowym zdarzało się, ze dekoder generował przypadkowy dźwięk. Niestety, przy silnych zakłóceniach niewykryte błędy pojawiają się częściej. Gdy dekoder jeździł w lokomotywie często zdarzały się przypadkowe dźwięki. Dlaczego tylko dźwięki wariowały? Bo program reaguje na zmianę stanu eFek. Wykrywa zmianę i generuje dźwięk. W przypadku wyjść funkcyjnych nic nie było widać, bo po błędnym pakiecie pojawiał się w kilkadziesiąt ms poprawny. Problem rozwiązałem przez akceptowanie co najmniej 2 takich samych pakietów. W przypadku pakietów krótkich można to traktować jak dodatkową CRC 24-bit, długich 32-bit. To daje szanse na niewykrycie błędu jak ok 1: 16,8e6 i 4.2e9. Kto chce niech policzy co jaki czas błąd nie jest wykrywany. Pominę tu fakt, że wskazałem liczbę prawdopodobieństwa dla CRC a rozpatrywać należy przypadek gdzie dwa razy pod rząd pojawia się taki sam błąd. Różnica taka jak dwa razy pod rzad wygrać w Lotka a dwa razy wygrać obstawiając takie same liczby.
Problem rozwiązałem ale kosztem realnego zmniejszena przepływności 2 razy. Prawdopodobnie inni programiści robią tak samo. W konsekwencji reakcja na naciśnięcie przycisku na manipulatorze może być opóźniona gdy na torach jest dużo dekoderów. Do opóźnienia związanego z pakietami trzeba dodać opóźnienie generowane przez manipulator, centralkę, ewentualnie mechanizmy związane z SUSI. Testujac SUSI miałem podłączony MX623 (o ile dobrze pamiętam). Opóźnienie (przy jednym dekoderze) wahało się od 05, do ponad sekundy. Jakie byłoby gdyby dekoderów było więcej? Oczywiście zależy to od centralki, na NanoX, czyli także RailBox, należy spodziewać się największych opóźnień.

Problem CRC wynika z błędnych założeń DCC. Suma powinna być 16-bit i nie zwykły XOR. Niestety jest 8-bit XOR tak samo kiepski jak zwykłe ADD.

 

[r-mik]

W praktyce może czas być ten krótszy ze względu na zastosowane algorytmy zarządzania slotami.

@PiotrK, które konkretnie centralki mają algorytmy zarządzania slotami? Sprawdziłem nowe NanoX i PIKO SmartControllerLight i tam w kółko leci to samo. Jedyne odstępstwa to wysyłanie ramek do akcesori i związanych z CV. Inteligencji żadnej tu nie ma, raz użyty adres, mimo, ze przez godzinę nie jest używany, cały czas jest w ramkach danych. Wystarczy więc aktywowac raz wszystkie max dopuszczlną liczbę adresów aby spowolnić drastycznie odświeżanie informacji. Pomaga tylko reset, jak w przypadku Window$ i Arduino.

 

[PiotrK]

NanoX to konstrukcja amatorska, tam tego nie znajdziesz. Co do PIKO Smart ControlerLight (też na XpressNet) się nie wypowiadam, bo nie używałem.
Ja mówiłem raczej o profesionalnych centralach, które potrafią zarządzać dużą liczba slotów. np DCS240

 

[r-mik]

Sprawdziłem DR5000 i wysyła "poza kolejnością" (na razie nie moge sprawdzić ile razy) pakiety jeśli coś na manipulatorze zmieniło się. Można więc bez obaw włączyć wysyłanie F12+ co nie wpłynie na szybkość reakcji na zdarzenia. Co ciekawe, pakiety związane z prędkością jazdy wysyłane są częściej gdy prędkość jest różna od zera niż gdy stoi. To mi podoba. Niestety, jak w PIKO, pakiety do nieużywanego adresu są ciągle wysyłane. Ma to tą zaletę, że gdy lokomotywa straci komunikację (np zostanie zdjęta z torów) to po jej odzyskaniu funkcje zostaną ustawione tak jak były a nie jak są po resecie dekodera. Ja bym to rozwiązał trochę inaczej i w takiej sytuacji wysyłał pakiety co np sekundę.

 

[PiotrK]

Czyli jak widać DR5000 też zarządza obsługa slotów bardziej inteligentnie (co zresztą należało oczekiwać).

Jeżeli chcesz by nie używane sloty (czyli nie odświeżane od dłuższego czasu przez manipulator, z ustawioną prędkością 0) były zwalniane to musisz ustawić Purge time na wartość minut inną niż 0. Po zwolnieniu slotu, nie będą już generowane skojarzone z nim pakiety DCC.

 

[r-mik]

Jeżeli nie chcesz by nie używane sloty (czyli nie odświeżane od dłuższego czasu przez manipulator, z ustawioną prędkością 0) były zwalniane to musisz ustawić Purge time na wartość minut inną niż 0. Po zwolnieniu slotu, nie będą już generowane skojarzone z nim pakiety DCC.

Przydałoby się instrukcja wyjaśniająca szczegółowo co do czego służy.

Zagadnienie opisujące jak generują sygnał różne centralki to duży temat. Wymaga sporego nakładu czasu. Na tyle ile potrzebowałem zbadałem NanoX, PKO i DR5000. NanoX ma 8 slotów. Po resecie wysyła pakiety NOP. Uaktywnienie jakiegoś adresu zajmuje wolny slot. Podobno wersja którą testowałem obsługuje 16 adresów ale nie sprawdziłem co się dzieje gdy 8 już wykorzystam.
PIKO jest niewiele lepsze od NanoX. Nie wysyła NOP tylko dodaje kolejne sloty. Sprawdziłem przy kilkunastu adresach. W PIKO niema czegos takiego jak w DR500, że zmiana stanu manipulatora generuje dodatkowy pakiet. Czestsze odświerzanie zrealizowana pracując na granicy normy co jak wiadomo, nie jest zalecane. Należałoby sprawdzić co będzie jak użyj się 30 adresów. Wyniki mogą być zaskakujące. Niestety, takie testy wymagają czasu a mam inne zajęcia.

Niewątpliwie z centralek, które badałem, najlepsza jest DR5000. NanoX to zabawka. Wpołączniu z Minimouse wiele się nie zdziała. Nie programuje CV ponad 255 więc nie da się skonfigurować dekoderów po SUSI. Nie miałem okazji sprawdzić czy nanoX + MMRoco da radę. Będzie okazja jak zacznę prace nad dekoderami po SUSI.

 

[Patriarcha]

@netlareq na które rozwiązanie się ostatecznie zdecydowałeś?