Budowa tanich dekoderów trakcji, dźwięku, funkcyjnych

[r-mik]

Alana potrzebuje max wymiarów aby dekoder zmieścił się w TT.

 

[piotr66]

Jeśli chodzi o technologię wyrobu dekoderów jestem laikiem, ale nie za bardzo rozumiem twój problem z dźwiękami r-miku. Jest baza dźwięków płatnych i darmowych, zrób dobry dekoder a sound to już sprawa użytkowników, raczej nikt nie udostępni ci SP45 czy EU07.

 

[r-mik]

est baza dźwięków płatnych i darmowych

Daj linki.

rób dobry dekoder a sound to już sprawa użytkowników

Nie na tym etapie, na którym jestem. Już wcześniej o tym pisałem. Aktualnie dźwięki trzeba kompilować razem z programem, czasem modyfikować kod. Z tego powodu użytkownik nie może sam modyfikować dźwięków bo ilu zna C na tyle aby to zrobić? Nawet jeśli potrafią, to nie udostępnię za free źródeł. każdy, kto posiada źródła może produkowac dekodery ponosząc znikome do moich koszty nie płacąc mi nic za opracowanie konstrukcji.
Problemu nie rozwiąże też aplikacja, która umożliwiała by "komponowanie" dźwięków jak Zimowskie ZSP bo do tego potrzebny sprzęt w postaci programatora, a taka aplikacja i sprzęt to kolejne dziesiątki tysięcy zł inwestycji. Jeśli są inwestorzy, zapraszam do współpracy.
Jak nie stracę na sprzedaży dekoderów, to zgodnie z tym co pisałem wcześniej, będzie można z poziomu terminala wgrywać dźwięki. To jednak tez nakład czasu i pieniędzy.
Na tą chwilę dekodery są w postaci takiej jaką oferuje np MRC. Wybiera się typ a przez CV można wybierać rodzaje dźwięków.

 

[sun71]

Jakąś super sprzedaż dekodera z 256kB FLASH nie liczę ale niewiele droższy, z 1MB FLASH to inny temat. Przy 8kHz mieszczę 240 sekund dźwięku 16-bit! Oczywiście DAC w STM32 ma tylko 12-bit ale taką jakość* zapewnia GSM, ISDN, VoIP (typowo bo jest też wersja HD). Mogę zwiększyć jakość, dając 16kHz i 120 sekund dźwięku. W przeciwieństwie to większości rozwiązań konkurencji, mogę mieć zarówno 8, 16 jak i 32kHz w dekoderze. Daje np wysoka jakość "puff" i niską ale długa zapowiedź peronową. Możliwości są naprawdę duże. Dekoder z 1MB FLASH ma taktowanie do 120MHz! Ten, który jest na filmach "tylko" 48MHz. Pomijając szybkość rdzenia, przy 48MHz mam 8 kanałów i obciążenie CPU ok 50%. Łatwo wyliczyć, że 120MHz pozwoli na 16 kanałów z obciążeniem ok 40%! Niestety, jako detalista, za tymi uC muszę czekać nawet 20 tygodni!
Inny temat to liczba wyjść funkcyjnych. 20 a nawet 24 w tym min 16 PWM to nie mało. Konkurencja (chyba) tego nie ma. Programowe PWM 12-bit to raczej kłopot ale 8 -bit nie widzę problemu. Na PIC czy AVR to sfera marzeń. 20 wyjść to otwarta droga do świateł PKP E1. Tu dekoder z zewnętrzą FLASH przegrywa. Fakt, tam mam 4MB pamięci ale niestety mało wyjść funkcyjncyh, z którymi wiążę duże nadzieje. Programowe PWM na ARM to nie duży problem.
To czego mi brak, to zastrzyk gotówki. Jak zarobię na dekoderach z 30-50k zł to mogę ruszyć z kolejnymi pracami. Tak Panowie i Pani, nie rozmawiamy od tysiącach a o dziesiątkach tysięcy zł. Kto nie wierzy niech sam spróbuje.


* ISDN, łącza telefoniczne analogowe (ASS), VoIP, to 12-bit 8kHz. Kodowanie G711, to niby 8-bit ale ADC i DAC to 12-bit z tym, że uzywana jest "sztuczka" jak w radiu FM, coś w rodzaju preemfazy i deemfazy. Kompresja na podobę DOLBY (B czy NR, nie pamiętam) w magnetofonach - kto pamięta taśmy 3,8mm?

Standardowa telefonia ma próbki 8 bitowe, od początku telefonii i komutacji cyfrowej, przy próbkowaniu 8kHz. Co daje użyteczne pasmo w telefonii 320-3600Hz. 12 bitów to jakośc więcej niż wystarczająca, trzeba by sie tylko zastanowić nad górną częstotliwością, myślę, że 8kHz to wypas, czyli 16kHz próbkowania. Większość dźwięków taboru mieści się w niskich częstotliwościach, jedyne co wyskoczy trochę wyżej to współczesne przetwornice
Soft... jak wiemy ten nigdy nie jest doskonały, żeby zachęcić ludzi do kupienia czegoś niedoskonałego trzeba dać możliwość łatwych aktualizacji, możliwych do wykonania bez konieczności zakupu drogiego programatora, tudzież softu na PC. No i trzeba te aktualizacje robić
Nie myślałeś nad otwarciem oprogramowania? To jest droga do perfekcji, czyli sytuacjy gdzie każdy sam sobie wrzuca swój zestaw dźwięków, ewenatualnie z jakąś tablicą ich przypisań do zdarzeń? Miałbyś ogromną szanse powalczyć na rynku oferując końcowemu użytkownikowi możliwość łatwej zmiany i oprogramowania i zestawu dźwięków. Ale sam tego nie zrobisz grzebiąc równocześnie w hardware i software, albo zajmie Ci to lata. Ja jak juz pisałem - chętnie - dla dobra społeczności - mogę trochę pogrzebać w sofcie, niezależnie czy chcesz go uwolnić, czy nie.

 

[r-mik]

tandardowa telefonia ma próbki 8 bitowe, od początku telefonii i komutacji cyfrowej, przy próbkowaniu 8kHz.

Nie. Już o tym pisałem, w telefonii używane są przetworniki 12-bit i kompresja/dekompresja (kodowanie) G711u/a-law. 8-bit to chyba nigdy nie było w praktyce użyte. Nawet E-10 miały G711.

o daje użyteczne pasmo w telefonii 320-3600Hz.

Pasmo to wynika z czegoś innego jak próbkowanie 8kHz, bo przy takim byłoby 0-4kHz.

aktualizacji, możliwych do wykonania bez konieczności zakupu drogiego programatora, tudzież softu na PC.

Programator 14zł, soft za free ale coś za coś, trzeba przylutować 3 przewody. Jak ma być łatwo i przyjemnie to już nie będzie tanio.

Nie myślałeś nad otwarciem oprogramowania?

Za duże koszty poniosłem i jeszcze będę ponosił, aby dać soft dekodera za free. Nie widzę jednak problemu, aby ktoś napisał soft na komputer, wykonał prototyp programatora, napisał moduł bootloadera. Ta część softu i sprzetu, której jeszcze nie ma, może być jak najbardziej za free, tyle, że chętnych do pracy za free to za bardzo nie ma. Więc ideę darmowego softu, możemy sobie raczej darować.

Ale sam tego nie zrobisz grzebiąc równocześnie w hardware i software, albo zajmie Ci to lata.

Główną przeszkodą są fundusze.

 

[sun71]

Nie. Już o tym pisałem, w telefonii używane są przetworniki 12-bit i kompresja/dekompresja (kodowanie) G711u/a-law. 8-bit to chyba nigdy nie było w praktyce użyte. Nawet E-10 miały G711.


Pasmo to wynika z czegoś innego jak próbkowanie 8kHz, bo przy takim byłoby 0-4kHz.

.

To może nieistotne z punktu widzenia modelarstwa kolejowego, ale będę się upierał co do zagadnień telekomunikacyjnych
G711 z obiema krzywymi kompresji zakładają próbkowanie 8 bitowe, z częstotliwością próbkowania 8kHz, co daje typowy kanał cyfrowy o przepływności 64kbps. Później zwielokrotniany w hierarhiach SDH i PDH. Taki też kanał mamy w ISDN. Przy czym poziomy kwantowania nie są liniowe, tylko właśnie logarytmiczne. Oczywiście patrząc na zagadnienie z punktu widzenia matematyki i twierdzenia Nquista pasmo powinno być takie jak piszesz, ale zaszłości telefonii analogowej spowodowały jego obcięcie.
Dlaczego więc przetwornik 12 bitowy? Bo bez drogich i niedostępnych w czasie powstawania pierwszych central cyfrowych procesorów DSP da sie za pomocą takiego przetwornika zaimplementować logarytmiczne krzywe kompresji G711 poprzez manipulację kolejnością podawanej ósemki bitów (zwanej w telekomunikacji oktetem, a nie bajtem).

Zakładając jednak kwantowanie liniowe, 12 bitowe, IMHO jest to więcej niż potrzeba dla dekodera.

 

[r-mik]

przy czym poziomy kwantowania nie są liniowe, tylko właśnie logarytmiczne.

Twierdzenie, że G711 to próbki 8-bit jest tożsame z twierdzeniem, że ADPCM ma rozdzielczość 4-bit. Jak na 4-bit (tyle dawał SID w Commodore 64) to dobra jakość dźwięku jest w dekoderze.

12 bitowe, IMHO jest to więcej niż potrzeba dla dekodera.

Raczej optymalne. 8-bit to trochę za mało (za mała dynamika) 16 czy nawet 14-bit w prostym dekoderze, niewiele się różni od 16 bit, jeśli wcale. Liniowość DAC w STM nie powala, wiec te 12-bit to nie tak do końca.

 

[sun71]

Twierdzenie, że G711 to próbki 8-bit jest tożsame z twierdzeniem, że ADPCM ma rozdzielczość 4-bit. Jak na 4-bit (tyle dawał SID w Commodore 64) to dobra jakość dźwięku jest w dekoderze.


Raczej optymalne. 8-bit to trochę za mało (za mała dynamika) 16 czy nawet 14-bit w prostym dekoderze, niewiele się różni od 16 bit, jeśli wcale. Liniowość DAC w STM nie powala, wiec te 12-bit to nie tak do końca.

Jeszcze całkiem "niedawno" zachwycaliśmy się 8-bitowym Covoxem na drabince rezystorów

Jak chcesz to przechowywać, jako pliki 16 bitowe? Czy nie lepiej to jednak upakować?
Jeszcze z ciekawości - jak szybko Twój system wstaje po przerwach w zasilaniu? Rozumiem, że jest tu priorytet na podtrzymanie jazdy, a dźwięk pojawia się później? To chyba najsłabszy punkt "większego" procka i rozbudowanego software, jak rozumiem jazdę masz podpiętą pod przerwania i to jest niejako niezależne od głównej części programu?

Szkoda tylko, że nie zrobiłeś od razu Plux22, bo przy takiej ilości wyjść można by dorobić bajery, typu rozświetlanie poszczególnych reflektorów w różnym tempie, czy też lekkie opóźnienia zapalania poszczególnych lamp, jak przy ręcznym ich zapalaniu...

 

[r-mik]

ak chcesz to przechowywać, jako pliki 16 bitowe?

Było o tym już kilka razy - ADPCM.

jak szybko Twój system wstaje po przerwach w zasilaniu?

Na tą chwile nie odpowiem, bo używane jest wiele funkcji debugujących, które dopiero w wersji produkcyjnej zostaną wyłączone.

jest tu priorytet na podtrzymanie jazdy, a dźwięk pojawia się później?

Nie.

o chyba najsłabszy punkt "większego" procka i rozbudowanego software

Nie. Takie argumenty słyszę od miłośników 8-bit, którzy nie znają ARM.

Jak rozumiem jazdę masz podpiętą pod przerwania i to jest niejako niezależne od głównej części programu?

To "oczywista oczywistość". Dużo dzieje się w przerwaniach, sporo robi DMA. Typowo pętla główna wykonuje się w kilkanaście us, czasem przerwanie audio zawiesza ją na dłużej.

Szkoda tylko, że nie zrobiłeś od razu Plux22,

Wszystko kwestia funduszy. Gdybym miał kasę jak ZIMO czy ESU to od razu byłoby Pux22, małe wymiary na 4 warstwach PCB, programator, program, baza setek dźwięków. Fundusze są skromne i jest co jest ale inni producenci nie dają dokumentacji za free a do moich dekoderów, co już pisałem, będzie. Niestety, baza dźwięków będzie bardzo skromna bo dając za darmo dokumentację i plik wykonywalny, nie będę inwestował w zakup dźwięków. Na razie jest:
BR01/44/50/52/93
br218/216/232
ES64U4 'Taurus/Husarz'
EZT1099
Mam dźwięki SM42 ale póki co dekoder jest na nią za duży. Do ST44 w zasadzie mam tylko silnik. Z EU07 za dużo roboty. Na tą chwilę szkoda czasu. Co innego gdybym dostał dźwięki nie wymagające wycinania fragmentów i wystarczyłoby zresamplowac i skonwertować do ADPCM następnie plików C. Niestety, współpracy Forumowiczów w tym temacie nie ma. Chętni na dźwięki ST44 czy EU07 są, chętnych aby je dostarczyć nie ma. Na pewno ograniczy to początkowa bazę dźwięków a to, które będą kosztowne, nie będą dostępne za free.

Srednio zdolny elektronik zmontuje sobie dekoder sam. Koszt łatwo oszacować po elementach i wymiarach PCB, pewnie ok 50zł. Soft można sobie wgrywać jaki pasuje, nie ma więc problemu aby przełożyć dekoder z parowozu do dizla czy elektrowozu.

 

[piotr66]

Bazę dźwięków oferuje ZIMO, znajdziesz ją na ich stronie bez problemu. Ja korzystam z tej bazy od lat dopasowując dźwięki do moich niszowych modeli jak SM03 czy parowy Kp4.

 

[r-mik]

Bazę dźwięków oferuje ZIMO, znajdziesz ją na ich stronie bez problemu. Ja korzystam z tej bazy od lat dopasowując dźwięki do moich niszowych modeli jak SM03 czy parowy Kp4.

Daj konkretny link do EU07, ST44 czy innej popularnej lokomotywy bo jak na razie, to piszesz, ze dźwięki są w Internecie ale konkretnego miejsca nie wskazujesz.

 

[sun71]

Daj konkretny link do EU07, ST44 czy innej popularnej lokomotywy bo jak na razie, to piszesz, ze dźwięki są w Internecie ale konkretnego miejsca nie wskazujesz.

Dźwięki są w bazie ZIMO. Jest tylko jeden "drobny" problem - większość,, w tym wszystkie "polskie", nie są darmowe. Swoja droga to ciekawe jest spojrzenie na format: 8 bitowy PCM z częstotliwością próbkowania ok. 11kHz.

 

[r-mik]

Dźwięki są w bazie ZIMO.

Upierm się przy konkretnym linku bo:

Jest tylko jeden "drobny" problem - większość,, w tym wszystkie "polskie", nie są darmowe.

problem jest inny. Przeważnie jest to plik wszystko w jednym. Zrobienie z tego dźwięków nadających się do użytku to może byc dzień lub więcej roboty.

Swoja droga to ciekawe jest spojrzenie na format: 8 bitowy PCM z częstotliwością próbkowania ok. 11kHz.

A co w tym ciekawego?

 

[sun71]

Upierm się przy konkretnym linku bo:


problem jest inny. Przeważnie jest to plik wszystko w jednym. Zrobienie z tego dźwięków nadających się do użytku to może byc dzień lub więcej roboty.


A co w tym ciekawego?

Baza ZIMO jest tutaj: http://www.zimo.at/web2010/sound/tableindex_EN.htm# wszystkie dźwięki darmowe dostępne są w formie wydzielonych plików z pojedynczym efektem. A co do ich parametrów - ZIMO uważane jest chyba za produkt referencyjny, w związku z tym mozna przyjąć, że takie parametry zapewniają jakość oczekiwaną przez większość użytkowników.

 

[r-mik]

Baza ZIMO jest tutaj: http://www.zimo.at/web2010/sound/tableindex_EN.htm# wszystkie dźwięki darmowe

Znam ta bazę, używam (wystarczy posłuchac dźwięków które prezentowałem) ale wskaż mi konkretnie, gdzie mam ST44, EU07, temat których przewija się już od dłuższego czasu, jak i SU45, TEM48, itp, o które mam pytania, w postaci

są w formie wydzielonych plików z pojedynczym efektem.

Nie miałem ani jednego pytania, o to, co mozna za darmo ściągnąć z ZIMO a nie ma w bazie dźwięków, która teraz oferuję.

 

[piotr66]

Jeżeli znasz tą bazę to po co o to pytasz? To oczywiste że nie ma tam polskich lokomotyw, takiej bazy jeszcze długo nie będzie, dlatego jedynym rozsądnym rozwiązaniem byłoby umożliwienie wgrywania użytkownikom, raczej należałoby się dopasować do systemu, niż tworzyć własny.

 

[r-mik]

jedynym rozsądnym rozwiązaniem byłoby umożliwienie wgrywania użytkownikom,

Nie wiem od kiedy obserwujesz ten wątek ale temat dźwięków, ich wgrywania był poruszany kilkukrotnie. Aby nie powtarzać się kolejny raz napiszę w skrócie: Zainwestujesz minimum kilkanaście (z praktyki wiem, że kilkadziesiąt) tysięcy zł? Jak tak, to napisz do mnie na es@ep.com.pl, uzgodnimy szczegóły i uruchamiam projekt wgrywania dźwięków przez użytkownika. Wszyscy będą szczęśliwi, no może poza Tobą, jak okaże się, że zwrot np 50k zł będzie trwał 10 lat albo wcale biznes się nie zwróci.

 

[r-mik]

Aby wszyscy mieli wyobrażenie o jakich kosztach mówimy przytoczę kilka cyfr ale najpierw zagadnienie zarobku.
- Ile zarabiacie na godzinę?
- Ile byście chcieli?
- Ile zapłacicie komuś za godzinę pracy?
Programiście piszącemu aplikację trzeba zapłacić ok 100zł/h. Napisze ją w ok 2 miesiące. To daje 2 miesiące * 160godzin = 320 godzin. 320 * 100zł/h = 32'000 zł. Do tego podatek, może i ZUS + sprzęt (dekodery, centralki) na którym musi pracować. 50k zł lekką ręką za aplikację.
Przypuśćmy, że sprzedam 1000 dekoderów (marzenia). 50k zł / 1000szt = 50zł i tyle muszę doliczyć do ceny dekodera.
Aplikacja to nie wszystko, program wymaga gruntownych zmian. Sam w sensownym czasie nie zrobię, więc potrzebny kolejny programista, tym razem gorzej bo musi umieć programować niskopoziomowo ale za 100zł/h się znajdzie. No i robi się 100'000zł aby w ok 2 miesiące mieć dekoder z możliwością wgrywania dźwięków przez użytkownika. To wariant optymistyczny, co jak prace się przedłużą do 3 albo 4 miesięcy?
Kredyt w banku? A co jak przez parę miesięcy sprzedaż dekodera będzie kiepska? Tracimy mieszkanie, dom.

Jeśli uważacie, że 100zł/h to dużo, to ok, znajdźcie kogoś za 15zł co napisze program. Ze względu, że ryzykowne aby ktoś za takie pieniądze zrobił to dobrze, to zaryzykujcie wynagrodzenie dla tego programisty. Za 50zł pewnie da się kogoś znaleźć ale co jak nie dokończy pracy? Zaryzykujecie 25k zł za aplikację?

Jeśli ktoś lubi hazard, zapraszam do biznesu, jeśli ktoś jest w stanie napisać aplikację a wynagrodzenie będzie otrzymywał za każdą sprzedaną sztukę programu, też zapraszam do biznesu. Chcecie aplikacji opensource? Zapraszam chętnych do współpracy.

 

[Adam Kobyliński]

Programiście piszącemu aplikację trzeba zapłacić ok 100zł/h. Napisze ją w ok 2 miesiące. To daje 2 miesiące * 160godzin = 320 godzin. 320 * 100zł/h = 32'000 zł. Do tego podatek, może i ZUS + sprzęt (dekodery, centralki) na którym musi pracować.

Nie zapomnij mu dodać jeszcze prywatnej opieki medycznej z dentystą włącznie, siłowni, basenu, solarium i sauny. No i koniecznie wyżywienie bo przecież padnie z głodu. I po wszystkim jakieś wakacje nad morzem Śródziemnym żeby się odstresował.

 

[sun71]

Aby wszyscy mieli wyobrażenie o jakich kosztach mówimy przytoczę kilka cyfr ale najpierw zagadnienie zarobku.
Chcecie aplikacji opensource? Zapraszam chętnych do współpracy.

Ja już pisałem - jestem gotów na opensource. Popatrz na konkurencję -ZIMO, tam jest 20 parę osób w tej firmie, obecnie (już od dawna) szukają programistów, oferują od 2700EUR, to mało jak na polskie warunki, a co dopiero austriackie?!, więc co najwyżej znajdą hobbystów, albo emerytów - w każdym razie od marca nie znaleźli chętnych.

Opensource to jedyny rozsądny sposób na zrobienie dobrej aplikacji. Bezkosztowo. Ustaw licencję projektu tak, żebyś mógł go sobie na pewnym etapie zamknąć (oczywiście zostawiając kod z momentu forka społeczności) i będziesz miał zrobione. Pozostaje kwestia klonów hardware, proponujesz rozsądną cenę, więc raczej nikt nie będzie Ci tu próbował rynku podbierać, albo po prostu nie publikuj projektu hardware