Forum Miłośników Symulatorów Lotniczych
Zaplecze => Software & Hardware => Sprzęt wykonany samodzielnie => Wątek zaczęty przez: Sundowner w Maja 31, 2010, 12:18:56
-
Panowie, stuknęło 5 lat od kiedy po raz pierwszy użytkownik tego forum zmontował Mjoya i rozpoczął nową erę w naszej piaskownicy. Czas najwyższy ruszyć 4 litery i zabrać się za następcę tego kontrolera. Tym razem już mniej prowizorycznie*.
Żeby jakoś ruszyć z miejsca, może zacznijmy od analizy tego co oferuje nam M'joy - jego mocne i słabe strony.
Przykładowo. Osobiście wykorzystuję go do obsługi wszystkich kontrolerów lotu. Co jest dość kłopotliwe, bo odległości są znaczne, a ilości potencjometrów i przycisków również są liczone w dziesiątki, a to z kolei generuje sporych gabarytów okablowanie ciągnące się od joya / przepustnicy / orczyka do kontrolera. Stąd mój pomysł, aby następca Mjoy'a był jednak w podstawowym wariancie układem modułowym, gdzie bazowy kontroler otrzymywałby już sygnały w postaci cyfrowej, a nie analogowej z podległych mu kart peryferyjnych. Stad np, zamiast ciągnąć do Joysticka 20 przewodów, wystarczyłoby kilka bo w samym Joysticku znajdowałaby się karta peryferyjna będąca przede wszystkim przetwornikiem analogowo-cyfrowym, może nawet i w ilości dwóch sztuk - jedna w chwycie zbierająca przyciski, a druga w podstawie - zbierająca osie i dodatkowe przyciski.
*Płytkę pod M'joya 16 zaprojektowałem z myślą o wykonywaniu jej domowym sposobem - stąd i jej niezbyt efektywne gabaryty. Oryginalny projekt powstał an takich, a nie innych kościach - bo było na nie dostępne oprogramowanie do komunikacji z USB - nie wymagające dodatkowego, drogiego układu - dzisiaj juzt e funkcje są zintegrowane w układach scalonych.
-
Bardzo mocna strona MJoy'a - prostota (montażu i użycia).
Słaba strona - mało peryferii (osi, przycisków, enkoderów), problem w użyciu większej ilości wejść bez dodatkowego oprogramowania (to jest jednak bardziej problem gier/symulatorów) i wspomniane okablowanie.
Pytanie zasadnicze: następca ma być podzieleniem MJoy'a na moduły czy całkowicie nowe rozwiązanie (niekoniecznie działające jako standardowy joystick w Windows) ?
-
Myślę nad nowym układem elektronicznym. Cały temat zapoczątkowałem, bo właśnie zakupiłem programator PICkit2 pod układy Microchip'a. Mam na stanie kilkanaście sztuk PIC18F4550 więc myślę o zabawie z nimi - one mają już obsługę USB rozwiązaną hardware'owo i mają ten dodatkowy plus, że są praktycznie darmowe (można zamówić do 3 sztuk jako próbki).
-
Pojawił się na naszym forum projekt codeking,który ma dosyć duże możliwości.Jego wada to brak interfejsu USB,to było dyskutowane oraz brak przetwarzania analogowego.
Zastosowanie układów Microchipa jest związane z poznaniem struktury tych uP.Programować można z poziomu języka wyższego rzędu tutaj nie powinno być problemów.2 lata wstecz Damos zrobił krótką analizę co potrzeba aby programować i testować platformy zbudowane na uP.Programator jest oczywiście niezbędny,ale przydałby się jakiś analizator sygnałów itp.
Damos zrobił także analizę MJoya i stwierdził,że więcej nie można już z niego wycisnąć,dlatego zaprojektował dodatkową kartę realizującą enkodery i współpracującą z MJoyem.
Zgadzam się z Sundowner,że wadą MJoya jest prowadzenie sygnałów.Tutaj rozwiązanie Skalarki eliminuje ten problem.
W mojej ocenie pomysł jest ciekawy,ale jak zwykle realizacja zależy od programistów.Szkoda,że nie ma już na forum Damosa,ale jest jeszcze kilku programistów.Może koledzy znajacy się na programowaniu wyrażą swoją opinię.
-
A właśnie sobie planowałem złożyć mjoya, a tu taka niespodzianka.
Czego można chcieć?
Po pierwsze prostota obsługi. Niech składanie będzie jednocześnie wyzwaniem i przyjemnością. Niech programowanie takiego ustrojstwa w ogóle nie będzie potrzebne, a jeżeli już to jak najmniej. Niech wszystko robi się poprzez USB. Niech ma w sobie nieograniczoną ilość możliwości podpinania potków i pstryczków.
Modułowość to zaleta, ale nie należy z tym przesadzać co by kosztów nie mnożyć. Wydaje mi się że samego joya można obsłużyć jednym modułem. Dajmy na to osie X i Y + w zapasie jeszcze 1 lub 2 dodatkowe i z 8 - 16 przycisków. Przepustnica to minimum 1 a max z 8 osi. Podział czysto z czapki, ale jakiś zarys jest. Pedały można napędzić z joya lub przepustnicy, chyba że ktoś będzie chciał mieć dodatkowo lewy i prawy hamulec na potkach.
Eekhem. Sporo tych kombinacji. Zdaje się że trzeba wyliczyć sensowne minimum geratów w module podstawowym, aby cena i możliwości spełniały oczekiwania przeciętnego kowalskiego, a resztę obrabiać rozszerzeniami potki i przełączniki.
Jak będę mógł sobie zrobić na tym wszystkie wichajstry z F-16, lub BlackSharka to znaczy że jest dobrze. No i najważniejsze. Musi działać win7/64.
-
Odnośnie ilości osi i przycisków: jesteśmy ograniczeni przez możliwości DirectX (max. 8 osi i 128 (może 256?) przycisków), więc większe możliwości to potrzeba albo zastosowania wirtualnego joystick'a (np. dwa joystick'i "podpięte" do nowego MJoy'a - dzięki temu mamy możliwość wykorzystania w każdej grze/symulatorze), albo dodatkowy program do interakcji kontroler<->symulator (ograniczamy się wtedy do gier/symulatorów, które posiadają interfejs programowy umożliwiający sterowanie symulatorem). Jedno rozwiązanie nie wyklucza drugiego, a wirtualne joystick'i są już dostępne (PPJoy).
-
Może od końca.
Maksymalna ilość przycisków nie jest jakimś specjalnym problemem jeżeli będzie dostępny program który pozwoli podpiąć pod nie skróty klawiaturowe - jak robi to SV Mapper.
Odnoścnie SimOut, to nie ma co tu komplikować sobie życia, następca M'joya powinien według mnie być w pierwszej kolejności dobrym kontrolerem dla podłączenia wajch - dającym wysoką czułość i jakość danych z osi i pewną sensowną ilość przycisków. Powiedzmy dla bazowego układu spokojnie mogą wystarczyć 4 osie i 8 przycisków - dość by obsłużyć typowa wajchę. Ale z cyfrowymi wyjściami na kolejne moduły, jak pod większą liczbę przycisków, enkodery czy tensometry. Może i nawet wielopoziomowy - przykładowo do głównego układu podpinamy na kablu 4 -żyłowym joystick, w którym mamy kolejne płytki - jedną zbiorczą, a dwie kolejne pod osie i przyciski - jedna w podstawie, drugą w chwycie. Skończyłoby się przeciąganie kilometrów przewodów.
Oczywiście układ o otwartej architekturze i dostępnym kodzie źródłowym, by się rozwijał jak najdłużej.
Co do braku potrzeby programowania - nie wiem czy da się to przeskoczyć. W wypadku mikro kontrolerów PIC problem tutaj narasta. Do Atmegi każdy z nas był w stanie skręcić prosty programator pod COMa, ale z PICami już sie chyba tak zrobić nie da. Ogromnym plusem jest dostępność układów i ich cena, ale już nie każdy będzie w stanie je zaprogramować.
-
No to mam kilka "głupich" pytań osoby ni w ząb nie wiedzącej jak działa joy + winda.
Jest możliwość zwiększenia ilości osi ponad 8? Jeżeli jest jakiś patent (z posta Codekinga wnioskuję że się da) to zmarnowanie takiej okazji byłoby niewybaczalne.
Też myślę, że podstawowa funkcja to kontroler, ale nie ma się co ograniczać. Jeżeli da się wycisnąć więcej to należy to zrobić.
przykładowo do głównego układu podpinamy na kablu 4 -żyłowym joystick, w którym mamy kolejne płytki - jedną zbiorczą, a dwie kolejne pod osie i przyciski - jedna w podstawie, drugą w chwycie. Skończyłoby się przeciąganie kilometrów przewodów.
Może aż tak bym się nie rozdrabniał. Przy modyfikacjach czy twórczym zapale od podstaw nie zawsze jest miejsce na wciśnięcie tylu płytek (w końcu rączka w joyu ma swą ograniczoną pojemność), a i koszty mogą przez to wzrosnąć. Myślę że ograniczyć się należy do w miarę całościowych urządzeń (joy, przepustnica, orczyk) opartych każde z nich na podobnej płytce, a do tego dopiero rozszerzenia dla wymagających. W takim wypadku starczyło by po 3 osie na płytkę i po kilka przycisków. Reszta to już mogą być bloki po 16, 32 i 64 przyciski czy ileś tam potów.
Z tym programowaniem to ... w zasadzie to od mjoya odstrasza mnie właśnie to. Nie urodzę sobie w kompie gniazda drukarki com czy innego. Po prostu ich n ie mam i już. Wiem wiem, można kupić takie pod usb, karty rozszeżeń itp itd. W pracy takie kupowałem technikom. Dopiero 4 czy 5 zakup pozwolił obsłużyć całość wymaganych urządzeń. Poprzednich kart soft jakoś nie widział. Troszkę to głupie, bo o ile wydałbym kasę na ryzykowne w moim przypadku zabawy w lutowanie takiej zabawki, to już przed wydaniem kasy na "port" się wewnętrznie spinam.
-
Mniej więcej tak.
Problem jaki ja mam jest taki, że przeciągam wiązkę 18 przewodów przez cała długość przedłużonej rączki Joya, a kabelków drobnych nie wykorzystuję. Potem do tej zwitki dołącza jeszcze 6 od osi i to leci kolejne półtora metra do Mjoya. Kable ważą u mnie dwa razy więcej niż Joystick. Stąd i odkłada mi się w nieskończoność przerabianie przepustnicy pod obsługę przez Mjoya, bo to by oznaczało pociągniecie tych kabli... 30.
Dlatego mi osobiście zależałoby na jak najszybszym przetworzeniu sygnałów na cyfrowe i przesyłanie ich dalej jak najmniejszą liczbą przewodów. Co ma zresztą dodatkowe plusy, bo dobre kable tanie nie są, a ich recykling jest ograniczony.
Kolejny problem jaki miałem ostatnio to przepalający się dławik. Co było skutkiem występującego "gdzieś" zwarcia - na szczęście zacząłem od miejsca gdzie miało największe prawdopodobieństwo powodować takie niebezpieczne awarie - przewody potencjometrów i źródło znalazłem dość szybko - nie musiałem całkowicie rozbierać Joya i przepustnicy, bo to z powodu ilości kabli jest zadaniem na pół dnia.
Mjoy16 w formie płytki, którą zaprojektowałem też nie jest zbyt wygodny jeżeli chcemy mieć po jednym na urządzenie - jest po prostu zbyt duży. Dlatego następce widziałbym jak najbardziej kompaktowego, ale z zachowaniem przejrzystości konstrukcji.
-
A jesteś w stanie stworzyć płytkę na tyle małą, aby zmieściła się gdzieś w rączce joya, i do tego obsłużyła hata (lub 2) i tak z 8 przycisków?
Ja też mam pewne awersje, ale w tym wypadku (nawet jak ma się 45 cm drąga :002: ) łatwiej chyba przepuścić przez niego 20x0,5 w jednej wiązce i mieć to z głowy, niż kombinować gdzie tu zmieścić ten jebonit co to go Pan Sun wykoncyptował (przypomniał mi się kawał z celofanem i ebonitem). Ja laik jestem i jedyne czym mogę służyć to mój "wypaczony" pogląd na użyteczność :004: ale wydaje mi się że w samej rączce joya czy przepustnicy i tak kabelki do płytki będą biegły, tyle że będą teraz krótsze.
Myślę zresztą że w chwili obecnej to spór czysto akademicki i że pora na niego przyjdzie (o ile w ogóle) później. W sumie można zrobić płytkę "uniwersalną", a do tego małe ustrojstwa typu puzle (chcesz przyciski w rączce użyj płytki X, aaa, chcesz ich aż 6? no to płytka Y. Masz tu dane 2 osie, a każda następna to płytka Z.
-
A jesteś w stanie stworzyć płytkę na tyle małą, aby zmieściła się gdzieś w rączce joya, i do tego obsłużyła hata (lub 2) i tak z 8 przycisków?
Bez problemu. Ja planuję Hata, 20 przycisków i 2-4 osie w czymś takim zmieścić ;)
Ja korzystam z przewodów o 2mm średnicy izolacji - to już swoje zajmuje i waży ;)
Tak jak pisałem wcześniej, ja bym to widział, przede wszystkim jako bazę - która miałaby wystarczyć do złożenia normalnego kontrolera. Ale aby od razu były tworzone do tego dodatkowe moduły rozszerzające pozwalające na podłączenie wszystkich przycisków chwytu do układu wewnątrz niego, który przesyłałby już dalej tylko dane w postaci cyfrowej - do głównego komponentu, do którego byłyby np już podpięte potencjometry... bądź inna płytka obsługująca Halle, albo tensometry. I np bazowy kontroler obsługiwałby 10 bitowo osie, ale płytka rozszerzająca już pozwalałaby wyciągnąć z nich 16 bitów, z dodatkową filtracją itp. Każdy mógłby złożyć zestaw jaki by był mu potrzebny.
-
Najtrudniejsze wydaje mi się oprogramowanie PIC'a tak by można było rozszerzać możliwości joystick'a i oczywiście odpowiednie raportowanie do Windows o pełnych możliwościach (baza + rozszerzenia).
Taki kontroler 4 osie + 24 wejścia to zgrabne rozwiązanie do realizacji kontrolerów lotu tudzież kierownic do simracing'u :)
Przypomina to mniejszego MJoy'a.
Kibicuje wszystkim, którzy się w projekt zaangażują :) Ostatnio myślałem o paru wajchach do sterowania śmigłowcami, taka płytka byłaby tu idealna.
-
Ostatnio robiłem mod do przepustnicy Cougara i musiałem przeciąć wiązkę kabli i ją wydłużyć.W przepustnicy są przełączniki oraz potencjometr.Jest mała płytka z diodami połączona wiązka kabli (około 20 nie pamiętam dokładnie).Sterownik znajduje się w podstawie drążka.Połączenie przepustnicy z drążkiem w kokpicie to około 3m kabla.
Można zrobić prosty interfejs pomiędzy przepustnicą i drążkiem np.RS232 minimalizując ilość kabli.Jest to bardzo proste rozwiązanie.
Co do programatorów do PIC to można to rozwiązać na 3 sposoby,kupić zrobić samemu lub prosić na forum o zaprogramowanie kości.Gorzej z znajomością uP,opis jest dosyć obszerny i to jest moim zdaniem wąskie gardło.
-
Bez problemu. Ja planuję Hata, 20 przycisków i 2-4 osie w czymś takim zmieścić
Lepszy niż Japończycy :002: . A w sumie to o to chodzi.Ja korzystam z przewodów o 2mm średnicy izolacji - to już swoje zajmuje i waży
Rozumiem, że jak ciągniesz kabel od potencjometru do płytki MJoya, to straty napięcia nie są pożądane, ale na boga, toż to musiały by być "kilometry", bo na przestrzeni standardowego urządzenia typu joystic (z 10 - 20 cm) to może być pomijalne. Oczywiście, w MJoyu można osiągnąć spore odległości jak się łączy kilka wajch (przepustnica, joy, itp) bo trzeba było wszystko do jednej płytki prowadzić, w takim wypadku kable są problemem. W tym projekcie jednak tego nie widać. Nawet ekran nie wydaje się nie być konieczny, odległości będą niewielkie i ewentualne szumy na kablach i tak znikną w śmieciach wchodzących przez same luty czy wtyczki i inne takie. A jak się zrobi magistralę na RS232, jak to Vito_zm sugerował, to starczy dwa kabelki 0,5mm (no jeszcze coś do prunda) i kilkaset metrów powinno śmigać. Tylko czy RS232 wystarczy na planowane cuda. Dobrze by było moduł zasilający opracować, bo USB może nie wydolić przy większych projektach. Ewentualnie dostosować rozszerzenia pod jakieś w miarę standardowe zasilacze +/- 5V.
obsługująca Halle, albo tensometry
Tak mi dobrze, tak mi mów :002:
Najtrudniejsze wydaje mi się oprogramowanie PIC'a tak by można było rozszerzać możliwości joystick'a i oczywiście odpowiednie raportowanie do Windows
Ktoś będzie musiał wykonać tą pracę, a praca kosztuje. Nie widzę problemu aby zapłacić komuś za jego dzieło.
Kibicuje wszystkim, którzy się w projekt zaangażują
Proponuję kibicować również samemu sobie Panie Codeking. Społeczność Pana potrzebuje :001:
No i jako że mam urlop to czas wziąć pilnik i popracować nad kołyską do joya. Czuję że za niedługo będzie potrzebna.
-
Lepszy niż Japończycy :002: . A w sumie to o to chodzi.
Mam scalaki PIC18F4550 w obudowach TQFP44 - one są wielkości jednogroszówki, a w sobie mają to samo co DIP40, które są gabarytów tych samych co do tej pory używane przez nas Atmegi. Oczywiście problemem staje się lutowanie takich mikrusów.
(http://img527.imageshack.us/img527/9144/dsc01146resize9ic.th.jpg) (http://img527.imageshack.us/img527/9144/dsc01146resize9ic.jpg/)
Oczywiście, w MJoyu można osiągnąć spore odległości jak się łączy kilka wajch (przepustnica, joy, itp) bo trzeba było wszystko do jednej płytki prowadzić, w takim wypadku kable są problemem. W tym projekcie jednak tego nie widać.
Następca Mjoya ma być właśnie tym - następcą Mjoya - spełniać wszystkie jego funkcje + nowe, efektywniej. Jak ktoś z tego będzie korzystał to jego sprawa, czy będzie do każdego Geratu osobny kontroler wstawiał, czy tylko jeden centralny - to jest wybór użytkownika. Ale niezależnie od tego wyboru trzeba dać użytkownikowi możliwość najbardziej efektywnego wykorzystania urządzenia.
Proponuję kibicować również samemu sobie Panie Codeking. Społeczność Pana potrzebuje :001:
Im więcej ludzi za to się zabierze tym lepiej dla projektu, pod warunkiem, że jakaś współpraca zostanie zachowana ;)
No i jako że mam urlop to czas wziąć pilnik i popracować nad kołyską do joya.
Powodzenia, czekam na zdjęcia z prac w temacie Schmeissera.
-
(http://ww.seguro.pl/sklep/admin/zdjecia/b27857b4061a0b34a9df23052010f0ff.jpg)
Takie ustrojstwo może trochę ułatwić montaż, ale bez mikroskopu skaningowego i nanomanipulatorów się i tak nie obejdzie.
Bywało w sumie gorzej, w pracy ciągle chcą ode mnie niemożliwego więc się przyzwyczaiłem.
Czas na konkrety: Jakiej pomocy oczekujesz? Czego trzeba aby to ruszyć z miejsca?
Umiem dość dokładnie zamiatać i odśnieżać. Wynoszenie śmieci jest problemem, ale szybko się uczę :002:.
OT
Kołyska w końcu powstanie, mam zamiar ukraść Ci projekt i dostosować go do elementów ogólnodostępnych. Znalazłem już dwa pierścienie stalowe 120/90 mm posłużą za bazę. resztę muszę wyszperać ale mam już pewne pomysły. fotobloga umieszczę w "słodowym"
Powrót na ziemię, czas wyjść z psem na długi spacer.
-
Czas na konkrety: Jakiej pomocy oczekujesz?
Wiedzieć czego ludzie potrzebują - po to jest ten temat.
Czego trzeba aby to ruszyć z miejsca?
8 lat doświadczenia w pracy z PICami :020:
A na serio, to kości mam, dokumentację też, programator zamówiłem, pozostaje jedynie czekać na Breadborda aż dotrze z Chin, a na to mają 20 dni.
-
Wiedzieć czego ludzie potrzebują - po to jest ten temat.
Można spróbować to określić, widzę takie potrzeby:
- wolant/drążek sterowy (śmigłowce) - 2 osie, hat, 8 (z zapasem) przycisków
- orczyk - 3 osie
- przepustnice (3-8 osi)
- dźwignia skoku (śmigłowce) - min. 2 osie, hat, 8 (z zapasem) przycisków
Do tego dochodzą różne panele do których potrzeba sporo przycisków i niewiele mniej enkoderów, np taki moduł: 16 wejść + 4 enkodery - taka płytka powinna wystarczyć do realizacji prostych paneli, MCP i FMS to inna bajka.
Chętnie pomogę, ale możliwości odnośnie PIC'ów i doświadczenia w elektronice mam żadne lub nikłe. Po stronie Windows mogę działać.
-
No i jako że mam urlop to czas wziąć pilnik i popracować nad kołyską do joya. Czuję że za niedługo będzie potrzebna
Temat zaczyna być interesujący.Mam problem z modem do drążka Cougara.Generalnie muszę zmniejszyć gabaryty podstawy lub zastosować inne rozwiązanie.Rozwiązanie EGHI jest ciekawe,ale trudne do realizacji.Zdaję sobie sprawę,że temat jest w złym miejscu,ale chciałem zwrócić uwagę autora cytatu na problem,który mnie interesuje.Może yano będzie ten temat kontynuował w innym wątku.
-
Dziwny jest ten świat, już dawno temu pokazałem taki projekt, dokładnie na PIC-ach 4550 (chociaż w chwili obecnej one są już stare, mają swoich następców) z potężnymi możliwościami, płytki są gotowe i przetestowane, DK pracuje z tym urządzeniem ....
ale się nie da, potrzeba wymyślać nowy SIMOUT potem jeszcze coś nowego i nowego.... do czego to prowadzi.... i na końcu zainteresowanie żadne bo zawsze będzie za drogo, bo wymiary nie te etc ...
Jak teraz czują się osoby kibicujące ostatniemu projektowi SIMOUT, zachęcające Zająca do pracy a teraz się na ten projekt wypną.
Nie rozumiem też Codekinga, jaki był cel tracenia czasu na SIMOUT? (bo w tej chwili zdechnie, nikt już na to pieniędzy nie wyda widząc nowe kombinacje).
Sundowner, życzę powodzenia (ale przygotuj się na katastrofę)
Skalarki
-
już dawno temu pokazałem taki projekt
płytki są gotowe i przetestowane
ale się nie da, potrzeba wymyślać nowy SIMOUT
Oj sporo żalu słychać.
A można troszkę więcej informacji? Nie wiem czy koniecznie trzeba wyważać otwarte drzwi.
i na końcu zainteresowanie żadne bo zawsze będzie za drogo
To nie do końca tak. Jakoś ludziska wydają setki złotych na joye. Oczywiście, na początku im taniej tym lepiej, ale jak ktoś się wciągnie, to z czasem poszukuje troszkę lepszych niż ogólnodostępne komercyjne rozwiązania. Jasne że cena ma znaczenie, ale nie przesadzajmy. "Za psie pieniądze będziemy jeść psie żarcie". Tu do kształtowania popytu dochodzi jeszcze czynnik wykonania. Łatwiej udać się do Media, czy Saturna, niż samemu coś wydłubać.
Dla mnie ideałem byłoby aby takie "cusie" dostępne były w wersji puzzle oraz dla tych mniej uzdolnionych manualnie w wersji gotowej.
-
Nie rozumiem też Codekinga, jaki był cel tracenia czasu na SIMOUT? (bo w tej chwili zdechnie, nikt już na to pieniędzy nie wyda widząc nowe kombinacje).
Nie rozumiem. W którym miejscu projekt następcy Mjoy'a wchodzi w paradę projektowi SimOut ?
Sundowner, życzę powodzenia (ale przygotuj się na katastrofę)
Nie wiem co by musiało się stać aby jakąkolowiek porażkę w tym projekcie określić mianem katastrofy... układ po pierwszym uruchomieniu musiałby chyba ściągnąć kilka asteroid na kurs kolizyjny z ziemią.
-
Przepraszam za OT (w razie czego można utworzyć temat do dyskusji nad celami/przesłankami towarzyszącymi takim projektom).
ale się nie da, potrzeba wymyślać nowy SIMOUT potem jeszcze coś nowego i nowego.... do czego to prowadzi.... i na końcu zainteresowanie żadne bo zawsze będzie za drogo, bo wymiary nie te etc ...
Każdy kto zrobił (lub próbował) tego typu projekt tak aby wszyscy byli zadowoleni, wie, że to jest niemożliwe, właśnie ze względu na to co napisałeś (cena, wymiary itd.). Twoje rozwiązanie jest bardzo dobre i mi osobiście bardzo się podoba, ale cena na realia polskie jest kosmiczna. simOUT nie ma być zamiennikiem żadnych innych tego typu projektów, ma być uzupełnieniem MJoy'a. Stąd mały stopień skomplikowania uruchomienia i niska cena.
Jak teraz czują się osoby kibicujące ostatniemu projektowi SIMOUT, zachęcające Zająca do pracy a teraz się na ten projekt wypną.
Jeśli masz na myśli osoby, które zamówiły płytki to w przypadku gdy ktoś jednak stwierdzi, że to nic nie warte to niech do mnie napisze - postaram się problem rozwiązać.
Nie rozumiem też Codekinga, jaki był cel tracenia czasu na SIMOUT? (bo w tej chwili zdechnie, nikt już na to pieniędzy nie wyda widząc nowe kombinacje).
To nie był (jest) stracony czas. Projekt powstał przede wszystkim dla Zająca i dla mnie. Jak ktoś z niego skorzysta to fajnie, jak nie to OK.
Sundowner, życzę powodzenia (ale przygotuj się na katastrofę)
Nie będzie katastrofy pod warunkiem, że Sundowner nie traktuje tego czysto komercyjnie (a tego nie zauważyłem w tym temacie) bo wtedy takie ryzyko istnieje.
Tutaj wg. mnie tkwi problem i różnice w projektach takich jak MJoy, simOUT i SkalarkiIO. Te pierwsze to projekty non-profit. Jak ktoś robi coś komercyjnie to na pewno jest stres bo czas poświęcony na projekt jest przeliczany na pieniądze. W projektach non-profit ten czas przeliczany jest bardziej na "fun".
Koniec OT.
-
W elektronice nigdy nie grzebałem, ani nie będę dla zysku. Jeżeli uda mi się coś stworzyć na bazie tych PICów, to plany i soft będą dostępne dla wszystkich. Może będę miał parę układów złożonych dostępnych po cenie materiałów + coś za robotę, ale to przy okazji, a nie cel takiego projektu.
-
Oj sporo żalu słychać.
I tak i nie. Nie jest to żal za utraconymi dochodami bo projekt na tym forum został przedstawiony początkowo jako komercyjny w fazie rozwojowej ale potem plan był taki aby projekt udostępnić dla każdego.
Twoje rozwiązanie jest bardzo dobre i mi osobiście bardzo się podoba, ale cena na realia polskie jest kosmiczna.
Ceny, które pojawiły się w tamtym czasie były dla płytek prototypowych. Jeśli porównać ilość elementów oraz ich koszt np z SIMOUT to jest ona bardzo podobna, ale już możliwości o wiele większe. Druga sprawa to firma, która robiła płytki dla mnie wtedy zdarła ze mnie okrutnie, sam koszt płytki to było 60% ceny końcowej. Teraz płytki robię w drukowane i są kilkakrotnie niższe. Dla jasności płytka do mojego projektu I/O GLARE kosztuje około 60zł. A możliwości płytki to: 96 wejść, 48 wyjść, 6 przetworników A/C i 32 wyświetlacze 7-seg. oraz 2 dodatkowe gniazdka dla rozszerzania możliwości.
Nie rozumiem. W którym miejscu projekt następcy Mjoy'a wchodzi w paradę projektowi SimOut ?
Nie wiem co by musiało się stać aby jakąkolwiek porażkę w tym projekcie określić mianem katastrofy... układ po pierwszym uruchomieniu musiałby chyba ściągnąć kilka asteroid na kurs kolizyjny z ziemią.
Nie tyle chodziło bezpośrednią "konkurencję" a o to że będzie to dodatkowy projekt, który ani nie rozwiązuje problemu budowniczych małych kokpitów, skrzyneczek, itp ani nie zastąpi SImOUTa
Moim zdaniem potrzebny jest projekt, który połączy zalety w jedną całość i nikt nie będzie musiał kombinować, co czym sterować, łatwiej i taniej.
A mówiąc o "katastrofie" miałem na myśli efekt finalny projektu... czyli po ekscytacji, dziesiątkach postów itp skończy się jak zawsze.
-
W elektronice nigdy nie grzebałem, ani nie będę dla zysku. Jeżeli uda mi się coś stworzyć na bazie tych PICów, to plany i soft będą dostępne dla wszystkich. Może będę miał parę układów złożonych dostępnych po cenie materiałów + coś za robotę, ale to przy okazji, a nie cel takiego projektu.
Zrobić coś na tych PIC-ach nie jest trudno bo support i materiały są dostępne. Ale jeśli rzeczywiście nie "grzebałeś w elektronice" a dokłądniej przy mikrokontolerach PIC to przegryzienie się przez datasheeta, projektowanie układów, SPI, I2C, przetworniki A/C itd, itp zajmie ci rok albo dłużej, chyba że masz na to czas 24/7.
Kończąc... jeśli jest wola żeby kontynuować w jakiejkolwiek formie mój projekt - mogę udostępnić moje materiały i służyć pomocą jeśli będzie taka wola ...
Skalarki
-
Witam,
mam pewne doświadczenia związane z projektowaniem układów elektronicznych,dlatego pozwoliłem sobie na wyrażenie swojej opinii.
Kilka uwag ogólnych.Stosuję kilka "platform" w swoim projekcie.Pytanie, dlaczego?Z kilku powodów,głównie jest to związane z przypadkowym poznawaniem kolejnych projektów.Każdy z tych projektów ma wady oraz zalety.Przykład:
Mjoy.
Zaletą tego sterownika jest jego prostota w montażu,uruchamianiu oraz stosunkowo duże możliwości.
Wady brak sterowania układów wykonawczych np.LED,7-seg.LED itp.Czasem pojawiają się problemy z uruchamianiem inna nazwa,nie rozpoznawanie urządzenia itp.Pomimo tych wad ja go będę stosował.Jest przydatny tam gdzie chcemy obsłużyć tylko jeden lub dwa panele np.ICP w Falconie.Dodatkowa zaleta to przyjazny SVMapper.
Karty OC.
Główną ich zaletą jest możliwość pracy autonomicznej np.sterownik serwo oraz oprogramowanie SIOC (jest możliwe do opanowania).
Tutaj dodatkowa uwaga.Gdyby jeden z pitbuilderów (Michi) nie napisał programu FAST,który umożliwia sterowanie Falconem,to nie mógłbym stosować tych kart.
SimOUT.
Zamówilem i czekam.Potrzeba sterowania paneli w symulatorze spowodowała,że codeking zaprojektował pod swoje potrzeby tę platformę.Udostępnił ją dla innych i chwała mu za to.Nie chcę oceniać możliwości tej platformy jest za wcześnie.Dla moich potrzeb jest ona przydatna głównie ze względu na DK z opcją dla Falcona.
Będę miał w swoim kokpicie 2 Mjoy,karty OC oraz SimOUT.
Moim zdaniem dla sterowania kokpitu najlepszym rozwiązaniem jest platforma Skalarki z kilku powodów.Gdybym budował elektronikę dla kokpitu od nowa zastosowałbym platformę Skalarki.
Co do następcy MJoya to warto przeczytać wypowiedź Damosa z 9 04 2009 (odpowiedź #494)
http://www.il2forum.pl/index.php?topic=8603.msg195270#msg195270
Ja się z nim zgadzam.Wąskie gardło tego projektu to programowanie piców.Z grona osób biorących udział w tej dyskusji tylko Skalarki ma doświadczenie w programowaniu tych uP.Jeśli ten projekt ma powstać w jakim określonym czasie np.12 miesięcy to tylko jego pomoc może to zapewnić.
Przepraszam jeśli trochę zamąciłem,ale może jestem zbyt ostrożny w swoich opiniach.
-
Witam po długiej przerwie :010: :banan
Właśnie wróciłem z ponad półrocznego wygnania do UK i widzę, że dużo się działo :) Nawet moje konto zostało skasowane... :121:
Mam nadzieję, że Ojcowie Moderatorzy wybacza mi off-topa, jednak muszę:
Codeking, Skalarki, Vito_zm, Zając - zrobiliście kawał dobrej roboty! Wyrazy szacunku!
Powracając do meritum... Sundowner - nie zrażaj się. Roboty masa, czasu brak (coś o tym wiem), ale satysfakcja z osiągniętego efektu - bezcenna :010: :020: Pójdź w kierunku urządzenia HID a SVMapper i reszta tooli będą nadal działać.
Co do następcy MJoya - sądząc po ilości problemów z kompatybilnością software'owego USB ze standardem - przydał by się bardzo. Są obecnie dostępne układy, które mają sprzętowe USB, kosztuje 15 PLN, mają masę portów in-out i centymetr kwadratowy powierzchni... Mogą zrealizować MJoy'a na płytce o wielkości 3x6 cm (gdzie większość zajmują złącza). Stosując jedynie kilka (5?) elementów dyskretnych:
(http://img208.imageshack.us/img208/3332/atmega32u4boardsmdtop.th.jpg) (http://img208.imageshack.us/i/atmega32u4boardsmdtop.jpg/)
można i na montażu tradycyjnym:
(http://img199.imageshack.us/img199/8809/atmega32u4boardtop.th.jpg) (http://img199.imageshack.us/i/atmega32u4boardtop.jpg/)
masz do dyspozycji 12 osi analogowych lub do 26 przycisków lub do 13 enkoderów. Brak zabawy w programatory i złącza do nich - wszystko przez USB. Jeśli chodzi o stabilność - startowało mi to na "pająku" nawet bez kondensatorów przy rezonatorze! :karpik . Są też takie rozwiązania gotowe w cenie poniżej 150$
Skalarki ma rację, że wiele różnych projektów (software i hardware) nie pasujących do siebie zniechęca. Dlatego (imho) należy szukać dobrze zdefiniowanych punktów styku (interface'ów), takich jak np. HID (który akurat udokumentowany jest dość kiepsko ;) ), TCP/IP itp.. Należy dążyć do sytuacji, kiedy każdy może zrobić swój hardware, mały driver do niego i reszta systemu go obsłuży. Tak samo z softwarem. Powinien bez zmian obsłużyć każdy nowy hardware zgodny z pewnymi założeniami. Wtedy niczyja praca się nie zmarnuje. Wiem.. łatwo powiedzieć :)
"Mój" projekt miał być właśnie takim bridgem, ale z powodu ambitnych założeń tudzież innych zdarzeń losowych zatrzymał się na minimum koniecznym do realizacji pierwszego wdrożenia (jednokierunkowe sterowanie światłami): server "output-only", biblioteki klienta, emulator, configi w xml'u, specyfikacja dla driverów i przykładowy driver USB. Nadal daleko do dwukierunkowej komunikacji i ładnego UI do zarządzania konfiguracją. Kompletny brak dostępu przez HTTP, tylko TCP, brak SDK do pisania sterowników dla własnych urządzeń :015: Musiało to chodzić na Linuxie, co przysparzało dodatkowych problemów. Mikro-sukcesem na otarcie łez jest wdrożenie, w którym firma 3-cia dorobiła driver do własnej karty sterującej i wszystko zadziałało :)
Pomyślcie o takim modelu - może wtedy uda się połączyć wszystkie Wasze obecnie istniejące moduły i sukcesywnie dodawać nowe?
Ja ze swej strony boję się cokolwiek deklarować, bo jak firma znów wpadnie w kłopoty a ja wyląduję na "wysuniętej placówce" z NDA na karku i blokowanym internetem - to kolejny raz wyjdę na idiotę...
W czwartek zabieram rodzinę na długie i zasłużone wakacje a po powrocie będę do dyspozycji, jeśli do czegoś się przydam :)
Apropos nowoczesnych mikrokontrolerów, chłopaki z USA na podobnej płytce:
(http://img22.imageshack.us/img22/8249/avr32board1top.th.jpg) (http://img22.imageshack.us/i/avr32board1top.jpg/)
zrobili emulator klawiatury, który w odpowiedzi na załączenia poszczególnych styków wysyła kody klawiszy, które udają działania usera (uruchamiają akceleratory na przyciskach w aplikacji). Taki MJoy+SVmapper w jednym. Niemal dowolnie konfigurowane przez USB. Konfigurowali pod Windowsem, podłączali później do Linuxa i nie potrzebowali tam żadnych sterowników - po prostu udawało klawiaturę. IMO świetny pomysł. Na tej kości można by zrobić USBJoy'a konfigurowalnego pomiędzy dowolnymi wariantami osi analogowych, przycisków, enkoderów (a tam jest do 8-miu osi analogowych, do 44 przycisków bez setki diod i do 22 enkoderów, 7 end-pointów USB, co pozwala zrobić na nim 3 joye :) a to wszystko na płytce 10x5 cm )
Obudowa TQFP i raster 0,5 mm może przestraszać, ale nie ma się czego bać: http://www.youtube.com/watch?v=vZ1qisX52rI w praktyce łatwiejsze niż może się wydawać na pierwszy rzut oka.
Tu przewagę mają PIC'e, bo tam chyba w obudowie DIP jest sprzętowe USB. Jednak ja znam się jedynie na Atmelach i tam mogę pomóc (obudowy "trudniejsze" ale i dużo więcej pinów).
-
Witaj Damos,jak to dobrze znów ciebie "widzieć".Bardzo się o Ciebie martwiłem,tak nagle zamilkłeś.Próbujemy na forum coś robić,ale brakowało nam konsultanta.Tym masz duże doświadczenie i szersze spojrzenie na projektowanie układów uP.Witamy ponownie na forum i liczymy na Twoje wsparcie.
-
Witaj z powrotem Damos.Powracając do meritum... Sundowner - nie zrażaj się. Roboty masa, czasu brak (coś o tym wiem), ale satysfakcja z osiągniętego efektu - bezcenna :010: :020: Pójdź w kierunku urządzenia HID a SVMapper i reszta tooli będą nadal działać.
Co do następcy MJoya - sądząc po ilości problemów z kompatybilnością software'owego USB ze standardem - przydał by się bardzo. Są obecnie dostępne układy, które mają sprzętowe USB, kosztuje 15 PLN, mają masę portów in-out i centymetr kwadratowy powierzchni... Mogą zrealizować MJoy'a na płytce o wielkości 3x6 cm (gdzie większość zajmują złącza). Stosując jedynie kilka (5?) elementów dyskretnych:
(...)
masz do dyspozycji 12 osi analogowych lub do 26 przycisków lub do 13 enkoderów. Brak zabawy w programatory i złącza do nich - wszystko przez USB.
Zrażać się nie mam czym, do PICów i tak usiąść muszę z powodu odkładanych od dłuższego czasu innych projektów, więc i na tym polu zadziałać spróbuję.
Czy dobrze rozumiem, że ten uP programuje się bezpośrednio przez USB ? To rozwiązuje wiele problemów.
Co do wszystko-funkcyjnych układów, to moje zdanie jest takie, że układy powinny być minimum dwa. Jeden kontrolerów lotu, drugi - reszty kokpitu. Mimo wszystko ludzi budujących dodatkowe panele nie ma wielu. Jeszcze mniej takich co składają sobie zegary czy całe kokpity. Dochodzą dodatkowe problemy poza symulacjami Falcon/LockOn/DCS/FSX. W starszych/ prostszych grach niekoniecznie możliwości kombajnów da się wykorzystać, albo są i takie gdzie wręcz przeszkadza (jak to ostatnio doświadczam w MechWarriorze 4). Stąd własnie pomysł aby powstał bezpośredni następca Mjoya - układ czysto do kontrolerów - bazowo optymalnie prosty, ale z możliwością rozbudowy o dodatkowe moduły według potrzeb. Przede wszystkim komunikacja jednostronna, chociaż przy jednym z projektów przydałaby mi się drobna dwustronna - aby obsłużyć układ sterujący siłą na drążku (według prędkości i przyspieszeń) oraz "wibrę" (według informacji o przeciągnięciu).
Sam nadal rozpisuję sobie to co będzie potrzebne - to co bazowo, to co dodatkowo itp. Programator już dostałem, czekam tylko na Breadboarda, bo typowy pajączek mnie już nie bawi ;)
-
Czy dobrze rozumiem, że ten uP programuje się bezpośrednio przez USB ? To rozwiązuje wiele problemów.
Tak. Atmega32U4 fabrycznie jest zaopatrzony w tzw. "bootloader" i po wciśnięciu resetu (lub w innych uC: reset + dodatkowy pin HWB) przełącza się w tryb programowania i można go zaprogramować via USB używając programu dostarczonego przez producenta. Przejść w tryb programowania można też czystko "software'owo po stronie kontrolera - np. twój soft dostaje po USB polecenie (np. przez HID Contorl Report) i wywołuje kod bootloadera, lub ustawia odpowiednią flagę i wywołuje RESET. Możesz też do własnego programu dołączyć funkcjonalność pobrania i zapisania nowej wersji firmware'u.
Co do wszystko-funkcyjnych układów, to moje zdanie jest takie, że układy powinny być minimum dwa. Jeden kontrolerów lotu, drugi - reszty kokpitu. Mimo wszystko ludzi budujących dodatkowe panele nie ma wielu.
W pełni się z Tobą zgadzam.
Przede wszystkim komunikacja jednostronna, chociaż przy jednym z projektów przydałaby mi się drobna dwustronna - aby obsłużyć układ sterujący siłą na drążku (według prędkości i przyspieszeń) oraz "wibrę" (według informacji o przeciągnięciu).
HID - jest od tego standard, który definiuje zasady wymiany informacji o FF. Wtedy urządzenie będzie działać na każdym kompie z każdą grą.
kilka hintów, z tego, co mam pod ręką:
http://www.usb.org/developers/devclass_docs/HID1_11.pdf
http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
http://www.usb.org/developers/devclass_docs/pid1_01.pdf
http://www.usb.org/developers/devclass_docs/pdcv10.pdf
http://www.microsoft.com/whdc/archive/hidgame.mspx
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf
http://www.usb.org/developers/hidpage/dt2_4.zip
http://www.usb.org/developers/hidpage/question/
Jednak, niestety braki/niejasności w dokumentacji prowadzą to takich paradoksów: The problem with some joysticks is the way buttons are assigned and the special meaning certain buttons have. Basically every device has one button number which is the first button assigned and this has a special meaning in identifying the class of device. So the first button for joysticks is BTN_JOYSTICK, the first one for a gamepad BTN_GAMEPAD and BTN_DIGI is the first one for tablets. Any further buttons get a number of the first button + x. Unfortunately the number range is limited and nobody thought of devices with 40 buttons. So those end up with buttons that would normally stand for a completely different class of device.
And then (having BTN_DIGI defined) it is not considered a joystick because that would be a tablet and did cause tablets to come up as non functional joysticks.
W przypadku PIC'ów polecam też ten wątek:
http://www.microchip.com/forums/tm.aspx?m=476706&mpage=1&key=񴾫
No to masz materiał na ładnych kilka tygodni ;)
-
Poczytałem o tym ATmega32U4 i wygląda bardzo interesująco. Zamówiłem kilka sampli... ciekawe czy tym razem przyślą. Microchip i Maxim ślą sample w prawie hurtowych ilościach Atmel i Allegro za Chiny ludowe nawet jednej kości do tej pory nie chciały.
Dzięki za materiały, zaraz je przejże.
-
Sample :)
Ja na nie nie liczyłem - tam kupowałem http://www.seguro.pl/sklep/?zobacz=5127&producent=
Natomiast resztę części tu: http://www.maritex.com.pl/pl/shop/index/ggid/8661 4 PLN za 100 szt kondensatorów, 1,25 PLN za 100 szt. rezystorów :020:
Rzuć jeszcze okiem na to: http://www.seguro.pl/sklep/?zobacz=4841&producent=
80 DMIPS, zewnętrzny zegar na poziomie nie wymagającym zaawansowanego PCB (12 MHz ?) a wewnętrzny PLL do 60 MHz, 44 porty IO.
IMO Atmega32U4 świetnie nadaje się na USBJoya a AT32UC3B na coś większego.
-
A rozglądałeś się za przetwornikami ADC ? MAX11046 wygląda interesująco - 16bit, 8 równoległych kanałów, tylko kosztuje 5x tyle co ten uP ;) Ale można zamówić sample - po tygodniu - dwóch są dostarczane.
-
patrzyłem na to:
http://www.seguro.pl/sklep/?zobacz=5084&producent=
W jednej kości 50 portów I/O (z matrycą diodową daje to 625 przycisków ;) )
Do tego 16 12-bitowych przetworników samplujących 2 Msps. Przy takiej prędkości można zrobić oversampling dla zwiększenie rozdzielczości. Całość umieszczona w osobnym układzie i połączona przez I2C nie wymaga od głównego procka obsługującego USB przechodzenia w trakcie próbkowania w tryb "uśpienia" dla zmniejszenia szumów ADC. Do tego dwa przetworniki DAC (!). Jest też tańsza wersja - za 15 PLN mająca bardziej przyjazną obudowę (TQFP44) i mniej portów I/O - 34 zamiast 50 i 12 kanałów ADC. Reszta ta sama. Samodzielny, pojedynczy przetwornik 12-bit kosztuje podobnie (tyle, że jest szybszy).
Za bardziej precyzyjnymi nie rozglądałem się...
edit:
MAX11046 wygląda bardzo interesująco, super-niskie szumy i równoległy sampling...
-
Powoli rozplanowuję sobie budowę drążka na tensometrach. W chwili obecnej będzie to wersja dostosowana do Mjoya (wpinana zamiast potków).
Mam w związku z tym kilka pytań do "wszechwiedzących"
Jakie siły są przykładane przez pilota na sidestick z f16 (coś mi mówi że pewnie w granicach do 5 - 7 kg, ale warto by mieć szczegółowe dane)
Jaką rozdzielczość ma mjoy na osi.
W założeniach projektu* przyjąłem sobie nacisk na drążek do 5 kg, przy czym wydaje się że dokładność pomiaru nacisku do 1g będzie granicą tego co ludzka ręka może uzyskać.
Ostatni raz parałem się jelektroniką 25 lat temu, a i to tylko miganie żarówką (LEDów wtedy jeszcze nie znano) i takie tam zabawki, więc prace posuwają się opornie. Na szczęście rozwój jaki od tamtego czasu nastąpił spowodował powstanie wielu dziwnych symulatorów układów, dzięki czemu łatwiej się wiedzę przyswaja.
Chociaż wydaje mi się że teraz jest o wiele łatwiej. Bierze się magiczną czarną kostkę, podpina pod nią mostek pomiarowy z tensometrów do tego dowolne zasilanie i już się ma na wyjściu 0 - 5 V niczym się nie przejmując. Jakbym miał to lutować z części o jakich pamiętam że kiedyś były na topie, to nie dość że pewnie bym się wyłożył już przy samym zasilaczu wzmacniacza, to dodatkowo miało by to wielkość telewizora "Rubin"
*dumnie brzmi
-
Jakie siły są przykładane przez pilota na sidestick z f16 (coś mi mówi że pewnie w granicach do 5 - 7 kg, ale warto by mieć szczegółowe dane)
Nie pamiętam już danych dotyczących sił na drążku w F-16, ale przy innych maszynach z klasycznym drążkiem i układem zwrotnym jest między 1, a 2 funty na każde 7° wychylenia, a maksymalne wychylenie jest w granicach 16-18°
Jaką rozdzielczość ma mjoy na osi.
1024 punkty pomiarowe (10 bit) ale... tylko jeżeli wykorzystasz pełen przedział 0 do 5V podawane na port przetwornika analogowego. Im mniejszy zakres wykorzystasz, tym gorsza będzie dokładność.
W założeniach projektu* przyjąłem sobie nacisk na drążek do 5 kg, przy czym wydaje się że dokładność pomiaru nacisku do 1g będzie granicą tego co ludzka ręka może uzyskać.
Zdziwiłbyś się ;) Weź elektroniczną wagę kuchenną i pobaw się nią naciskając ręką i zobacz jakie najmniejsze zmiany jesteś w stanie świadomie wprowadzać ;)
-
Zdziwiłbyś się ;) Weź elektroniczną wagę kuchenną i pobaw się nią naciskając ręką i zobacz jakie najmniejsze zmiany jesteś w stanie świadomie wprowadzać
No przecież od tygodnia w każdym sklepie się wagą bawię. Fakt że te wagi najczęściej są właśnie do 1g, ale trzeba się nieźle natrudzić aby utrzymać stabilny nacisk 1g. Jeżeli chodziło Ci o to że to za dużo, to przecież zapas nikomu nie zaszkodzi. Jeżeli za mało to też nie problem o ile jakieś ustrojstwo wyciągnie z mojego zakresu napięcia większą rozdzielczość. Jak widać mjoy do tego będzie troszkę słaby... potrzeba mi minimum 12 bitów a 14 i więcej byłoby ideałem.
Tak czy siak nie znam się na tych małych czarnych diabelskich kostkach, więc ktoś inny musi pokombinować jak to zmajstrować, aby moje 0 - 5 V przerobić na precyzyjną oś.
tylko jeżeli wykorzystasz pełen przedział 0 do 5V
Właśnie w tym przedziale będzie działać. przy czym od zera do kilka miliV będzie obcięte na zero, co by przy epilepsji dało się grać.
Nie pamiętam już danych dotyczących sił na drążku w F-16, ale przy innych maszynach z klasycznym drążkiem i układem zwrotnym jest między 1, a 2 funty na każde 7° wychylenia, a maksymalne wychylenie jest w granicach 16-18°
To jakieś 3 kg przy maksymalnym zakresie. No nic, zacznę od nieruchomego (niewychylnego) aby potestować sam układ. Co do wychyleń mam kilka pomysłów, ale tu wchodzi w grę mechanika, której domowym zestawem pilnika, piłki do metalu i płaskoszczypów uniwersalnych nijak nie obsłużę.
Przy okazji - czy ktoś zna w Warszawie jakieś miejsce z dostępem do frezarki? Tylko nie takie gdzie trzeba tysiące sztuk na raz zamawiać.
-
Jak widać mjoy do tego będzie troszkę słaby... potrzeba mi minimum 12 bitów a 14 i więcej byłoby ideałem
Można rozpocząć testy od MJoya.Później przejść na precyzyjny przetwornik 16 bitowy a/c.Z tym jest związanych parę problemów,które można pokonać.Jeśli projekt będzie na etapie modelu pracującego z np.MJoyem to można pomyśleć o dokładniejszym przetworniku.Trzeba mieć świadomość o jakich napięciach myślimy.Dla przetwornika 12 bitowego przy zakresie 0-5V musimy kodować napięcia rzędu pojedynczych mV.
-
Można rozpocząć testy od MJoya
Moim szatańskim planem było złożyć całość do kupy na mierniku, a potem podesłać Ci do testów na mjoyu :002: , jako że sam takiego ustrojstwa nie posiadam i jeżeli ktoś go dla mnie nie zrobi to raczej nie będę posiadał.
Dla przetwornika 12 bitowego przy zakresie 0-5V musimy kodować napięcia rzędu pojedynczych mV.
Mogę podać na wyjściu ze wzmacniacza prawie dowolne napięcie, ograniczeniem będzie ADC i jego możliwości w tym zakresie (no i cena końcowa), nie wiem na co sobie można w mjoyu pozwolić.
Planowałem zrobić do testów coś na kształt potka elektronicznego sterowanego mostkiem tensometrycznym, aby po prostu wpiąć to w mjoya zamiast potka.
-
Rozmawiałem dzisiaj z kolegą,który ma praktykę w układach analogowych.Projektował między innymi kodeki dla stereo na bazie przetworników 16 bitowych z tym,że wykorzystywał tylko 14 bitów.Zwrócił mi uwagę na fakt,że można wykorzystać przetwornik 10 bit w uP,ale stosując kompresję sygnału wejściowego,która polega na tym,że wzmacniamy sygnały o małym poziomie.Charakterystyka wzmacniacza jest podobna do logarytmicznej.Daje to lepszy stosunek sygnał szum kwantyzacyjny.
W naszym przypadku jeśli założymy,że kodujemy sygnały od 1g do np.3kg to potrzeba rzeczywiście 12 bitów.
Mam pytanie do Sundownera,jaki wpływ na działanie sticka miałoby nieliniowe kodowanie sygnału wejściowego.Kolega zwrócił uwagę na fakt,że w samochodach przy małej prędkości mamy działanie wspomagania inne niż przy dużej prędkości.
Jeszcze jedna uwaga,czy można założyć,że w sterowaniu samolotem działamy głównie w zakresie mniejszych sił a maximum występuje w wyjątkowych sytuacjach?
Co do testów to nie ma problemu,ostatnio testowałem kartę SimOUT i testy wyszły pozytywnie.Mogę także pożyczyć Tobie MJoya do testów.
-
Stosunek wychylenia sterów do odchylenia drążka sterowego jest praktycznie zawsze charakterystyką liniową - reakcja samego samolotu na wychylenie sterów już oczywiście nie. Ale nic nie stoi na przeszkodzie by joystick pracował nieliniowo - przy niektórych mało dokładnych kontrolerach, jest to wręcz wskazane, zważywszy, że potrzebujemy wysokiej precyzji w centrum. Stąd np zmieniamy charakterystyki na kwadratową lub inną pokraczną w takim Il2, czy LockOn. W Joypadach też mamy z tym do czynienia, bo inaczej nie dałoby się z nimi żyć.
Zmiana siły na samych sterach ma miejsce w maszynach kierowanych klasycznie przez cięgna i popychacze - wraz ze wzrostem prędkości - więc i sił na lotkach. Nie ma tego w maszynach posiadających proste wspomaganie hydrauliczne - np. Bell JetRanger, oraz bardziej skomplikowanym hydraulicznym z układem zwrotnym. Jednakże na myśliwcach odrzutowych stosuje się zmiany sił mimo wspomagania hydraulicznego - nie tylko zależnie od prędkości, ale przede wszystkim od przeciążenia - albo poprzez przeciwwagę (F-8 Crusader), albo przez zmianę przełożenia siły z klasycznych sprężyn na drążek (zmiana długości ramienia).
Problem jest taki, że żaden z tych układów nie powoduje nieliniowej zmiany sił niezależnie od warunków lotu. Stojąc na rampie przez cały zakres ruchów sterów - siły będą liniowe w każdej z tych maszyn.
-
Jak widać mjoy do tego będzie troszkę słaby... potrzeba mi minimum 12 bitów a 14 i więcej byłoby ideałem.
Mam coś takiego:
http://www.leobodnar.com/products/BU0836A/
Poniżej strony są też sensory Halla. Mogę tą kartę udostępnić do testów.
-
Na razie szukam dobrego wzmacniacza pomiarowego, bo mi się niezbyt chce lutować tego ustrojastwa z operacyjnych.
Gdzieś kiedyś widziałem takie cudo co to było precyzyjne i jeszcze samo sobie prunda stabilizowało - wtedy by można to nawet przez USB zasilić.
Jak nie znajdę to droga przez mękę - precyzyjne zasilanie, wzmacniacz i to wszystko gołymi ręcami.
Jak już wytypuję części, to później zakup, dostawa i zabawa. A czas sobie płynie więc proszę się nie spodziewać efektów na już.
No.
Przyjąłem sobie że zajmę się tym malutkim wycinkiem co to na wyjściu poda jakieś napięcie. Jak to zrobić coby był z tego joy to już mnie na chwilę obecną przerasta.
Mjoy będzie dobry przy testowaniu optymalnego zamocowania tensometru i samego kształtu "odkształcacza".
Później mam nadzieję Sun stworzy tego 16 bitowego potwora, a ludzie będą mieli wybór potki hale tensy czy co tam jeszcze.
-
Rozmawiałem dzisiaj z kolegą,który ma praktykę w układach analogowych. [...] można wykorzystać przetwornik 10 bit w uP,ale stosując kompresję sygnału wejściowego,która polega na tym,że wzmacniamy sygnały o małym poziomie.
To jeszcze nic nie daje, ale...
Charakterystyka wzmacniacza jest podobna do logarytmicznej.
To radykalnie zmienia postać rzeczy :) Przez odpowiednią charakterystykę można zwiększyć czułość w zakresie małych wartości - dobry pomysł :010:
Mam coś takiego:
http://www.leobodnar.com/products/BU0836A/
Znamy, znamy :) Vito_zm już kiedyś podawał :) 12bitów... i dużo i mało. Fajna płytka - mało elementów zewnętrznych, tylko cena lekko "zaporowa" :) Jeśli projekt Sundownera wypali (a pewne postępy już zostały poczynione) - uzyskamy dużą przewagę nad BU i innymi ADC wbudowanymi w uC - napięcie na wejściu ADC :010: Normalnie, mikrokontrolery tolerują na wejściu ADC napięcie pomiędzy AGND a AVCC . Zewnętrzny ADC (tu dla przykładu MAX1046) akceptuje napięcia symetryczne względem masy. Można mu podać od -5V do +5V (maximum ratings: -7,5 do + 7,5) co daje zakres 10v (maximum ratings: 15V :118: ) (wymagane, niestety - symetryczne względem AGND zasilanie potencjometrów :) ). Tak szeroki zakres na wejściu przełoży się na lepszy stosunek sygnału do szumu (np. zmniejszy się wpływ napięć indukowanych w przewodach). Dobrze było by znaleźć tani i szybki ADC obsługiwany przez I2C - bo ten max "zjada" na złączu równoległym strasznie dużo pinów :(
Poniżej strony są też sensory Halla. Mogę tą kartę udostępnić do testów.
A jakaś charakterystyka tych sensorów? Ma ktoś dokumentację?
Na razie szukam dobrego wzmacniacza pomiarowego, bo mi się niezbyt chce lutować tego ustrojastwa z operacyjnych.
Gdzieś kiedyś widziałem takie cudo co to było precyzyjne i jeszcze samo sobie prunda stabilizowało
Takie rzeczy, to tylko w Erze ;)
Jak już wytypuję części, to później zakup, dostawa i zabawa. A czas sobie płynie więc proszę się nie spodziewać efektów na już.
Nie ma pośpiechu - inne rzeczy też wymagają czasu... :)
Przyjąłem sobie że zajmę się tym malutkim wycinkiem co to na wyjściu poda jakieś napięcie. Jak to zrobić coby był z tego joy to już mnie na chwilę obecną przerasta.
Mjoy będzie dobry przy testowaniu optymalnego zamocowania tensometru i samego kształtu "odkształcacza".
I słusznie. Projektowany Joy powinien być na tyle uniwersalny, aby obsłużyć zewnętrzne napięcie z dowolnego źródła - czy to będzie pot, czy hall, czy tensometr, czy pot elektroniczny.
-
Dzięki za wyjaśnienia.Wspomniałem o kompresji dla przetwarzania A/C,ponieważ jest to normalna praktyka przy transmisji mowy lub muzyki.Po odbiorze jest proces odwrotny czyli dekompresja w dekoderach C/A.Wszystko po to aby zmniejszyć przesyłane pasmo oraz polepszyć stosunek sygnał szum kwantyzacji.U nas jest tylko proces kodowania A/C nie ma C/A.Normalnie robi się kompresję aproksymując krzywą logarytmiczną (13 segmentów).Pytałem z ciekawości,ponieważ wydaje się,że stick byłby bardziej czuły na małe siły.Pytanie czy jest to normale.
Co do kodeków to są to przetworniki symetryczne wzg.GND zasilane +V oraz -V. Pytanie czy można przesunąć środek (GND) tak aby był niesymetryczny jedno napięcie zasilania a jednocześnie poprawnie kodował.
-
Po konsultacjach z Damosem na temat nowego MJoya postanowiłem napisać swoje "życzenia" związane z następcą starego.Ponieważ Damos włączył się do projektu to mam pewność,że zostanie zrealizowany na wysokim poziomie technologicznym.Tyle wstępu a teraz moje uwagi.
1.Jeśli sterownik będzie widziany jako kontroler gier to powinien mieć możliwość ustawiania ID w konfiguracji,jeśli nie to nie ma takiej potrzeby.Ja musiałem zmieniać w MJoyu ID ze względu na konflikt z Cougarem.Pisałem o tym na forum.
2.Problem kłopotów z USB myślę,że już został rozwiązany przez Damosa.
3.Dobrze byłoby mieć możliwość elastycznego definiowania wejść jako pushbuttons,toggle switches lub enkoder.O innych definicjach wejść nie piszę ponieważ nie było o tym jeszcze mowy w tym wątku.Tak jest zrobione w rozwiązaniu Master OC.
4.Dobrze byłoby zwiększyć liczbę wejść.
5.Na temat wejść analogowych nie wypowiadam się,ponieważ wykorzystuję u siebie tylko jedno jako ster kierunku.
6.Dobrze byłoby mieć możliwość sterowania zewnętrznego kodeka np.12-16 bit porzez standardowy interfejs.Jest to związane z innym projektem sticka na tensometrach.
7.Dobrze byłoby zrobić sterownik w ten sposób aby matryca była na innej płycie.Ja tak zrobiłem wszystkie moje MJoye tzn.wyprowadzałem kolumny oraz wiersze a matrycę rozproszoną realizowałem na zewnętrznych kartach w zależności od potrzeb.Nawet kartę Master z OC też w ten sposób zaprojektowałem.
8.Uzupełnienie do punktu 7.W MJoyu matryca jest zrobiona z 8 kolumn oraz 14 wierszy co daje 112 pozycji.W Master zrobiono podobnie tzn.9 kolumn oraz 8 wierszy co daje 72 pozycje.U nas przydaloby się trochę więcej wejść np.256.
Jeszcze jedna sprawa związana z MJoyem.To wystąpiło u mnie.Robiłem testy z kontrolerami.Podłączałem Cougara,Logitech oraz 3 MJoye i mój pc w pewnych sytuacjach przekłamywał.Jeśli zmniejszyłem liczę MJoy do 2 to jest o.k.Nie wiem na czym to polega,ale mam tylko u siebie na jednym pc 2 MJoye,Cougar oraz inne sterowniki z OC,które nie są kontrolerami gier.
W nowym projekcie przewiduję jako wejścia nowe MJoye co najmniej 2.Ma to pewne zalety tzn.dekompozycja (mniejsza liczba przewodów itp.)
Na koniec pytanie o soft.MJoy ma obecnie SVMapper,dla Master pisze się skrypty w SIOC (nie tyko).Dobrze byłoby stworzyć przyjazny sposób konfigurowania wejść.Wspomniałem o OC,ponieważ oprócz SIOC mają prosty sposób konfiguracji można to sprawdzić na ich stronie (ja tego nie stosuję).
To są moje uwagi na gorąco,jeśli coś pominąłem to napiszę później.
-
1.Jeśli sterownik będzie widziany jako kontroler gier to powinien mieć możliwość ustawiania ID w konfiguracji,jeśli nie to nie ma takiej potrzeby.Ja musiałem zmieniać w MJoyu ID ze względu na konflikt z Cougarem.Pisałem o tym na forum.
Jakaś customizacja i tak będzie potrzebna - żeby można było wprowadzić własną nazwę typu "panel1" albo "panel2" - i ona była by widoczna dla użytkownika.
4.Dobrze byłoby zwiększyć liczbę wejść. [...] W MJoyu matryca jest zrobiona z 8 kolumn oraz 14 wierszy co daje 112 pozycji.W Master zrobiono podobnie tzn.9 kolumn oraz 8 wierszy co daje 72 pozycje.U nas przydaloby się trochę więcej wejść np.256.
Zrobiłem na 180 przycisków, ale SVmapper widzi tylko 128. Nie wiem, czy to nie jest ograniczenie sterownika (Direct Input) Joysticka HID dla Windows? We wcześniejszych wersjach DInput było ograniczenie na 32 przyciski.
6.Dobrze byłoby mieć możliwość sterowania zewnętrznego kodeka np.12-16 bit porzez standardowy interfejs.Jest to związane z innym projektem sticka na tensometrach.
Sundowner planuje użycie zewnętrznego ADC, prawdopodobnie po I2C. Liczę na to, że Yano i Sundowner "rozpracują" tensometry, czujniki Halla i zewnętrzne ADC :banan
BTW - kodek to układ pary koder-dekoder (CODEC = COderDECoder). Może lepiej będzie używać pojęcia "przetwornik AC"? Pozwoli to uniknąć później nieporozumień z kodekami Audio-Video tak dziś popularnymi :)
Jeszcze jedna sprawa związana z MJoyem.To wystąpiło u mnie.Robiłem testy z kontrolerami.Podłączałem Cougara,Logitech oraz 3 MJoye i mój pc w pewnych sytuacjach przekłamywał.
Na czym polegały "przekłamywania" ? Nie widział urządzeń, pokazywał złe przyciski czy złe wartości osi? To brzmi niepokojąco.
Dobrze byłoby zrobić sterownik w ten sposób aby matryca była na innej płycie.Ja tak zrobiłem wszystkie moje MJoye
Sundowner mówił o tym samym. Ja też chcę zrobić bazową płytkę jak najbardziej uniwersalną i nie dedykowaną jednemu rozwiązaniu.
Na koniec pytanie o soft.MJoy ma obecnie SVMapper
SVMapper jest nie tylko dla MJoya, ale dla każdego Joysticka USB HID. Z "moim" rozwiązaniem też pracuje. Obecnie używam SVMappera jako... testowego wyświetlacza pokazującego za pomocą stanu przycisków informacje, "co się dzieje" w środku uC :)
dla Master pisze się skrypty w SIOC (nie tyko).
Niezłą platformę skryptową zrobił Codeking - nie można by jej wykorzystać?
Dobrze byłoby stworzyć przyjazny sposób konfigurowania wejść.
Planuję prostą aplikację, która umożliwi konfigurację za pomocą "wyklikania" myszką.
-
Na czym polegały "przekłamywania" ? Nie widział urządzeń, pokazywał złe przyciski czy złe wartości osi? To brzmi niepokojąco
O ile sobie przypominam (było to bardzo dawno temu) to miałem problemy z hatem Cougara z widokami.Było to związane z dużą liczbą kontrolerów w tym 3 MJoy-e.Nie badałem tego problemu,ponieważ doszedłem do wniosku,że 2 MJoye wystarczą.
Co do ID to Cougar musiał być na pierwszej pozycji kontrolerów gier,jeśli nie to też były problemy z niektórymi jego funkcjami.Ponieważ jestem praktykiem to znalazłem rozwiązanie problemu nie wchodząc dlaczego tak się dzieje.Po za tym nie znam się na tych problemach.
BTW - kodek to układ pary koder-dekoder (CODEC = COderDECoder). Może lepiej będzie używać pojęcia "przetwornik AC"? Pozwoli to uniknąć później nieporozumień z kodekami Audio-Video tak dziś popularnym
Jest dokładnie tak jak piszesz,będzie przetwornik AC.
Niezłą platformę skryptową zrobił Codeking - nie można by jej wykorzystać?
To byłoby idealne rozwiązanie.
-
Właśnie sobie uświadomiłem oczywistą oczywistość. O ile mnie umysł nie myli to potencjometr w joyu, gdy ten jest bez wychyleń, jest w pozycji środkowej. Wychylenie w którąś stronę zmienia napięcia na "+" lub "-" od tej wartości. Analogicznie, nie mogę zastosować zrównoważonego mostka pomiarowego w pozycji neutralnej. Musi być gdzieś w połowie. Jednym słowem element pomiarowy musi już być odkształcony (ja wiem że to dla wszystkich może być oczywiste, ale jak sobie to napiszę, to oczywistym stanie się również dla mnie).
Jeżeli ma to być projekt "samoróbka" dla każdego, to problemem może być powtarzalność elementów. Ja sobie zrobię "tak", z taką dokładnością, ale obywatel X zastosuje inną stal na czujnik i wartości odkształceń, a co za tym idzie zmiany napięcia będą inne. Czy standardowa kalibracja sobie z tym poradzi? Chciałbym uzyskać efekt Plug and Pray, coby po podłączeniu i chwili na modlitwę wszystko działało.
Coś mnie wątpliwości dopadają. Wsparcia mi trzeba :001:
-
Poradzi sobie spokojnie, jeżeli oczywiście wszyscy czujniki będą wykorzystywać o podobnej specyfikacji.
-
Przejrzałem wątek jeszcze raz i widzę,że wszystko na temat założeń zostało już powiedziane.Włączenie się Damosa do tematu gwarantuje sukces.Nie muszę tego uzasadniać wystarczy przejrzeć linki,które podał na temat HID.Chcę tylko przypomnieć o możliwości edycji nie tylko nazwy ale ID producenta kontrolerów.Możliwość programowania 180 wejść jest o.k.Wspomniałem,że Master OC ma tylko 72 wejścia a cały zestaw 4xMaster 288.
Z ciekawości mam pytanie na temat różnicy pomiędzy sterownikami a kontrolerami gier sterowanymi przez USB.MJoy jest widziany jako kontroler gier.OpenCockpits oferuje proste sterowniki na picach z wbudowanym USB np.do sterowania serw lub silników różnego typu.Czy w przypadku tych sterowników też występują znormalizowane protokoły (HID) czy jest to uproszczony interfejs programowy.
Jeszcze jedna sprawa mnie interesuje.Jeśli stosuję kilka sterowników z różnymi interfejsami lub z tym samym np.USB to co z obciążeniem CPU.Damos wspomniał o odpytywaniu stanu wejść.Jest to tylko jeden z procesów związanych z symulatorem. SIOC z OC reaguje na zmianę stanu wejść co daje pewną oszczędność obciążenia CPU.Z drugiej strony odpytywanie w karcie Master nie jest aż tak częste.Damos kiedyś to analizował i o ile pamiętam to nie były to krytyczne czasy.
-
wystarczy przejrzeć linki,które podał na temat HID.
To, że podałem linki, nie znaczy, że wszystko przeczytałem i zrozumiałem :) Każda pomoc będzie mile widziana :023:
Chcę tylko przypomnieć o możliwości edycji nie tylko nazwy ale ID producenta kontrolerów.
Będzie. Słyszałem o problemie sortowania po VendorID - dlatego będzie to można zmienić. Jednak działanie takie nie jest do końca legalne - każdy ID jest przydzielany producentowi przez organizację nadzorującą USB. Oficjalnie nie wolno używać "cudzych" ID-ków :118: :021: Jednak jeśli każdy sam sobie to zrobi - nie dojdzie do sytuacji dystrybuowania hardware'u z cudzym ID. :121:
Możliwość programowania 180 wejść jest o.k.Wspomniałem,że Master OC ma tylko 72 wejścia a cały zestaw 4xMaster 288.
Ile ich dokładnie będzie - to się okaże. Teoretycznie max dla tego scalaka (przy matrycy 13x13 i braku osi analogowych) to 169 przycisków fizycznie podłączonych. Softwareowo mogę "udawać" więcej - np. inny przycisk wysyłany przy wciśnięciu naszego "mechanicznego" przycisku a inny przy jego zwolnieniu. Byle tylko SVMapper dał radę je obsłużyć.
Z ciekawości mam pytanie na temat różnicy pomiędzy sterownikami a kontrolerami gier sterowanymi przez USB.MJoy jest widziany jako kontroler gier.OpenCockpits oferuje proste sterowniki na picach z wbudowanym USB np.do sterowania serw lub silników różnego typu.Czy w przypadku tych sterowników też występują znormalizowane protokoły (HID) czy jest to uproszczony interfejs programowy.
W przypadku tamtych układów protokół jest wielką niewiadomą :( Mogą używać HID do transferu niezidentyfikowanej binarki lub używać emulacji COM'a.
Jeszcze jedna sprawa mnie interesuje.Jeśli stosuję kilka sterowników z różnymi interfejsami lub z tym samym np.USB to co z obciążeniem CPU.
Praktycznie brak wpływu. Zależy od konkretnego interface'u. Jak stosujesz wiele interface'ów zjadajacych czas CPU - to wtedy będzie większe obciążenie. Zależy też od ilości wysyłanych danych.
Damos wspomniał o odpytywaniu stanu wejść.
Tym zajmuje się uC. Zbiera dane "do kupy" i szykuje do wysłąnia do PC. Kiedy PC stwierdzi, ze chce dostać update - wysyła takie życzenie do uC. To odpytywanie jest dość sprawne - SVMapper zużywa 0% procka.
Jest to tylko jeden z procesów związanych z symulatorem. SIOC z OC reaguje na zmianę stanu wejść co daje pewną oszczędność obciążenia CPU.Z drugiej strony odpytywanie w karcie Master nie jest aż tak częste.Damos kiedyś to analizował i o ile pamiętam to nie były to krytyczne czasy.
W jaki sposób "reaguje" na zmiany stanu? Wysyła tyko to, co się zmieniło? Wydaje mi się, że tam było odpytywane wszystko po kolei?
-
W jaki sposób "reaguje" na zmiany stanu? Wysyła tyko to, co się zmieniło? Wydaje mi się, że tam było odpytywane wszystko po kolei?
Wyraziłem się nieprecyzyjnie.Odpytuje po kolei i porównuje nową wartość z starą.Jeśli nie było zmiany stanu nie reaguje,jeśli była wykonuje odpowiednią procedurę.
Teoretycznie max dla tego scalaka (przy matrycy 13x13 i braku osi analogowych) to 169 przycisków fizycznie podłączonych. Softwareowo mogę "udawać" więcej - np. inny przycisk wysyłany przy wciśnięciu naszego "mechanicznego" przycisku a inny przy jego zwolnieniu. Byle tylko SVMapper
Nie będzie to problemem,zawsze można zastosować 2 nowe MJoye.Ja tak robię.
-
Sprawdziłem w opisie SIOC jak ten program działa.W dowolnym tłumaczeniu jest napisane,że system jest oparty na zdarzeniach (events).Dalej jest definicja "zdarzenia"
..an event can be defined as a group of operations that are executed when something happens...
W SIOC te "events" są wykonywane jeśli stan lub wartość zmiennych wewnętrznych (internal) ulegnie zmianie lub jeśli wystąpią zmiany na wejściach.
Ja to rozumiem w ten sposób,że jeśli w symulatorze nastąpiła zmiana wartości jakiegoś parametru to informacja o tym zostanie wysłana na wyjście jakiejś karty np Master.I podobnie na wejściu karty,jeśli będzie zmiana stanu to system zareaguje wykonując odpowiednie procedury.Nie wiem czy dobrze to wyjaśniłem.Manuel Velez twórca SIOC oraz całego systemu podkreśla,że to wyróżnia ten system.Nie znam się na tym,powtarzam co napisano.Mam nadzieję,że wyjaśniłem to co miałem na myśli pisząc o reakcji na zmiany stanu zmiennych wewnętrznych.
-
..an event can be defined as a group of operations that are executed when something happens...
Aha. Czyli standardowo - skrypcik lub execution list. Codeking ma to samo. jest do dobre, sprawdzone podejście. SVMapper działa podobnie - dla niego button jest "something happens" a asymulowanie wciskania klawiszy z jakimś opóźnieniem to "excuted group of operations". Myślałem, ze MB ma coś na kształt skryptu i na niej coś się dodatkowo "samo robi" (a takie niecne plany ma Sundowner) ;)
-
(a takie niecne plany ma Sundowner) ;)
Muhahahahahaha...
(http://whyisthispopular.files.wordpress.com/2009/06/demotivational__the_evil_laugh_by_nenja_black.jpg)
Póki co siedzę i grzebię w dokumentacjach przetworników ADC Maxima, szukając właściwego do mixu, nie jest łatwo ;)
-
Mały update dla zainteresowanych:
Dorobiłem odczyt i zapis:
- Vendor ID
- Product ID
- Serial Number (max 8 znaków)
- Product Name (max 8 znaków)
Ograniczenie do 8 znaków jest ze względu na oszczędność pamięci. Wszystko ląduje tam w eepromie, którego jest bardzo mało a teksty są przechowywane w Unicode. Obecnie na konfigurowalne nazwy oraz identyfikatory idzie już 5% całej pamięci. Uważacie, ze 8 znaków wystarczy? Jeśli nie - proszę i feedback.
Przykładowe teksty seriala i Product Name:
(http://img687.imageshack.us/img687/2739/screenjw.th.png) (http://img687.imageshack.us/i/screenjw.png/)
IMO powinno wystarczyć.
Od razu odpowiadam, że serial jest mi potrzebny, ponieważ mój system I/O używa plików XML z opisem konfiguracji sprzętu, który identyfikuje hardware po VendorID, ProductID i Serial.
-
Oczywiście,że starczy(tak myślę).Dla precyzji opisu mam pytanie.Czy znak oznacza jeden bajt w pamięci?
W MJ16 opis,vendor oraz product ID zajmuje 8 bajtów.Np. 4D 4A 31 36 00 00 02 00,gdzie jest podane w kodzie ASCII nazwa MJ16 dalej ID vendor oraz ID product.
Pytam dlatego,że bajt jest reprezentowany przez 2 znaki ASCII.
Patrząc na przykład to myślę,że jest to zrobione w następujący sposób:
nazwa DM Joy 01 7 znaków ASCII
vendor 0x3eb 3 znaki ASCII
product 0x8 1 znak ASCII
Co daje 11 znaków ASCII prawie 8 bajtów pamięci.
Zmiana nazwy daje uporządkowanie w kontrolerach gry oraz SVMapper.Zmiana pozostałych parametrów umożliwia zmianę pozycji w liście kontrolerów.Nie mam pojęcia jakie są ID joysticków,ja zmieniałem intuicyjnie ID vendora na młodszym bajcie tak aby był poniżej ID Cougara.Tyle moich doświadczeń.
Wiem,że ten temat był dyskutowany na forum,może koledzy wypowiedzą się na ten temat.
-
Czy znak oznacza jeden bajt w pamięci?
Nie. Znak tekstowy z nazwy to dwa bajty w pamięci.
Pytam dlatego,że bajt jest reprezentowany przez 2 znaki ASCII.
Patrząc na przykład to myślę,że jest to zrobione w następujący sposób:
nazwa DM Joy 01 7 znaków ASCII
vendor 0x3eb 3 znaki ASCII
product 0x8 1 znak ASCII
Co daje 11 znaków ASCII prawie 8 bajtów pamięci.
Nie. 0x3eb oraz 0x8 to hexadecymalna postać liczby zapisywanej na 2 bajtach. Tak więc 0x3eb zajmuje dwa bajty(0x03+0xeb) tak samo jak 0x8 (0x00+0x08)
Sam tekst jest zapisywany jako unicode - po dwa bajty na znak. Teoretycznie mógłbym zapisywać w ASCII i przy wysyłaniu z urządzenia do PC zamieniać na ucs2, ale wtedy stracił bym możliwość zapisu znaków narodowych. Gdy zabraknie mi eepromu - zrobię tak.
Ty jednak nie musisz się tym przejmować - w aplikacji na załączonym screenie:
(http://img690.imageshack.us/img690/16/screen2eb.th.png) (http://img690.imageshack.us/i/screen2eb.png/)
1 - zaznaczasz na liście interesujące się urządzenie
2 - program łączy się z urządzeniem i wypełnia oznaczone na czerwono pola z: VendorID, ProductID, Serial number, Device name.
3 - w polach zaznaczonych na czerwono wpisujesz teksty i liczby, których oczekujesz
4 - wciskasz przycisk "save changes" (oznaczony na niebiesko) i wszystko zapisuje się w mikrokontrolerze.
Nie trzeba znać rozmieszczenia tych danych w pamięci, nie trzeba znać reprezentacji tekstu w zapisie szesnastkowym, nie trzeba nic zmieniać w pliku *.eep i później programować. Po prostu zmieniasz wartości w polach edycyjnych. Joy ma zaimplementowaną obsługę poleceń do odczytu i zapisu tych wartości a program do konfiguracji wysyła mu odpowiednio spreparowane komendy. Po restarcie urządzenia (np. odłączenie od USB i ponowne podłączenie, choć może dodam polecenie restartu) urządzenie będzie widoczne w systemie z nowymi parametrami. To ma być maksymalnie proste i przyjazne użytkownikowi.
Zmiana nazwy daje uporządkowanie w kontrolerach gry oraz SVMapper.Zmiana pozostałych parametrów umożliwia zmianę pozycji w liście kontrolerów.
Taki jest właśnie cel implementacji edycji tych właściwości. Nie mam pojęcia jakie są ID joysticków
Nie ma czegoś takiego jak ID joysticka. Każdy producent może wystąpić o przyznanie mu VendorID a później ProductID i inne rzeczy ustala sam w-g własnego "widzimisię".
-
Dzięki za wyjaśnienia.Napisałem o znakach ASCII tylko dlatego,że w MJoyu trzeba zamieniać liczbę dziesiętną np.16 na 2 znaki ASCII 31 oraz 36.Oczywiście trzeba znać adres gdzie to należy zrobić oraz odpowiednie komendy w np.PonyProg.
W Twoim programie jest to trywialne i o to chodzi,nie trzeba znać mapy pamięci oraz sposobu zamiany znaków alfabetu na kod ASCII.Moje gratulacje Damos.Wiedziałem,że jak wejdziesz w temat to zrobisz to profesjonalnie.
-
Jeszcze raz spojrzałem na załączony obrazek USB DMJoy conf......i zauważyłem 2 opcje Commands oraz Config.Commands omówiliśmy.Moim zdaniem jest to bardzo potrzebna opcja dla tych co mają kilka kontrolerów lub problemy z pozycją na liście.Jako ciekawostkę mogę podać przykład,że inni też mają problemy tego typu np.z dwoma BU0836X w tym samym pc.
W MJoy była taka możliwość,ale wymagała pewnej wiedzy.
Teraz chciałbym nawiązać do drugiej opcji Config.Załóżmy,że definiujemy dowolne wejścia jako przycisk, przełącznik lub enkoder (analogia do MJoya).Mam w związku z tym pytania:
1.W programie Damosa zdefiniowaliśmy fizyczne wejścia.Możemy tym wejściom przypisać kombinacje klawiszy i to jest zrozumiałe.Program zastępuje SVMapper.
2.SVMapper widzi naszego nowego DMJoya.Pytanie jest następujące.Czy w SVMapper możemy definiować kombinacje klawiszy po uprzednim zdefiniowaniu wejść w programie Damosa?
3.Pytanie do Damosa oraz Codeking.Czy można będzie przypisywać kombinacje klawiszy w module GameControllersInput czy trzeba będzie stworzyć nowy moduł?
4.Pytanie jest związane z punktem 3.Mając możliwość przypisania kombinacji klawiatury do fizycznych wejść DMJoya co daje możliwość zrobienia tego samego w DK Codeking?Czy w DK można lepiej zdefiniować działanie przycisków,przełączników oraz enkoderów?
Pytam dlatego,że w swoim kokpicie MJoye definiowałem w SVMapper,a Master w Sioc,ponieważ karta OC nie była widziana jako kontroler gier.
-
Jeśli Damos w swoim programie daje możliwość zdefiniowania kombinacji klawiszy, które będą wysyłane po naciśnięciu konkretnego przycisku (DMJoy wysyła odpowiedni pakiet do Windows ?) to w DK nie ma potrzeby tego robić. DK ma moduł do wysyłania skrótów klawiaturowych. Jeśli DMJoy jest widziany jako zwykły kontroler to na 99% nie muszę nic dorabiać do DK żeby go obsłużył.
-
Teraz chciałbym nawiązać do drugiej opcji Config.Załóżmy,że definiujemy dowolne wejścia jako przycisk, przełącznik lub enkoder (analogia do MJoya).Mam w związku z tym pytania:
1.W programie Damosa zdefiniowaliśmy fizyczne wejścia.Możemy tym wejściom przypisać kombinacje klawiszy i to jest zrozumiałe.Program zastępuje SVMapper.
Nie do końca. On będzie "udawać" wciskanie przycisków Joysticka a nie klawiatury. SVMapper daje większe mozliwości interpretacji wciskania przycisków Joy'a. Mapowanie wewnątrz DMJoya daje abstrakcję względem sprzętu, której SVMapper nie jest w stanie zapewnić - np. rozbicie dwustanowego "prawdziwego" przycisku na dwa osobne przyciski Joysticka lub zadajnika kodu BCD (http://www.tme.eu/pl/katalog/zadajniki-kodu_100059/#id_category%3D100059%26) na 16 różnych przycisków Joysticka których właczanie/wyłączanie jest symulowane w czasie załączenia odpowiedniej pozycji zadajnika.
Przykład: masz obrotowy zadajnik kodu BCD 8-mio pozycyjny i 8 różnych typów uzbrojenia przełączanych tym pokrętłem. Mapujesz taki jeden pseudo-przełącznik obrotowy na 8 różnych przycisków Joy'a. W ten sposób przełaczenie na każdą z pozycji wygeneruje wciśnięcie innego przycisku Joy'a. (tak będzie to widział SVMapper ) Przycisków będzie 8 a zużytych wejść w uC tylko 3 (kod BCD).
2.SVMapper widzi naszego nowego DMJoya.Pytanie jest następujące.Czy w SVMapper możemy definiować kombinacje klawiszy po uprzednim zdefiniowaniu wejść w programie Damosa?
Tak - dla SVMappera nasz Joystick to taki sam jak każdy inny kupiony w sklepie lub też MJoy.
3.Pytanie do Damosa oraz Codeking.Czy można będzie przypisywać kombinacje klawiszy w module GameControllersInput czy trzeba będzie stworzyć nowy moduł?
To pytanie do Codekinga. Jeśli ten moduł działa w oparciu o DirectInput i obsługuje "normalne" Joysticki to będzie działać bez problemów.
4.Pytanie jest związane z punktem 3.Mając możliwość przypisania kombinacji klawiatury do fizycznych wejść DMJoya co daje możliwość zrobienia tego samego w DK Codeking?Czy w DK można lepiej zdefiniować działanie przycisków,przełączników oraz enkoderów?
W module DK będzie można zdefiniować wiele rzeczy korzystając z wiedzy - co jest podłączone do DMJoya (enkodery, przełączniki dwupozycyjne mono/bistabilne, przełączniki wielopozycyjne, zadajniki kodu itp.) i skryptów. Jeśli coś nie będzie obsługiwane, to jakoś się z Codekingiem dogadamy i zrobimy obsługę :) (możemy nawet podawać wartość "wyklikaną" przez enkoder za pomocą kombinacji bitów przekazywanej na wybranych przyciskach ! :karpik - to dopiero hardcore :) )
Z testów praktycznych wychodzi mi, że DirectInput obsługuje do 128 przycisków - więc tyle ich będzie mógł symulować DMJoy
Pytam dlatego,że w swoim kokpicie MJoye definiowałem w SVMapper,a Master w Sioc,ponieważ karta OC nie była widziana jako kontroler gier.
Tu jest właśnie przewaga rozwiązania bazującego na spełnieniu wymagań HID i pracy jako kontroler gier. Oczywiście - nie wszystko można tym zrobić i nie zawsze jest to najlepsze wyjście z sytuacji, ale w wielu przypadkach jest bardzo uniwersalne.
Jeśli Damos w swoim programie daje możliwość zdefiniowania kombinacji klawiszy, które będą wysyłane po naciśnięciu konkretnego przycisku (DMJoy wysyła odpowiedni pakiet do Windows ?)
Na razie udaję jedynie Joystick. Coś, co zasymuluje klawiaturę i SVMappera w jednym - jest planowane, ale w późniejszym terminie. Wtedy każdemu ze 169 przycisków będzie można przypisać jakąś sekwencję klawiszy z klawiatury.
Tak więc na razie - jedynie Joystick.
Jeśli DMJoy jest widziany jako zwykły kontroler to na 99% nie muszę nic dorabiać do DK żeby go obsłużył.
Dokładnie tak jest :023:
-
Z tego co zrozumiałem to będzie można stosować moduł GameControllersInput z DK lub SVMapper w wersji początkowej DMJoy dla przypisania kombinacji klawiszy dla jego wejść.Jest to dobra wiadomość.
-
Przykład: masz obrotowy zadajnik kodu BCD 8-mio pozycyjny i 8 różnych typów uzbrojenia przełączanych tym pokrętłem. Mapujesz taki jeden pseudo-przełącznik obrotowy na 8 różnych przycisków Joy'a. W ten sposób przełaczenie na każdą z pozycji wygeneruje wciśnięcie innego przycisku Joy'a. (tak będzie to widział SVMapper ) Przycisków będzie 8 a zużytych wejść w uC tylko 3 (kod BCD).
:karpik Czym zaskoczysz nas jutro ?
-
:karpik Czym zaskoczysz nas jutro ?
Nie ma się z czego śmiać. Ja takiego feature'a potrzebuję. Zadajnik kodu ma tą przewagę nad enkoderem, że po resecie urządzenia wiadomo, w jakiej pozycji jest pokrętło.
Mały update:
otrzymałem zamówione płytki:
(http://img197.imageshack.us/img197/2981/img1477r.th.jpg) (http://img197.imageshack.us/i/img1477r.jpg/)
i z drugiej strony:
(http://img19.imageshack.us/img19/818/img1478g.th.jpg) (http://img19.imageshack.us/i/img1478g.jpg/)
Po zmontowaniu wygląda tak:
(http://img819.imageshack.us/img819/7923/img1470.th.jpg) (http://img819.imageshack.us/i/img1470.jpg/)
i nieco elementów od spodu:
(http://img29.imageshack.us/img29/2692/img1471ue.th.jpg) (http://img29.imageshack.us/i/img1471ue.jpg/)
Montaż uC okazał się nadspodziewanie prosty - dużo szybszy i łatwiejszy niż późniejsze lutowanie goldpinów! :)
W sumie mam 3 urządzenia zrobione:
(http://img249.imageshack.us/img249/8621/img1467d.th.jpg) (http://img249.imageshack.us/i/img1467d.jpg/)
i 3 "gołe" płytki (jeden komplet pójdzie do Sundownera).
Z odpaleniem pierwszej płytki był mały problem - okazało się, że nie startuje z wlutowanymi kondensatorami rezonatora kwarcowego (!) To samo miałem w prototypowym "pająku" (nietypowy, mały kwarc, czy bardzo duże pojemności ścieżek PCB ?)
Teraz już wszystkie działają bez problemów :023: Jak widać - płytki są dośc małe i w produkcji powinny być tanie (jakieś 5-8 PLN brutto). Koszt elementów również jest niewielki (szczególnie po tym, jak "odpadły" dwa kondensatory :118: ;) )
Teraz pozostaje kontynuować development... :595: Zobaczymy, co da się z tego "wydusić".
Zrobiłem sobie też płytkę pod 32-bitowy uC:
(http://img130.imageshack.us/img130/5548/img1483f.th.jpg) (http://img130.imageshack.us/i/img1483f.jpg/)
ale ona jest dużo większa i zawiera więcej elementów - tak więc zgaduję, że chętnych też było by dużo mniej?
-
Moje gratulacje.Prawdopodobnie pojemność ścieżek wystarczyła.Co do mnie to jestem chętny na każdy Twój projekt,cena jest sprawą drugorzędną.Ja podobnie jak Ty lubię rozwiązywać problemy i to mnie najwięcej "bawi".Widzę duże możliwości zastosowania nowych możliwości DMJoya w projektowaniu paneli.
-
Nie ma się z czego śmiać. Ja takiego feature'a potrzebuję. Zadajnik kodu ma tą przewagę nad enkoderem, że po resecie urządzenia wiadomo, w jakiej pozycji jest pokrętło.
E, to nie był śmiech, tylko podziw. Proste i genialne rozwiązanie.
Płytka jest malutka, można pomyśleć o dodatkowej z key-matrix.
-
Płytka jest malutka, można pomyśleć o dodatkowej z key-matrix.
Tak. Dla tych, którzy będą potrzebować więcej przycisków niż 26 lub 3 osie i 23 przyciski - płytka z key matrixem będzie potrzebna. Planujemy ją jako "nasadkę" na bazowa płytkę.
-
cytat Damos
Z testów praktycznych wychodzi mi, że DirectInput obsługuje do 128 przycisków - więc tyle ich będzie mógł symulować DMJoy
http://www.viperpits.org/smf/index.php?topic=5501.165
reply 166 Reboot
cytat
The problem! SVMapper only see’s 4 virtual joysticks that’s 128 input’s,
Chciałbym się odnieść do tych dwóch cytatów.Śledzę cytowany wątek i jest tam mowa o Direct-x oraz SVMapper.
Czy mogę prosić o wyjaśnienie pewnych pojęć.
W panelu sterowania przyciski controlerów np.MJoy mają ograniczenia do 32.Doczytałem,że Direct-x jest biblioteką MS dotyczącą wejść.
Pytanie 1.
Czy to ograniczenie wynika z Direct-x ?
Pytanie 2.
Czy ograniczenie 128 także wynika z Direct-x ?
Pytanie 3.
Ja widzę w SVMapper dwa MJoye czyli 112 x2 wejść.Jak to się ma do wspomnianych cytatów.
Dodatkowo w wątku viperpits jest mowa o ograniczeniach SVMappera związanych z stosowaniem Cougara.Ja mam Cougara,który ma swój profil i nie jest programowany w SVMapper oraz 2 MJoye mapowane w SVM i nie mam problemów.
Czy mógłbym prosić kolegów programistów o oświecenie.
-
cytatChciałbym się odnieść do tych dwóch cytatów.Śledzę cytowany wątek i jest tam mowa o Direct-x oraz SVMapper.
Czy mogę prosić o wyjaśnienie pewnych pojęć.
W panelu sterowania przyciski controlerów np.MJoy mają ograniczenia do 32.
Tak - to jest bardzo stare ograniczenie.
Doczytałem,że Direct-x jest biblioteką MS dotyczącą wejść.
Pytanie 1.
Czy to ograniczenie wynika z Direct-x ?
DX Input jest od "wejść" Starsze wersje DX Input obsługiwały max 32 przyciski. W którejś tam wersji poprawiono do ... ?? 128 ?
Pytanie 2.
Czy ograniczenie 128 także wynika z Direct-x ?
ZGADUJĘ, że tak
Pytanie 3.
Ja widzę w SVMapper dwa MJoye czyli 112 x2 wejść.Jak to się ma do wspomnianych cytatów.
W tamtych cytatach mamy przypadkową zbieżność ze 128 wynikającą z 4 joy'ów po 32 buttony. IMHO DX Input ma ograniczenie do 128 przycisków z JEDNEGO joysticka. Z 2 będzie 256 itd. Jeszcze tego nie testowałem, ale zrobię test.
-
Dzięki za wyjaśnienia dotyczące Direct-x.W wątku o którym wspomniałem http://www.viperpits.org/smf/index.php?topic=5501.165 toczy się nadal dyskusja na temat SVMappera.Zapytano mnie o moją konfigurację i ograniczenia tego programu.
Mam w związku z tym pewien problem.Moje testy z tym programem wykonywałem dawno temu i z tego co pamiętam to badałem zachowanie MJoya mając podłączone 2 joye oraz 3 kontrolery MJoy.Ten system pracował poprawnie tylko jeśli były podłączone 2 joye oraz 2 MJoye.Musiała być zachowana opowiednia kolejność na liście kontrolerów gier.
Autorzy w wspomnianym wątku sugerują,że SVMapper jest ograniczony do 4 wirtualnych joysticków co odpowiada 4x32=128 wejściom.Tutaj odpowiedni cytat
What a shame we have to drop SVMapper due to its 4 input maximum. I am also looking for the same solution here guys. I have Cougar hotas, CH MFP, cougar mfds, Touchbuddy touchscreen device, Saitek pedals and two Leo Bodnar BU0836X boards in the construction stage and possibly more to come, so I will need support for a stack of input devices
Chciałbym zrozumieć problem.
Zakładam,że mam w chwili obecnej u siebie Cougar hotas oraz 2 MJoye i dołożę jeszcze cougar mfds.Programuję Cougar hotas oraz cougar mfds w setup Falcona.W SVMapper programuję tylko 2 MJoye.
Pytanie jest następujące.SVMapper widzi wszystkie wymienione powyżej kontrolery,ale tylko 2 z nich (MJoye) są zaprogramowane w tym programie pozostałe tak jak wspomniałem są w setup Falcona.Czy to ograniczenie związane z 4 kontrolerami tutaj ma miejsce?Ja rozumuję w ten sposób,że jeśli mamy podłączone np.16 kontrolerów a tylko 4 z nich są programowanie w SVMapper to ograniczenie dotyczy tylko tych czterech.
Druga sprawa to ta magiczna liczba 128.Jeśli mogę programować 4 kontrolery w SVMapper to czy mam ograniczenie 4x32 wejścia?
Ja mam podłączone 2 MJoye i mam 112x2 pozycji,gdzie wykorzystuję wszystkie przyciski oraz przełączniki czyli powyżej 128 pozycji.
Temat jest na czasie.W praktyce stosuje się większą liczbę kontrolerów projektując niezależne moduły paneli.
Proszę kolegów o opinię.Na podstawie waszej opinii będę dalej dyskutował na viperpits.
-
:( to pytania raczej do twórcy SVMappera. Jeśli mi się uda (znajde czas i 3 kable :) ) - zrobię dziś test z 3-ma urządzeniami po 128 przycisków
Na razie wydaje mi się, że mamy ograniczenie do 128 przycisków z jednego urządzenia.
-
Zrobiłem test z 3-ma DMJoyami - SVMapper widzi (i obsługuje) wszystkie trzy, w każdym osobne 128 przycisków. W sumie 384 przyciski.
edit:
Direct Input allowing up to 128 buttons
DirectInput's support for 8 axes, 128 buttons
Tak więc ograniczenie do 128 wynika z DirectInput
-
Bardzo dziękuję za testy.Wynik jest obiecujący tzn.nie ma ograniczeń na jeden kontroler 32 tylko 128.Pozostaje do wyjaśnienia tylko jedna sprawa jak zachowuje się SVMapper gdy mamy podłączone więcej niż 4 kontrolery w tym joysticki.
Tutaj może wystąpić kilka przypadków:
1.Jest ograniczenie do 4 lub do innej liczby kontrolerów.
2.Jeśli jest ograniczenie do 4 kontrolerów w tym joysticki to czy:
a)ograniczenie występuje niezależnie czy mapujemy dany kontroler w SVMapper
b)ograniczenie dotyczy tylko 4 kontrolerów,które są mapowane w SVMapper
Jeśli SVMapper zachowuje się tak jak w punkcie a) to jest to poważne ograniczenia.W moim przypadku będę miał Cougar hotas oraz cougar mfds (2 sztuki) co daje możliwość użycia tylko jednego DMJoya.
Jeśli wystąpi przypadek b) to jestem wygrany ponieważ mogę zastosować do 4 DMJoy.
Uwaga końcowa.
Zawsze można stosować DK i tutaj nie powinno być problemów.
-
Przepraszam,że jeden za drugim post,ale znalazłem na forum viperpits rozwiązanie ewentualnych problemów z większą liczbą kontrolerów.
http://www.viperpits.org/smf/index.php?topic=5501.165
Rebbot przetestował u siebie kilka kontrolerów z programem Xpadder i to mu pracuje.Czyli mamy ewentualnie alternatywę jeśli pojawią się problemy.
-
Widząc takie problemy wydaje się zasadnym oprogramowanie naszej płytki kolejnym wsadem:
układ powinien wysyłać kody klawiatury w odpowiedzi na wciskanie klawiszy. Odpadnie problem z maksymalną liczbą przycisków i konieczność stosowania SVMappera.
Układ powinien być prostszy do zrobienia niż Joy - brak wejść analogowych i konieczności kalibracji. PCB będzie to samo. Co wy na to? IMHO ma sens.
-
układ powinien wysyłać kody klawiatury w odpowiedzi na wciskanie klawiszy
Czy to znaczy,że mamy coś podobnego do programu OC ConfigIOCard.Tutaj małe wyjaśnienie.W OC można opisać działanie układów wykonawczych takich jak przycisk,przełącznik,enkoder,LED.7segLED,serwery itd.albo pisząć skrypt w SIOC albo w wspomnianym programie ConfigIOCard.W tym programie wypełnia się odpowiednie rubryki w tabeli takie jak:nazwa,numer wejścia,zmienna,wartość dla key ON/OFF,typ itp.Ja tego nie stosuję wolę skrypt,ale jest to łatwiejszy sposób opisu.
Wracając do SVMappera to obawiam się,że jest ograniczenie związane z liczbą kontrolerów (max 4).Jak będę miał możliwość to ten problem sprawdzę.Jeśli okaże się,że jest to prawda to w moim przypadku nie będę mógł go stosować ponieważ planuję 5 kontrolerów:Cougar hotas,cougar mfds (2 szt) conajmniej 2 DMJoy.Z kartami OC nie będzie problemu.
-
Czy to znaczy,że mamy coś podobnego do programu OC ConfigIOCard.Tutaj małe wyjaśnienie.W OC można opisać działanie układów wykonawczych takich jak przycisk,przełącznik,enkoder,LED.7segLED,serwery itd.albo pisząć skrypt
Bez skryptu. Po stronie PC nie było by żadnego specjalizowanego oprogramowania, które uruchamiało by jakieś skrypty. Należało by użyć specjalnego programu do konfiguracji powiedzmy "DMKeys" ;) Gdzie pod każdy przycisk mógłbyś przypisać sekwencję klawiszy, jaka była by wysyłana do PC. Po konfiguracji całość była by zapisywana w pamięci uC. Ten zajął by się resztą i w odpowiedzi na wciśnięcie/zwolnienie buttona wysyłał by wcześniej ustaloną sekwencję klawiszy.
-
Jest to duże ułatwienie.W zasadzie funkcje SVMappera byłyby wykonywane przez program konfiguracyjny.Myślę,że Twój projekt może stać się hitem.
-
Wracając do SVMappera to obawiam się,że jest ograniczenie związane z liczbą kontrolerów (max 4).Jak będę miał możliwość to ten problem sprawdzę.Jeśli okaże się,że jest to prawda to w moim przypadku nie będę mógł go stosować ponieważ planuję 5 kontrolerów:Cougar hotas,cougar mfds (2 szt) co najmniej 2 DMJoy.Z kartami OC nie będzie problemu.
Już to sprawdziłem.Niestety jest ograniczenie SVMapper do 4 kontrolerów.W moim przypadku mogę tylko liczyć na Damosa,że jego pomysł jest możliwy do realizacji.
-
mogę tylko liczyć na Damosa,że jego pomysł jest możliwy do realizacji.
Jest możliwy. Powinien być nawet prostszy (pod pewnymi względami) do zrobienia od Joysticka. Na razie jednak pracuje nad stroną PC (aplikacja do konfiguracji) gdzie Windows skutecznie utrudnia działanie. na przykład poprzez normalne API nie ma dostępu do raportów kontrolnych HID typu VENDOR, czego używałem. Alternatywą jest stosowanie zewnętrznego sterownika instalowanego w systemie (libusb w trybie filter driver) czego wolał bym uniknąć a i sami twórcy nie zalecają, ponieważ na niektórych maszynach (Windows) może spowodować utratę dostępu do wszystkich urządzeń USB. Na linuxie wszystko działa. Pod windows muszę kombinować z wchodzeniem do garażu przez komin i wyjeżdżaniem przez okno ;)
Drugi problem to chwilowy brak dostępności uC ATMega32U4. Nikt ich nie ma, dostawy planowane na październik :( Z drugiej strony - do tego czasu może skończę soft i będzie OK ;)
-
Na razie jednak pracuje nad stroną PC (aplikacja do konfiguracji) gdzie Windows skutecznie utrudnia działanie
Nie znam się na tym.Tak z ciekawości,czy to jest związane z sterownikiem?Mam na myśli rozwiązania OC,gdzie są pliki konfiguracyjne,które trzeba uzupełniać.Pliki te są związane z poszczególnymi kartami (sterownikami).Jest też możliwość uzupełnienia pliku konfiguracyjnego obejmującego wszystkie karty.
Jest możliwy. Powinien być nawet prostszy (pod pewnymi względami) do zrobienia od Joysticka.
To mnie cieszy.Okazało się,że na viperpits mieli rację z SVMapper.Generalnie unikają tzw.Direct-x.Już o to pytałem (częściowo),ale czy jest możliwość wyboru albo Direct-x albo inna opcja?
-
Nie znam się na tym.Tak z ciekawości,czy to jest związane z sterownikiem?Mam na myśli rozwiązania OC,gdzie są pliki konfiguracyjne,które trzeba uzupełniać.
I tak i nie. W przypadku Joysticka nie mogę stosować własnego, uniwersalnego sterownika - musi być to wbudowany w Windows sterownik do urządzeń HID. Sterowniki kojarzy się z urządzeniem za pomocą pliku inf. W nim opisuje się do jakiej pary VID-PID system ma załadować jaki sterownik. W przypadku braku takiego pliku system sam "odgaduje" jaki sterownik załadować. Odgaduje to po krótkiej "rozmowie" z urządzeniem. Dla Joysticka jest to sterownik do urządzeń HID. Tak więc mamy opcje:
- wbudowany w system uniwersalny sterownik
- własny, prosty sterownik (nie widziany dla systemu jako HID)
- własny sterownik VxD rejestrujący urządzenie HID w systemie i realizujacy wszystko to, co wbudowany sterownik HID
- uniwersalny driver LibUSB w trybie "filter driver" (wymaga osobnej instalacji)
Opcja trzecia odpada ze względu na złożoność (napisanie VxD to kupa roboty, cały zespół Saiteka walczył ze sterownikami 64 bit do X52 około roku) i konieczność instalacji sterownika po każdej zmianie VID lub PID
Opcja druga odpada ze względu na to, iż urządzenie nie będzie widoczne dla gry jako Joystick
Opcja czwarta jest kusząca i z niej dotąd korzystałem: sprzęt jest widoczny jako HID, a ja mam do niego pełen dostęp poprzez USB. Wszystko chodziło mi bez problemu. Jednak niedawno dowiedziałem się, że ludzie, którzy stworzyli LibUSB gorąco odradzają używanie trybu "filter driver" u użytkownika końcowego. Podobno potrafi on czasem odciąć dostęp do magistrali USB (w wyniku wewnętrznego błędu) i ktoś, kto ma klawiaturę USB straci możliwość kontroli PC-ta (a raczej swojego "Windowsa"). Po restarcie nadal nie będzie mieć klawiatury, a nie każdy potrafi uruchomić system w trybie awaryjnym i wyładować wskazany sterownik.
jak widać - opcja pierwsza jest jedyną akceptowalną:
- sprzęt jest widoczny jako Joystick
- brak konieczności instalowanie dodatkowych sterowników
- można niemal dowolnie zmieniać VID/PID (byle nie trafić na kombinację przypisaną już do jakiegoś urządzenia)
Jednak zastosowanie wariantu 1 zmusza do porozumiewania się z urządzeniem przez mocno obcięte API, które akurat nie ma zaimplementowanej obsługi komend przewidzianych standardem (USB VENDOR specific control transfer), których używam do konfiguracji urządzenia (konfigurowanie gdzie są przyciski, osie analogowe, jaki VID, PID). Teraz kombunuję, jak przerobić swój firmware aby "wcisnąć" go w windowsa. Na Linuxie - jak pisałem, nie ma tego problemu. Może to jest jeden z powodów - dlaczego nie ma jeszcze takiego (konfigurowalnego) zastępnika dla MJoy'a ? ;)
Okazało się,że na viperpits mieli rację z SVMapper.Generalnie unikają tzw.Direct-x.Już o to pytałem (częściowo),ale czy jest możliwość wyboru albo Direct-x albo inna opcja?
To wybiera już sama gra. Dla urządzeń, które nie muszą być widoczne w systemie jako standardowe (zwykłe I/O a nie joy) nie korzysta się z Direct-X.
-
Dzięki za tak obszerne wyjaśnienia.Mam takie skojarzenia,że Cougar Hotas jest widziany w menedżer urządzeń jako USB interfejsu HID.Natomiast sterowniki OC być może są z opcji 2 tzn.własny, prosty sterownik (nie widziany dla systemu jako HID)
Życzę powodzenia i mam nadzieję,że dasz radę rozwiązać problemy.
-
Mam takie skojarzenia,że Cougar Hotas jest widziany w menedżer urządzeń jako USB interfejsu HID.
Tak. Najprawdopodobniej ma sterownik VxD, który umożliwia mu stworzenie dowolnej ilości wirtualnych urządzeń będących wewnątrz Cougara. W ten sam sposób może meldować się jako HID. To jest już skomplikowany model interakcji wymagający wielu testów. Sterownik pracuje na Ring0 i jest najczęstszą przyczyną blue-screenów.
Natomiast sterowniki OC być może są z opcji 2 tzn.własny, prosty sterownik (nie widziany dla systemu jako HID)
Dokładnie tak. Tak też działa moja wersja I/O - korzystając równiez z lib-usb ale "device mode" a nie " filter mode". Niedawno sterowniki lib-usb device mode uzyskały certyfikat z Micro$oftu więc można je bezpiecznie instalować i użytkować.
Życzę powodzenia i mam nadzieję,że dasz radę rozwiązać problemy.
Oczywiście - jak tylko znajdę trochę czasu :) Wyjściem awaryjnym jest "filter mode" (który u mnie i u Ciebie działa bez problemów) właczany tylko na czas rekonfiguracji urządzenia.
-
Potwierdzenie słuszności naszych założeń.
http://www.viperpits.org/smf/index.php?topic=5998.0;topicseen
Dobrze,że jest możliwość zmiany nazwy oraz ID.Dziwię się,BU0836x nie ma takiej możliwości,chociaż jest w wątku uwaga,że można indywidualnie zamówić kartę z inna nazwą (nie jestem pewien czy dobrze zrozumiałem).
-
Powalczyłem dzisiaj trochę z zmianą vendor oraz ID produktu w MJoy.Chciałem osiągnąć w liście kontrolerów gier następującą kolejność:Cougar hotas,MJoy 16,MJoy 17,MFD 1,MFD 2.To się nie udało.Jeśli nr vendora jest poniżej 00 05 to MJoy jest przed Cougar,jeśli jest 00 05 to poniżej hotas.Chciałem rozdzielić Cougar od MFD,ale się nie udało.Próbowałem jeszcze z ID produktu,ale bez powodzenia.
Po co to robiłem?Gdybym ułożył kolejność tak jak założyłem to mógłbym stosować nadal SVMapper dla 2 MJoy.W moim przypadku mogę tylko zastosować jeden MJoy.
Dobrze,że w projekcie Damosa nie będzie tego problemu.
-
Projektując założenia do elektroniki pod full kokpit przewiduję zastosowanie projektu Damosa DSMjoy.Po pozytywnych testach SimOUT zastanawiam się czy Zajac nie powinien pomyśleć o zrobieniu matrycy dla DSMjoy podobnie jak zrobił pcb dla SimOUT.Co o tym myślicie?Czy jest za wcześnie na taki projekt.
-
IMHO odrobinę za wcześnie. PCB jak i rozkład pinów mogą ulec zmianie.
-
Witam entuzjastów DMJoya.Dzięki uprzejmości Damosa mam możliwość testowania jego prototypów.Płytki robią wrażenie w porównaniu do starego MJoya.Testy są w fazie początkowej to jest zrozumiałe.Będę relacjonował postępy.Na początek stwierdzam,że DMJoy jest widziany w SVMapper oraz w kontrolerach gier.
W SVMapper controler jest widziany jako DMJoy 02 z 128 pozycjami.
W kontrolerach gier jest na pierwszej pozycji (to będzie można zmienić) i ma 6 osi.
Mam zainstalowany program do odczytu urządzeń USB podłączonych do PC.Jest tam widziany jako:
bus-0/\\.\libusb0-0003--0x0101-0x0002 0101/0002
- Manufacturer : DAMOS
- Product : DMJoy 02
- Serial Number: 1235
Wspomniany program jest bardzo przydatny.Można odczytać dane vendora oraz produktu (ID).Dla mnie możliwość ustawienia tych danych w DMJoyu zadecyduje czy będę mógł zostawić w moim projekcie jeden stary MJoy.Ten problem wynika z ograniczeń SVMappera,to tak przy okazji.
Mam nadzieję,że będę systematycznie informował o postępach w moich testach.
-
Fakt, płyteczki pierwsza klasa, malutkie, jak ktoś się uprze to i w chwycie (sporego) joya zmieści. Nawet tak się zastanawiam czy może nie warto by było zrobić drugiej wersji - nisko profilowej, z wyrzuconym gniazdem USB-B, które jest największym komponentem na tej płytce i nie pozostawić po prostu 5 otworów, jak kto chce, albo na goldpiny, albo na bezpośrednie wlutowanie przewodu zakończonego wtyczką USB-A (mam tak na jednym z Mjoyów).
Opcjonalnie wręcz zrobić tak by druga płytka, o której dyskutowaliśmy - swoisty "key matrix" - miał własnie miejsce na port USB-B, jeżeli ktoś potrzebuje.
U siebie kontempluję wrzucenie DMjoya do chwytu mojego Suncoma (zmieści się po wyrzuceniu gniazda USB-B).
-
Można wrzucić mniejsze gniazdo USB - bodaj USB-A. Oddalanie gniazda i przedłużanie drutów między uC a gniazdem nie jest zalecane.
-
Dalsze testy wykonane z DMJoy.Zanim to opiszę chciałbym wyjaśnić parę spraw.Mikroprocesor pracuje w dwóch trybach.Tryb nazwijmy go aplikacyjny czyli ten,który będziemy stosować.W tym trybie nasz uP będzie np.DMjoy.Jest też tryb programowalny.W tym ostatnim trybie uP komunikuje się z programatorem w naszym przypadku z Flip.Chip ma zaszyty program do komunikacji z programatorem DFU Bootloader.Na temat tego programu można poczytać w internecie,ale nie jest to potrzebne do naszych celów.Aby przejść do trybu programowania wystarczy nacisnąć przycisk reset na płytce.Tyle wstępu,teraz konkrety.
1.Pobieramy z strony Damosa program libus-win32-devel-filter-1.2.0.0 i go instalujemy.
2.Powstała ścieżka LibUSB-Win32,gdzie jest program Test(Win)Program.Uruchamiamy ten program.Po uruchomieniu mamy wyświetlone wszystkie podłączone do PC urządzenia USB z parametrami.
Nasza mała płytka może być widziana albo jako DMJoy albo jako ATm32U4DFU w zależności od tego czy nacisnęliśmy przycisk reset.
3.Instalujemy drivery dla DMJoy.Gdy włączymy pierwszy raz płytkę do PC i naciśniemy reset to uaktywni się kreator.W tym momencie postępujemy zgodnie z opisem w help programatora Flip.Jest to opisane szczegółowo w punkcie USB Driver Installation.Tutaj uwaga trzeba zainstalować programator Flip.Można go pobrać z internetu JRE-Flip-Instaler-3.4.1.Z instalacją nie ma problemu.
4.Teraz możemy przystąpić do programowania uP przy pomocy programatora Flip.
Damos napisał instrukcję opisującą szczegółowo jak programować,jest ona na jego stronie.
Testowałem DMJoy zgodnie z tą instrukcją.Jest ona napisana bardzo czytelnie i nie powinno być problemów.Porównując do PonyProg to jest nawet łatwiej programować w Flip.Jest kilka różnic.W Flip nie programujemy bitów specjalnych security bits.Jest to robione w programie Damosa.
Robiąc testy zapomniałem zapisać program Damosa na dysk i przy jednym z testów go wymazałem.Wniosek jest taki,że najpierw trzeba zapisać program źródłowy na dysku.
Gdy otrzymam następne programy opiszę ich działanie.
-
Po wykonaniu testów z programatorem Flip chciałbym przedstawić kilka praktycznych rad.Programujemy uP dwoma plikami źródłowymi jeden dotyczy pamięci flash i ma rozszerzenie hex drugi pamięci eeprom i ma rozszerzenie eep.Dobrze jest założyć ścieżkę (folder) np.progDMJoy w ścieżce Atmel i tam umieszczać programy źródłowe hex i eep.
Ładując plik eep należy w okienku Files of type ustawić all files tak aby wpisać właściwy plik.Tutaj uwaga,jeśli wspomniane pliki otworzymy Notatnikiem to nie będą widoczne w dużym oknie Flip rozszerzenia hex oraz eep.
Postępujemy zgodnie z opisem na Damosa stronie.Można załadować pamięć flash na dwa sposoby (tak mnie się wydaje).Polecam załadowanie pliku hex przyciskiem Run w polu Operations Flow.Jeśli są zaznaczone okienka w tym polu to program wykonuje wymazanie,programowanie oraz weryfikację.
Drugi sposób polega na wyborze opcji Device,następnie Erase oraz Program.
Jeszcze jedna uwaga.Po zaprogramowaniu uP nie ma możliwości odczytu pamięci.Przy próbie odczytu pojawia się komunikat:Device protection is set.Z drugiej strony nie ma takiej potrzeby.
Myślę,że te moje uwagi ułatwią programowanie.
-
Witam ponownie.Dzięki zaangażowaniu Damosa w projekt możliwe było wykonanie kolejnych testów.Damos napisał program do konfiguracji DMJoy.Można w tym programie konfigurować następujące parametry:vendor ID,product ID,serial number oraz device name.Dwa parametry są niedostępne:vendor name-DAMOS oraz version.To jest logiczne.
Program instalujemy w PC.Pełna jego nazwa:USB DMJoy configuration utility by Damos.Nazwa wyjaśnia jego funkcję.
Omówię krótko jego najważniejsze cechy.
1.Jedną z najważniejszych cech tego programu to zdalne programowe resetowanie.Nie musimy naciskać na przycisk chcąc zmienić program w uP np.upgrade.Wystarczy nacisnąc przycisk programowy start DFU i mamy połączenie z programatorem Flip.
2.Druga ważna cecha to wyświetlanie wszystkich urządzeń USB podłączonych do naszego PC.Są wyświetlane główne parametry tych urządzeń.Nie musimy włączać programu LibUSB-Win32 Test Program.
3.Mamy możliwość wpisania wspomnianych wcześniej parametrów.
4.Jest widoczny log opisujący wykonywanie kolejnych czynności w programie.
5.Działanie programu jest trywialne.Jeśli chcemy zmienić parametry DMJoy to wpisujemy dane w odpowiednie okienka,następnie wykonujemy Save changes oraz Restart i to wszystko.
6.Jeśli chcemy wgrać nowy program (upgrade) to wykonujemy start DFU.Następnie otwieramy programator Flip i ładujemy program do jego pamięci,wybieramy Run,ładujemy program do eeprom oraz Start Application i to wszystko.Punkt 6 jest opisany w poprzednim mailu.
Na załączonym obrazku widać platformę tego programu.
(http://img163.imageshack.us/img163/5729/dmjoytest1.th.jpg) (http://img163.imageshack.us/i/dmjoytest1.jpg/)
Wspomniałem wcześniej o możliwości wpisania ID vendora oraz ID produktu.Co to daje.W moim przypadku daje to możliwość stosowania jednego starego MJoy oraz SVMapper.Mając możliwość zmiany wspomnianych parametrów w DMJoy mogę go umieścić na końcu kolejki kontrolerów gier w Windows.U mnie będzie 5 kontrolerów widzianych w Windows oraz 4 widziane w SVMapper.Zrobiłem testy co widać na załączonych zdjęciach i wszystko jest o.k.
Chciałbym w tym momencie po raz kolejny podziękować Damosowi za jego projekt.
(http://img178.imageshack.us/img178/8969/dmjoytest2.th.jpg) (http://img178.imageshack.us/i/dmjoytest2.jpg/) (http://img443.imageshack.us/img443/6397/mlab.th.jpg) (http://img443.imageshack.us/i/mlab.jpg/)
-
Polecam stronę Damosa.Jest już na stronie opisany program USB DMJoy configuration utility by Damos.Ja pisałem o nim ogólnie Damos wyjaśnia bardziej szczegółowo posługując się zdjęciami.Jak zwykle jest to zrobione profesjonalnie moje gratulacje.
-
Polecam stronę Damosa.
Panowie, jakiś link do tej strony podacie? :001:
-
Musiałem tam nieco porządku zaprowadzić.
Nie jestem webmasterem, więc strona wygląda, jak wygląda :) Top raczej moje pierwsze próby zrobienia strony WWW.
Proszę też nie komentować marnej jakości tłumaczenia :003: Pomoc w tej materii chętnie przyjmę :) Wersję angielską zacząłem dorabiać po sugestiach vito_zm.
Oto link:
https://sites.google.com/site/damosmpds/home (https://sites.google.com/site/damosmpds/home)
-
Damos - pełen profesjonalizm, gdy w wątku była cisza, Wy (team) nie próżnowaliście :) Czekam na ostateczną wersję (z obsługą osi i enkoderów).
PS. O co chodzi z tym odliczaniem do przesyłki od Atmela ?
-
Damos jest bardzo skromny.Moim zdaniem strona jest super i co najważniejsze będzie bardzo przydatna przy uruchamianiu kontrolerów.Cisza była pozorna,Damos poświęcił dużo wolnego czasu aby osiągnąć ten etap projektu.Nie chcę zapeszać,ale projekty są zrobione profesjonalnie.
-
PS. O co chodzi z tym odliczaniem do przesyłki od Atmela ?
Obecnie nigdzie nie można kupić układów ATmega32U4. Podwykonawcy Atmela i innych producentów w czasie kryzysu zredukowali moce przerobowe (pozamykali fabryki lub zmniejszyli ilość linii produkcyjnych) i obecnie nie mogą wyprodukować odpowiedniej ilości układów aby zaspokoić popyt. Najbliższa dostawa z Atmela zawierająca te układy ma być bodaj w.. październiku? Odbiorcy widząc znikające w oczach stany magazynowe i daty najbliższej, planowanej dostawy w panice zaczęli kupować na zapas. W wyniku tego z rynku zniknęło wiele układów i nikt nie ma na stanie nawet 10 sztuk.
Ten countdown jest właśnie do najbliższej dostawy z Atmela, choć wartość dobrałem "na oko".
Wskutek braku układów w sklepach vito_zm ma jedną płytke z układem, Sundowner ma drugą a ja mam dwie. Nie przyszło mi do głowy kupować więcej układów, kiedy to robiłem (połowa 2009 ?) A teraz było już za późno.
-
Umieściłem na stronie informacje o projektach Damosa oraz Codeking.
http://www.viperpits.org/smf/index.php?topic=4399.30
Mam wrażenie,że te informacje trochę zaskoczyły pitbuilderów na tamtym forum,ponieważ stosują rutynowo od lat znane rozwiązania firm,które kiedyś były na rynku oraz nowych które się pojawiły.Myślę,że po jakimś czasie dotrze do ich świadomości fakt,że są inne lepsze i tańsze rozwiązania.Ja będę propagował nasze projekty.Teraz kolej na prezentację naszego projektu gaugesów zrobionych na serwo.
Mój angielski nie jest najlepszy,proszę o wyrozumiałość.
-
Protestuję ! ;)
DMKeys będzie obsługiwać 169 przycisków a nie 128 i nie będzie mieć osi analogowych. DMJoy będzie mieć analogowe osie, ale za to nie udźwignie 169 przycisków.
Bardziej niż na stworzeniu "kolejnego, rzekomo tańszego rozwiązania" (DMJoy, DMKeys) zależy mi na jakiejś standaryzacji protokołów komunikacyjnych (MPDS).
-
Protest przyjęty,obiecuję poprawę :004:.Masz rację Damos przepraszam za nieścisłości .Zastanawiam się dlaczego nikt nie pyta o szczegóły może jest to dla nich dziwne,że ktoś w Polsce też projektuje konkurencyjne sterowniki oraz platformy programowe za free.Zobaczymy czy zareagują na prototyp EGHI gaugesów dla Falcona,który mam zamiar zaprezentować.Może nasze polskie forum za jakiś czas będzie alternatywą dla pitbuilderów.
-
Nie przejmuj się, Vito_zm - uwierzą, kiedy zobaczą działające (ja z resztą też ;) )
Pierwszy Firmware do testowego DMKeys8 jest już w 3/4 gotowy. Dziś lub jutro Ci wyślę.
-
Dziś dzięki uprzejmości vito_zm DMkeys8 przeszedł pierwsze testy po za moim kompem - pomyślnie! :) Mimo kilku niespodziewanych trudności udało się uruchomić pierwszą, ograniczoną wersję. Klikanie w podłączone push-buttony jest już zamieniane na wysyłanie predefiniowanej sekwencji przycisków. Teraz zostało dorobić tool do zapisywania ustawień wewnątrz kości i urządzenie niemal gotowe!
-
Potwierdzam DMkeys8 jest widziany jako klawiatura.Zrobiłem testy z push-button jest o.k.Układ (program)jest odporny na drgania styków nie ma powtórzeń,reaguje bardzo szybko.Te niespodziewane trudności jak zwykle okazały się trywialne.Trzeba było zmienić dane sterownika w pliku .eep.Teraz widać jak ważna jest możliwość dokonania tych zmian w programie Damosa to tak przy okazji.
-
Potwierdzam DMkeys8 jest widziany jako klawiatura.Zrobiłem testy z push-button jest o.k.Układ (program)jest odporny na drgania styków nie ma powtórzeń,reaguje bardzo szybko.
I tak miało być :010: :banan
Te niespodziewane trudności jak zwykle okazały się trywialne.Trzeba było zmienić dane sterownika w pliku .eep
hmm... czy my zmienialiśmy cokolwiek w plikach? :021: Chyba nie :118: Życie staje się prostsze, jeśli masz odpowiednią opcję w programie :020: Prawda :011:
-
Jak zwykle masz rację,dostępna opcja rozwiązała problem.DMkeys8 jest widziany w menedżer urządzeń jako klawiatura HID.Oczywiście nie ma go w kontrolerach gier co rozwiązało następny problem z SVMapper.
Sprawdziłem wyprowadzone na łączówkę porty testując program.Wszystkie działają.Jeszcze nie wiemy czy Damosowi wystarczy pamięci do zaprogramowania 169 wejść,ale wstępnie można założyć,że maxymalna pojemność matrycy diodowej wyniesie 169 lub mniej.
W związku z czym prośba do Zajca aby się temu przyjrzał.Wyprowadzenia są dostępne na stronie Damosa.Mam taką sugestię aby wyprowadzić każdy wiersz z 13 kolumnami na łączówkę co daje 13 łączówek 14 pin.Myślę,że można wstępnie rozpocząć dyskusję jak wyprowadzić sygnały z matrycy.
-
W związku z czym prośba do Zajca aby się temu przyjrzał.Wyprowadzenia są dostępne na stronie Damosa.Mam taką sugestię aby wyprowadzić każdy wiersz z 13 kolumnami na łączówkę co daje 13 łączówek 14 pin.Myślę,że można wstępnie rozpocząć dyskusję jak wyprowadzić sygnały z matrycy.
apropos matrycy - ze względów wydajnościowych planuję matrycę 10x16. 10 kolumn będzie zasilanych a z 16 wierszy będę odczytywać dane. Odczyt będzie realizowany na 2 pełnych portach po 8 wyjść każdy, co umożliwi realizację tego w 2 cyklach zegarowych.
Tak więc cała prawa strona z obrazka:
(https://sites.google.com/site/damosmpds/projects/projekt/hardware/atmega32u4-8bit-avr/pinout/DMBoard8.PNG)
będzie zmapowana do wierszy a piny z lewej: PC6-PF0 będą kolumnami.
Sumarycznie ubędzie 9 wejść (160 zamiast 169), ale pozwoli to na znaczną optymalizację kodu jak i struktur danych.
Obecnie pracuję nad zapisem konfiguracji układu do pamięci eeprom, która ma zaledwie 1024 bajty. 44 bajty "poszły" na VENDOR_ID, Product_ID, Serial, Name i tym podobne. Tak więc na config zostało ok. 980 bajtów. To daje średnio 6 bajtów na opis jednej kontrolki, wliczając w to sekwencje klawiszy, które mają być wysłane . Piekielnie mało:
każdy element (button, switch, przełącznik multipozycyjny, encoder) musi być opisany swoim ID - 1 bajt
każdy pin musi mieć opisane - do którego punktu matrycy jest dołączony (1 bajt * ilość pinów), (przycisk = 2 bajty,enkoder i prosty przełącznik = 3 bajty)
wysyłana sekwencja klawiszy może być wysłana po naciśnięciu lub po zwolnieniu - więc dwie sekwencje na przycisk, 2 na enkoder, 2 na każdą z pozycji przełącznika...
sekwencja to:
1 bajt opisu długości, 1 bajt na modyfikatory typu shift, ctrl, alt itp. 1 bajt na każdy klawisz, w sumie: min 3 bajty
W tym układzie na każdy przełącznik potrzeba min 10 bajtów, na każdy push-button z podpiętymi 3 klawiszami (np. ctrl+M+D+1) trzeba 9 bajtów... wychodzimy za limit :)
Tak więc teraz rozpracowuję sposób na zmieszczenie w kości opisu o wielkości większej niż eeprom :karpik (ok 1,5 KB).
-
Tak więc teraz rozpracowuję sposób na zmieszczenie w kości opisu o wielkości większej niż eeprom
Jeśli nie wyrobisz z pamięcią to pozostają dwa rozwiązania.Zmniejszyć pojemność matrycy lub zrobić zewnętrzny program podobny do SVMapper o ile jest to możliwe.Jeszcze jedna myśl przyszła mi do głowy.Ponieważ jest różnica 1 bajtu w opisie push-button oraz przełączników to można ograniczyć liczbę tych ostatnich tak jak w MJoyu zyskując kilka bajtów.
-
U mnie sam decydujesz, co jest podpięte gdzie - jak wstawisz sobie dużo przełączników to zostanie mniej wolnych miejsc dla przycisków. Możesz nawet dać tylko 8 push buttonów, do każdego podpiąć 16 sekwencji po 6 klawiszy każda (osobne 16 na na ON i osobne 16 na OFF ) i zużyjesz całą dostępną pamięć :karpik . Tu NIE MA wejść na sztywno przypisanych dla przełączników lub innych dla przycisków. Wszystko możesz podłączyć wszędzie - i odpowiednio skonfigurować w programie.
Program we właściwym momencie sam powie - STOP - więcej się już nie da, nawet jeśli pozostaną wolne piny ma matrycy.
-
Damas jesteś genialny,jest to rozwiązanie problemu.W ten sposób użytkownik sam decyduje o konfiguracji mając świadomość ograniczeń.
-
Chwileczkę. Ale czemu nie ograniczyć się na bazowej konfiguracji do powiedzmy 64 przycisków, a skrzydła rozwijać dopiero po podpięciu płytki - matrycy, na której umieścić kość zewnętrznego EEPROMu, komunikującego się po IIC ? I wtedy już właściwie bez limitów pamięci, bo te EEPROMy są ogromne, w porównaniu z "on chip".
Albo w ogóle na ostatecznej wersji płytki dać miejsce na zewnętrzny EEPROM, jak ktoś będzie potrzebował zwykłego kontrolera joya, to zostawi wolne, a jak kontroler panelu, to go tam wciśnie.
-
Chwileczkę. Ale czemu nie ograniczyć się na bazowej konfiguracji do powiedzmy 64 przycisków, a skrzydła rozwijać dopiero po podpięciu płytki - matrycy
Bo "bazowo" mamy tylko 26 przycisków.
, na której umieścić kość zewnętrznego EEPROMu, komunikującego się po IIC ? I wtedy już właściwie bez limitów pamięci, bo te EEPROMy są ogromne, w porównaniu z "on chip".
Albo w ogóle na ostatecznej wersji płytki dać miejsce na zewnętrzny EEPROM, jak ktoś będzie potrzebował zwykłego kontrolera joya, to zostawi wolne, a jak kontroler panelu, to go tam wciśnie.
1 - Odczyt eeprom jest wolny, a zewnętrznego jeszcze bardziej
2 - wewnętrznego RAM'u jest jedynie 2,5 KB na wszystkie zmienne (wliczając w to stack USB oraz na stos)...
A odczytywanie eeprom "na raty" przy każdej iteracji odpytania wyjść odpada - nie zmieści się między kolejnymi ramkami USB. (myślałem o tym)
-
Mały update DMKeys8:
Trafiło się kilka wolnych nocy i rozwiązałem problemy z pamięcią i dynamiczną konfiguracją wejść układu. Zrobiłem obsługę:
- przycisków,
- przełączników,
- emulacji przełącznika bistabilnego za pomocą przycisku
- obsługę 3 rodzajów enkoderów.
Ciekawostka: po skonfigurowaniu na obsługę ponad 50 enkoderów (!) układ nadal "wyrabiał się" czasowo i poprawnie je obsługiwał, co jest pozytywnym zaskoczeniem :)
Całość zaczyna wyglądać obiecująco. Teraz pozostał do zrobienia jakiś "przyjazny" program do konfiguracji wejść i będzie gotowe.
-
Ciekawostka: po skonfigurowaniu na obsługę ponad 50 enkoderów
Moje gratulacje.Jest to bardzo dobra wiadomość,ponieważ zauważyłem,że do realizacji kokpitu F16 potrzeba trochę enkoderów.W moim przypadku liczba 50 jest dużym zapasem.
-
zauważyłem,że do realizacji kokpitu F16 potrzeba trochę enkoderów.W moim przypadku liczba 50 jest dużym zapasem.
OK, odpaliłem nawet 80 enkoderów :banan (więcej się nie da ze względu na ilość wejść matrycy) wymagało to nieco zabawy w optymalizacje kodu, ale w końcu poszło.
W międzyczasie zetknąłem się z problemem, jakim jest jakość enkoderów.
Normalnie przebieg sygnału powinien wyglądać tak: (sygnały przesunięte w fazie o 90stopni)
(http://img163.imageshack.us/img163/1378/powinnobyc.th.png) (http://img163.imageshack.us/i/powinnobyc.png/)
Niestety - w praktyce wygląda to dużo mniej idealnie. Musiałem dostosować firmware do obsługi 2 typów enkoderów, które akurat posiadam:
- enkoder bez przycisku, 12 kroków/obrót
- enkoder z przyciskiem w osi, 24 kroków/obrót
Pierwszy generuje takie przebiegi:
obrót w prawo:
(http://img338.imageshack.us/img338/7813/noswprawo.th.jpg) (http://img338.imageshack.us/i/noswprawo.jpg/)
obrót w lewo:
(http://img828.imageshack.us/img828/7972/noswlewo.th.jpg) (http://img828.imageshack.us/i/noswlewo.jpg/)
Widać bardzo mocną degenerację sygnału i praktycznie brak przesunięcia fazowego z jednej strony. Okres istnienia przesunięcia fazowego jest czasem bardzo mały: 240 uS, co wymagało by odpytywania z częstotliwością ponad 8000 razy na sekundę, co w naszym przypadku nie jest możliwe.
Drugi typ enkodera (z przyciskiem w osi) ma lepszy kształt sygnału, generuje za to dużo większy jitter :)
obrót w prawo:
(http://img266.imageshack.us/img266/903/swprawo.th.jpg) (http://img266.imageshack.us/i/swprawo.jpg/)
obrót w lewo:
(http://img218.imageshack.us/img218/134/swlewo.th.jpg) (http://img218.imageshack.us/i/swlewo.jpg/)
Ze względu na większą ilość impulsów na obrót timingi też są bardziej krytyczne - przesunięcie sygnałów bywa i na poziomie 160uS (wymaga próbkowania 12000/s)
Do tego poważny jitter: tu o amplitudzie 4.6V i czasie trwania kilku szybkich impulsów !
(http://img132.imageshack.us/img132/8648/swjitter.th.jpg) (http://img132.imageshack.us/i/swjitter.jpg/)
Generuje dodatkowe, przekłamujące impulsy:
(http://img524.imageshack.us/img524/3254/swjitter4.th.jpg) (http://img524.imageshack.us/i/swjitter4.jpg/)
(http://img138.imageshack.us/img138/2319/swjitter3.th.jpg) (http://img138.imageshack.us/i/swjitter3.jpg/)
(http://img233.imageshack.us/img233/8261/swjitter2.th.jpg) (http://img233.imageshack.us/i/swjitter2.jpg/)
Przy powolnym obracaniu (nie szybciej niż 1 sek/obrót) układ działa bezbłędnie. Przy bardziej dynamicznym obracaniu zaczyna generować "fałszywe klawisze" tzn - w ciągu klawiszy przypisanych obrotowi w prawo pojawia się jeden lub kilka klawiszy przypisanych obrotowi w lewo.
Obawiam się, że enkodery jeszcze gorszej jakości mogą nie pracować idealnie.
Niestety - nie mam tu zbyt wielkiego pola manewru i jeśli taka jakość wystarczy - wolał bym na razie przy niej pozostać. Jedyny sposób na złagodzenie tych dolegliwości to obniżenie ilości stosowanych przez użytkownika elementów i zwiększenie (ustawienie w opcjach programu konfiguracyjnego) wartości filtra cyfrowego (ustawiane osobno dla enkoderów i osobno dla przycisków i przełączników)
Co Wy na to ?
-
Tak na szybko z tego co widzę.Enkodery,które nie dają przesunięcia fazowego sa nie do przyjęcia.Trochę tego nie rozumiem,ponieważ kod Graya powinien zapewnić prawidlowe przebiegi sygnałów.Pytanie jak to zmierzyć kręcąc gałką (oscyloskop z pamięcią?).
Co do jitera to rzeczywiście albo filtr cyfrowy albo analogowy (całkowanie).Wygląda to tak jak styki przekaźnika.
Moim zdaniem to ograniczenie liczby enkoderów oraz zrobienie filtu cyfrowego jest dobrym pomysłem.Dodatkowo ograniczenie szybkości obracania gałką.Nie ma sensu żyłowania układu po to aby osiągnąć maximum możliwości.Lepiej mieć ukłd stabilny.Jeśli będzie brakowało enkoderów można zastosować kilka sterowników.W MJoyu niektóre tanie enkodery także dawały przekłamania.Co innego w przemyśle,gdzie enkodery są precyzyjne i wielobitowe,ale są bardzo drogie.
Z tego co napisałeś wynika,że chcesz się także zabezpieczyć przed drganiem zestyków dla przycisków,czy mam rację?
-
Tak na szybko z tego co widzę.Enkodery,które nie dają przesunięcia fazowego sa nie do przyjęcia.
Niestety - w takim układzie odpada 99% towaru na rynku :) Te Enkodery z załączonych oscylogramów są już obsługiwane :)
Trochę tego nie rozumiem,ponieważ kod Graya powinien zapewnić prawidlowe przebiegi sygnałów.
To raczej enkoder powinien zapewnić kod Gray'a z prawidłowymi przebiegami. Obawiam się, ze tanie, czysto mechaniczne konstrukcje mogą nie być w stanie tego zrobić.
Pytanie jak to zmierzyć kręcąc gałką (oscyloskop z pamięcią?).
Dokładnie tak to zrobiłem. Układ nie działał zgodnie z założeniem i w końcu sięgnąłem po oscyloskop cyfrowy.
Co do jitera to rzeczywiście albo filtr cyfrowy albo analogowy (całkowanie).Wygląda to tak jak styki przekaźnika.
Całkowanie analogowe za pomocą pojemności wymagało by rezystora rozładowującego dla każdego PIN'a, który mógłby powodować problemy z matrycą. Dla zmniejszenia ilości elementów nie używam żadnych zewnętrznych rezystorów ( w przeciwieństwie do MJoy'a ). Ponadto sam "burst" odczytania stanów matrycy to seria sygnałów o częstotliwości ok 1MHz - a tam pojemności zaczynają grać rolę. Sama długość kabli zrobi już swoje.
Moim zdaniem to ograniczenie liczby enkoderów oraz zrobienie filtu cyfrowego jest dobrym pomysłem.Dodatkowo ograniczenie szybkości obracania gałką.
Problem w tym, że wielkość czasu przesunięcia sygnałów nie zależy liniowo od szybkości kręcenia :( Nawet kręcąc powoli mamy dość mały delay.
Z tego co napisałeś wynika,że chcesz się także zabezpieczyć przed drganiem zestyków dla przycisków,czy mam rację?
Oczywiście! Przełączniki mają potężne drgania na stykach i tam bezwzględnie należy się przed nimi chronić. Inaczej po jednym wciśnięciu przycisku dostał byś kilka(naście) sekwencji klawiszy. Sprawa przycisków i przełączników jest już załatwiona i problem drgania styków nam nie grozi (ten wsad, który wysłałem ci poprzedni już miał filtr cyfrowy na wejściu, obecnie jedynie przerobiłem go na wersję konfigurowalną za pomocą zewnętrznego programu).
Enkoder jest większym problemem, bo czas na wygaszenie styków musiał by być czasem większy niż odstęp między kolejnymi sygnałami w innym przypadku.
-
Enkoder jest większym problemem, bo czas na wygaszenie styków musiał by być czasem większy niż odstęp między kolejnymi sygnałami w innym przypadku.
Można zrobić ograniczenie w założeniach projektu dotyczące szybkości manipulowania gałka.
Zastanawiam się nad tymi wykresami.Nie mam oscyloskopu z pamięcią,dlatego nie mogę tego przebadać.Z tego co pamiętam to po stwierdzeniu,że niektóre enkodery przekłamują zrobiłem prosty układ do testowania tzn.2 LED podłączone do styków.Obracając oś w lewo i w prawo testowałem kolejność zapalania LED (powinny zapalać wg.kodu Graya).Dla tych tańszych enkoderów zdarzały się przekłamania kodu,ale be droższe były stabilne.Oczywiście był to prymitywny test,ale można było zauważyć,że niektóre enkodery przekłamują.Tutaj uwaga,przekłamanie było chwilowe tzn.w momencie przejścia z jednego stanu (kodu Graya) do drugiego.
-
Można zrobić ograniczenie w założeniach projektu dotyczące szybkości manipulowania gałka.
Dodałem w nocy filtr cyfrowy na generowany output (ograniczenie na prędkość generowanych na wyjściu impulsów) podeślę Ci firmware do przetestowania na twoich enkoderach. (będzie działać na płytce, którą masz)
Zastanawiam się nad tymi wykresami.Nie mam oscyloskopu z pamięcią,dlatego nie mogę tego przebadać.Z tego co pamiętam to po stwierdzeniu,że niektóre enkodery przekłamują zrobiłem prosty układ do testowania tzn.2 LED podłączone do styków.Obracając oś w lewo i w prawo testowałem kolejność zapalania LED (powinny zapalać wg.kodu Graya).
W tym przypadku oko ludzkie ma zbyt dużą bezwładność aby wykryć drgania styków
Dla tych tańszych enkoderów zdarzały się przekłamania kodu,ale be droższe były stabilne. Oczywiście był to prymitywny test,ale można było zauważyć,że niektóre enkodery przekłamują.
Możesz podać linka do pozycji w jakimś sklepie z tymi "poprawnymi" enkoderami ? Chętnie kupię i zobaczę, jak działają.
Oczywiście był to prymitywny test,ale można było zauważyć,że niektóre enkodery przekłamują.Tutaj uwaga,przekłamanie było chwilowe tzn.w momencie przejścia z jednego stanu (kodu Graya) do drugiego.
Oczywiście. Stan "spoczynkowy" to rozłączenie obu wyjść i tam nie ma co przekłamywać :)
-
W tym przypadku oko ludzkie ma zbyt dużą bezwładność aby wykryć drgania styków
Masz rację,dlatego mam wątpliwości czy moje uwagi dotyczące lepszych lub gorszych enkoderów są słuszne.Kupilem je 2 razy na Allegro oprócz różnicy w cenie jedne miały dodatkowy przycisk i przy przeskodu było "kliknięcie" te drugie były bez przycisku i zmiana pozycji była "niewyczuwalna" tak jakby był mechanizm ślizgowy??
Myślę teraz o czym innym.Test o którym napisałem zrobiłem po uwadze jednego z kolegów na forum,że enkoder przekłamuje.Pytanie podstawowe jak wykonać obiektywny test w domowych warunkach.W symulatorze można przekłamania nie zauważyć.Gdybym był programistą to napisałbym prosty program w którym na wyjściu licznika rewersyjnego podłączyłbym wyświetlacze.Impulsy "dodatnie" obrót w prawo sterowałby wejście dodające a impulsy "ujemne" wejście odejmujace.Obrót w prawo powinien zwiększać wyświetlaną liczbę obrót w lewo zmniejszać.Oczywiście brak rozróżnienia czy drgania czy jitter.
Dochodzę do wniosku,że trzeba założyć to co pomierzył Damos,że dostępne na rynku enkodery przekłamują (drgania,jitter) i zabezpieczyć się programowym filtrem,nic innego nie przychodzi mi do głowy.
-
Witam,
zrobiłem wstępne testy układu Damosa.Testowałem przyciski oraz enkodery.Wyniki są pozytywne.Damos wprowadził nowe opcje dla przycisków.Można np.emulować przycisk bistabilny.Zastanawiam się jak to będzie można wykorzystać w kokpicie.Na zdjęciu jest pokazany sterownik oraz panel z enkoderami.
(http://img214.imageshack.us/img214/5615/mtesty.jpg) (http://img214.imageshack.us/i/mtesty.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Przy testach enkoderów okazuje się,że jakość kodu generowana przez te elementy jest nienajlepsza delikatnie mówiąc.Można to zauważyć na wykresach,które zamieścił Damos.Aż nie chce się wierzyć,że był w stanie programowo to skorygować.Wszystko wskazuje na to,że będziemy mieli godnego następce MJoya.
-
No Panowie szacuneczek i ukłon w Waszą stronę. Miałem powoli kompletować zamówienie na płytki MJoya v1,bo się wyczerpały, ale jak to widzę to jednak zaczekam na następnę.
z wypiekami na twarzy
noker
-
Chciałbym uzupełnić informację o następcy MJoya.Dzisiejszy dzień poświęciliśmy z Damosem na testy.W czasie testów enkoderów mieliśmy różne wyniki.Wynikało to z tego,że mieliśmy różne typy enkoderów.Przyznam się szczerze,że nie miałem o tym pojęcia.Dobrze,że to wyszło na etapie testów.Jeszcze jeden wniosek.Kupując enkoder trzeba wiedzieć jaki to jest typ,ponieważ w programie konfiguracyjnym Damosa będzie opcja wyboru typu.W MJoyu tej opcji nie było.Muszę sprawdzić jak jest w SIOC.Przy okazji podziękowanie dla Damosa za jego pracę.
Jeszcze jedna myśl.Te różnice można było zauważyć w programie testowym.Taka sugestia dla Damosa.Czy można zrobić opcję testującą typ enkodera?W sklepie mogą nie znać jego typu.
-
Taka sugestia dla Damosa.Czy można zrobić opcję testującą typ enkodera?W sklepie mogą nie znać jego typu.
EGHI też o to pytał, widocznie trzeba będzie coś takiego dodać.
Chodzi ci o opcję w programie, czy możliwość podłączenia i sprawdzenia enkodera w sklepie ? (4 paluszki i układ robi się mobilny...)
-
Chodzi ci o opcję w programie, czy możliwość podłączenia i sprawdzenia enkodera w sklepie ?
Najlepiej obie opcje, ja często kupuję online, więc opcja w programie będzie przydatna.
Proponuje, żeby wyjaśnić po co taki test? I czym różnią się enkodery typu 1:1, 1:2, 1:4.
Damos, zrobisz to najlepiej. :)
Pozdrawiam.
-
Jaki jest tego efekt?
Otóż:
program przystosowany do enkodera 1:1 będzie w przypadku enkodera 1:2 emitował impuls co drugi krok (tak jest u ciebie) a w przypadku enkodera 1:4 impuls będzie emitowany co czwarty krok !
Jeśli zaś program przeznaczony do obsługi enkodera 1:4 zastosujemy do obsługiwania enkodera 1:1 to na jeden "krok" zostaną wygenerowane 4 impulsy !
Tak więc muszę dodać do swojego programu kolejne opcje uwzględniające typ enkodera :)
Pozwoliłem sobie załączyć cytat z korespondencji z Damosem.Ja mam enkoder 1:2 i tak to działa jak w cytacie.
Myślę,że większość z nas kupuje w internecie,dlatego opcja testu w programie jest właściwa.Generalnie w programie powinno być sprawdzenie czy element działa i gdzie jest podłączony.W MJoy jest to pokazane graficznie u Codeking można także sprawdzić wyjścia.Podobnie jest w OC.U nas będą przyciski,przełączniki oraz enkodery.Co do enkoderów to można zaprogramować np.wersję 1:1 i sprawdzić w panelu symulatora.Jeśli będzie widziany efekt po 2 lub 4 "krokach" to będzie wiadomo jaki mamy typ enkodera.Jeśli inny niż 1:1 to programujemy kość jeszcze raz z właściwym typem.W ten sposób możemy zrezygnować z identyfikacji typu enkodera w programie Damosa.
-
Proponuje, żeby wyjaśnić po co taki test? I czym różnią się enkodery typu 1:1, 1:2, 1:4.
Damos, zrobisz to najlepiej. :)
OK, w takim razie lecimy:
Enkoder inkrementalny ma dwa wyjścia A i B, na których w miarę obracania pojawia się zmienny sygnał w kodzie Graya: http://pl.wikipedia.org/wiki/Kod_Graya (http://pl.wikipedia.org/wiki/Kod_Graya) . Na każdej "nóżce" pojawia się naprzemiennie 0-1-0-1-0-1-0-1-... itd
Kierunek obrotu można ustalić za pomocą analizy przesunięcia fazowego - po ludzku mówiąc: sprawdzając, na której nóżce sygnał zmienił się najpierw.
Enkoder, o którym mówimy (bo nie każdy) obraca się skokowo a nie płynnie, to znaczy, że ma pewną ilość ustalonych pozycji, na których chce się zatrzymać podczas obracania (czuć wtedy po palcami delikatny opór). Takich pozycji jest najczęściej 8 lub 16.
Pomiędzy jedną pozycją a druga powinna zajść jakieś zmiany "na nóżkach" enkodera, aby obsługujący go program poznał, że użytkownik obraca. Zmiana może być jedna lub kilka - i tu właśnie wpadamy w klasyfikację 1:1, 1:2, 1:4.
Otóż - na pełen cykl zmian na obu wyjściach, tzn kiedy A o B przejdą przez stany 0-1-0 enkoder może mieć 1 krok, 2 kroki lub 4 kroki. Jeżeli program obsługujący enkoder ma generować jeden impuls na każdy krok - musi wiedzieć, ile kroków przypada na jeden cykl.
Algorytm dla 1:1 dokonuje detekcji zbocza opadającego lub wznoszącego jednego z sygnałów i sprawdza, czy to nastąpiło po zmianie na zero lub 1 drugiego sygnału - zależnie od tego obrót jest w lewo lub w prawo
Algorytm dla 1:2 dokonuje detekcji obu zboczy jednego sygnału i konfrontuje ten moment ze stanem drugiego sygnału - to pozwala mu określić kierunek
Algorytm dla 1:4 reaguje na zbocza opadające i rosnące obu sygnałów i w każdym z tych momentów musi określić przesunięcie fazowe względem drugiego sygnału dla detekcji kierunku obrotu.
Oto graficzne przedstawienie przebiegów czasowych idealnego enkodera w 3 wariantach: 1:1, 1:2 i 1:4. Na każdym diagramie pokazałem:
- szary obszar zawierający jeden cykl zmian
- fioletowe, pionowe linie symbolizujące - kiedy zatrzymało się pokrętło w każdym kroku (punkty zatrzymania pokrętła enkodera) pomiędzy tymi liniami jest właśnie krok obrotu enkodera
- poziome, zielone linie symbolizujące 3 odrębne algorytmy programu - najwyższa dla enkodera 1:1, niższa dla 1:2 i najniższa dla 1:4, na nich zaznaczam, kiedy "wyłapują" krok enkodera
- czerwone kropki pokazujące, na jakie zdarzenie reaguje jaki algorytm (wtedy generuje informację o obrocie o jeden krok)
- czarne "iksy" (X) pokazujące, w których krokach dany algorytm nie wygeneruje impulsu, ponieważ nie wystąpiły warunki właściwe dla danego algorytmu
Oto działanie 3 algorytmów na enkoderze 1:1
(http://img842.imageshack.us/img842/3607/cykl11w.png)
widać, że:
algorytm 1:1 wygeneruje w trakcie jednego kroku jeden impuls
algorytm 1:2 wygeneruje w trakcie jednego kroku dwa impulsy (dwa impulsy na jeden skok gałki - jeden impuls nadmiarowy)
algorytm 1:4 wygeneruje w trakcie jednego kroku cztery impulsy (cztery impulsy na jeden skok gałki - trzy impulsy nadmiarowe)
następny przypadek: 3 algorytmy i enkoder typu 1:2 (dwa skoki gałki na pełną cyrkulację sygnału)
(http://img210.imageshack.us/img210/7039/cykl12w.png)
widać, że:
algorytm 1:1 nie wygeneruje w trakcie pierwszego kroku impulsu, wygeneruje za to w kolejnym kroku - mamy więc impuls co drugie zatrzymanie gałki (jeden impuls zgubiony)
algorytm 1:2 wygeneruje w trakcie jednego kroku jeden impuls (czyli mniej niż poprzednio i akurat tyle, ile trzeba)
algorytm 1:4 wygeneruje w trakcie jednego kroku dwa impulsy (dwa impulsy na jeden skok gałki - jeden impuls nadmiarowy)
jak widać, algorytm dla 1:1 zaczyna "gubić" impulsy a algorytm 1:4 jeszcze generuje więcej niż powinien
przejdźmy do trzeciego przypadku:
3 algorytmy i enkoder typu 1:4 (4 skoki gałki na pełną cyrkulację sygnału)
(http://img407.imageshack.us/img407/6269/cykl14w.png)
widać, że:
algorytm 1:1 nie wygeneruje w trakcie pierwszych 3 kroków ani jednego impulsu, wygeneruje za to w czwartym kroku - mamy więc impuls co cztery zatrzymania gałki (3 impulsy zgubione)
algorytm 1:2 nie wygeneruje w trakcie pierwszego i trzeciego kroku żadnego impulsu (generuje za to dwa impulsy w krokach 2 i 4) - mamy więc impuls co drugie zatrzymanie gałki (dwa impulsy zgubione)
algorytm 1:4 wygeneruje w trakcie każdego kroku jeden impuls (mamy więc jeden impuls na jeden skok gałki)
Wszystkie moje enkodery (mimo, iż są różne) są typu 1:1. Vito_zm ma natomiast 1:2. Ciekaw jestem, czy ktoś ma 1:4 ? Te powinny być najlepszej jakości.
BTW - a teraz powiedzcie mi, jak algorytm 1:4 ma ustalić, który przebieg urósł jako pierwszy w takim przypadku: :) :118: :karpik
(http://img121.imageshack.us/img121/470/enoswprawo.jpg)
To tyle w ramach wyjaśnień - jeśli są pytania - proszę śmiało.
-
Bardzo profesjonalnie to wyjaśniłeś.Zrobiłem testy z nowym wsadem dla mojego przypadku tzn.enkoderów 1:2.Testy wyszły pomyślnie.Teraz moje enkodery wysyłają "sekwencję testową" przy każdym "kroku".Tak jak to wyjaśnił Damos krok jest wyczuwalny przy obrotach gałką.Jeszcze jedno wyjaśnienie związane z "sekwencję testową".Damos zrobił program testujący w którym przy obrotach osi enkodera są wysyłane sekwencje znaków w programie Notatnika.Jest to bardzo przydatny program do testowania enkoderów oraz przycisków.
-
Okres istnienia przesunięcia fazowego jest czasem bardzo mały: 240 uS, co wymagało by odpytywania z częstotliwością ponad 8000 razy na sekundę, co w naszym przypadku nie jest możliwe.
Przepraszam że się wcinam, ale może by spróbować "załatwić to" w obsłudze przerwania od zbocza na wejściach zamiast męczyć uP poolingiem ?
Nie wiem jaką kostką to obsługujecie, więc być może moja propozycja nie jest zbyt mądra ?
-
Przepraszam że się wcinam, ale może by spróbować "załatwić to" w obsłudze przerwania od zbocza na wejściach zamiast męczyć uP poolingiem ?
Nie wiem jaką kostką to obsługujecie, więc być może moja propozycja nie jest zbyt mądra ?
Uwaga jak najbardziej celna i słuszna :010: :)
Tylko, że możliwości techniczne ATmega32U4 są zbyt małe :( Jedynie13 pinów może generować przerwania (wystarczy na 6 enkoderów). W dodatku używam trybu matrycowego, co skutecznie eliminuje możliwość używania przerwań (cała idea matrycy to jeden wielki pooling). Założenie jest takie, że za pomocą odpowiedniego programu w PC konfigurujesz sobie, jakie peryferia są obsługiwane przez układ. Stąd maksymalizacja możliwości i tryb matrycowy na 160 wejść cyfrowych.
Do trybu w pełni przerwaniowego można by wykorzystać układ bazujący na AT32UC3B (ma indywidualne przerwanie na każdym pinie) - ale on wymaga już dużo elementów "dodatkowych" (kondensatory blokujące itp.), zasilania 3.3V i ma obudowę z "gęstymi" pinami:
(http://img22.imageshack.us/img22/8249/avr32board1top.th.jpg) (http://img22.imageshack.us/i/avr32board1top.jpg/)
Obecny układ bazuje na ATMega32U4, jest mały i tani:
(http://img193.imageshack.us/img193/4957/img4778oj.th.jpg) (http://img193.imageshack.us/i/img4778oj.jpg/)
ale ma swoje ograniczenia. Jak na razie pracuje całkiem dobrze z 70-ma enkoderami lub 24-ma enkoderami i 80-cioma przyciskami. (Samych przycisków obsłuży 160, jedynie enkodery są wrażliwe na ilość podłączonych elementów). IMHO ma potencjał bycia niezłą alternatywą dla MJoy'a.
-
Przepraszam że się wcinam, ale może by spróbować "załatwić to" w obsłudze przerwania od zbocza na wejściach zamiast męczyć uP poolingiem ?
Intencja jest słuszna,ale dla jednego lub kilku enkoderów.Nam zależy na większej ich liczbie.Nie chcę wchodzić w szczegóły związane z przerwaniami,ale są one na tyle cenne,że programiści stosują je dla ważniejszych zadań.
Druga sprawa to jitter oraz drgania styków.Nie chcę znowu wchodzić w szczegóły,ale rozwiązanie Damosa jest optymalne.
-
Jestem naprawdę pod wrażeniem. Ale jak rozumiem obsługa 70 enkoderów jest możliwa przy założeniu że nikt nie będzie kręcił wszystkimi jednocześnie ?
-
Fizycznie jest to niemożliwe.Robimy projekt pod symulator gdzie wirtualny pilot wykonuje określone czynności wg.procedur.
-
Przy założeniu że powiedzmy 60 enkoderów w wirtualnej kabinie np. F-16 będzie obsługiwane przez jeden "centralny uP" będziecie jak rozumiem zmuszeni do przeciągnięcia ok. 120 przewodów o długości być może 100 cm. Uwzględniając wymagane czasy narastania zbocza sygnału ~ 10 us czy nie obawiacie się zakłóceń, odbić, przerostów itp. Jak rozumiem to nie są pętle prądowe ?
Zauważyłem bardzo dużą oszczędność na dodatkowych elementach pasywnych – ale czy to się nie odbije w końcowym złożeniu wszystkiego w całość ?
Do powyższych pytań zmuszają mnie zawodowe uprzedzenia do długich przewodów jakich się nabawiłem przy projektach pracujących w środowiskach o dużym poziomie zakłóceń.
Czy można gdzieś obejrzeć schemat (może być blokowy) całości ?
-
jak rozumiem obsługa 70 enkoderów jest możliwa przy założeniu że nikt nie będzie kręcił wszystkimi jednocześnie ?
Można kręcić wszystkimi jednocześnie (przy zastosowaniu diod)
Przy założeniu że powiedzmy 60 enkoderów w wirtualnej kabinie np. F-16 będzie obsługiwane przez jeden "centralny uP" będziecie jak rozumiem zmuszeni do przeciągnięcia ok. 120 przewodów o długości być może 100 cm.
60 enkoderów to 180 przewodów :010: :021:
Uwzględniając wymagane czasy narastania zbocza sygnału ~ 10 us czy nie obawiacie się zakłóceń, odbić, przerostów itp.
Czas narastania sygnału wyemitowanego przez uC jest ważny. Faktycznie, to powinien być nawet dużo mniejszy niż 10us. Obecnie mam opadanie 19ns, narastanie 20ns. Podłączenie metrowego kabla daje zwiększenie czasów do 24ns. A odbić, sprzężeń, zakłóceń boimy się jak jasna... Taka pajęczyna taktowana kilka KHz moze nieźle siać i doskonale zbiera tętnienia z sieci. Dlatego układ jest mały - aby mógł być blisko urządzeń. Można użyć skrętki do krosowania kabli, ekstremalne rozwiązania to ekranowane przewody :) W matrycy należy stosować diody, co pomoże odciąć część część indukowanych prądów dzięki minimalnemu napięciu przełączenia diody.
Jak rozumiem to nie są pętle prądowe ?
Niestety - rezystory podciągające mają średnio po 35K więc prąd jest tam minimalny pewnie poniżej 0,14mA. W ekstremalnym przypadku można dołożyć do układu zewnętrzne rezystory podciągające, nie mniejsze jednak niż 1K (ok. 5mA). Ale zwiększenie obciążenia prądowego zwiększy wymagania dla filtracji zasilania.
Zauważyłem bardzo dużą oszczędność na dodatkowych elementach pasywnych – ale czy to się nie odbije w końcowym złożeniu wszystkiego w całość ?
EMC nie planuję :) Są pojemności blokujące i dławiki na zasilaniu (prawie) zgodnie z wytycznymi Atmela.
(http://img715.imageshack.us/img715/8233/img4779iu.th.jpg) (http://img715.imageshack.us/i/img4779iu.jpg/)
Czy można gdzieś obejrzeć schemat (może być blokowy) całości ?
Raczej schemat ideowy :) Na bloki trudno to podzielić - za małe.
-
Prześledź kilka wątków na tym forum.Ten wątek jest jednym z wielu.Kokpity są budowane można to sprawdzić np.na forum viperpits.Generalnie zasada jest taka,że robi się projekt modułowy tzn. kilka niezależnych sterowników.W moim przypadku jest ich kilka i dodatkowo są sterowane z różnych programów.Zaleta jest taka,że są krótkie przewody.Damos oparł swój projekt na specjalnym interfejsie odpornym na zakłócenia i zrobiony na 3 przewodach.
Co do zakłóceń to jest to temat sam w sobie ciekawy.Co innego urządzenia w środowisku przemysłowym lub militarnym a co innego w mieszkaniu.Zgadzam się z Tobą,że w środowisku gdzie jest duży pozim zakłóceń trzeba stosować odpowiednie projektowanie oraz zabezpieczenia.Jak zauważyłeś na forum są konstruktorzy amatorzy,dlatego nikt nie wnika zbyt głęboko w te tematy.
Schematy są dostępne na forum OpenCockpits,na stronie Codeking SimOUT,na stronie Nokera jest MJoy oraz na stronie Damosa są założenia nowych sterowników.
-
60 enkoderów to 180 przewodów :010: :021:
Wiem :002: - to asekuracja z mojej strony - być może wymyśliliście jakiś myk ze wspólnym przewodem ?
Raczej schemat ideowy :) Na bloki trudno to podzielić - za małe.
Nie wiedząc czy chcecie udostępniać schemat ideowy - wolałem zapytać tylko o blokowy :002:
Prześledź kilka wątków na tym forum.Ten wątek jest jednym z wielu.Kokpity są budowane można to sprawdzić np.na forum viperpits.Generalnie zasada jest taka,że robi się projekt modułowy tzn. kilka niezależnych sterowników.W moim przypadku jest ich kilka i dodatkowo są sterowane z różnych programów.Zaleta jest taka,że są krótkie przewody.Damos oparł swój projekt na specjalnym interfejsie odpornym na zakłócenia i zrobiony na 3 przewodach.
No to teraz już nic nie rozumiem. Z poprzednich postów "powziąłem domniemanie" że w kokpicie ma być jeden centralny moduł na 70 pokręteł i 80 przycisków :008:
Co do zakłóceń - jak produkt wytrzyma telefon mojej córki leżący w odległości 1 m to będzie OK :001:.
-
Wiem :002: - to asekuracja z mojej strony - być może wymyśliliście jakiś myk ze wspólnym przewodem ?
Nie do zrobienia w matrycy :)
No to teraz już nic nie rozumiem. Z poprzednich postów "powziąłem domniemanie" że w kokpicie ma być jeden centralny moduł na 70 pokręteł i 80 przycisków :008:
To są około-graniczne możliwości jednego modułu z punktu widzenia timingów. Vito_zm myśli o dodatkowych płytkach z osobnym uC (bez USB), które będą się łączyć z "płytą-matką" za pomocą I2C: (ok, sterowanie napięciowe, ale na 2 metry powinno dać radę z odpowiednimi terminatorami)
(http://img841.imageshack.us/img841/7616/img4774w.th.jpg) (http://img841.imageshack.us/i/img4774w.jpg/) (http://img193.imageshack.us/img193/9207/img4786b.th.jpg) (http://img193.imageshack.us/i/img4786b.jpg/)
Jednak nie każdy musi chcieć budować tak złożone układy - wtedy używa bazowej płytki z USB. Wystarczy wgrać jej nowy firmware i zmienia się z emulatora klawiatury (obecnie omawiany) w Joy'a, albo w programator, albo w uniwersalny moduł I/O.
-
No teraz wszystko jasne.
Panowie - nie wiem gdzie jest emotka od bicia pokłonów ale wyobraźcie sobie ze to ta :001:
Wiele razy myślałem o czymś takim - chodzi mi o wielomodułowe rozwiązanie z płytą-matką.
Gdyby powstała analogiczna grupa software'owców o takim zaangażowaniu jak Wasza to można by się pokusić o napisanie własnego symulatora samolotu/okrętu/czołgu itp - ale takiego z najskrytszych marzeń.
Życzę Wam powodzenia i dalszego zapału w pracy - wyniki na pewno będą super.
-
Wiele razy myślałem o czymś takim - chodzi mi o wielomodułowe rozwiązanie z płytą-matką.
Jak widać - nie tylko Ty :)
Gdyby powstała analogiczna grupa software'owców o takim zaangażowaniu jak Wasza
Ale tutaj software to 95% roboty :)
to można by się pokusić o napisanie własnego symulatora samolotu/okrętu/czołgu itp - ale takiego z najskrytszych marzeń.
Myślisz o takim - własnym symulatorze a'la Lock-On? Awykonalne. Na 120% - vide Fighter Ops :118: Zrobienie czegoś takiego to kilka mln $ i kilka lat pracy.
-
Wiele razy myślałem o czymś takim - chodzi mi o wielomodułowe rozwiązanie z płytą-matką
Wiem,że znasz FalconaAF.Ja mam to rozwiązane w następujący sposób.ICP jest sterowane z sterownika o nazwie MJoy,który jest podłączony do pc przez USB.Ten sterownik steruje także HSI.Są to bardzo krótkie połączenia.
Left Aux Console jest sterowany przez inny sterownik także MJoy.
Left Console jest sterowany przez karty OpenCockpits.Tutaj filozofia jest następująca:płyta komunikująca się z pc do której można podłączyć 4 płyty Master.Do każdej Master można podłączyć inne karty w zależności od potrzeb np.karta Display itd.Jest to konfiguracja modułowa z różnymi opcjami.
Right Aux Console jest sterowane przez inny sterownik SimOUT,który zaprojektował Codeking z naszego forum.
Right Console będzie sterowane przez sterownik Damosa,który jest w fazie końcowej projektowania (soft).
MJoye maja swój soft SVMapper,SimOUT pracuje z softem napisanym przez Codeking HSC.Damos tworzy swój soft.Karty OC pracują z SIOC.
Jak widzisz projekt jest dosyć rozbudowany.
Zapomniałem o jeszcze jednym rozwiązaniu hardware tzn.sterownik Skalarki,który także pracuje z córkami i jest widziany przez HSC Codeking.
Jak widzisz jest na naszym forum paru zapaleńców i są już efekty ich pracy.To co robi Damos, Codeking i Skalarki jest bardzo profesjonalne i porównywalne z rozwiązaniami z viperpits.Hardware nie jest problemem problemem jest soft i tutaj są potrzebni doświadczeni programiści znający także uP.
-
Ja znam ARM-y, zwłaszcza z seri AT91SAM7XXX. Drivery pod WinXP też pisałem. Zgłosiłbym się "na ochotnika" ale w najbliższym czasie będę niestety mocno zajęty (mam nadzieję bo z czegoś trzeba żyć).
Jak znajdę więcej wolnego czasu to może pomogę - oczywiście jeśli chcecie.
-
Pomoc jest mile widziana zwłaszcza programistów.Dodam tylko,że jest teraz tendencja do projektowania gotowych paneli tzn.mechanika z sterownikiem jako całość np.Right Console wskaźniki.EGHI zrobił tańsze rozwiązanie oparte na sterowniku z OpenCockpits http://www.f16pit.dbv.pl/news.php
Teraz myślimy o zastosowaniu silników krokowych,ale musimy poczekać na soft Codeking.Reasumując mamy ambicję zrobić polską wersję hardware oraz softu dla symulatorów.Jest to możliwe dzięki zaangażowaniu Codeking oraz Damosa,którzy robią to za free.Pozostali koledzy próbują im pomóc w miarę swoich możliwości.
-
Witam,
robię prosty tester do sprawdzania konfigurowania DMKeys.Dwa sznury 34 pin łączą sterownik z płytką,która jest rozdzielaczem sygnałów.Mam do dyspozycji tzw."handheld" czyli moją starą pomocniczą klawiaturę z wyjściem na DB9.Dołożę jeszcze enkoder i przełączniki 3 pozycyjne.
(http://img291.imageshack.us/img291/1286/mtester.jpg) (http://img291.imageshack.us/i/mtester.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Po wykonaniu testów płytkę przerobię na rozdzielacz dla mojego kokpitu.
-
Mam pytanie do Damosa.Wiem,że kończysz soft do konfiguracji DMKeys,dlatego pytanie.Czy jest możliwość konfigurowania "makroinstrukcji"?
Wyjaśnię na przykładzie.W Falconie jest dużo komend związanych z komunikacją radiową.Np.wywołujemy AWACS (dokładnie stronę pierwszą) klawiszem Q.Na tej stronie mamy 9 możliwości wyboru komendy (klawisz 1 do 9).Możemy wybrać stronę drugą naciskając dwa razy klawisz Q.Na stonie drugiej mamy 7 możliwych komend.
Oczywiście nie ma sensu robić makroinstukcji dla wszystkich kombinacji ale można je zrobic dla kilku,które są często powtarzane.
Teraz konkretne pytanie czy jest możliwość przypisania do klawisza takiej sekwencji : Q -> Q -> 4.
W profilu Jagnstanga dla Cougara są makroinstrukcje w Foxy dla 4 komend radiowych,króre są przypisane do jednego przełącznika 4 poz.(hat).
Pytanie traktuję jako ciekawostkę,ponieważ w SIOC nie doczytalem czy to jest możliwe,ale może czytałem niedokładnie.
-
Tak, pod każdy event można przypisać sekwencję maksymalnie 15 akcji z których każda może mieć maksymalnie 6 równocześnie wciśniętych przycisków + osiem przycisków specjalnych (alt, ctrl, shift itp.) jest to ograniczenie protokołu klawiatury HID na USB.
Więc w wariancie prostszym - można zbudować sekwencję 15 przycisków naciskanych jeden po drugim wraz z modyfikatorami typu alt, ctrl.
W wariancie bardziej złożonym - można spowodować wysłanie maksymalnie (6+8)x15=210 klawiszy w wyniku zmiany stanu jednego przełącznika.
Z powodu ograniczeń pamięciowych uC nie ma supportu dla opóźnień czasowych między kolejnymi klawiszami.
-
Super,to daje duże mozliwości.Do tej pory nie mialem takiej potrzeby.Teraz chcę zrobić małą klawiaturę pomocniczą,która będzie odpowiedzialna za komunikację radiową.Tak jak wspomniałem są komunikaty,którę się często powtarzają i wymagają wyboru strony oraz pozycji czyli 3 lub 4 zdarzenia.Mam nadzieję,że opóźnienia nie będą krytyczne sprawdzę to w testach.
-
Mam dobrą wiadomość dla czekających na nowy sterownik DMKeys. Prawdopodobnie będę go testował na początku czerwca. Damos jest bardzo zajęty pracą, dlatego realizacja projektu trochę się przedłużyła. Przy okazji pytanie dotyczące konstrukcji mechanicznej. Ostatnio przerabiałem klawiaturę 3x4 oraz 4x4 pod swoje potrzeby. Jest o tym tutaj http://www.il2forum.pl/index.php/topic,9985.450.html wiadomość #455.
Z zakupionej klawiatury potrzebowałem tylko przyciski i obudowę, pozostałe elementy zrobiłem sam lub kupiłem. Klawiatura kosztuje 24 zł, pozostałe elementy nie są tak drogie. Myślę teraz o własnej konstrukcji klawiszy oraz obudowy pod te klawisze. Jest to związane z projektem DMKeys, który może strować dosyć dużą matrycą. Gdyby zaprojektować matryce córki np. 8x8, 4x3 lub inne z których można składać matrycę matkę pod swoje potrzeby w symulatorach. Przyciski są dostępne na rynku i mają zróżnicowane wysokości dla klawiszy. Przyciski sprężynują i dla matryc np.4x4 nie potrzeba dodatkowych sprężyn "powrotnych" dla klawiszy. Pozostaje problem klawiszy oraz ich osadzenia. Z czego zrobić, czym to wykonać i cena. Może ktoś ma pomysł lub to już zrealizował. Zapraszam do dyskusji. Jeśli będzie zainteresowanie tym tematem to można założyć nowy wątek.
-
Czym wykonać? Najlepiej zbudować najpierw frezarkę cnc :-)
-
Znajomy z viperpits buduje frezarkę.
http://www.viperpits.org/smf/index.php?topic=6545.msg89942#msg89942
Jest to możliwe, ale wymaga czasu. Można zrobić rysunek klawisza i próbować to wykonać z pleksi. Być może dla większej ilości takich klawiszy cena ich wykonania nie byłaby tak duża. Można kupić klawisze wciskane do specjalnych przycisków montowanych do druku, ale jest problem z umieszczeniem płyty maskującej z opisami.
(http://img28.imageshack.us/img28/3682/mklawisze.jpg) (http://img28.imageshack.us/i/mklawisze.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Na tym zdjęciu u góry jest przykład zastosowania tych klawiszy. Na dole są zwykłe przyciski przykręcane do płyty maskującej. Temat nie jest całkiem trywialny, ja stosuję różne techniki z dostępnych na rynku przycisków oraz klawiszy, ale pomyślałem o bardziej profesjonalnym wykonaniu. Większość z nas ma jakiej urządzenia wspomagające symulatory i jakąś klawiaturę, dlatego temat może być na czasie.
-
Jest całe polskie forum poświęcone cnc. Czytałem trochę na ten temat. Koszt budowy to około 2000pln. Można kupić czasem proste urządzenia tego typu na allegro - w podobnej cenie - ale raczej to tandeta, albo niepewna samoróbka.
Co do przycisków. Ja, jeśli bym musiał to zrobiłbym tak, jak narysowałem poniżej. Górna warstwa przycisku (najpewniej dałbym do wygrawerowania) to mniejszy kwadrat pasujący w otwór panelu. Dolna większy kwadrat, przyklejony do pierwszego elementu. <- przycisk nie wypadnie na zewnątrz. Od dołu trzymałby go mikroprzełącznik na pcb - nie wpadłby do środka. Jeśli plexa byłaby wystarczająco gruba, można by w przycisku diodę umieścić.
(http://images37.fotosik.pl/816/47b842bc8b934cfdm.jpg) (http://www.fotosik.pl/showFullSize.php?id=47b842bc8b934cfd)
A tutaj jest ciekawy pomysł na przyciski. Przewiń na środek strony. http://www.737ngproject.be/mip.htm
-
Pomysł dobry, gorzej z realizacją. Na tej stronie jest ciekawe rozwiązanie, ja coś podobnego mam u siebie w miejscach gdzie są potrzebne przyciski oraz podświetlenia napisów. W niektórych przyciskach mam 3 napisy i 2 sterowane diody (alarmy). Myśląc o klawiaturze miałem na myśli coś uniwersalnego np.16x16 oraz podobne matryce trochę pod testy DMKeys i jego późniejsze zastosowanie.
-
Też mam pewien pomysł na realizacje przycisku, tym razem do MCP od 737. Mam nadzieje, że moje przyciski będą gotowe w ciągu tygodnia dwóch / wizyty u grawera /. Żeby długo nie opisywać - wszystko jest w tym pliku PDF - ftp://zajac.homeftp.net/projekt_przycisku.pdf (ftp://zajac.homeftp.net/projekt_przycisku.pdf). Wszystko później ładnie sklejone i pomalowane dookoła na czarno. Oczywiście jeżeli jest potrzebne tylko podświetlenie przycisku a nie osobne świecenie rożnych elementów to nie trzeba środkowej części robić w dwóch elementach i dokładać podziału w środek.
pozdrawiam Zając
-
Moje zrealizowane projekty dla kokpitu na dwóch pierwszych zdjęciach.
(http://img27.imageshack.us/img27/811/41121674.jpg) (http://img27.imageshack.us/i/41121674.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
(http://img812.imageshack.us/img812/4118/33063626.jpg) (http://img812.imageshack.us/i/33063626.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
(http://img402.imageshack.us/img402/8552/31079517.jpg) (http://img402.imageshack.us/i/31079517.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Na ostatnim zdjęciu jest rozebrany przycisk z wyświetlaniem stosowany w realnych kokpitach. Chciałem go zastosować u siebie, ale w końcu zrobiłem własne.
-
A pytanko do zając'ka. Czy przyklejasz przycisk do mikroswicha? Czy jest na wcisk? Chodzi mi o zabezpieczenie przed wypadnięciem.
-
Stosuję obie metody w zależności jakie mam dostępne przyciski. Są przyciski z profilem dla specjalnych wciskanych klawiszy, ale odległość od klawisza i obudowy przycisku jest mała i trudno tam umieścić płytę z opisami.
-
A pytanko do zając'ka. Czy przyklejasz przycisk do mikroswicha? Czy jest na wcisk? Chodzi mi o zabezpieczenie przed wypadnięciem.
Cześć
Nie przyklejam tylko wciskam - wchodzi na głębokość około 4 mm i się bardzo stabilnie trzyma / sprawdzone doświadczalnie /. Cały pomysł zaczerpnąłem z tej strony http://home.hccnet.nl/jwopdenakker/building%20tip.html (http://home.hccnet.nl/jwopdenakker/building%20tip.html) tylko troche go zmodyfikowałem pod swoje potrzeby.
pozdrawiam Zając
-
Panowie, w związku z tematem wątku i bliską finalizacją DMKeys8 potrzebuję ochotnika do testów programu na PC.
Wymagania: doświadczenie z MJoyem i SVmapperem, czynne i często używane konto na Skype, obycie z komputerem (wiedza, co to jest "input focus" wskazana :) ).
-
Jestem do dyspozycji.
-
W takim razie vito_zm i Sundowner dostaną dziś paczki softu do testów.
-
Jestem pod wrażeniem testując program konfiguracyjny DMKeys. Chciałbym przedstawić swoje uwagi. Damos zrobił dla nas testujących jego program 13 stronicową instrukcję z obrazkami. Zrobił to bardzo profesjonalnie. Program do koniguracji sterownika jest tak zrobiony, że sygnalizuje błędy konfigurującego, tzn. jest "głupio odporny" co jest jedną z jego zalet. Nie będę omawiał jego konstrukcji, ponieważ będzie to na stonie Damosa. Wspomnę tylko, że ten program przypomina trochę inne programy np. Foxy's Open Falcon.key File Analizer, gdzie jest podgląd przypisań klawiatury do tzw. callbacks. Ma pewne elementy podobne do SVMapper tzn. wybierając manualnie klawisze widzimy je na ekranie. Jeśli chodzi o test hardware to wizualnie będzie trochę przypominał jeden z testów Cougara tzn. sekwencje będą widziane w przypadku DMKeys w notatniku. Tyle ogólnych uwag. Teraz chciałbym zasugerować Zającowi zrobienie płyty współpracującej z DMJoy. Celowo napisałem DMJoy, ponieważ widzę uniwersalność tej opcji. DMJoy to wersja small matrix DMKeys z dodatkowymi wejściami analogowymi. Ta opcja ma matrycę o wymiarze 96 oraz 6 wejść analogowych. Można pomysleć o grupowaniu wejść matrycy i podłączeniu do mniejszych łączówek tak jak w simIN. Ja przygotowałem sobie dla testów coś podobnego jak na zdjęciu.
(http://img819.imageshack.us/img819/9955/testere.jpg) (http://imageshack.us/photo/my-images/819/testere.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
-
Damos zrobił dla nas testujących jego program 13 stronicową instrukcję z obrazkami.
Prymitywna i niechlujna, ale nie miałem zbyt dużo czasu.
Panowie - dziękuję za pomoc w testach.Vito_zm, Sundowner i Viker znaleźli błędy, które mi umknęły.
Viker miał najwięcej uwag, choć Vito_zm znalazł najpoważniejszego "buga".
Wasza pomoc jest bardzo cenna a przesyłane uwagi wpłyną na finalny wygląd i działanie aplikacji :010: :023:
-
Wracam do pomysłu zrobienia płytki rozdzielacza sygnałów dla DMKeys lub raczej DMJoy. Ten ostatni ma 2 łączówki 34pin i realizuje matrycę o wymiarze 96 (8 kolumn x 12 wierszy) oraz 6 wyjść analogowych. Stosując łączówki 10 pin można zrealizować matrycę na 6 łączówkach wyprowadzając na każdą 8 kolumn oraz 2 kolejne wiersze co daje 8 x 2 x 6 = 96. Analogi można wyprowadzić na łączówkach 3 pin dla przykręcanych przewodów. Diody byłyby umieszczane w pobliżu układów wykonawczych.
Podobnie można zrobić płytę przejściową dla wersji big stosując np. 5 łączówek 10 pin oraz 5 łączówek 8 pin.
-
I tak i nie.
Osobiście nie jestem entuzjastą płytek rozdzielczych ani samego rozwiązania Key Matrix (potworna ilość diod, duży koszt płytki ze względu na wielkość, masa kabli jeśli płytka jest daleko od przełączników).
Pozwólcie, że zademonstruję na przykładzie.
Wariant 1: płytka kontrolera podłączona do płytki key-matrix. Od niej rozprowadzone przewody do przycisków na odległych panelach:
(http://img266.imageshack.us/img266/5751/matrixvsinplacev2stage1.th.png) (http://imageshack.us/photo/my-images/266/matrixvsinplacev2stage1.png/)
Musimy tam poprowadzić 18 przewodów aby podłączyć 9 klawiszy. W sumie - ilość przewodów = ilość_klawiszy * 2
Wariant 2: diody montowane są bezpośrednio do przycisków i przełączników. Minimalna ilość przewodów doprowadzona do panelu i tam rozprowadzona z wielokrotnym wykorzystaniem każdego z przewodów:
(http://img600.imageshack.us/img600/8814/matrixvsinplacestage3.th.png) (http://imageshack.us/photo/my-images/600/matrixvsinplacestage3.png/)
Do obsługi 9-ciu przycisków wystarczy tylko 6 przewodów. Przy większej ilości stosunek jest jeszcze lepszy (8 kabli dla 16-tu przycisków, 10 dla 25-ciu itd). Co więcej - możne poprowadzić kaskadowo wszystkie 26 przewodów od panelu do panelu i tam się dołączać w miarę potrzeby - wtedy da się znacznie zredukować ilość okablowania.
Oczywiście - płytka rozdzielcza pozwala utrzymać większy porządek itp. itd.
-
Masz rację, ja też o tym myślałem. Jest jeden problem do rozwiązania. Na DMKey są 2 rzędy pinów, gdzie zewnętrze są prawie wszystkie gnd (plus opcja zasilania). My potrzebujemy dla matrycy small tylko 20 przewodów dla big 26 przewodów, ale trzeba je jakoś wyprowadzić dlatego pomyślałem o zwykłej płycie spełniającej krosowanie połączeń tzn. przejście z 34x2 pinów na 20 lub 26 pinów oczywiście bez diod. Teraz można zrobić tak jak sugerujesz tzn. kaskada na przewodach tak jak w połączeniach komputerowych (wpięte w przewody łączówki) lub kaskada na płytkach, które są w pobliżu układów wykonawczych.
Dalsza redukcja przewodów polega na odpowiednim grupowaniu sygnałów tak jak w Twoim przykładzie. Ja tak zrobiłem realizując w starym rozwiązaniu przyciski (20 przycisków) przy MFD za pomocą kilku przewodów (diody były przy ramkach MFD).
-
Panowie, potrzebuję do testów enkoder 1:4. Wie ktoś, gdzie taki można dostać?
-
damos,
sprawdź tutaj: http://www.opencockpits.com/catalog/encoder-with-pushbutton-p-100.html?cPath=24
-
Z tym jest zawsze problem. W sklepie sprzedawca nie wie jaki posiada. W internecie w danych tego parametru nie można znaleźć. Ja jeszcze w swojej praktyce nie miałem takiego enkodera. Może ten jest 1:4
http://www.tme.eu/html/PL/mechaniczne-enkodery/ramka_2266_PL_pelny.html
-
Właśnie przeprowadziłem pierwsze udane testy całości DMKeys8:
konfiguracja pinów i klawiszy za pomocą oprogramowania po stronie PC a następnie używanie zaprogramowanych przycisków. Dość przyjemna chwila :)
Jeszcze kilka dni i będzie można rozpocząć poważne testy software+hardware.
-
Działają już:
przyciski zwykłe,
przyciski bistabilne,
enkodery 1:1 ze stałą prędkością,
enkodery 1:1 ze zmienną prędkością - sterowanie przyciskiem monostabilnym
enkodery 1:1 ze zmienną prędkością - sterowanie przyciskiem bistabilnym
enkodery 1:2 ze stałą prędkością,
enkodery 1:2 ze zmienną prędkością - sterowanie przyciskiem monostabilnym
enkodery 1:2 ze zmienną prędkością - sterowanie przyciskiem bistabilnym
Teoretycznie układ może obsłużyć do 160 przycisków lub 80-ciu enkoderów, ale jakie to będą liczby w praktyce - zobaczymy :) Testowałem jak na razie 27 enkoderów na raz - wszystko działa (niemal) zgodnie z oczekiwaniami. Na jednym układzie miałem problem z zakłóceniami.
-
Gratulacje, czekam na soft, hardware już przygotowane. Po testach softu po stronie pc mogę stwierdzić, że jest to profesjonalnie zrobiony program. Jego główną cechą jest łatwość obsługi powiem więcej jest "głupio odporny" tzn. jeśli coś żle zrobisz to zostanie to wykryte, pojawi się odpowiednia uwaga oraz blokada tego działania. Można dopisywać komentarze do przypisań pinów. Jest to bardzo cenne ponieważ można opisać np. kolory przewodów, drogę połączeń itp. Programowanie uP jest bardzo proste , stosujemy program FLIP, płytka jest połączona przez USB nie potrzeba LPT. Jest możliwość programowanego zerowania uP. Program wykrywa inne urządzenia podłączone do USB. Zapomniałem o najważniejszym, można programowo usunąć efekt drgania styków w stanach nieustalonych. To te najważniejsze cechy programu, które zapamiętałem. Program jest w wersji angielskiej co nie stanowi problemu, ponieważ na stronie Damosa są instrukcje w obu językach. Dzięki temu program ma szansę przebić się na szersze wody.
-
Kurde chłopaki :002: Czytam wasze wpisy w wypiekami na mordzie. Ja wypadłem na jakiś czas z obiegu ale powoli wracam do "żywych". Nie ma co, Magicy z Was pierwsza klasa. Gratulacje!
-
Do mnie wczoraj przyszedł w końcu Cougar, na nim będę prowadził rozwój projektów bo jego konstrukcja daje pewne dość ciekawe możliwości i z tym joyem można zrobić na prawdę ciekawe rzeczy przez wymianę poszczególnych komponentów. Elektronika też będzie wymieniona na DMjoy'a tylko z tym trzeba poczekać na poszczególne wersje :)
Na chwilę obecną priorytety to usprawnienie mechaniki (oś przepustnicy, centrowanie joy'a) i sensorów.
-
Mnie jednak martwią zakłócenia, których doświadczyłem w nocy z jedną z płytek. Po włączeniu i trzymaniu wciśniętego jednego z przycisków dotknięcie palcem nie podłączonych nigdzie pinów płytki (tych podciągniętych do 1-ki logicznej ) powodowało generację ciągu impulsów. Wskazuje to na jedną z kilku możliwych przyczyn:
- silne sprzężenie
- zbyt duży wydatek prądowy przy zwieraniu przycisku
- zbyt słabe wewnętrzne rezystory podciągające
Co więcej - występowało to tylko w przypadku jednej płytki (!), co sugeruje punkt 3. Słyszałem już opinie o słabej jakości wewnętrznych rezystorów podciągających. W tym przypadku trzeba będzie podłączyć 16 (BIG_MATRIX) lub 8(SMALL_MATRIX) zewnętrznych rezystorów. Z jednej strony jest to irytujące, ale z drugiej - znamy na to proste lekarstwo. Gdyby to były sprzężenia między ścieżkami - sprawa stawała by się dużo bardziej skomplikowana.
-
Damos jeśli jedna płytka jest podejrzana tak jak sugerujesz to podłącz pająka z rezystorami i zobacz czy to coś zmieni. Ponieważ te zew. będą równoległe do tych wew. to mam nadzieję, że te wew. mają za duże wartości, jeśli odwrotnie to mamy problem. Zobaczymy jak będzie u mnie.
-
Jestem już po wstępnych testach DMKeys. Na zdjęciu jest pokazany DMKeys, płyta przejściowa oraz matryca 5x3.
(http://img39.imageshack.us/img39/7816/test2l.jpg) (http://imageshack.us/photo/my-images/39/test2l.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Teraz przewiduję testy z inną matrycą, gdzie diody są umieszczone na matrycy.Kolejne testy to enkodery.
-
Gratulacje! Nie obyło się bez pewnych problemów, jednak udało się je pokonać.
Testy drugiej matrycy powinny przejść bez problemów. Ciekaw jestem testów enkoderów. Raczej nie uda się przetestować wszystkich możliwych (80) jednak dobrze było by podłączyć przynajmniej 20 lub 30... :)
Wygląda na to, że całość zaczyna pracować tak, jak tego oczekujemy :)
-
Kolejna matryca sprawdzona. Ma inną organizację 5 kolumn oraz 4 wiersze. Jest tak zaprogramowana, że naciskając jakiś przycisk wysłana jest sekwencja znaków opisująca która kolumna, wiersz oraz położenie w mapie matrycy. Jest to pokazane na załączonym zdjęciu.
(http://img832.imageshack.us/img832/5599/tester1d.jpg) (http://imageshack.us/photo/my-images/832/tester1d.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
W czasie testów Damos zrobił kolejne mody do swojego programu. Jest teraz dodana opcja run test. Na zdjęciu widać także ile jest potrzebnej pamięci dla tego przykładu.
-
Jako, że testy DMKeys idą całkiem sprawnie a prace zbliżają się ku końcowi czas zastanowić się nad funkcjonalnością kolejnej rzeczy: DMJoy.
Bogatszy o nieco doświadczeń z developmentu i zaznajomiony z oczekiwaniami co niektórych użytkowników mam pewną wizję tego urządzenia.
Chciałbym tu podyskutować o ewentualnych nie przewidzianych jeszcze właściwościach.
Ogólne założenia dla pierwszej wersji:
- płytka ta sama, co DMKeys8
- brak wymogu posiadania sterowników dla normalnej pracy (po skonfigurowaniu)
- obsługa 6-osi osi analogowych (z przyciskami trymerów na każdą oś)
- obsługa do 96 przycisków Joysticka (widziane w systemie jak zwykłe przyciski Joysticka: "JoyButton")
- obsługa do 48 enkoderów
- obsługa do 96 przycisków "KeyMapped", którym można przypisać klawisze klawiatury (tak, jak w DMKeys8 ; inaczej mówiąc - zintegrowany SVmapper)
Osie analogowe: są konfigurowalne - użytkownik ustala, do których pinów podłącza potencjometry i ile ich podłączył.
Trymowanie każdej osi: to pomysł Sundownera. Polega to na wychyleniu osi w pewne miejsce, wciśnięciu przycisku ustawiania trymu i od tego momentu ta oś przesunie swoje "0" w miejsce, w którym się aktualnie znajduje. Innym przyciskiem można takie ustawienie skasować.
Przyciski "JoyButton": to przyciski widziane przez grę jako zwykłe przyciski Joysticka. Program konfiguracyjny pozwala skonfigurować - które przyciski fizyczne pracują jako które przyciski Joysticka.
Przyciski "KeyMapped": to przyciski rodem z DMKeys - pod wciśnięcie lub zwolnienie każdego można przypisać jakąś sekwencję klawiszy.
Enkodery - każdy wie :)
Jeśli ktoś ma sugestie lub potrzeby - zapraszam do ekspresji :)
-
Damos, czy 6 osi to maksimum dla tego układu? Jeśli nie, to mogłoby być 8 osi jak w MJoy'u.
Dla osi można by zrobić coś takiego, żeby móc przypisać konkretną wartość w określonym położeniu.
Mogłoby to być przydatne m.in w przepustnicach z zapadkami, ale też do ustawienia zakresów potencjometrów bo zamiast obracać o 270o wystarczyłoby przypisać 100% dla np. 90o
-
Damos, czy 6 osi to maksimum dla tego układu? Jeśli nie, to mogłoby być 8 osi jak w MJoy'u.
Mogę dać 8 osi, wtedy ilość maksymalna przycisków spadnie z 96 do 80 (64 w przypadku wykorzystywania trymerów).
Dla osi można by zrobić coś takiego, żeby móc przypisać konkretną wartość w określonym położeniu.
Mogłoby to być przydatne m.in w przepustnicach z zapadkami, ale też do ustawienia zakresów potencjometrów bo zamiast obracać o 270st wystarczyłoby przypisać 100% dla np. 90st
Możesz to nieco przybliżyć?
-
Vikerowi chodzi o to o czym Tobie kiedyś wspominałem - czyli ustawieniu funkcji według której wartość wejścia jest modyfikowana do uzyskania odpowiedniej wartości wyjścia. W gruncie rzeczy przy zintegrowaniu trymu coś takiego też można by od razu dorzucić, z jednym zapewne zastrzeżeniem - zasobożernością.
8 osi i mniej przycisków dla DMjoy to lepsze rozwiązanie, idealnie gdyby można było sobie zdefiniować ilość jednych i drugich.
-
Nie znam się zbyt dobrze na stosowaniu analogów, dlatego mam zaufanie do Sundownera. Mogę tylko wyrazić opinię na temat pozostałych elementów DMJoya. Po pierwsze DMKeys spełnia wymagania dotyczące przycisków, przełączników oraz enkoderów. Ma nowe możliwości w porównaniu do MJoya. To co ograniczało liczbę enkoderów oraz przełączników tutaj nie istnieje. Następna cecha, która wyróżnia ten program oraz sterownik to definiowanie przełączników z pozycji programowania klawiatury. Można było zwiększyć liczę przełączników w MJoy, ale pisząc skrypt w HSC, tutaj tego nie ma.
Reasumując ponieważ DMKeys realizuje potrzebne funkcje to można w DMJoy skupić się na pozostałych potrzebnych funkcjach. Jeszcze jedna uwaga, nie ma ograniczenia na liczbę DMKeys oraz DMJoy zastosowaną w panelach. Sterowniki nie są drogie i są bardzo małe. Tyle moich wstępnych uwag.
-
8 osi i mniej przycisków dla DMjoy to lepsze rozwiązanie, idealnie gdyby można było sobie zdefiniować ilość jednych i drugich.
Reasumując ponieważ DMKeys realizuje potrzebne funkcje to można w DMJoy skupić się na pozostałych potrzebnych funkcjach.
Zgadzam się z przedmówcami :002: DMJoy raczej powinien skupiać się na osiach, w razie czego zawsze jest DMKeys.
Moja poprzednia sugestia dotyczyła tego, by można było w określonym położeniu ustawić wartość wyjściową. Przykład: Wychylając oś o 20o chciałbym aby w tym położeniu miała 40% wartości maksymalnego wychylenia, gdzie normalnie bez przypisania miałaby np. 30 %.
-
Zgadzam się z przedmówcami :002: DMJoy raczej powinien skupiać się na osiach, w razie czego zawsze jest DMKeys.
Rozumiem :) To nawet ułatwia mi zadanie, choć Sundowner oczekiwał DMKeys i DMJoy w jednym :)
Moja poprzednia sugestia dotyczyła tego, by można było w określonym położeniu ustawić wartość wyjściową. Przykład: Wychylając oś o 20o chciałbym aby w tym położeniu miała 40% wartości maksymalnego wychylenia, gdzie normalnie bez przypisania miałaby np. 30 %.
Chodzi więc o interpolację liniową dla 3 punktów z clampowaniem danych przy przekroczeniu zakresu?
Jak na obrazku:
(http://img197.imageshack.us/img197/3213/potsc.png) (http://imageshack.us/photo/my-images/197/potsc.png/)
Oczywiście - wiąże się to z utratą rozdzielczości osi analogowej, szczególnie w obszarze między czerwoną a żółtą kreską. Jeśli normalnie dla zakresu zakresu mamy 1024 punkty, od 50% do 100% mamy 512 punktów to w tym układzie dla PC zakres 50% do 100% będzie miał ich jedynie 256 a zakres 0%-50% jakieś 400 punktów. W sumie cała oś redukuje się do ok. 700 różnych wartości.
jednak - oczywiście jest to do zrobienia.
-
Oczywiście - wiąże się to z utratą rozdzielczości osi analogowej,
To nie ma sensu mam na myśli utratę rozdzielczości.
-
To nawet ułatwia mi zadanie, choć Sundowner oczekiwał DMKeys i DMJoy w jednym
Chciałbym rozwinąć tę myśl. DMKey lub DMJoy ma ograniczenia wynikające z możliwości uP. Na zdjęciu w moim post widać wyraźnie ile pamięci potrzebuje ten projekt (zielony pasek z lewej strony, jest to 98%). Jest to mała matryca 5x4, ale ma dużo przypisań klawiaturowych, średnio 15 na przycisk. Dla ostatnich pozycji musiałem zmiejszyć liczbę przypisać dla przycisków. Jaki z tego wniosek, musimy rozsądnie gospodarować zasobami i do tego program Damosa jest bardzo dobry.
W moim kokpicie mam 2 MJoye, sinIN oraz zestaw z OC. Musimy założyć, że DMKeys oraz DMJoy będą realizowały tylko część zadań w kokpicie. Ja myślę, czy nie próbować zastosować DMJoy tylko do sterowania np. jakiegoś protoptypu drążek, przepustnica.
Reasumując sterowniki Damosa są uniwersalne, łatwe do programowania, ale mają ograniczenia związane z pamięcią uP.
Jeszcze jedna sprawa związana z DMJoy. Porównujemy go z MJoy w sensie możliwości ilość wejść analogowych, przycisków, przełączników, enkoderów. W sensie ilościowym to może te dwa sterowniki będą podobne, ale w sensie jakości rozwiązania oraz elastyczności konfiguracji przewaga DMJoy jest zdecydowana.
Porównując te dwa sterowniki przypomniałem sobie o tzw. hat. Czy w DMjoy ma sens to zrealizować?
-
Oczywiście - wiąże się to z utratą rozdzielczości osi analogowej, szczególnie w obszarze między czerwoną a żółtą kreską. Jeśli normalnie dla zakresu zakresu mamy 1024 punkty, od 50% do 100% mamy 512 punktów to w tym układzie dla PC zakres 50% do 100% będzie miał ich jedynie 256 a zakres 0%-50% jakieś 400 punktów. W sumie cała oś redukuje się do ok. 700 różnych wartości.
Tak jak rozmawialiśmy o trymie - utrata sumarycznej ilości wartości wcale nie musi nastąpić, jeżeli zakres wartości na wyjściu będzie większy niż na wejściu. Konkretnie - jeżeli mamy dajmy na to 10bit ADC w układzie, a układ do Direct input wysyła wartość 16 bit, to mamy spore pole do wykorzystania.
[edit]
Ups, mój błąd, faktycznie będzie, bo przecież w tym co chce Viker nie jest wykorzystywany cały zakres wartości wejścia.
-
Tak jak rozmawialiśmy o trymie - utrata sumarycznej ilości wartości wcale nie musi nastąpić, jeżeli zakres wartości na wyjściu będzie większy niż na wejściu. Konkretnie - jeżeli mamy dajmy na to 10bit ADC w układzie, a układ do Direct input wysyła wartość 16 bit, to mamy spore pole do wykorzystania.
Sun - my jednak rozmawialiśmy jedynie o trymowaniu - wtedy możemy tak zrobić. O tym z resztą napisałem wspominając o przyciskach trymujących.
Jednak "żeby móc przypisać konkretną wartość w określonym położeniu" więc minimum, centrum, maximum - wtedy się nie da bez utraty jakości.
Jednak Viker chciał, żeby przepustnica w położeniu 30% wskazywała 40% i jednocześnie mogła dojść do 0% i do 100% przy maksymalnych wychyleniach.
W rozwiązaniu, o którym rozmawialiśmy nigdy nie osiągniesz w skrajnych położeniach 0% oraz 100%
[edit]
Skoro już się dogadaliśmy to może poruszymy sprawę hat'a ?
Potrzebny, czy nie ?
[edit2]
ma dużo przypisań klawiaturowych, średnio 15 na przycisk.
:) tam, gdzie masz długie przypisania - masz po 17 klawiszy na kontrolkę :) Normalnie przypisuje się 1 klawisz + modyfikator typu Prawy lub lewy ALT, prawy lub lewy CTRL, prawy lub lewy Shift. Taki zestaw zajmuje 5 bajtów, układ obsłuży ich 160 a kombinacji na klawiaturze jest wtedy ok 600.
-
Jak dla mnie potrzebny, ale gdzie z nim dokładnie leży problem ?
Rozumiem :) To nawet ułatwia mi zadanie, choć Sundowner oczekiwał DMKeys i DMJoy w jednym :)
O co mi konkretnie chodziło to możliwość by przyciski np. joysticka mogły z miejsca również być widoczne jako naciśniecie przycisku klawiatury, normalnie, lub w trybie "alernatywnym" pracy.
Przykład: W joysticku Hat w trybie normalnym jest widziany jako hat kontrolera gier, ale po wciśnięciu zdefiniowanego innego przycisku służącego jako'shift' operując hatem wysyłamy wciśnięcia klawiszy kierunkowych klawiatury (np. operując trymem w simie). Zważywszy, że taka funkcja będzie wykorzystywana tylko w wypadku kontrolerów lotu, nie będziemy mieć specjalnie dużej ilości kombinacji, a oprogramowanie ładnie pokazuje ile jeszcze możemy z kości wycisnąć.
Dla przykładu, jeżeli ktoś sobie zrobi drążek - replikę z AH-64D, to będzie miał dwie analogowe osie + funkcje trymu do nich, 22 przyciski (n), oraz opcjonalnie ich funkcję alternatywną (n-1). Z kolei w wypadku dźwigni skoku ogólnego tej maszyny mamy 3 osie, bez udziwnień, 36 przycisków i ich opcjonalną funkcję alternatywną.
To są dwa najgorsze scenariusze, nie ma bardziej skomplikowanych sterów :)
-
Jak dla mnie potrzebny, ale gdzie z nim dokładnie leży problem ?
Problemu nie ma, zapytałem tylko z ciekawości.
Zważywszy, że taka funkcja będzie wykorzystywana tylko w wypadku kontrolerów lotu, nie będziemy mieć specjalnie dużej ilości kombinacji, a oprogramowanie ładnie pokazuje ile jeszcze możemy z kości wycisnąć.
To miałem na myśli pisząc o ograniczeniach. Jeśli nie ma dużo kombinacji to rośnie liczba przycisków.
W zasadzie jest tylko jeden problem ile faktycznie potrzeba wejść analogowych przy założeniu, że chcemy zrealizować jakąś replikę np.AH-64D lub Cougara.
-
Przy założeniu, że stosujemy jeden układ na kontroler, to w najgorszym wypadku mamy do czynienia z 5 osiami analogowymi w wypadku samych drągów. Problemem są natomiast wajchy silników, jeżeli by np ktoś chciał wykonać sobie 'throttle quadrant' Convair B-36, to osi analogowych jest tam... 40 :021: Ale to taki ekstremalny przypadek. W wypadku współczesnego lotnictwa 8 osi pozwoli na wykonanie 'throttle quadrant' dwu-silnikowej maszyny maszyny bojowej, wraz z funkcją klap i dwoma trymerami, bądź 4 silnikowego transportowca/bombowca. W wypadku maszyny drugo-wojennej możemy również zrobić maszynę dwusilnikową, jak np. P-38 Lighting, ale już bez funkcji innych niż bezpośrednio dotyczących pracy silników.
-
To wtedy dokładamy drugą płytkę i przybywa kilka kolejnych osi. To samo w przypadku braku przycisków.
-
Jednak Viker chciał, żeby przepustnica w położeniu 30% wskazywała 40% i jednocześnie mogła dojść do 0% i do 100% przy maksymalnych wychyleniach.
Nie chciał, tylko sugerował :003:
-
W joysticku Hat w trybie normalnym jest widziany jako hat kontrolera gier, ale po wciśnięciu zdefiniowanego innego przycisku służącego jako'shift' operując hatem wysyłamy wciśnięcia klawiszy kierunkowych klawiatury (np. operując trymem w simie).
Chciałbym nawiązać do tego cytatu. Jeśli planujemy zrobić jakąś replikę joysticka to taki wyróżniony przycisk nazywany "shift" w Cougar jest to S3, który modyfikuje działanie np. hata lub innego przycisku jest niezbędny. W DMKeys taki przycisk jest już zastosowany przy modyfikacji enkodera. Myślę, że wariant monostabilny byłby odpowiedni.
-
Można coś takiego zrobić, jednak w przypadku enkodera mamy do czynienia z osobnym (indywidualnym) przyciskiem na każdy enkoder. Tu oczekujemy jednego, wspólnego przycisku na cały joystick - prawda?
-
T
u oczekujemy jednego, wspólnego przycisku na cały joystick - prawda?
Myślę, że możemy uprościć tę funkcję do hata. Przy okazji pytanie czy jest dużym problemem zrobienie opcji dla hat, mam na myśli program. Jeśli nie ma problemu z hatem to może przewidzieć 2 lub 3 haty, co o tym myślicie?
-
Hat nie jest dużym problemem.
Jedynie raport HID jest jest u mnie statyczny (nie można zmieniać ilości osi, przycisków i hatów zgłaszanych do PC ) więc zaplanowana tutaj ilość hat'ów pozostanie stała i niezmienna.
W programie będzie można skonfigurować - które przyciski są przypisane do HAT'a. W przypadku braku takich - hat będzie widziany przez PC jako bezczynny, ale będzie widziany. To samo dotyczy osi analogowych i przycisków.
-
To dobra wiadomość. Faktycznie wprowadzenie przycisku modyfikującego działanie hat zwiększa możliwości joysticka. Przyklad z Cougara H1 może działać jako widoki lub trymowanie. Co o tym myślą pozostali koledzy?
-
A można zrobić tak, żeby Joystick miał jedynie zwykłe przyciski, plus kilka przycisków "pinky", bez przypisywania sekwencji klawiszy? Klawiszami zajęła by się płytka DMKeys. To oddało by dość dużo pamięci na funkcje typowe dla Joysticka. Czy jednak funkcjonalność klawiatury powinna być wbudowana w Joy?
-
Wiele gier nie rozpoznaje joysticków o dużej ilości przycisków (Mjoy) jeżeli damy wyłącznie przyciski, dublując ilość fizycznych na drążku to albo części z nich nie będzie można wykorzystać, albo SVmapper będzie dodatkowo wymagany.
Przykładowo drąg z F-16 ma 22 przyciski, w trybie alternatywnym mamy kolejne 21, łącznie 43 - o 11 więcej niż gry rozpoznają.
-
Próbuję zrozumieć problem i mam pewne zahamowania. Zacznę od mojego profilu do Cougara. Jeśli nie będę używał profilu (Foxy) to mogę traktować Cougar jako joystick widziany przez Windows i w setup np BMS4 zaprogramować przyciski i osie.
Stosując modyfikator przycisk S3 oraz program Foxy zwiększam możliwości programowania przycisków i przełączników w Cougarze.
Wracając do naszego DMJoy i do mojego przykładu. Załóżmy, że zrobiłem replikę Cougara w sensie osi i przycisków oraz z sterownikiem Damosa. Chcę zwiększyć liczbę funkcji stosując modyfikator w postaci jednego wyróżnionego przyciski np.S3. Programuję w setup przypisania do przycisków łącznie z HAT zgodnie z plikiem key w którym są przypisane klawisze do callbacks. Do tego momentu wszystko wydaje się o.k. Teraz załóżmy, że HAT1 ma spełniać podwójną rolę tzn. widoki jeśli S3 jest OFF oraz trymowanie jeśli S3 jest ON. Jeśli w DMJoy zrobimy takie same przypisania jak w setup BMS4 dla HAT1 widoki oraz HAT1 trymery z warunkiem : wyślij sekwencję widoki jeśli nie jest wciśnięty przycisk nazwany S3, wyślij sekwencję trymowanie jeśli przycisk S3 jest wciśnięty (wersja monostabilna). Może przedstawilem to trochę chaotycznie ale mam nadzieję, że sens jest zrozumiały.
Na koniec uwaga, w tworzonych obecnie profilach stosowanie modyfikatora S3 jest ograniczane.
-
Chciałbym wrócić do założeń. W DMJoy będą podłączone potencjometry, które są zasilane. Zakładam, że sygnał jest przesyłany przewodem w ekranie. Każdy z potencjometrów swoją masę GND połączoną z sterownikiem (masa jest na sąsiednim pinie obok pinów sygnałowych PF0, PF1, PF4, PF5, PF6 oraz PF7 ). Pozostaje zasilanie potencjometrów.
Załóżmy, że mamy odzielne zasilanie dla potencjometrów. Pytanie pierwsze jaka może być max. wartość napięcia aby nie uszkodzić uP. Pytanie drugie czy jest ograniczenie na wartość potencjometru. Pozostaje sprawa zakłóceń, ale to wyjdzie w trakcie testów. Porównując zasilanie MJoy oraz DMJoy to jest pewna różnica w zasilaniu pots. W MJoy napięcie podawane na pots jest napięciem z USB seperownym dławikiem (zakłócenia). Tak myślę, że dobrze byłoby rozpocząć projekt od analogów tzn. zrobić uproszczony program obsługujący jedno wejście analogowe i testować sterownik pod kątem parametrów przetwarzania sygnałów analogowych na cyfrowe i wpływu zakłóceń. Tutaj pojawia się następny problem jak to sprawdzać. Profesjonalne przyrządy mają możliwość pomiaru sygnałów AD oraz DA tzn. rozdzielenia sygnałów analog cyfra i odwrotnie. Może są uproszczone metody pomiaru dokładności przetwarzania oraz wpływu zakłócen na wynik. Sun robił już testy przetworników, może coś zasugeruje.
-
Chciałbym wrócić do założeń. W DMJoy będą podłączone potencjometry, które są zasilane. Zakładam, że sygnał jest przesyłany przewodem w ekranie. Każdy z potencjometrów swoją masę GND połączoną z sterownikiem (masa jest na sąsiednim pinie obok pinów sygnałowych PF0, PF1, PF4, PF5, PF6 oraz PF7 )
Zgadza się. Ekran powinien być podłączony do tej masy i tylko do niej. Po stronie potencjometru ekran nie może być podłączony do niczego i pod żadnym pozorem nie powinien pracować jako przewód masy! W przypadku podłączenia również po stronie potencjometru - zależnie od jego budowy może nastąpić zamknięcie obwodu z masą sygnałową i mogą tworzyć się pętle prądowe z indukowanego napięcia, które będą wprowadzać zakłócenia. O ile dobrze pamiętam - Viker może tu pomóc, ponieważ ma bogate doświadczenie z pracy w przemysłowym środowisku pełnym zakłóceń.
. Pozostaje zasilanie potencjometrów.
Załóżmy, że mamy odzielne zasilanie dla potencjometrów. Pytanie pierwsze jaka może być max. wartość napięcia aby nie uszkodzić uP.
Nie może przekraczać napięcia zasilania układu. Dla DMJoy8 bezpieczną wartością jest 4,7V dla DMJoy32 - 3,2V. Wstępnie jednak odradzam stosowanie zewnętrznego zasilania - za dużo z tym kłopotów.
Pytanie drugie czy jest ograniczenie na wartość potencjometru.
polecał bym wsadzenie czegoś między 5k a 100k. Mniejsza wartość potencjometru zwiększy zużycie prądu, ale z drugiej strony zmniejszy podatność na odbieranie zakłóceń. Dla 10k pobierany prąd po 0,5 mA więc znikomy.
Pozostaje sprawa zakłóceń, ale to wyjdzie w trakcie testów. Porównując zasilanie MJoy oraz DMJoy to jest pewna różnica w zasilaniu pots. W MJoy napięcie podawane na pots jest napięciem z USB seperownym dławikiem (zakłócenia).
Słuszna uwaga. DMJoy8 ma dwa dławiki:
- jeden na zasilaniu z USB, przez który jest odprowadzone zasilanie do potów:
(http://img27.imageshack.us/img27/6062/img4778opis.th.jpg) (http://imageshack.us/photo/my-images/27/img4778opis.jpg/)
- drugi, osobny do zasilania wewnętrznej sekcji przetworników ADC:
(http://img141.imageshack.us/img141/5647/img4779opis.th.jpg) (http://imageshack.us/photo/my-images/141/img4779opis.jpg/)
Nie dawałem dodatkowych sekcji filtrów LC dla każdego wejścia ADC, ponieważ nie zmieściło by się to na płytce. Dodatkowo w przypadku używania wyprowadzeń w innym celu niż ADC - powodowało by to kłopoty z działaniem układu (np. dla DMKeys8 w trybie BIG_MATRIX). Założeniem zaś było posiadanie jednej, uniwersalnej płytki.
Oczekiwane najmocniejsze zakłócenia do sygnał 50Hz i jego harmoniczne (zasilanie sieciowe). Jeśli ktoś ma przetwornice napięcia albo kiepski przewód do monitora w pobliżu kabli potencjometrów - wtedy mamy już praktycznie całe spektrum losowe wyniki rezonansu lub zdudnienia :)
Tak myślę, że dobrze byłoby rozpocząć projekt od analogów tzn. zrobić uproszczony program obsługujący jedno wejście analogowe i testować sterownik pod kątem parametrów przetwarzania sygnałów analogowych na cyfrowe i wpływu zakłóceń.
Właśnie nad tym pracuję. Jednak od razu będą dostępne wszystkie osie analogowe, które będzie można włączać i wyłączać za pomocą programu konfiguracyjnego. Tym samym można będzie przetestować wpływ wielu osi na działanie jednej - konkretnej. Układ ADC ma kilka trybów, nie jestem jeszcze pewien czy da się używać najlepszego, ponieważ wymaga on "uśpienia" całego uC na czas dokonywania pomiaru. Jak takie "uśpienie" wpłynie na komunikację z USB - sprawdzę empirycznie.
Tutaj pojawia się następny problem jak to sprawdzać. Profesjonalne przyrządy mają możliwość pomiaru sygnałów AD oraz DA tzn. rozdzielenia sygnałów analog cyfra i odwrotnie. Może są uproszczone metody pomiaru dokładności przetwarzania oraz wpływu zakłócen na wynik. Sun robił już testy przetworników, może coś zasugeruje.
Słuszna uwaga. Na dobrą sprawę ze względu na akumulowanie wyników pomiarów ADC i brak wiedzy o momencie wykonania pomiaru - nie ma możliwości skorelowania danych przesyłanych przez urządzenie z zapisem z oscylografu. Jedyne, co przychodzi mi do głowy to po prostu szybkie odpytywanie układu i zapisywanie gdzieś odpowiedzi, następnie stworzenie wykresu na ich podstawie. Bez zmian w położeniu potencjometru wykres powinien być płaski. W przypadku obserwacji zakłóceń możemy dodać uśrednianie ostatnich kilku odczytów.
-
Widzę, że płytka się już znacznie zmieniła - na tej co mam dławików chyba nie ma, jest tylko jeden microswitch... od czego jest ten drugi ?
-
To ty masz jeszcze starą wersję. Ta "nowa" ma już ponad rok :)
Drugi switch jest od siłowego wprowadzenia układu w tryb DFU (programowania).
Twoja płytka jest OK dla DMKeys. Dla DMJoy "średnio" się nadaje.
-
No o zmianach w hardware to specjalnie mnie nie informujesz ;)
-
Były zrobione razem z XMega - tymi podłużnymi do schowania w rączce. Na pewno Ci mówiłem :)
-
Koledzy,
Tak sledze Wasza dyskusje i mam pytanie bo nie ukrywam, ze z zainteresowaniem czekam na wypuszczenie gotowego projektu...
Jak zamierzacie rozwiazac dystybucje schematu, sprzetu i oprogramowania dla zwyklych uzytkownikow? Czy bedzie mozna na przyklad zamowic u damosa okreslona liczbe egzemplarzy DMKeys / DMJoy lub ewentualnie gotowych plytek? I co z programem konfigurujacym?
Pozdrawiam i trzymam kciuki bo sie przymierzam do budowy wlasnej tablicy oprzyrzadowania :-) ale nie ukrywam, ze czekam na zakonczenie Waszych prac...
-
Moją intencją jest darmowe udostępnienie zarówno schematu płytki jak i wsadów oraz oprogramowania na PC.
Jednak w przypadku braku możliwości samodzielnego złożenia (lutowanie SMD nie każdego musi bawić) mogę rozważyć odpłatną pomoc.
-
Damos,
Dzieki za odpowiedz... Wydaje mi sie, iz prawie pewno wykonanie plytki drukowanej trzeba bedzie komus zlecic podobnie jak bylo w przypadku MJoya...
Pozdrawiam...
-
Wydaje mi sie, iz prawie pewno wykonanie plytki drukowanej trzeba bedzie komus zlecic podobnie jak bylo w przypadku MJoya...
To na 100%. Płytka jest dwustronna, z metalizowanymi otworami. Samodzielne wykonanie i spasowanie warstw niemal niemożliwe.
Myślałem o montowaniu płytek "minimum" - z zamontowanym uC i koniecznymi elementami (rezonator, rezystory, dławiki, złącze USB) bez lutowania goldpinów.
To była by najtańsza opcja. Drugi wariant to "full-wypas" - zamontowane wszystko.
-
O ile dobrze pamiętam -Viker może tu pomóc, ponieważ ma bogate doświadczenie z pracy w przemysłowym środowisku pełnym zakłóceń.
Niestety, nie mogę tego potwierdzić. To nie ja :003:
Odnośnie zakłóceń.
W MJoyu mam z tym spory problem, chociaż przewody nie mają więcej niż 20 cm (przewody mikrofonowe 6mm, 2 żyły + ekran - ponoć super).
Wychylenie jednej osi powoduje drgania innej osi, a czasem nawet znaczne wychylenia i to osi która jest nieaktywna (zmostkowana).
-
Domyślam się, że uP ma odzielny pin na zasilanie przetwornikow analogowych i tam dałeś jeden z dławików. Z tego co napisaleś to jest zalecane zasilanie pots z jednego z pin DMJoy8. Mam także wersję Sun tzn. bez dławików.
Po stronie potencjometru ekran nie może być podłączony do niczego i pod żadnym pozorem nie powinien pracować jako przewód masy!
Z tym się zgadzam.
Oczekiwane najmocniejsze zakłócenia do sygnał 50Hz i jego harmoniczne
To też jest prawdą.
Z mojej pracy zawodowej pamiętam, że największe problemy mieliśmy przy projektowaniu nowych urządzeń z zakłóceniami oraz przesłuchami. Tutaj jest potrzebna teoria i doświadczenie (zasilanie bateryjne, filtry zew. na 50Hz oraz harmoniczne, ekranowanie, prowadzenie przewodów, rozprowadzanie masy - tak aby nie powstaly pętle itd.). W naszych warunkach domowych to raczej będzie problem chociaż można próbować minimalizować zakłócenia. Zobaczymy w praktyce jak to będzie wyglądać. Już testy dadzą pewien pogląd.
nie ma możliwości skorelowania danych przesyłanych przez urządzenie z zapisem z oscylografu.
Zastanawiałem się także nad tym problemem. Kiedyś kolega zajmował się przetwornikami i zagadnieniami z tym związanymi. Używaliśmy je do przetwarzania muzyki i przesyłania sygnału cyfrowego przez łącza. Były to trochę inne zagadnienia oraz inne problemy, ale problem zakłóceń zawsze jest ten sam. Ponieważ sygnał był nadawany i odbierany przez taki sam przyrząd to nie bylo problemu z pomiarami w ukladzie A-A, A-D czy D-A.
W naszym przypadku mamy problem. Jeśli sygnał wejściowy będzie stały to dla małych wartości są to mV można to wyliczyć z max. wartości amplitudy oraz dokladności przetwornika (myślę, że jest to 10 bitowy przetwornik) pomiar tego sygnału będzie problemem. Może lepiej zrobić pewne założenia na wartość minimalną sygnału co w jakiś sposób ogranicza rozdzielczość czy raczej liczbę poziomów kwantyzacyjnych. Z tego co wiem to Sun ma ambicję zrobienia dokładnego joja a to może być problemem. Myślę, że dla takego zastosowania to zew. przetwornik byłby lepszym rozwiązaniem.
-
Pytanie do kolegow wytwarzajacych/testujacych nastepce MJoy-a o postep prac... Jakos temat ucichl a sadze, iz kilka osob z niecierpliwoscia czeka na sygnal, iz prace zostaly ukonczone :-)
Pozdrawiam...
-
Można by powiedzieć że cały świat czeka na następcę MJoy'a, chociaż jeszcze o tym nie wie :004:
Cierpliwości :002:
-
Postępy w DMKeys były dość duże pod koniec roku, jednak DMJoy wymaga kilku zmian zarówno po stronie PC jak i firmware. Muszę jeszcze wysłać Sundownerowi i Vito_zm (Eghi chyba też jest na liście wysyłkowej) nowe płytki do testów- a te najpierw należy złożyć z zamówionych części, które dotrą :)
Wszystko rozbija się o czas...
Tak więc mogę jedynie prosić o cierpliwość :)
-
DMKeys realizuje conajmniej 80% możliwości MJoya, dlatego można go stosować. Nie realizuje tylko osi analogowych tzn. nie można podłączyć do niego potencjometrów. Jeśli ktoś nie ma potrzeby realizacji analogów to może zastosować DMKeys.
-
Koledzy, dziekuje za odpowiedz...
Czekamy dalej... Prosimy tylko, abyscie chociaz wrzucili krotkie podsumowanie od czasu do czasu... Jeszcze raz pozdrawiam...
-
Wygląda na to, że projekt DMKeys8 został ukończony na etapie umożliwiającym jego używanie.
Ok. 80% czasu zajęło zaprojektowanie i stworzenie programu konfigurującego i działającego na PC. Samo programowanie układu scalonego było dość proste.
Vito_zm przeprowadzi jeszcze nieco testów i podzieli się spostrzeżeniami. Ja nieco później opiszę działanie całego układu.
A teraz biorę się za DMJoy8. Mam nadzieję, że uda się go zrobić szybciej niż DMKeys (znów gros pracy to soft na PC, ale już prostszy - mam nadzieję).
Ostatni dzwonek na podawanie propozycji funkcjonalności! :)
-
Tak jak wspomniał Damos przeprowadziłem dodatkowe testy DMKeys8. Testy wypadły pozytywnie i można już ten sterownik stosować. Testy przeprowadziłem z panelem Avionics Power zarówno na biurku (zdjęcie) jak i w kokpicie.
(http://img171.imageshack.us/img171/5944/test1wr.th.jpg) (http://imageshack.us/photo/my-images/171/test1wr.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Pisałem w tym wątku dosyć dużo na temat moich poprzednich testów, dlatego dodam tylko parę uwag. W czasie testów wystąpiły pewne problemy związane z słabą jakością niektórych elementów np. enkodery czy z długimi przewodami. Te problemy spowodowały rozwój programu, który obecnie ma możliwość korekcji wspomnianych wad. Dodatkowo w czasie testów powstawały pomysły aby zrobić program konfiguracyjny prosty w obsłudze oraz intuicyjny i to się udało.
Wspomnę tylko o dwóch zaletach tego programu. Można programować z USB, co jest dużą zaletą, żadnych programatorów lub LPT. Druga zaleta to "podłącz do USB i zapomnij o DMKeys8", tak jak z niektórymi rakietami. Nie potrzeba dodatkowego programu tak jak w przypadku MJoy lub SimOut. Tak jak wspomniałem wcześniej program konfigurujący jest intuicyjny i prosty w obsłudze, nie potrzeba pisać skryptów i wchodzić w teorię jak je tworzyć.
Na stronie Damosa jest szczegółowy opis jak programować oraz tworzyć konfigurację. Mogą dla niektórych użytkowników wystąpić problemy z lutowaniem uP, ale są na to sposoby. Tyle moich uwag na gorąco.
-
Krótkie podsumowanie
Płytka:
- bazowa płytka DMKeys8 jest wielkości pudełka zapałek
- podłączana jest do gniazda USB i zasilana z gniazda USB
- DMKeys8 pracuje jako klawiatura USB.
- Nie potrzebuje dodatkowych sterowników, jest widziany jak zwykła klawiatura pod każdym systemem operacyjnym dla PC (Windows 98 - Win7, Linux, MAC OS)
- nie potrzebuje do działania żadnego programu typu SVmapper (nie zużywa CPU)
- jako urządzenia wejściowe mogą pracować: zwykłe przyciski, przełączniki dwustanowe, przełączniki obrotowe, najprostsze enkodery typu 1:1, typu 1:2, typu 1:4
- układ obsługuje maksymalnie do 160 przycisków lub do 80 enkoderów (oczywiście można mieszać np - 20 enkoderów i 128 przycisków; ze względu na odczyt matrycowy wymagane zastosowanie diod: po jednej na przycisk po dwie na enkoder)
- układ potrafi emulować przełącznik bistabilny za pomocą zwykłego przycisku (każde wciśnięcie przycisku to przełączenie wirtualnego przełącznika na przeciwną pozycję - emitowana jest inna sekwencja klawiszy)
- każde z urządzeń wejściowych może emitować serię klawiszy jako reakcję na: wciśnięcie przycisku, zwolnienie przycisku, przełączenie w inny stan przełącznika, obrót w lewo lub w prawo enkodera
- dodatkowo enkodery mogą być skonfigurowane jako enkodery pracujące z 2 prędkościami, prędkości te przełącza się zdefiniowanym uprzednio przyciskiem (np w osi enkodera)
- układ posiada filtry cyfrowe redukujące zakłócenia w długich przewodach i drgania styków. Pozwala na indywidualne dobranie parametrów filtrów w zależności od środowiska i posiadanego sprzętu.
Konfiguracja:
- płytkę konfiguruje się za pomocą osobnego programu na PC
- program nie jest potrzebny do działania płytki a jedynie do jej skonfigurowania, konfiguracja jest zapisywana na płytce
- w programie definiuje się, które piny kontrolek podłączane są do których pinów płytki
- program pokazuje graficznie widok płytki oraz klawiatury oznaczając na nich użyte piny i klawisze.
- program pilnuje poprawnego zaplanowania połączeń i uniemożliwia popełnienie błędu
- program umożliwia stworzenie i zachowanie notatek dotyczących każdej kontrolki i każdego pinu
- w programie definiuje się sekwencje klawiszy emitowane w wyniku użycia kontrolki (wciśnięcia lub zwolnienia przycisku, zmiany stanu przełącznika, obrotu enkodera)
- definiowana sekwencja klawiszy może zawierać maksymalnie do 90 klawiszy (jednak tak długie sekwencje są niezalecane - zmniejszają maksymalną ilość obsługiwanych kontrolek: mikroprocesor ma ograniczoną pamięć)
- konfigurację płytki robi się zdalnie - poprzez kabel USB, do którego jest podłączona, może być schowana głęboko wewnątrz kokpitu
- wgranie nowego firmware również nie wymaga wyjmowania ani dotykania płytki - robi się to za pomocą tego samego kabla USB
-
Mały update:
zrobiłem dziś wstępną wersję DMJoy8 i wysłałem na testy osi analogowych do Sundownera i vito_zm. Ciekaw jestem oceny stabilności osi analogowych.
jeśli nie zadziała na płytkach, które mają - będę musiał wysłać im również nowy hardware :)
Testowałem również emulację osi analogowej za pomocą enkodera.
Układ okazał się znacznie prostszy od DMKeys. Jeśli testy wypadną pomyślnie - przystąpię do dalszej pracy.
Najwięcej czasu pochłonie program konfiguracyjny na PC - będzie zbliżony do tego z DMKeys8.
Za pomocą programu będzie można zdefiniować, jakie kontrolery są podłączone do jakich pinów i jak mają działać.
Planuję następujące kontrolery i ich możliwości konfiguracyjne:
- potencjometr
- działa jak potencjometr: zmienia się wartość przypisanej do niego osi analogowej
- działa jak trymer - modyfikuje wartość innej (skonfigurowanej) osi analogowej
- przycisk
może:
- działać jak zwykły przycisk joysticka
- przy wciśnięciu wysyłać kliknięcie przycisku A a przy zwolnieniu kliknięcie przycisku B
- przy wciśnięciu zwiększać lub zmniejszać wskazanie skonfigurowanej osi analogowej o skonfigurowana wartość[size=78%] [/size]
- przełącznik
- przy przełączeniu na jedna z pozycji symulować wciśnięcie innego przycisku joysticka
- enkoder
- przy pokręceniu w lewo wciskać jeden przycisk joysticka a przy pokręceniu w prawo inny (przy alternatywnej prędkości inne przyciski joy'a)
- przy kręceniu w lewo lub w prawo może trymować skonfigurowaną oś analogową o skonfigurowaną wartość
- może zupełnie emulować oś analogową - zamiast potencjometru
Jakieś sugestie?
Przycisk Pinky?
Przełącznik Pinky?
Pinky tylko dla przycisków, czy dla osi analogowych również?
-
Nie wiem od czego zacząć. Na początek chciałbym zaznaczyć, że jestem "zielony" jesli chodzi o joystiki te stosowane w symulatorach. Posiadam dwa typy, prosty Extreme 3D PRO oraz Cougara. Korzystałem z gotowych profili dla Cougara, które modyfikowałem pod swoje potrzeby. Modyfikacje robiłem w Foxy. Próbowałem zagłębić się w temat tworzenia profili i nawet napisałem na ten temat w tym wątku http://www.il2forum.xt.pl/index.php/topic,14437.msg261898.html#msg261898. Sterownik Cougara można programować za pomocą Foxy lub w symulatorze np. BMS4.
W starym MJoy są oprócz przycisków, przełączników, enkoderów wejścia analogowe oraz jeden HAT. Analogi były widziane w Windows i można je było programować w setup symulatora.
Nowy DMJoy ma mieć większe możliwości od starego.
1. Zadam teraz może naiwne pytanie. Czy DMJoy ma być sterownikiem do budowy własnych joystików czy
ma wspomagać sterowanie symulatorów. Z tym pytaniem jest związany stopień jego komplikacji.
2.Drugie pytanie dotyczy programowania DMJoy. DMKeys był widziany jako wyspecjalizowana klawiatura. DMJoy będzie widziany w Winodows jako kontroler.
Jak będzie można programować DMJoya? Rozumiem, że w konfiguracji np. BMS4 będą widziane osie analogowe, które można odpowiednio przypisać do jego funkcji. Czy przyciski, przełączniki i enkodery będą programowane podobnie jak w DMKeys?
3.Przycisk Pinky w Cougarze daje możliwość zdefiniowania nowych funkcji np. w HAT. Jeśli będzie wciśnięty to mamy nowe funkcje np. widoki jeśli nie to trymowanie itp. Jest to definiowane w profilu. Jak to by mialo działać w DMJoy.
To są moje pytania związane z DMJoyem.
Jeśli chodzi o propozycje zawarte w ostatnim post Damosa to będę musiał to przemyśleć, ponieważ nie wszystko zrozumialem. Może Sun wypowie się na ten temat, ma większe doświadczenie.
-
1. Zadam teraz może naiwne pytanie. Czy DMJoy ma być sterownikiem do budowy własnych joystików czy
ma wspomagać sterowanie symulatorów. Z tym pytaniem jest związany stopień jego komplikacji.
Obie rzeczy. Będzie widziany jako zwykły kontroler, ale może być konfigurowany. Zrobię do niego kilka przykładowych plików konfiguracji - jako zwykły Joy, Joy z enkoderami, Joy z trymerami itd.
2.Drugie pytanie dotyczy programowania DMJoy. DMKeys był widziany jako wyspecjalizowana klawiatura. DMJoy będzie widziany w Winodows jako kontroler.
Jak będzie można programować DMJoya? Rozumiem, że w konfiguracji np. BMS4 będą widziane osie analogowe, które można odpowiednio przypisać do jego funkcji. Czy przyciski, przełączniki i enkodery będą programowane podobnie jak w DMKeys?
DMJoy8 będzie się konfigurować w bardzo podobny sposób, jak DMKeys8. Osobny program na PC i wgrywanie go do uC. W programie konfigurujesz - do jakich pinów podłączasz przyciski, osie i enkodery i ile ich podłączasz. Do każdego przycisku/enkodera przypisujesz również tryb działania - czy ma działać jako zwykły przycisk czy jako trymer, czy ma emulować oś analogową, czy generować wciśnięcia przycisków przy kręceniu w lewo/prawo.
3.Przycisk Pinky w Cougarze daje możliwość zdefiniowania nowych funkcji np. w HAT. Jeśli będzie wciśnięty to mamy nowe funkcje np. widoki jeśli nie to trymowanie itp. Jest to definiowane w profilu. Jak to by mialo działać w DMJoy.
W DMJoy8 komunikacja z otoczeniem (komputerem) odbywa się przez raportowanie stanu osi analogowych i przycisków Joysticka. Więc w różnych trybach wciśnięcie tego samego przycisku fizycznego powodowało by wysłanie do PC informacji o wciśnięciu innego przycisku Joysticka. Ten inny przycisk można zmapować w symulatorze do innej funkcji.
-
Ten inny przycisk można zmapować w symulatorze do innej funkcji.
To przypomina tzw. modyfikatory w Foxy. Pinky też jest modyfikatorem.
Jeszcze jedno pytanie. W MJoy jest wyróżniony przełącznik 4 kierunkowy HAT z czego to wynika? Właściwie są to 4 przyciski. Może chodzi o jakieś szczególne zabezpieczenie tych 4 przycisków np. drgania stykow czy coś podobnego. Pytam dlatego, że u Ciebie wszystkie styki są tak samo traktowane. Oczywiście możemy budować HAT w DMJoy podobnie jak w DMKeys.
-
To przypomina tzw. modyfikatory w Foxy. Pinky też jest modyfikatorem.
Zgadza się. Pytanie - czy taki feature jest potrzebny?
W MJoy jest wyróżniony przełącznik 4 kierunkowy HAT z czego to wynika?
Wynika to ze sztywnego przypisania HAT do pinów. HAT może być 4-ro lub 8-mio kierunkowy. Kierunek jest opisywany za pomocą wartości, która bezpośrednio nie wynika z ze stanu klawiszy więc przy braku złożonej logiki - MJoy musiał mieć zahardcode'owaną logikę do HAT'a.
Właściwie są to 4 przyciski. Może chodzi o jakieś szczególne zabezpieczenie tych 4 przycisków np. drgania stykow czy coś podobnego. Pytam dlatego, że u Ciebie wszystkie styki są tak samo traktowane.
Przyciski HAT'a są najmniej wymagającymi. Nie trzeba ich zabezpieczać w jakiś szczególny sposób.
Oczywiście możemy budować HAT w DMJoy podobnie jak w DMKeys.
W DMKeys nie ma HATa :) Chyba, że chodzi ci o dodanie w programie konfiguracyjnym kontrolki typu HAT i wskazaniu, gdzie będzie podłączona. Tak to ma wyglądać.
-
Wracam do pojęcia HAT w DMJoy8, ponieważ jest to istotny element. Jeśli dobrze zrozumiałem to jest lub będzie możliwość definiowania HAT-ów w DMJoy8.
Wynika to ze sztywnego przypisania HAT do pinów.
Czy w DMJoy nie będzie tego ograniczenia?
Jeden modyfikator wystarczy np. Pinky, dla tych którzy mają stare nawyki z Cougara, chociaż nie wszyscy z tego korzystają.
-
Wracam do pojęcia HAT w DMJoy8, ponieważ jest to istotny element. Jeśli dobrze zrozumiałem to jest lub będzie możliwość definiowania HAT-ów w DMJoy8.Czy w DMJoy nie będzie tego ograniczenia?
Tak - będzie można podłączyć pewną, z góry ograniczoną ilość HAT-ów. Jeśli nie skonfiguruje się HAT-a w programie, on nadal będzie raportowany przez Joystick, ale nie będzie działać. To samo dotyczy osi analogowych i przycisków. Osie analogowe (6 lub 8 ) będą zgłaszane, ale jeśli w programie nie skonfigurujesz, że do osi jest podłączony potencjometr - ta oś nigdy się nie poruszy. Joystick będzie zgłaszać 32(?) przyciski, ale jeśli w programie nie zdefiniujesz, że np. enkoder przy obracaniu w prawo generuje kliknięcie przycisku nr 12 a przy obracaniu w lewo kliknięcie przycisku nr 13 to te przyciski pozostaną widoczne dla gry, lecz gra nigdy nie otrzyma informacji o ich wciśnięciu.
Prawdopodobnie znamionowa konfiguracja Joysticka (wbudowana w program na początku) będzie mieć osie analogowe 2 HAT'y, z 20 przycisków i 6 enkoderów. To powinno wystarczyć początkującym aviatorom.
Jeden modyfikator wystarczy np. Pinky, dla tych którzy mają stare nawyki z Cougara, chociaż nie wszyscy z tego korzystają.
Własnie - chciałbym poznać oczekiwania ew. użytkowników :)
-
Nie wiem czy to odpowiedni moment na zgłaszanie takich uwag, ale czy nie lepiej byłoby aby DMJoy8 obsługiwał same osie analogowe - około 8?
Przy budowie kokpitów wykorzystywałoby się kombinacje płytek (DMJoy8 i DMKeys8) które mogłyby jakoś współdziałać (np. wspólne podłączenie USB, itp). Jednocześnie bardziej zaawansowani budowniczowie pitów mogliby dobierać ilość podzespołów w zależności od potrzeb. Potrzeba więcej osi na trymy, obsługę 4 silników itp to dodajemy sobie kolejne DMJoy8. Zabrakło enkoderów, "psztyczków" itp, dodajemy DMKeys8. Całość konfigurowana z jednego programu, w którym po dodaniu nowych płytek widać dodatkowe osie lub przełączniki.
Zrobienie JoySticka poprzez zmontowanie 2 płytek też nie jest jakimś dużym utrudnieniem. Chociaż finalnie, połączenie DMKeys8 i DMJoy8 może być zintegrowane w "JoyStick kit" na jednej płytce.
-
Nie wiem czy to odpowiedni moment na zgłaszanie takich uwag, ale czy nie lepiej byłoby aby DMJoy8 obsługiwał same osie analogowe - około 8?
Czyli już wszystko zrobione? :) Chciałbym, żeby jedna płytka mogła załatwić więcej spraw niż jedynie osie analogowe. Ma być zastępstwem dla MJoy'a więc musi mieć możliwość pracy jako normalny Joy.
Osie analogowe już mam zrobione :118:
Przy budowie kokpitów wykorzystywałoby się kombinacje płytek (DMJoy8 i DMKeys8) które mogłyby jakoś współdziałać (np. wspólne podłączenie USB, itp). Jednocześnie bardziej zaawansowani budowniczowie pitów mogliby dobierać ilość podzespołów w zależności od potrzeb. Potrzeba więcej osi na trymy, obsługę 4 silników itp to dodajemy sobie kolejne DMJoy8. Zabrakło enkoderów, "psztyczków" itp, dodajemy DMKeys8.
Można tak dodawać - bez problemu.
Całość konfigurowana z jednego programu, w którym po dodaniu nowych płytek widać dodatkowe osie lub przełączniki.
Ciekawy pomysł, jednak obecnie program skupia się na skonfigurowaniu jednej, konkretnej płytki. To musiał by być system "nadrzędny" :) Nie myślałem o czymś takim - nie wiem, czy jest potrzebny?
Zrobienie JoySticka poprzez zmontowanie 2 płytek też nie jest jakimś dużym utrudnieniem. Chociaż finalnie, połączenie DMKeys8 i DMJoy8 może być zintegrowane w "JoyStick kit" na jednej płytce.
Łączenie wszystkiego na jednej płytce? Dwie są bardziej uniwersalne i łatwiej zmieścić je we wnętrzu zabudowy.
-
Łączenie wszystkiego na jednej płytce? Dwie są bardziej uniwersalne i łatwiej zmieścić je we wnętrzu zabudowy.
Właśnie o tym piszę, jedna z osiami DMJoy8, druga z resztą DMKeys8. Z dwóch płytek lub ich krotności składamy wszystko. Opcję DMJoy8 obsługujący jednocześnie jakieś przełączniki i przyciski (ograniczoną ilość) dodałbym dla chcących tylko joy.
Nie myślałem o czymś takim - nie wiem, czy jest potrzebny?
W wypadku budowy kokpitu z kilku elementów, przykładowo 2 x DMKeys8 i 3 x DMJoy8 (bo potrzebujemy np 20 osi) możemy całość widzieć jako "jedno urządzenie" i bawić się nim dowolnie w jednym programie. Myślę że posiadacze kokpitów doceniliby takie ułatwienie.
Osie analogowe już mam zrobione :118: Można tak dodawać - bez problemu.
Czyli wszystko gotowe. Teraz jakbym chciał obsłużyć 20 osi, to muszę użyć 3 DMJoy8. Jednocześnie z każdym z nich dochodzi mi kilkanaście przełączników i innych takich. Samo w sobie na pewno nie jest to wadą, ale przy założeniu budowy kokpitu, korzystniej może być osobna obsługa osi i osobna przełączników. Jeżeli osie mam zgrupowane z jednej strony a przełączniki z innej to albo i tak użyję dodatkowej DMKeys8, albo poprowadzę kilometr kabli aby nie tracić przycisków z DMJoy8.
Chciałbym, żeby jedna płytka mogła załatwić więcej spraw niż jedynie osie analogowe. Ma być zastępstwem dla MJoy'a więc musi mieć możliwość pracy jako normalny Joy.
Dlatego wcale nie proponuję wyrzucać projektu do kosza. Zwracam tylko uwagę że w obecnej postaci DMJoy realizuje również, w ograniczonym zakresie, funkcje z DMKey. Znakomity pomysł jeżeli chodzi o JoyStick, jednak w innych wypadkach nie musi być optymalne rozwiązanie.
-
Yano, kombinujesz pod górę ;)
Im więcej możliwości DMkey będzie w DMjoy tym lepiej - to właśnie będziesz miał oszczędności w drugą stronę, zamiast pakować się w dwie płytki przy czymś prostym, wykorzystasz tylko DMjoy - jeżeli są tam potrzebne osie analogowe. DMjoy i DMkey to ta sama płytka i ten sam (relatywnie kosztowny!) mikrokontroler. Im więcej da się wycisnąć z każdej płytki, tym lepiej!
-
Sun ma rację. Budowaliśmy kokpity mając skromne możliwości w postaci starego MJoya. Teraz mamy platformę HSC Codeking, którą można sterować simOUT, simIN oraz MJoye. Pojawił się DMKeys, który nie potrzebuje platformy ponieważ jest widziany jako wyspecjalizowana klawiatura. Tworzy się DMJoy, który ma jeszcze inne możliwości.
Można wykorzystać projekt Skalarki oraz HSC i mieć coś podobnego do idei yano, tak ma EGHI. Możliwości jest dużo. Jeśli chcemy analogowe gaugesy to musimy jeszcze kupić kartę od OC i programować to w SIOC.
OC ma bardzo dobrą platformę programową, ale ma dużą liczbę wyspecjalizowanych sterowników. Zawsze musi być jakiś kompromis.
W związku z osiami analogowymi mam do yano pytanie. Czy masz rozeznanie ile osi jest potrzebnych w BMS4 zakładając, że mamy Cougara. Ja w moim kokpicie mam tylko jedną oś dla orczyka, pozostałe funkcje realizuje Cougar lub enkodery.
-
Czy masz rozeznanie ile osi jest potrzebnych w BMS4 zakładając, że mamy Cougara. Ja w moim kokpicie mam tylko jedną oś dla orczyka, pozostałe funkcje realizuje Cougar lub enkodery.
I to w zasadzie koniec. Jeszcze hamulce - ponoć z klawiatury łapią na ustalonym prawie na max poziomie ale gdzieś czytałem że można to przenieść na potencjometr (zabij, nie pamiętam gdzie o tym było). Na upartego można by myśleć o trymach , ale to chyba nie najlepszy pomysł. W samej zabawie przydaje się jeszcze podpiąć przybliżanie TP pod jakąś oś. oraz zbliżenie widoku. W wypadku BMS to już chyba wszystko co można zdziałać.
BMS4 wygląda na przyjazny pod względem ilości osi. Gorzej z wszystkim innym.
-
Jeszcze hamulce - ponoć z klawiatury łapią na ustalonym prawie na max poziomie ale gdzieś czytałem że można to przenieść na potencjometr (zabij, nie pamiętam gdzie o tym było).
W Setup/controllers/advanced options/ Flight control, masz wszystkie osie analogowe i są też hamulce, o trymach nie wspomnę ;).
-
Zapomniałem o panelu z trymerami, ponieważ nie mam go u siebie z braku miejsca. U mnie trymery są w HAT1 i są dostępne po wciśnięciu pinky.
-
Napisałem że trymer na osiach może być problem w kokpicie. Skłoniły mnie do tego pewne przemyślenia "teoretyczne" (nie dysponuję kokpitem więc nie mam jak sprawdzić). Problem wygląda mniej więcej tak:
Trymować można za pomocą panelu oraz za pomocą sidestika. Jeżeli w panelu umieścimy potencjometry i zaczniemy trymować przełącznikiem na sidestiku, to w efekcie rozjadą nam się wartości. Potencjometry fizycznie będą w położeniu neutralnym, ale trymowanie już nie. Przykładowo trymujemy sidestickiem tak, aby samolot maksymalnie przechylić w lewo. Potencjometry pozostały w pozycji zerowej. Spróbujmy teraz za pomocą panelu uzyskać maksymalny trym w prawo. Okazuje się że możemy dojechać do środka i dalej kończy się potek.
-
Enkodery.
-
Panowie, proszę nie kraść wątku :) temat o detalach kokpitu piętro niżej ;)
Mały update:
za pomocą 32-krotnego oversamplingu udało mi się zwiększyć rozdzielczość osi analogowych do 12 bitów (skuteczna rozdzielczość ponad 11 bitów: ok 4000 różnych wartości) z zachowaniem akceptowalnej szybkości i stabilności odczytu rzędu 0,09%. Więc czułość jest między 4.8mV a 1,5mV (zakres 5V podzielony na 4096 różnych wartości daje najmniejszą rozdzielczość na poziomie 1,2mV). Przy tak obiecujących efektach można pomyśleć o 13-to lub 14-to bitowej osi, ale to będzie już ryzykowne - zwiększanie rozdzielczości o 50% ma już więcej wspólnego ze statystyką niż pomiarami :)
@Yano - jeśli trymer będzie mógł "spowodować" maksymalne wychylenie steru - to nic na to nie poradzisz nawet w prawdziwym samolocie. Trymery muszą być "słabsze" od osi trymowanej. Na przykład - maksymalne wychylenie trymera to max 25% wartości osi.
-
z zachowaniem akceptowalnej szybkości i stabilności odczytu rzędu 0,09%.
Sun mam do Ciebie pytanie. Jak u Ciebie z stabilnością odczytu. U mnie w programie DIView jest niestabilnie na pozycjach 0,xx% względem wartości maxymalnej. Jest to trochę więcej od 0,09%.
-
Jeszcze nie mam podpiętych potencjometrów. W tej chwili wskrzeszam Suncoma by spełniał zadania platformy testowej, jest z tym trochę roboty.
-
Sun mam do Ciebie pytanie. Jak u Ciebie z stabilnością odczytu. U mnie w programie DIView jest niestabilnie na pozycjach 0,xx% względem wartości maxymalnej. Jest to trochę więcej od 0,09%.
Vito, zewrzyj wszystkie osie do masy, za wyjątkiem osi X.
W programie DIView jest log, on u mnie pokazuje to:
w pozycji lewej:
(http://img560.imageshack.us/img560/8657/analogilewy.png)
na środku:
(http://img705.imageshack.us/img705/8814/analogi.png) (http://imageshack.us/photo/my-images/705/analogi.png/)
w pozycji prawej:
(http://img803.imageshack.us/img803/8804/analogiprawy.png)
jak widać na przykładzie - różnice są na poziomie +/- 16 (26511-26495), cały zakres to 65536 więc 16 to 0,02% wartości maksymalnej.
Oczywiście - każdy układ będzie inny ze względu na zakłócenia, parametry indywidualne każdego ADC itd.
-
To są moje wyniki dla 3 zakresów położenia suwaka.
(http://img819.imageshack.us/img819/7623/ox1k.th.jpg) (http://imageshack.us/photo/my-images/819/ox1k.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
(http://img819.imageshack.us/img819/6126/ox3y.th.jpg) (http://imageshack.us/photo/my-images/819/ox3y.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
(http://img443.imageshack.us/img443/4070/ox2i.th.jpg) (http://imageshack.us/photo/my-images/443/ox2i.jpg/)
Uploaded with ImageShack.us (http://imageshack.us)
Z analizy wyników wynika, że różnica pomiędzy sąsiednimi pozycjami wynosi 16. Z czego to wynika?
-
To są moje wyniki dla 3 zakresów położenia suwaka.
Z analizy wyników wynika, że różnica pomiędzy sąsiednimi pozycjami wynosi 16. Z czego to wynika?
Oryginalnie wyniki mają 4097 różnych wartości. Są z zakresu 0-4096 (powinno być 0-4095 - poprawię to :) ). Zobaczysz to klikając prawym przyciskiem na oknie danej osi i wybierając opcję "View Raw Data". Wtedy na czerwono będą pokazywane dane źródłowe (wysyłane przez kontroler).:
(http://img411.imageshack.us/img411/4022/analogiraw.png) (http://imageshack.us/photo/my-images/411/analogiraw.png/)
Software na PC ekstrapoluje je do zakresu 0-65535. To wymaga pomnożenia przez 16. Z tego wynika, że zmiana o 1 w danych "surowych" z urządzenia powoduje zmianę o 16 dla zakresu podawanego na osi.
Najmniejszy skok ekstrapolowanej osi to 16 - bo zmiana o 1 z 12-to bitowego zakresu (0-4095 na 0-65535) wynosi właśnie tyle.
-
Masz rację, sprawdziłem. Wynika z tego, że te "niestabilności" wynikają z zasady kodowania 12-bitowego zakresu.
-
Jesli dobrze rozumiem DMjoy8 jest jeszcze w trakcie testow i dopracowywania?
Mialem zrobic sobie Mjoya ale postanowilem poczekac na DMjoya:]
-
Tak - DMJoy jest w fazie developmentu.
Jednak brakuje mu naprawdę niewiele.
Powinien okazać się dużo bardziej stabilny niż zwykły MJoy. I koszt części + płytka jest mniejszy ;)
-
Damos,
A jak zamierzacie rozpowszechniać płytkę i ewentualnie zaprogramowany m-procesor DMKeys8 i DMjoy8? Macie na oku jakąś stronę, gdzie można by to zamawiać?
Czy ewentualnie będzie cały opis na Twojej stronie ze wzorami płytek, tak aby można było sobie samemu przygotować płytki jak również plik binarny (wsad) do m-procesora?
Pozdrawiam, jeszcze raz, gratuluję Wam (Tobie i osobom testującym) uporu i determinacji i niecierpliwie czekam na zakończenie prac :banan
-
Planuję udostępnić schemat płytki i wsad tak, aby każdy mógł samodzielnie zbudować sobie układ.
Problemem dla niektórych może być kwestia montażu, który wymaga dokładności, cierpliwości i ... lupy :)
(http://img715.imageshack.us/img715/8233/img4779iu.th.jpg) (http://imageshack.us/photo/my-images/715/img4779iu.jpg/)
(http://img193.imageshack.us/img193/4957/img4778oj.th.jpg) (http://imageshack.us/photo/my-images/193/img4778oj.jpg/)
Więc dla tych, którzy nie będą chcieli robić tego samodzielnie wymyślę jakąś formę pomocy w postaci możliwości zamówienia zmontowanej i uruchomionej płytki..
Płytka jest mała, uniwersalna i może służyć do wielu rzeczy (Joy, Keyboard, sterowanie LED, 7SEG, LCD, przekaźniki ) - więc pod tym względem projekt jest interesujący.
-
Ja tez gratuluje, i wlasnie widze ze z tego co czytam to niewiele juz brakuje dlatego czekam z niecierpliwoscia:]
-
Ja już się nie mogę doczekać aby wymienić szwankujące Mjoy'e.
Damos jeśli będę mógł w czymś pomóc to daj znać.
-
Panowie, piękna robota! Leo Bodnar wcale nie zrobił lepszej. A z tego co mówicie i funkcjach jakie oferuje, jest o niebo lepsza, no i na pewno będzie TAŃSZA :banan
Chyba wszyscy którzy jechali do tej pory ma starym mjoyu właśnie tego potrzebowali.
Dzięki, że Wam się chciało :)
-
Płytka jest mała, uniwersalna i może służyć do wielu rzeczy (Joy, Keyboard, sterowanie LED, 7SEG, LCD, przekaźniki ) - więc pod tym względem projekt jest interesujący.
Ponieważ biorę udział w testach obu wersji tej płyty to dodam od siebie, że obie wersje rozszerzą znacznie możliwości MJoya.
Chciałbym wyjaśnić co oznacza ten cytat. Damos ma zamiar nie tylko zastąpić funkcjonalnie starego MJoya, ale rozszerzyć możliwości swojego sterownika o funkcje opisane w wspomnianym cytacie, ale to wymaga czasu. Można wejść na stronę Damosa i poczytać na temat projektów http://www.mpds.damos.pl/
-
Co do ceny, Mjoy sam w sobie nie jest wcale kosztowny - jest tańszy od urządzeń Bodnara o co najmniej połowę. DMjoy z kolei o ile posiada mniej elementów i znacznie mniejszą PCB, to ogólnie kosztami powinien wyjść podobnie - taniej tylko przy dużym nakładzie.
W cenie nie doszukiwałbym się przełomowości, ale w możliwościach - zaczynając od programowania, do którego nie potrzeba żadnego dodatkowego urządzenia. Ustawień funkcji jakie mają spełniać podłączone komponenty, które możliwościami wykraczają poza SVmappera, czy pod pewnymi względami oprogramowanie Thrustmastera. Czy zupełnie nowe możliwości, jak np zintegrowany w joystick trymer.
To zapewne dopiero początki, bo na oku jest trochę komponentów z którymi warto byłoby zintegrować układ, a które nie są obsługiwane przez żadne inne znane mi urządzenie tego typu.
-
Pytanie dla pitbuilderów. Czy Waszym zdaniem byłby przydatny przycisk lub przełącznik realizujący funkcję synchronizacji przełączników tych z fizycznego kokpitu z tymi z symulatora (na ekranie monitora) w DMKey. Jakie istnieje niebezpieczeństwo stosowania tego przycisku. W ramp start jeśli mamy źle ustawione przełączniki i naciśniemy ten przycisk to musimy poszukać gdzie jest błąd. Byłby to taki "dydaktyczny przycisk". Jakie jest Wasze zdanie na ten temat, czy jest sens zastosowania takiej funkcji w DMKey. W kokpicie musiałby być specjalny przycisk do synchronizacji.
-
Sensowne do realizacji wyjścia z sytuacji niezsynchronizowanych przełączników są dwa:
- albo działa się z listą, i pieczołowicie ustala położenie przycisków w picie, zgodne z tym w symulacji.
- albo program obsługujący pit sam sprawdza położenie przełączników w porównaniu do symulacji i pokazuje różnice, ewentualnie przekazuje symulacji położenie rzeczywiste,
czyli wymusza przełączenie ich w pozycje odpowiadające pitowi.
Oba rozwiązania mają wady. W pierwszym wada jest oczywista, w drugim wadą mogą być niekontrolowane wyłączenia lub załączenia systemów. O ile w działaniu z Ramp Start będzie to niegroźne, o tyle gdybyśmy chcieli polecieć szybkie Taxi lub Runway, to już robi się problem. Tak czy siak wracamy do czeklisty i badamy co się przestawiło.
Ideałem byłoby posiadać w rzeczywistym picie mechanizm ustalający położenie każdego z przełączników. Wczytujemy misję, jakiś programik bada ustawienie wszystkiego w symulacji i przekazuje pozycje psztyczków do pitu, a elementy wykonawcze dokonują przełączenia ich na wymagane pozycje.
Osobiście budując własny pit, byłbym załamany taką komplikacją. Wszyscy posiadający pity raczej pomysł odrzucą ze względu na komplikację i koszty.
-
Tak czy siak wracamy do czeklisty i badamy co się przestawiło.
Do tego samego doszedłem wniosku.
Ideałem byłoby posiadać w rzeczywistym picie mechanizm ustalający położenie każdego z przełączników.
To byłoby możliwe, ale DMKey ma być uniwersalny dla każdego symulatora i to trochę komplikuje.
elementy wykonawcze dokonują przełączenia ich na wymagane pozycje
DMKey działa w jednym kierunku tak jak klawiatura.
Dzięki yano za opinię. Mam nadzieję, że już we wrześniu spotkamy się na wirtualnym niebie gdzieś w Korei.
-
Informacje na temat DMKeys8 są na stronie Damosa https://sites.google.com/site/damosmpds/project-updates/dmkeys8ukonczony Są tam szczegółowe informacje na temat programowania uP oraz sterownika DMKeys8. Zadaniem mojego projektu jest zrobienie matrycy z 160 wyjściami. Punktem wyjścia jest opis matrycy tzw. big matrix na stronie Damosa. Matryca ma 16 kolumn oraz 10 wierszy. Kolumny oraz wiersze są ozn. zgodnie z schematem sterownika DMKeys8. W moich schematach zmieniłem oznaczenia kolumn w następujący sposób : C1-PB0, C2-PB1, C3-PB2, C4-PB3, C5-PB4, C6-PB5, C7-PB6, C8-PB7, C9-PD0, C10-PD1, C11-PD2, C12-PD3, C13-PD4, C14-PD5, C15-PD6 oraz C16-PD7. Podobnie wiersze : Row1-PC6, Row2-PC7, Row3-PE6, Row4-PE2, Row5-PF7, Row6-PF6, Row7-PF5, Row8-PF4, Row9-PF1 oraz Row10-PF0.
Mój projekt składa się z 2 płytek ozn. MasterDMKey oraz DMKeyOut i realizuje funkcję matrycy diodowej oraz rozdzielacza sygnałów. Płytkę MasterDMKey zrobiłem na płycie uniwersalnej natomiast DMKeyOut zaprojektowałem w programie Eagle (darmowy ale z ograniczeniami).
Zadaniem płyty MasterDMKey jest wyprowadzenie uporządkowanych sygnałów z sterownika DMKeys8 na łączówki. Na schematach ideowym oraz montażowym jest opis sygnałów oraz sposób ich wyprowadzenia na łączówki. W moim projekcie powielone wiersze są wyprowadzone na 5 łączówek 16 pin co daje możliwość podłączenia 5 płyt DMKeyOut. Z płytą MasterDMKey współpracują płyty córki DMKeyOut, które są matrycami diodowymi z 32 wyjściami. Można zrobić uproszczoną wersję płyty MasterDMKey wyprowadzając 16 kolumn C1-C16 na jedną łączówkę 16 pin. Powielenie sygnałów można zrobić podłączając odpowiednio do taśmy sygnałowej łączówki (tak jak w pc). Ja zrobiłem wersję tzw. gwiazdy tzn. 5 niezależnych kierunków rozprowadzania sygnałów.
Płyta master ma wyprowadzone 5 par wierszy na łączówkach 2 pin.
Płyty córki DMKeyOut są takie same. Połączenie łączówki 2 pin RA, RB z płytą master decyduje, które wyjścia są realizowane. Jest to opisane na schemacie ideowym oraz montażowym płyty MasterDMKey.
Mam już zrealizowaną płytę MasterDMKey, jest pokazana na zdjęciu. Zrobiłem także projekt płyty DMKeyOut w Eagle. Jestem na etapie trawienia miedzi metodą domową. Dokumentację umieszczę na stronie EGHI.
Reasumując, mój projekt jest jedną z propozycji praktycznego zastosowania DMKeys8 do realizacji sterowania przełączników, przycisków lub enkoderów w kokpicie.
(http://img515.imageshack.us/img515/4453/masterdmkey.th.jpg) (http://imageshack.us/photo/my-images/515/masterdmkey.jpg/)(http://img21.imageshack.us/img21/5480/masterdmkeymonta.th.jpg) (http://imageshack.us/photo/my-images/21/masterdmkeymonta.jpg/)(http://img211.imageshack.us/img211/9817/pytamdmkey.th.jpg) (http://imageshack.us/photo/my-images/211/pytamdmkey.jpg/)
(http://img829.imageshack.us/img829/273/dmkeyout.th.jpg) (http://imageshack.us/photo/my-images/829/dmkeyout.jpg/)(http://img833.imageshack.us/img833/8113/dmkeyoutmonta.th.jpg) (http://imageshack.us/photo/my-images/833/dmkeyoutmonta.jpg/)
-
Vito, Damos,
Jeszcze raz gratulacje i podziekowania za Wasza prace...
Mam tylko pytanie, gdzie mozna znalezc schemat plytki DMKeys8 (najlepiej w pdf-ie) aby mozna bylo samemu wykonac taka plytke? Przekopalem cala strone Damosa i jakos nie znalazlem... Chyba ze cos mi umknelo (co sie moglo zdarzyc...).
-
Zobacz tutaj (files). Powinny być schematy oraz soft.
https://sites.google.com/site/damosmpds/file-cabinet
Myślę, że Damos da znać na forum. Zaglądał tutaj w lipcu. Przy okazji małe wyjaśnienie dotyczące nazwy mojej płytki DMKeyOut. Powinno być DMKeyInput, ponieważ to są wejścia, ale nie ma to znaczenia dla jej działania. Jeśli w praktyce trzeba inaczej rozprowadzić sygnały w kokpicie to można to zrobić na kilka sposobów np. zamiast 5 córek DMKeyOut zastosować większą ich liczbę i podłączać tylko tyle wejść ile potrzeba w danym miejscu (zamiast 32 np.12 itp.).
Za pomocą DMKeys8 można podłączyć 160 wejść. Kolejny projekt DMJoy będzie realizował oprócz wejść cyfrowych wejścia analogowe. Ten projekt jest w fazie projektowania oraz testów.
-
Vito - gratulacje! Niezły "pająk" :)
Mam tylko pytanie, gdzie mozna znalezc schemat plytki DMKeys8 (najlepiej w pdf-ie) aby mozna bylo samemu wykonac taka plytke? Przekopalem cala strone Damosa i jakos nie znalazlem... Chyba ze cos mi umknelo (co sie moglo zdarzyc...).
Schemat raczej nie będzie bardzo pomocny w samodzielnym wykonaniu. Obawiam się, że możesz nie dać rady samodzielnie wykonać tej płytki - jest dwustronna, ma metalizowane otwory i bardzo cienkie ścieżki.
(http://img715.imageshack.us/img715/8233/img4779iu.th.jpg) (http://imageshack.us/photo/my-images/715/img4779iu.jpg/)(http://img193.imageshack.us/img193/4957/img4778oj.th.jpg) (http://imageshack.us/photo/my-images/193/img4778oj.jpg/)
Nawet firma zajmująca się wykonywaniem płytek drukowanych miała problemy:
(http://img715.imageshack.us/img715/825/badboard.th.png) (http://imageshack.us/photo/my-images/715/badboard.png/)
Planuję udostępnienie możliwości zamówienia płytki w drukowane.pl tak, jak jest w przypadku Mjoy'a i płytki z enkoderami. Ze względu na niewielkie rozmiary płytka powinna kosztować kilka PLN. Jednak zanim opłacę u nich tę usługę chcę zakończyć testy DMJoy8, aby mieć pewność, że nie będzie konieczności wprowadzania zmian na płytce. Stworzenie dokumentacji umożliwiającej masowe zamawianie płytki nie jest najtańsze.
-
Damos,
Wielkie dzieki za rozjasnienie tematu... W takim razie czekam dalej i trzymam kciuki!
-
Córka DMKeyInput już gotowa. Zaprojektowana w Eagle, są tylko 2 mostki. Ścieżki są stosunkowo grube gwarantujące dobre lutowanie elementów.
(http://img838.imageshack.us/img838/5489/dmkeyd1.th.jpg) (http://imageshack.us/photo/my-images/838/dmkeyd1.jpg/)(http://img507.imageshack.us/img507/2071/dmkeyd2.th.jpg) (http://imageshack.us/photo/my-images/507/dmkeyd2.jpg/)
Płytkę DMKeyMaster byłoby trudno zaprojektować na druku jednostronnym (duża liczba mostków).
-
W ostatnim czasie kilka elementów w moim kokpicie uległo uszkodzeniu między innymi powrócił stary problem z jednym z moich MJoy. Mógłbym próbować zaprogramować nową kość uP, ale doszedłem do wniosku, że jest okazja zaimplementować nowy sterownik DMKeys8 zamiast MJoy.
Na pierwszym zdjęciu jest pokazany rozdzielacz sygnałów dla kilku paneli kokpitu z starym sterownikiem. Na drugim zdjęciu jest ten sam rozdzielacz, ale z DMKeys8. Na ostatnim jest DMKeys8, który można wymontować z rozdzielacza i użyć jako sterownik dla mojego ICP.
(http://imageshack.us/a/img407/6425/mmp71rozdzielacz.th.jpg) (http://imageshack.us/photo/my-images/407/mmp71rozdzielacz.jpg/)(http://imageshack.us/a/img404/5273/mdmkeys8rozdzielacz.th.jpg) (http://imageshack.us/photo/my-images/404/mdmkeys8rozdzielacz.jpg/)(http://imageshack.us/a/img11/341/mdmkeys8icp.th.jpg) (http://imageshack.us/photo/my-images/11/mdmkeys8icp.jpg/)
Na ostatnim zdjęciu widać, że DMKeys8 jest przykręcony do małej płytki, która posiada złącze szufladowe 16 pin do połączeń z ICP lub np. z rozdzielaczem sygnałów. Na tej płytce są także dwa złącza do połączeń z DMKeys8 (wiersze oraz kolumny matrycy). Płytkę można wykonać w Eagle. Mnie zależy na czasie dlatego druk uniwersalny. Teraz muszę zaprogramować uP w DMKeys8 zgodnie z poprzednim mapowaniem MJoy.
Na tych przykładach pokazałem jak można zaimplementować DMKeys8 dla potrzeb budowy paneli w kokpicie.
-
Znalazłem przyczynę nie działania mojego MJoy. Jest to stary problem tego sterownika. W moim przypadku po około 2 latach nastąpiło "samoistne" przeprogramowanie EEPROM w ATmego 16. Nie znam mechanizmu tego zjawiska, mogę tylko stwierdzić fakty. W MJoy pod adresem 004000 jest wpisane 8 istotnych bajtów określających nazwę, ID vendor oraz ID produktu. Jest to obszar pamięci EEPROM. Stosując kilka sterowników w tym np. 2 MJoye oraz SVMapper trzeba zmienić w jednym z MJoy nazwę oraz ID po to aby programy w pc prawidłowo interpretowały sterowniki.
U mnie "przeprogramowanie" polegało na tym, że 3 wymienione parametry name, ID vendor oraz ID product wróciły po 2 latach do pierwotnych wartości. PonyProg2000 umożliwia zarówno odczyt jak i zapis tych parametrów. Reasumując nie rozumiem tego zjawiska, ale jest to kolejny argument aby przejść na nowy sterownik Damosa.
-
W chwili obecnej DMKeys8 pełni rolę sterownika dla panelu ICP. Umieściłem go w box HUD dlatego, że jest łatwy do niego dostęp oraz ze względu na przewidywane w przyszłości testy nowego prototypu ICP, który projektuje Tomu.
(http://imageshack.us/a/img191/2355/micpu.th.jpg) (http://imageshack.us/photo/my-images/191/micpu.jpg/)
-
Mam tylko pytanie, gdzie mozna znalezc schemat plytki DMKeys8 (najlepiej w pdf-ie) aby mozna bylo samemu wykonac taka plytke? Przekopalem cala strone Damosa i jakos nie znalazlem... Chyba ze cos mi umknelo (co sie moglo zdarzyc...).
Wracam do tego pytania po analizie problemu wykonania samodzielnie montażu płytki DMKeys8. Moim zdaniem nie ma możliwości samodzielnego montażu tej płytki. Wymienię tylko 3 główne powody. Potrzeba wyspecjalizowanego sprzętu do lutowania, doświadczenia w montażu elementów smd szczególnie uP w obudowie TQFP44 oraz umiejętności w uruchamianiu sterownika.
DMKeys8 jest już sprawdzony i można go zamówić u Damosa na pw. Samodzielna próba montażu kończy się na ogół dużymi kosztami związanymi z uszkodzeniem elementów, dlatego Damos nie przewiduje takiej opcji. Jeśli się mylę to proszę o sprostowanie. Mam dosyć duże doświadczenie w tego typu projektach i dlatego zgadzam się z opinią Damosa.
-
Samodzielna próba montażu kończy się na ogół dużymi kosztami związanymi z uszkodzeniem elementów, dlatego Damos nie przewiduje takiej opcji.
To nie do końca tak :) Jak najbardziej przewiduję możliwość samodzielnego montażu. Informowałem jednak Vito, że nie jest to prosta sprawa, ponieważ wymaga:
- dobrej lupy (80 PLN)
- stacji lutowniczej (uziemiony grot, regulowana temperatura) (300PLN - 2500 PLN)
- grotów typu "minifala" (10-60 PLN)
- dobrego topnika w żelu lub płynie (absolutnie nie kalafonia) (80 PLN)
- stabilnego mocowania płytki podczas lutowania (30-200 PLN)
- ok. godziny czasu na zmontowanie i uruchomienie płytki
trzeba się liczyć z tym, że jeśli podczas lutowania za bardzo rozgrzejesz układ scalony lub laminat - jeden albo drugi ulegną uszkodzeniu. Równie dobrze możesz kupić uszkodzony układ scalony (rzadkie, ale możliwe) lub uszkodzoną płytkę (zdarzyło mi się odebrać z drukowane.pl płytki z poprzerywanymi ścieżkami). W przypadku uszkodzenia płytki lub układu scalonego zestaw po zmontowaniu nie ruszy i praktycznie jest do wyrzucenia (wylutowanie uC bez uszkodzenia płytki lub układu scalonego jest dużo trudniejsze niż przylutowanie). Więc dla tych, którzy nie chcą podjąć ryzyka - zmontuję płytki, uruchomię i wyślę.
Na razie płytkę czekają jeszcze kosmetyczne zmiany spowodowane ułatwieniem używania jako DMJoy (dodatkowe piny dla zasilania osi analogowych) i wtedy będę gotowy do realizacji zamówień. Wystawię również gerbery - aby każdy mógł wykonać płytkę w dowolnym zakładzie.
Jednak nadal gorąco zachęcam do prób samodzielnego montowania! W przypadku powodzenia daje to ogromną satysfakcję! W przypadku niepowodzenia może być frustrujące. Sam zniszczyłem kilka układów zanim opanowałem montaż TQFP44 :)
-
Zrobiłem druk pod moje potrzeby dla panelu ICP. Można ten projekt wykorzystać jako interfejs dla DMKeys.
(http://img689.imageshack.us/img689/2637/mdruk.th.jpg) (http://imageshack.us/photo/my-images/689/mdruk.jpg/)(http://img842.imageshack.us/img842/9942/mdmkeyspyta.th.jpg) (http://imageshack.us/photo/my-images/842/mdmkeyspyta.jpg/)(http://img401.imageshack.us/img401/6449/mdmkeysinter.th.jpg) (http://imageshack.us/photo/my-images/401/mdmkeysinter.jpg/)
Na płycie są 3 łączówki pin 10, pin 14 oraz pin 16. Wyprowadzenia dla ICP są na łączówce pin 14 na pozostałych jest wyprowadzona pełna matryca tzn. 16 kolumn oraz 10 wierszy co daje 160 wejść. Dokumentacja będzie dostępna na stronie EGHI. Podziękowania dla Damosa za wspaniały sterownik.
-
...Na razie płytkę czekają jeszcze kosmetyczne zmiany spowodowane ułatwieniem używania jako DMJoy (dodatkowe piny dla zasilania osi analogowych) i wtedy będę gotowy do realizacji zamówień. ...
Witaj Damos, jako ze na forum dosc dlugo panuje bezruch zwracam sie z pytaniem o stan rozwoju DMJoy-a, czy jest jeszcze w fazie testow i zmian czy juz doszliscie z vito_zm do produktu finalnego?
Jesli juz DMJoy jest dostepny jako produkt finalny to z przyjemnoscia zamowilbym jeden taki uklad --> szczegoly pewnie na Priv, tak?
Pozdrawiam
-
Ostatnio Damos zmieniał mikrokontroler na zapewniający trochę więcej możliwości zabawy z nim, więc prace nadal są w toku.
-
Ja tez bylbym chetny :].
Wielka litera i kropka w prezencie od Zfrr.
-
Widać, że chętnych jest coraz więcej. Ja wymieniłem u siebie 2 MJoy na 2 DMKeys8, ale jeden MJoy jest podłączony tylko ze względu na jedno wejście analogowe, które potrzebuję dla pedałów.
-
Dziekuje koledzy za update... W takim razie czekamy dalej... Jedynie prosba o troche czestsze relacje z pola walki, choc to troche nam umili czekanie...
-
Jedynie prośba o trochę częstsze relacje z pola walki, choć to trochę nam umili czekanie...
Ostatni MJoy został zamieniony na DMJoy8. Konfiguracja jest na załączonym zdjęciu.
(http://img5.imageshack.us/img5/7632/mdamossterowniki.th.jpg) (http://imageshack.us/photo/my-images/5/mdamossterowniki.jpg/)
DMJoy8 jest w starej wersji zapewniającej 6 wejść analogowych. Pracuje bardzo stabilnie. Nowa wersja DMJoy8 będzie zrealizowana na takiej samej płytce jak DMKeys8. Wkład (program hex) będzie decydował jaki realizuje sterownik. Ja korzystam tylko z jednej osi "obrót Z", która steruje pedałami. Pedały są podłączone szeregowo do 2 pot. o wartości 51 k. Damos ograniczył pot do wartości 10 k (zalecenie), ale jak widać działa bez problemu.
Nowa płytka ma dodatkowe elementy bierne w postaci dławików oraz pojemności blokujących. Aktualnie ją testuję pod kątem analogów. Damos rozbuduje funkcje DMJoy o realizację przycisków, przełączników oraz enkoderów, dlatego to trochę potrwa. To tyle z placu boju...
-
Witam
Wlasnie skonczylem czytanie tego watku i podobnie jak kolega kosiu jestem zainteresowany wykonaniem plytek do projektu Damosa, i tak jak wyzej wspomniany kolega nie moge nigdzie znalezc schematow. Jesli chodzi o wykonanie plytek mysle ze nie powinno mi to sprawic zadnych problemow, a nawet gdyby to zawsze mozna skorzystac z adaptera TQFP-44 na DIP.
Koledzy Chinczycy produkuja przynajmniej kilka roznych typow tego adaptera dla tego zlacza.
Niestety nie wiem czy mozna takowe znalezc na allegro poniewaz sprawdzalem jedynie na ebay. Co do lutowania, to swojego czasu w porywie despeacji przykleilem procka do druku klejem przewodzacym.
Chetnie zakupilbym gotowe plytki ale pewnie koszty przesylki bylyby wyzsze niz same plytki poniewaz mieszkam za kaluza.
Tak ze jesli bylaby taka mozliwosc i dobre checi ze strony wszystkich wspoltworcow tego projektu bylbym wdzieczny za pomoc.
Przepraszam za brak polskich literek i pozdrawiam
Andrzej
-
Płytki są tak małe i lekkie, że można będzie kilka upchać do koperty bąbelkowej i wysłać jako list ;)
-
nie moge nigdzie znalezc schematow.
Dostępnych schematów jeszcze nie ma, ale będą tak jak obiecał Damos.
zawsze mozna skorzystac z adaptera TQFP-44 na DIP
Nie ma potrzeby. Polutowałem DMKeys8 korzystając tylko z pasty lutowniczej i zwykłej lutownicy. Damos jest twórcą projektu i tylko on decyduje o dokumentacji. Mam u siebie w kokpicie jego 3 sterowniki ale na tej zasadzie, że je testuję i muszę przyznać, że DMKeys8 spisuje się bardzo dobrze. DMJoy8 także jest zainstalowany, ale jeszcze trzeba z tym sterownikiem poczekać. DMKeys8 może już być rozpowszechniany do stosowania. Myślę, że Damos zadecyduje w jakiej formie będzie dostępny. Będzie w Polsce przed świętami i powinien dać odpowiedź.
-
W takim razie poprosze na priv o info w sprawie zakupu.
-
Musisz poczekać na powrót Damosa do kraju i go zapytać na priv o informację. Ja jestem tylko "testerem".
-
o zawsze mozna skorzystac z adaptera TQFP-44 na DIP.
Koledzy Chinczycy produkuja przynajmniej kilka roznych typow tego adaptera dla tego zlacza.
Obawiam sie, że taki adapter podwoił by koszt projektu :)
Chetnie zakupilbym gotowe plytki ale pewnie koszty przesylki bylyby wyzsze niz same plytki poniewaz mieszkam za kaluza.
W takim przypadku optymalne wydaje się wysłanie płytek bez pin-headereów. Te każdy sam może sobie przylutować a paczka będzie mniejsza i mniej podatna na uszkodzenia.
DMKeys8 może już być rozpowszechniany do stosowania.
Soft na PC należy pozbawić komunikatów diagnostycznych i można myśleć o dystrybucji. Kilka okien powinno być bardziej "user friendly".
-
Witaj Damos.
Myślę o rozbudowie mojego hadware'u, to co potrzebuję docelowo, to obsłużenie dziesięciu osi, kilkudziesięciu enkoderów (min 25 sztuk) ok 35 przełączników hebelkowych ON-OFF, ON-OFF-ON, ok 30 przełączników obrotowych oraz od groma przycisków (na pewno więcej niż 150).
Mam prośbę o małą radę w temacie oraz o możliwość zrealizowania tego za pomocą Twoich płytek i softu.
Obecnie mam kontrolery:
Saiteka - obsługujące wolant, orczyk, hamulce, przepustnice i rewersy, speedbraki, klapy - jak zrobię we własnym zakresie sterownice - cały Saitek poza pedałami pójdzie do pudełka i pewnie na Allegro.
M-joy16 - obsługujący 3 kolejne osie - sterowanie przednią golenią, ruder i aileron trim
Ponadto do m-joya podłączone są dwie płytki dla enkoderów oraz trochę przycisków i przełączników
Mam dylemat, czy skorzystać całkowicie z nowego, Twojego hardware'u (np. 2 x DMJoy8) , czy np. zostawić m-joya oraz użyć dla nieobsłużonych jeszcze przycisków,przełączników i enkoderów DMJoy8.
Tu małe info - do X-plane'a nie potrzeba SVmappera - symulator ma wbudowany mapper
Od razu mam prośbę, czy jest już możliwość zakupienia np. dwóch DMJoy8 (nie dam rady poklecić we własnym zakresie). Czy nie ma problemu z obsługą w pełnym zakresie tych kontrolerów razem w jednym czasie pod windą 7 64bit itp.
Z góry dziękuję za info
PS (jak coś to spadam na tydzień na urlop ;))
-
Damos odpowie na temat możliwości realizacji DMKeys8 oraz DMJoy oraz związanych z nimi pytań. Ja mogę tylko przedstawić swoją konfigurację, w której są sterowniki Damosa. Swój kokpit rozbudowywałem w ciągu paru lat, dlatego powstał pewien bałagan sprzętowy, który próbuję teraz uporządkować. Rozpocząłem od MJoy 16 tak jak wszyscy. Były na początku pewne ograniczenia, ale pojawienie się SVMapper zwiększyło możliwości kontrolera. Następnie dokupiłem sterowniki od OpenCockpits, gdzie były także możliwości podpięcia przełączników. Kokpit się rozbudowywał i trzeba było dołożyć kolejny MJoy 16. Dołożenie dwóch ramek MFD uniemożliwiło zastosowanie programu SVMapper, ponieważ ma on pewne ograniczenia, polegające na tym, że widzi tylko 4 kontrolery. U mnie był Cougar, dwie ramki MFD oraz MJoy 16. Pojawienie się platformy HSC codeking z naszego forum rozwiązało problem zastosowania drugiego MJoy 16. W tym momencie ta konfiguracja wystarczyła do sterowania mojego kokpitu. Kokpit był nadal rozbudowywany i brakło wejść dla sterowania przyciskami. Pojawił się na naszym forum nowy sterownik zrobiony przez codeking SimOUT oraz SimIN. Zastosowałem u siebie obydwa sterowniki i miałem problem rozwiązany do momentu awarii jednego z MJoy 16. W tym momencie postanowiłem wymienić MJoy 16 na DMKeys8 oraz DMJoy. W chwili obecnej mam u siebie dwa DMKeys8 oraz jeden DMJoy. Dlaczego o tym piszę. Jeśli ktoś jest na etapie początkowym projektu to dobrze jest mieć koncepcję całości a nie robić to etapami tak jak w moim przypadku.
Dobrym przykładem jest dreju, który kupił gotowe rozwiązanie sterowania kokpitu F16. Wracając do twojej konfiguracji to jeśli MJoy 16 pracuje poprawnie i nie jest sterowany z SVMapper to można go zostawić ma 8 wejść analogowych. DMKeys8 Damosa jest widziany jako klawiatura i nie potrzebuje wsparcia programowego. Na dzień dzisiejszy DMKeys8 nie obsługuje analogów i odwrotnie DMJoy nie obsługuje przycisków i enkoderów. Ja jestem zadowolony z sterowników Damosa. Tyle moich uwag na resztę odpowie autor projektu.
-
Witaj Damos.
Myślę o rozbudowie mojego hadware'u, to co potrzebuję docelowo, to obsłużenie dziesięciu osi, kilkudziesięciu enkoderów (min 25 sztuk) ok 35 przełączników hebelkowych ON-OFF, ON-OFF-ON, ok 30 przełączników obrotowych oraz od groma przycisków (na pewno więcej niż 150).
Mam prośbę o małą radę w temacie oraz o możliwość zrealizowania tego za pomocą Twoich płytek i softu.
Dwa DMKeys8 powinny dać radę.
Mam dylemat, czy skorzystać całkowicie z nowego, Twojego hardware'u (np. 2 x DMJoy8) , czy np. zostawić m-joya oraz użyć dla nieobsłużonych jeszcze przycisków,przełączników i enkoderów DMJoy8.
Można zacząć od DMkeys8 ze starym MJoyem.
Od razu mam prośbę, czy jest już możliwość zakupienia np. dwóch DMJoy8 (nie dam rady poklecić we własnym zakresie). Czy nie ma problemu z obsługą w pełnym zakresie tych kontrolerów razem w jednym czasie pod windą 7 64bit itp.
Płytki da się załatwić. Są identyczne zarówno dla do DMKeys jak i DMJoy. Pracują bez problemów pod Windows 98, XP 32/64, Vista, Windows 7(32/64), Windows 8, MacOS, Linuxem.
Na dzień dzisiejszy DMKeys8 nie obsługuje analogów i odwrotnie DMJoy nie obsługuje przycisków i enkoderów.
Mam już wersję DMJoy, która obsługuje nieco przycisków i własnie dodaję enkodery.
-
W związku z zainteresowaniem sterownikiem DMKeys8 chciałbym uzupełnić swoje post związane z rozdzielaczami sygnałów o których pisałem w tym wątku. Na początek małe przypomnienie organizacji matrycy w DMKeys8. Tworzy ją 16 kolumn oraz 10 wierszy co daje 160 pozycji do zaprogramowania. Jest to pokazane na załączonym rysunku.
(http://img854.imageshack.us/img854/6964/cxn9.th.jpg) (http://imageshack.us/photo/my-images/854/cxn9.jpg/)
W tym wątku http://il2forum.pl/index.php/topic,13149.255.html #263 przdstawiłem swoją propozycję organizacji rozdzielaczy sygnałów dla tej matrycy. W pierwszym rzędzie pokazany jest schemat ideowy, montażowy (poglądowy) oraz model płytki nazwanej umownie MasterDMKey zrobionej na druku uniwersalnym. Jak widać na zdjęciach kolumny oznaczone C1-C16 są wyprowadzone na 5 łączówek 16 pin. Wiersze (row1-row10) są wyprowadzone z sterownika na łączówkę JP6 i pogrupowane po 2 oraz wyprowadzone na złącza 2 pin.
Płyta ozn. umownie MasterDMKey łączy się z 5 córkami poprzez sznur 16 pin oraz dwa przewody do złącza 2 pin.
Schemat ideowy i montażowy córki umownie nazwanej DMKeyOut jest pokazany na kolejnych 2 rysunkach. Do każdej córki można podłączyć np 32 przyciski. Do wszystkich córek (pięciu) można podłączyć 160 przycisków. Podłączamy jeden koniec przycisku do wyjść ozn. Out 0 - Out31 a drugi koniec do RA lub RB. Proponowana organizacja rozdzielacza daje rozdzielenie 160 sygnałów na 20 mniejszych grup po 8 sygnałów (diody są już na córkach). Można to inaczej zorganizować w zależności od własnych potrzeb.
W innym miejscu w tym wątku #274 umieściłem DMKeys8 na płytce, na której mam wyprowadzenia 16 kolumn na złączu 16 pin oraz 10 wierszy na złączu 10 pin. Dodatkowo mam wyprowadzone sygnały dla ICP, które potrzebuje tylko 25% pojemności matrycy.
Na koniec kilka ogólnych uwag. Przedstawione przykłady pokazują jak można praktycznie zorganizować matrycę stosując sterownik DMKeys8. Można to zrobić na kilka sposobów w zależności od potrzeb i wiedzy użytkownika. Można np. zamiast powielać sygnały C1-C16 na łączówkach w MasterDMKey zrobić to na taśmie 16 żył zaciskając łączówki 16 pin coś podobnego jak w pc. Można także zamiast połączeń przewodami DMKeys8 i MasterDMKey zrobić to przy pomocy "odpowiedniej podstawki" lub lutując piny wprost do druku (piny w DMKeys8 lutowane z drugiej strony, tylko jeden rząd). Jak widać można zrobić rozdzielacz sygnałów na wiele sposobów. Mam nadzieję, że nie zamieszałem.
Sposób łączenia przełączników 2, 3 pozycyjnych, obrotowych i enkoderów wynika z sposobu konfigurowania DMKeys8. Tutaj Damos może to lepiej wyjaśnić. Dodam tyko, że jest to lepiej zrobione niż w SVMapper.
-
Dzięki Vito.
Wreszcie zaczynam rozumieć o co w tym chodzi.
Zaczynam widzieć światełko w tunelu ;D i po woli klaruje mi się końcowa wizja elektroniki.
Np komputer pokładowy CDU posiada 78 przycisków (plus ewentualnie 2 dodatkowe). DMkeyOut można wprojektować bezpośrednio w płytkę z przyciskami lub w zespół płytek z przyciskami i taśmą ze stosunkowo niedużą liczbą przewodów połączyć z "matką" i DMkeys8
Kurcze - niesamowite możliwość.
-
Kurcze - niesamowite możliwość.
O to właśnie chodzi, że można elastycznie rozwiązać problem rozprowadzania sygnałów. Ja założyłem minimalną grupę sygnałów z mapy matrycy równą osiem. Można w danym punkcie kokpitu wykorzystać tylko np. 5 a w innym pozostałe 3 robiąc odpowiednio sznur 10 pin.
Zobaczysz zalety DMKeys8 po zaprogramowaniu uP. Uruchamiając kokpit można zapomnieć, że istnieją w systemie DMKeys8. Jest to zaleta, w moim przypadku muszę uruchomić kolejno kilka programów aby wystartował symulator.
-
Hi.
Wczoraj zrobiłem kilka pierwszych płytek drukowanych - powiem szczerze, że jest to znacznie prostrze, niż mi się do tej pory wydawało.
W wielu tematach był to dla mnie psychiczny blocker, przed pójściem dalej.
Co prawda na razie zrobiłem płytki do panelu autopilota - mają one łączyć: diody - SimOUT oraz wyjścia na enkodery i przyciski do DMkeys8.
W sumie 18 przycisków w tym 5 w enkoderach, 6 enkoderów i 13 par diod.
-
Czy zrobiłeś tylko pcb czy masz już gotowe fizycznie płytki zrobione metodą domową. Czy robiłeś sam pcb jeśli tak to w jakim programie. Moje robiłem w Eagle (free), który ma niestety ograniczenia 100x80mm.
-
Gotowe płytki - w sumie cztery sztuki - jedna jest już powiercona i ma wlutowany enkoder i switch.
Płytki robiłem w PCB Artist - bardzo prosty program, ale ma wiele ograniczeń, albo funkcjonalności, których nie potrafię użyć. Być może w wersji free są one nieaktywne. Na początek wystarczy: http://www.4pcb.com/
Muszę tego Eagla rozpracować - dla dalszych elementów powierzchnia 100x80 będzie wystarczająca.
-
Rozumiem, ze masz wersję free. Czy jest w tej wersji ograniczenie wymiarów projektowanej płytki tak jak w Eagle.
-
Muszę tego Eagla rozpracować - dla dalszych elementów powierzchnia 100x80 będzie wystarczająca.
W tym mogę Ci pomóc, jeśli będzie trzeba.
-
Hi.
Vito - ten program w wersji za free nie ma ograniczeń co do powierzchni - nie rozpracowałem jeszcze innych funkcji - na razie tylko proste ścieżki.
Z pod programu drukuje się bardzo prosto, można normalnie, można w odbiciu lustrzanym, wg wyboru warstw, itp.
Damos - wielkie dzięki - na pewno się przyda wszelka pomoc.
Co do moich dzisiejszych i wczorajszych prac domowych - walczę z panelem autopilota. Na razie jestem na półmetku, może w 1/3. Więcej jak zwykle na blogu i na Imgurze.
Na razie przetestuję na Mjoyu - dodatkowo w płytkę są wlutowane zielone diody (po 2 na każdy przycisk) na razie 4 sztuki. One będą podłączone do SimOUTa.
http://i.imgur.com/S2gHFG0.jpg
http://i.imgur.com/1r068Zb.jpg
http://i.imgur.com/AhWa5eV.jpg
-
Ostatnio postanowiłem zrobić joystick (3 osie) na bazie ATmega8 i bibliotek z obdev do USB. Właściwie wszystko już działa, ale naszła mnie pewna wątpliwość dotycząca kwestii pomiarów z ADC. Mianowicie, co pomiar z poszczególnego kanału zapisuje wynik i zmieniam kanał na kolejny. I tu moje pytanie do osób zajmujących się DMJoy. Uśredniacie wyniki pomiarów? Analizujecie je pod jakimkolwiek kątem? Czy po prostu, to co dostaniecie z ADC trafia "bezpośrednio" do PC?
-
naszła mnie pewna wątpliwość dotycząca kwestii pomiarów z ADC. Mianowicie, co pomiar z poszczególnego kanału zapisuje wynik i zmieniam kanał na kolejny. I tu moje pytanie do osób zajmujących się DMJoy. Uśredniacie wyniki pomiarów? Analizujecie je pod jakimkolwiek kątem? Czy po prostu, to co dostaniecie z ADC trafia "bezpośrednio" do PC?
Strach ci cokolwiek odpowiedzieć, bo bardzo nerwowo reagujesz, ale niech będzie....
Nie żebym ci wmawiał, że tak trzeba, ale w DMJoy8 robię oversampling na każdej osi, nie pamiętam teraz jakiego stopnia... prawdopodobnie 32-krotny. Więc zamiast 12-tu pomiarów robię ich 384.
Używasz trybu uśpienia na czas pomiaru na wejściu ADC?
-
Nie używam trybu uśpienia. Mając wynik z 32 pomiarów uśredniasz go później?
-
Oczywiście, że uśredniam, do tego podbijam rozdzielczość z 10 do 12 bitów przy akceptowalnej stabilności (Vito_zm testował).
U ciebie to raczej nie ma sensu - bo masz 9 bitów na rudder i po 7 na hamulce... To raczej downsampling niż oversampling :)
-
No to muszę pomyśleć o tym uśrednianiu, zwłaszcza, że jedyne potencjometry zamienne, które pasują mi do orczyka, to jakieś chińskie dziadostwo. Na hamulce 7 bitów wystarcza, ale finalnie może się okazać, że i tak użyje tam standardowego projektu joystick'a na hid i rudder będzie miał 10 bitów.
Dzięki za informacje.
PS. Swoją drogą mam ostatnio mało czasu wolnego, ale jakbyście potrzebowali wsparcia programisty, to może będę w stanie troszkę pomóc.
-
W czasie moich testów związanych z modem do Cougara pojawił się problem kalibracji osi x, y. Opisałem to tutaj http://il2forum.pl/index.php/topic,15831.new.html#new . W związku z moimi problemami z uzyskaniem pełnego zakresu wychyleń osi w układzie DMJoy oraz program DIView zastanawiam się czy jest sens zrobienia opcji w konfigurowaniu DMJoy regulacji zakresu wychyleń osi. Nie ma problemu jeśli na wejściach analogowych DMJoy podłączymy potencjometry. Pytanie czy jest sens zrobienia opcji podobnych trochę do konfiguracji Cougara. Z drugiej strony stary MJoy nie posiadał możliwości ustawiania profilu i był bardzo przydatny. Pozostawiam ten temat pod dyskusję.
-
Chciałbym uzupełnić mój ostatni post. Po zastanowieniu się doszedłem do wniosku, że w 99.9% nie ma potrzeby komplikować konfiguracji DMJoya. Mój przypadek jest wyjątkiem poza tym mod ma pracować z sterownikiem Cougara, gdzie jest możliwość ręcznej kalibracji wszystkich osi. Nie wiem jak to jest zrobione programowo, mogę się tylko domyślać. Kalibracja ręczna w Cougarze polega na wykonaniu sekwencyjnym pełnych wychyleń osi na czas 3 sek. Prawdopodobnie program przyjmuje to jako wartości graniczne i przelicza stopień kwantyzacji tak myślę, ale może być inaczej. Tak czy owak jest to komplikacja programowa i dla pojedynczych przypadków nie warta rozpatrywania.
-
Można dodać jakąś formę kalibracji w DMJoy -nawet taką, jak w Cougarze - każdą z osi wychylić na kilka sekund w lewo, w prawo i pozostawić na środku - później zostanie już tylko przeliczenie wartości, co nie jest specjalnie skomplikowane.
-
....później zostanie już tylko przeliczenie wartości, co nie jest specjalnie skomplikowane.
Ja się tego najbardziej obawiałem. Swoją drogą zastanawiam się dlaczego w Cougarze jest wymagane stworzenie tzw. profilu dla osi. Mam na myśli tylko wartości graniczne wychyleń. Jeśli program zna wartość napięcia z pc (USB) oraz zalecaną wartość pots oraz parametry przetwornika A-C to może obliczyć stopień kwantyzacji. Czy jeszcze jest jakiś parametr decydujący o dokładności "obliczeń". Nie biorę pod uwagę mojego przypadku, ponieważ jest to jakiś wyjątek (elektronika zamiast "gołego" potencjometru). W MJoy nikt się przejmował wartościami granicznymi osi.
-
Oczywiście, że jest wartość odpowiadająca za dokładność. To ekstrapolacja mniejszego zakresu na większy. Jeśli przetwornik A/D ma rozdzielczość 12bit (wartości od 0 do 4095) w zakresie od 0 do 5V, to w przypadku konieczności zmapowania takiego zakresu wyjściowego z wejścia od 1,25V do 3,75V pozostanie nam widoczny zakres od 0 do 4095, ale ze skokiem co 2. Więc tylko 2048 różnych wartości.
-
.....z wejścia od 1,25V do 3,75V pozostanie nam widoczny zakres od 0 do 4095, ale ze skokiem co 2. Więc tylko 2048 różnych wartości.
Masz oczywiście całkowitą rację, mnie się wydawało, że kalibrując Cougara programem CCP mamy stałe napięcie na wejściach analogowych zależne od napięcia zasilacza pc.
W moim przypadku musi być tak jak to określiłeś ekstrapolacja mniejszego zakresu na większy, ponieważ moje wartości graniczne są mniejsze z powodu zastąpienia potencjometrów na wejściach analogowych osi x, y układami elektronicznymi.
-
Witam
Z góry przepraszam jeżeli pytania będą banalne lub idiotyczne, elektronika ani tym bardziej programowanie to zupełnie nie mój konik (grafik), ale pasja do wirtualnego latania i majsterkowania jest ;) Przeleciałem z grubsza temat i jeżeli pytania się gdzieś powtarzają to bardzo przepraszam, umknęło mi to. Chciałem zbudować sobie pedały, bo skrętne joysticki doprowadzają mnie do szewskiej pasji powoli, ale jak zobaczyłem, że każdy dostępny kontroler na rynku dla domowych pitbuilderów obsługuje 8 osi i multum przycisków to żal zostawić, żeby się marnowały ;) W sumie mógłbym sobie kupić te pedały, ale 400zł za wątpliwej jakości produkt wykonany z trzeszczącego plastiku (najtańsze pedały Saitek'a lub CH) to w moim odczuciu kiepski biznes.
- czy jest możliwość, żeby zamiast dużej ilości przycisków kontroler obsługiwał 4 lub 5 HAT'ów 4-kierunkowych+kilka przycisków?
- czy można bez problemu podłączyć potencjometry HALL? Myślałem o montażu potencjometrów posiadających odczyt 90 stopni dla pedałów i podobnie dla trimów i ew. przepustnicy (chociaż tam chciałbym zamontować zbliżeniowy czujnik magnetyczny i samą przepustnicę wrzucić na szynę na łożyskach jednak nie jestem jeszcze do końca pewien skąd go wezmę :) w ostateczności wybebeszę z rosyjskiej przepustnicy Gametrix ECS - byłaby idealna gdyby nie fakt, że potrzebuję podwójną przepustnicę :()
- jak jest z opóźnieniami?
- czytałem, że jest plan aby zrobić budowę modułową - czy jest szansa aby poszczególne moduły wedle potrzeb podłączać bezpośrednio do siebie i aby całość działała na 1 kablu USB (oczywiście tak długo jak wszystko będzie zgodne z HID, czyli bodaj 8 osi i 32 przyciski?)
- czy jest możliwość zamówienia mini-płytki, która obsługiwała by tylko 3 osie?
- czy długość kabli od osi/przycisków do płytki ma wpływ na ogólną jakość działania kontrolera?
- płytka obsługuje określoną liczbę przycisków - czy jest możliwość stworzenia przełącznika trybów? Jeżeli tak to ma ktoś pojęcie jak to wykonać? Chodzi mi o taki "bajer" dostępny w większości sklepowych joysticków - np. w Saitek Aviator jest to pokrętło , które można przestawić w 3 tryby, w Defender Cobra M5 jest to zwykły 3-pozycyjny suwak, itp. dzięki którym te same przyciski odpowiadają za kolejne funkcje
Poza tym jak tam progres? - ostatni update w temacie był ponad 3 miesiące temu. Kiedy będzie można zamawiać? Jakie ceny? Chciałem złożyć swój "kokpit" przed premierą IŁ2: Battle of Stalingrad. Teraz latam głównie IŁ2 1946 oraz Rise of Flight, z kolei DCS czy FSX rzadziej.
Zamysł jest na razie taki (czy taki będzie do samego końca okaże się w praniu, bo jeszcze nie namierzyłem miejsca sprzedaży wszystkich potencjometrów, przycisków, enkoderów i HATów, których chciałbym użyć):
- joystick chciałem zbudować na bazie bebechów Defender Cobra M5 (lata na sensorach magnetycznych, posiada 2-stopniowy spust, 1 "dolny spust", 2 przyciski i 3-pozycyjny przełącznik funkcji - całkowicie pozbyłbym się podstawy, a elektronikę wsadził do nowej, własnej produkcji + wymieniłbym plastikowy gimbal na swoją metalową konstrukcję na łożyskach - z czasem wymieniłbym też "rękojeść" na drążek ~30-40cm - nie jestem jeszcze pewien, bo nie wiem jak wygląda płytka w Cobrze w środku drążka, a nie mam za bardzo dostępu do precyzyjnej lutownicy - przy sprzęcie który posiadam równie dobrze mógłbym to próbować zrobić młotkiem albo spawarką...)
- pedały (3osie)
- przepustnicę (7 osi, 3x HAT 4-kierunkowy, 2x HAT 2-kierunkowy, z 5 przycisków)
- przystawkę do przepustnicy (8 osi; przycisków ile wlezie, może jakiś enkoder tu i ówdzie)
Jeżeli chodzi o możliwość wykonywania elementów mechanicznych i/lub obudów to użytkownik jednego z for zaoferował swoją pomoc, ma dostęp do ekstrudera polipropylenu homopolimerowego więc jak zrobię odpowiednią formę (z tym akurat dam sobie radę, wreszcie te wszystkie lata rzeźby i innych totalnie zbędnych dziedzin przez które musiałem przebrnąć się przydadzą) to pewnie będzie można na kilogramy tego trzaskać za niewielką opłatą :) Pierwszy prototyp wydziergam najprawdopodobniej z drewna lub wyrzeźbię z gliny i wykonam wydmuszkę z masy papierowej, na polipropylen przyjdzie czas jak już wszystko zostanie skonfrontowane z rzeczywistością i dopracowane - jeżeli pomysł wypali to dwóch znajomych chętnie zakupi dodatkowe płytki i materiały na własne egzemplarze.
Za projekt mam zamiar pełną parą wziąć się w lutym i do końca wiosny go skończyć, niemniej już teraz muszę sobie wszystko dokładnie rozplanować żeby wiedzieć na czym stoję, stąd moje pytania.
Z góry dziękuję za odpowiedzi i pozdrawiam
Gildart
-
Witamy na forum. Poruszyłeś kilka ciekawych tematów. Z tego co napisałeś wynika, że masz zamiar zbudować pedały, joystick oraz przepustnicę częściowo na bazie istniejących rozwiązań (Defender Cobra M5 ) i to w stosunkowo krótkim czasie. Ponieważ projekt "kokpitu" jest ciekawy i obejmuje praktycznie kilka mniejszych projektów to proponuję założyć oddzielny wątek w którym będziesz mógł przedstawić postęp prac i problemy do rozwiązania i gdzie można będzie konsultować problemy. W chwili obecnej kilku kolegów buduje swoje kokpity i pewne problemy mogą być podobne. Dobrze byłoby przenieść to co napisałeś do tego nowego wątku, tutaj kolega KosiMazaki może pomóc. Tyle mojego wstępu.
Jeśli chodzi o konkretne pytania to odpowiem na nie ogólnie, ponieważ pytań jest dużo i myślę, że będziemy na nie kolejno odpowiadali.
Rozpocznę od sterowników Damosa, które zastępują MJoya. Na tych sterownikach część kolegów buduje swoje kokpity lub panele. Są dwa sterowniki DMKeys8 oraz DMJoy. Generalnie różnią się tym, że ten drugi realizuje analogi a pierwszy steruje pozostałymi elementami: przyciski, przełączniki, enkodery haty. Damos przewidział problemy z zakłóceniami związanymi z kiepskimi enkoderami oraz długością przewodów i w jego programie konfiguracyjnym można ustawić odpowiednie parametry. Jest zamiar rozbudowy DMJoy o nowe funkcje związane z przyciskami oraz innymi elementami. Na dzień dzisiejszy możesz rozwiązać swoje problemy stosując wymienione dwa typy sterowników Damosa.
Damos także chce wymienić elektronikę w Cougarze na swój zmodyfikowany sterownik. Modyfikacja dotyczy drążka oraz przepustnicy i będzie ciekawym rozwiązaniem opartym na styku IC2 a nie na równoległych sygnałach tak jak w oryginale. To rozwiązanie może być dla Ciebie interesujące.
Drejku oraz ja próbujemy także zrobić mod do Cougara zamieniając pots na sensory, ten temat jest w trakcie realizacji.
Celowo nie wchodzę w szczegóły sterowników Damosa ponieważ uważam, że autor wyjaśni to dokładniej. Sterowniki są u niego zamawiane i są tańsze w porównaniu do cen zachodnich odpowiedników. Myślę, że te kilka uwag na początek wystarczy.
-
Witam,
Zabieram się właśnie do zbudowania metalowej kołyski dla mojego Saiteka x45 (a później wymieniłbym pedały Saiteka na własnej konstrukcji :-)). Jeśli chodzi o elektronikę, to myślałem nad wykorzystaniem enkoderów magnetycznych AS5045 lub AS5040 (bardziej u nas dostępny) zamiast potencjometrów - http://www.ams.com/eng/Products/Position-Sensors/Rotary-Magnetic-Position-Sensors/AS5045. Czytając ten wątek doszedłem do wniosku, że najprościej będzie to zrealizować poprzez DMJoya + córka I2C, której zadaniem będzie obsługa enkodera, a w przypadku zmiany jego stanu wysłanie nowej pozycji do DMJoya. Mam w związku z tym pytanie:
Czy w obecnej postaci DMJoya taki sposób komunikacji jest obsługiwany, czy też córka I2C może przesyłać tylko informacje dotyczącą przycisków, a potencjometrów już nie?
Widziałbym to tak, że zbuduję układ, który będzie córką I2C współpracującą z DMJoyem i obsługującą enkoder magnetyczny. Ja wprawdzie uP nigdy nie programowałem, ale od strony zarówno sprzętowej jak i programowej powinienem sobie poradzić. Jestem programistą, więc język C nie stanowi problemu, a jeżeli byłby potrzebny asembler, to swego czasu programowałem w asemblerze procesory Z80 (ZX Spectrum) i Motorole MC68000 (Amiga :-) ). Dodatkowo mój bardzo dobry kolega zajmuje się hobbystycznie budowaniem i programowaniem układów z uP, więc mam dostęp do bazy laboratoryjnej umożliwiającej zlutowanie podzespołów na płytce, a w razie problemów będę miał się do kogo zwrócić o pomoc.
Co o tym myślicie?
-
Czy w obecnej postaci DMJoya taki sposób komunikacji jest obsługiwany, czy też córka I2C może przesyłać tylko informacje dotyczącą przycisków, a potencjometrów już nie?
Obecnie planowana jest obsługa potencjometrów, co jednak nie zamyka drogi do innych układów I/O. Z punktu widzenia M?B źródło danych na D/B nie jest istotne - liczy się jedynie przesłana wartość.
-
Rozumiem. W takim razie ja zamawiam układy i zabieram się za testy i tworzenie prototypu. Na początek i tak najważniejsza jest poprawna obsługa enkodera, bo bez tego nie ma co myśleć o integracji modułów. Ciekaw jestem jak faktycznie będzie z ich dokładnością. A może ktoś z tego forum już coś robił z enkoderami magnetycznymi AS5045 lub AS5040?
-
W związku z zainteresowaniem sterownikiem DMKeys8 chciałbym uzupełnić swoje post związane z rozdzielaczami sygnałów o których pisałem w tym wątku. Na początek małe przypomnienie organizacji matrycy w DMKeys8. Tworzy ją 16 kolumn oraz 10 wierszy co daje 160 pozycji do zaprogramowania. Jest to pokazane na załączonym rysunku.
(http://img854.imageshack.us/img854/6964/cxn9.th.jpg) (http://imageshack.us/photo/my-images/854/cxn9.jpg/)
W tym wątku http://il2forum.pl/index.php/topic,13149.255.html #263 przdstawiłem swoją propozycję organizacji rozdzielaczy sygnałów dla tej matrycy. W pierwszym rzędzie pokazany jest schemat ideowy, montażowy (poglądowy) oraz model płytki nazwanej umownie MasterDMKey zrobionej na druku uniwersalnym. Jak widać na zdjęciach kolumny oznaczone C1-C16 są wyprowadzone na 5 łączówek 16 pin. Wiersze (row1-row10) są wyprowadzone z sterownika na łączówkę JP6 i pogrupowane po 2 oraz wyprowadzone na złącza 2 pin.
Płyta ozn. umownie MasterDMKey łączy się z 5 córkami poprzez sznur 16 pin oraz dwa przewody do złącza 2 pin.
Schemat ideowy i montażowy córki umownie nazwanej DMKeyOut jest pokazany na kolejnych 2 rysunkach. Do każdej córki można podłączyć np 32 przyciski. Do wszystkich córek (pięciu) można podłączyć 160 przycisków. Podłączamy jeden koniec przycisku do wyjść ozn. Out 0 - Out31 a drugi koniec do RA lub RB. Proponowana organizacja rozdzielacza daje rozdzielenie 160 sygnałów na 20 mniejszych grup po 8 sygnałów (diody są już na córkach). Można to inaczej zorganizować w zależności od własnych potrzeb.
W innym miejscu w tym wątku #274 umieściłem DMKeys8 na płytce, na której mam wyprowadzenia 16 kolumn na złączu 16 pin oraz 10 wierszy na złączu 10 pin. Dodatkowo mam wyprowadzone sygnały dla ICP, które potrzebuje tylko 25% pojemności matrycy.
Na koniec kilka ogólnych uwag. Przedstawione przykłady pokazują jak można praktycznie zorganizować matrycę stosując sterownik DMKeys8. Można to zrobić na kilka sposobów w zależności od potrzeb i wiedzy użytkownika. Można np. zamiast powielać sygnały C1-C16 na łączówkach w MasterDMKey zrobić to na taśmie 16 żył zaciskając łączówki 16 pin coś podobnego jak w pc. Można także zamiast połączeń przewodami DMKeys8 i MasterDMKey zrobić to przy pomocy "odpowiedniej podstawki" lub lutując piny wprost do druku (piny w DMKeys8 lutowane z drugiej strony, tylko jeden rząd). Jak widać można zrobić rozdzielacz sygnałów na wiele sposobów. Mam nadzieję, że nie zamieszałem.
Sposób łączenia przełączników 2, 3 pozycyjnych, obrotowych i enkoderów wynika z sposobu konfigurowania DMKeys8. Tutaj Damos może to lepiej wyjaśnić. Dodam tyko, że jest to lepiej zrobione niż w SVMapper.
Jestem na etapie podłączania swoich paneli pod DMKeys8 i pojawił się problem: każdy panel ma przyporządkowaną 1 wiersz czyli 16 wyjść. Osobno każdy działa bezproblemowo ale podłączenie 2 lub więcej powoduje zawieszenie płytki, lub zapętlenie wykonywania zadanej funkcji. Czy powodem może być brak rezystorów przy każdym z przycisków / enkoderów?
-
Nie powinno być problemów z podłączeniem wszystkich przycisków, przełączników lub enkoderów. Nie potrzeba rezystorów, muszą być tylko diody.
Na co zwrócić uwagę. Jeśli ma być opcja "big matrix" to trzeba tę opcje wybrać. Dla tej opcji mamy 10 wierszy ozn. na schemacie PC6, PC7, PE6, PE2, PF0, PF1, PF4, PF5, PF6 i PF7. Kolumny są ozn. PB0-PB7, PD0- PD7. Anody diod są podłączone do kolumn, katody do wierszy. Można zrobić prosty test podłączyć przycisk(z diodą) do dowolnej kolumny i dowolnego wiersza. Drugi przycisk (z diodą) do innego wiersza i dowolnej kolumny. Jeśli to działa to nie powinno być problemu gdy podłączymy pozostałe kolumny do tych dwóch wybranych wierszy. Na stronie Damosa powinna być jakaś uproszczona instrukcja.
-
1N4148 - diody prostownicze - takie będą OK?
-
Będą dobre. Diody muszą być, powinno być o.k
-
Problem zniknął. Dzięki :)
-
1N4148 - diody prostownicze - takie będą OK?
Tak tylko dla porządku - 1N4148 to diody przełączające a nie prostownicze.
-
Robiąc dla mavericks interfejs z płyty MJ16 dla DMKeys8 http://il2forum.pl/index.php/topic,8603.870.html wpadłem na pomysł, aby zrobić coś podobnego dla siebie. Jest pokazany na zdjęciu.
(http://i700.photobucket.com/albums/ww5/vito_zm/test1D.jpg) (http://s700.photobucket.com/user/vito_zm/media/test1D.jpg.html)
Ten na zdjęciu był mi bardzo potrzebny gdy testowałem DMKeys8, ale niestety go nie posiadałem. Obecnie jest wykorzystywany do testowania różnych konfiguracji DMKeys8. Planuję dorobić panel gdzie będą układy wykonawcze czyli enkodery, przełączniki oraz przyciski. W ten sposób mogę sprawdzić "na sucho" bez podłączania do kokpitu działanie podłączonych elementów a następnie tester będzie udawał kokpit tzn. ten fragment, który będzie zaimplementowany.
Na obrazku zaznaczyłem wiersze matrycy DMKeys8 (pogrubiony opis) oraz kolumny cyfry od 0 do 7. MJ16 można sprawdzić 160 wejść przekładając tylko taśmę 8 żyłową na DMKeys8. Powoduje to zmianę kolumn zamiast PB0-PB7 mamy PD0-PD7. W ten sposób jedną płytą MJ16 mogę sprawdzić całą matrycę DMKeys8.
Po sprawdzeniu działania konfiguracji z elementami wejściowymi w testerze mogę bezpiecznie umieścić docelowe elementy wejściowe i je połączyć zgodnie z konfiguracją w kokpicie oraz wgrać konfigurację do docelowego tego w kokpicie DMKeys8. Nie powinno być niespodzianek, jeśli pojawią się problemy związane z długością przewodów to Damos przewidział w sofcie możliwość korekcji.
-
Do wspomnianego wcześniej interfejsu dla DMKeys8 na bazie MJ16 dorobiłem układ wykonawczy, który można podłączyć do interfejsu. Ma on 4 enkodery, przełącznik 6 poz. obrotowy, 3 pozycyjny dźwigniowy oraz 16 przycisków. Mogę w ten sposób sprawdzać działanie sterownika dla różnych konfiguracji.
(http://i700.photobucket.com/albums/ww5/vito_zm/tester.jpg) (http://s700.photobucket.com/user/vito_zm/media/tester.jpg.html)
-
Pełne wykorzystanie możliwości DMKeys8. W ramach projektu dla mavericks przerobiłem drugą płytę MJ16 jako interfejs dla DMKeys8. Płyty są połączone 2 przewodami 10 żyłowymi. Jedną płytę MJ16 można umieścić np. na lewej burcie a drugą na prawej. Tester z prawej strony służy do sprawdzania działania całości.
(http://i700.photobucket.com/albums/ww5/vito_zm/DMKeys-MJ16.jpg) (http://s700.photobucket.com/user/vito_zm/media/DMKeys-MJ16.jpg.html)
-
A mavericks już zaciera ręce i jutro pędzi do Vito odebrać DMjoys Hybrid :) W moim przypadku jest to rewelacyjne rozwiązanie, gdzie przy wsparciu bardzo przyjaznego i przemyślanego softu Damosa stanowi ciekawą alternatywę dla budowniczych kokpitów :) Duży plus jest też taki, że udało się wykorzystać kulejącego mjoya. Może w przyszłości uda się też użyć niektórych nieaktywnych wejść. Tak czy inaczej rozwiązanie jest stabilne i nie potrzebuje żadnego dodatkowego softu działającego w tle podczas gry.
-
Panowie - a propos DMKeys8: korzystam z 3 szt. i na dwóch przy znacznym obłożeniu pamięci (ok 80%) pojawiają się "przeskoki" - przełączenie jednego hebelka powoduje przestawienie innego. Mieliście takie przypadki? Czy powodem może być np. niska jakość enkoderów?
-
Podczas testów płyty MJ16 jako interfejs dla DMKeys8 zauważyłem "przesłuch" jednego wiersza PF1 na PF4, dlatego wiersz PF1 w matrycy jest u mnie wyłączony.Zmniejsza to matrycę z 160 pozycji do 144. Damos już o tym wie i obiecał, że problem rozwiąże. Efekt tego przesłuchu jest taki, że kręcąc enkoderem podpiętym do wiersza PF1 mamy także działanie na PF4. Na pozostałych pozycjach matrycy u mnie jest dobrze.
-
Czy możesz podać w jakim miejscu matrycy pojawiają się te "przeskoki". U mnie pojawiały się tylko w jednym kierunku np. przełączanie przełącznika podpiętego do PF1 działało na element podpięty do PF4 a nie odwrotnie. Zjawisko to dotyczyło tylko jednego wiersza tzn. PF1. Jeśli u Ciebie jest w innym miejscu matrycy to mamy coś nowego.
-
Problem polega na tym, że przeskoki które występują w jednym miejscu po przestawieniu któregoś przełącznika potrafią zacząć występować w innym. Dlatego trudno to zdiagnozować. Przykłady tych najczęstszych: PF/PD4 - PF5/PD4; PF6/PD7 - PF5/PD7; PF5/PD6 - PF5/PD7; PF7/PD6 - PF5/PD7.
Wczoraj zapełniłem pamięć jednej z płytek do poziomu 93%. Pojawiło się zjawisko "wieszania się" płytki, ale po zredukowaniu zapełnienia do 85% ustąpiło.
Poniżej mój sposób rozprowadzenia wiązek do poszczególnych gniazd:
(http://fotozrzut.pl/zdjecia/3ac4780c40.jpg) (http://fotozrzut.pl/)
(http://fotozrzut.pl/zdjecia/66bb17460a.jpg) (http://fotozrzut.pl/)
(http://fotozrzut.pl/zdjecia/6c02771693.jpg) (http://fotozrzut.pl/)
-
To jest inne zjawisko od mojego. W zasadzie powinno to wystąpić także u mnie to takie pierwsze spostrzeżenie. Jak ja to testuję u siebie. Mam zaprogramowaną każdą pozycję matrycy jako liczbę określającą jej położenie na mapie matrycy czyli liczby od 0 do 159 przedzielone spacjami. Testuję w ten sposób, że zwieram po kolei wszystkie pozycje matrycy od 0 do 159. Wiem którą pozycję zwieram i oczekuję na monitorze liczbę określającą tę pozycję. Jeśli jest tzw. przesłuch to oprócz oczekiwanej prawidłowej pozycji matrycy mam wyświetlaną dodatkową pozycję gdzie jest przesłuch. W ten sposób stwierdziłem, że mam wpływ PF1 na PF4 i tylko w jednym kierunku. Pozostałe pozycje matrycy u mnie są ok. Jest jedna różnica między moją metodą a twoim przypadkiem. Ponieważ ten mój test "znakowy" zajmuje dużo pamięci, dlatego podzieliłem całą matrycę na 4 obszary, gdzie każdy obszar jest testowany innym programem testowym. Być może dlatego u mnie wystąpił problem tylko z jednym wierszem.
Mam do testowania tylko jeden MJ16, którym mogę sprawdzić połowę matrycy. Muszę także zredukować program testujący ze względu na zajmowaną pamięć. Jeśli coś znajdę dam znać.
Ponieważ mam u siebie w kokpicie nadmiar kontrolerów w sumie 4 w tym 2 DMKeys8 oraz jeszcze dwa inne układy to obciążenie DMKeys8 jest może w granicach 75%. Nie zauważyłem w kokpicie problemów z przesłuchem. Problem wystąpił gdy robiłem dla mavericks z MJ16 interfejsy dla DMKeys8. Tak jak wspomniałem zrobię inny program testujący obejmujący połowę matrycy i sprawdzę jak to wygląda.
-
Powtórzyłem testy. U mnie jest tak jak opisałem poprzednio. Testowałem połowę matrycy, program testujący zajmuje 91% pamięci. Jest przesłuch PF4 na PF1. Przesłuch polega na tym, że to co jest zapisane na PB0 PF4 powtarza się na PB0 PF1 i tak dalej aż do końca wiersza. Nie ma przesłuchu w drugim kierunku tzn. z PF1 na PF4. W moim przypadku nie programuję PF1 co daje mi ograniczenie matrycy do 144 wejść i obciąża pamięć w 82%. Damos zna problem.
Przy okazji moje gratulacje, mam na myśli kokpit. Czy jest on przeznaczony dla konkretnego symulatora? Możesz coś powiedzieć na temat joysticka.
-
Wspaniały kokpit, Marcin jak możesz to podlinkuj może więcej fotek w innym wątku np. "kokpit własnej roboty full wypas" czy jakoś tak ;) Tutaj chyba nie za wiele osób zagląda. Domyślam się że kokpit jest zrobiony pod latającego świniaka ;)
-
Problem sygnalizowany przez vito_zm i Marcin_B może być związany z długością przewodów i szybkością odczytywania matrycy. Obecnie dla uzyskania przyzwoitej jakości obsługi enkoderów matryca jest odpytywana z częstotliwością taktowania rzędu kilkunastu KHz. Przy bezpośrednich połączeniach (bez przewodów i diod)nie udało mi się zreplikować problemów (na gołej płytce nie mam tych objawów, które ma Vito). Dlatego buduję dużą matrycę 16x10 i na niej będę testować. Niestety - każda sprawa hardware'owa zajmuje mi więcej czasu niż software'owa :(
Jednak dzięki pomocy Marcin_B mam dodatkowe pliki konfiguracyjne i to powinno przyśpieszyć rozwiązanie problemu. (zapewne skończy się spowolnieniem odczytywania lub zmniejszeniem bufora na konfigurację).
Również jedna uszkodzona lub odwrotnie podłączona dioda może dać podobne efekty.
-
U mnie niektóry taśmy między przełącznikiem/enkoderem a Mjoyem mają parędziesiąt centymetrów do tego jeszcze dochodzi przewód łączący Mjoya z DMkeys. Teoretycznie mogę potestować i sprawdzić jak na zjawisku przeskoku przesłuchu wpływa długość taśm. Im dłuższy tym gorzej ? czy powyżej jakiejś wartości długości danej taśmy to już nie ma znaczenia ?
-
Dodam kilka uwag. U mnie w kokpicie niektóre przewody mogą mieć nawet 90cm. Tak jak wspomniałem nie mam problemów z tzw. "przesłuchem" poza jednym wyjątkiem, który opisałem. Mam matrycę do testów tylko 8x10 gdzie mogę przełączać albo PB0-PB7 albo PD0-PD7 czyli mogę sprawdzić cały obszar ale na raty. Kolejna sprawa to program konfiguracyjny. Chciałem mieć czytelny program dlatego dla każdej pozycji matrycy są co najmniej 3 sekwencje określające daną pozycję plus spacja. To pochłania dużo pamięci. Obecnie gdybym miał zestaw mavericks tzn. 2xMJ16 zrobiłbym inną konfigurację tzn. taką aby zaprogramować całą matrycę i zmieścić się w 100% pamięci. Z drugiej strony moje poprzednie programy konfiguracyjne do testowania tylko części matrycy powinny wykryć wszystkie nieprawidłowości, ale może lepiej zrobić to jednym programem. To tyle moich uzupełnień.
-
Chciałbym przy okazji zwrócić uwagę na problem interfejsu oraz matrycy dla DMKeys8. W tym wątku są pokazane różne sposoby realizacji interfejsu. Pod #274 jest pokazana moja realizacja tego interfejsu. Na łączówkach są wyprowadzone 10 wierszy oraz 16 kolumn. Można na bazie tego interfejsu zbudować w prosty sposób matrycę 10x16. Trochę wcześniej zrobiłem projekt matrycy oraz interfejsu dla DMKeys8 pod #263, ale obrazki już nie są wyświetlane.
W ostatnim czasie zrealizowałem interfejs oraz matrycę na bazie dwóch płyt MJ16. Jest to pokazane pod #323. Jeśli kogoś interesuje jak to zrobić to mogę zamieścić schematy.
Inna realizacja pokazana jest pod #328, którą zrobił Marcin_B. Ponieważ kilka osób już zakupiło u Damosa DMKeys8 to każdy zrobił po swojemu matrycę dla tego kontrolera. Może ktoś zrobił już druk pod tę matrycę. Ja kiedyś zrobiłem druk jednostronny, ale dla mniejszych matryc 2x16, które były połączone z płytą master, która rozdzielała sygnały z DMKeys8. To takie uzupełnienie dla tematu DMKeys8.
-
U mnie w kokpicie niektóre przewody mogą mieć nawet 90cm.
Moje nie są dłuższe niż 50cm - tyle tylko żeby sięgnęły do płyty z DMKeys8.
http://fotozrzut.pl/zdjecia/409269fc5a.jpg
http://fotozrzut.pl/zdjecia/25172d92ee.jpg
-
Ładnie wykonane przewody. Przyłączam się do mavericks z sugestią umieszczenia inf. o twoim kokpicie w jakimś wątku.
-
Już jest :)
Forum Miłośników Symulatorów Lotniczych » Zaplecze » Software & Hardware » Sprzęt wykonany samodzielnie » Wątek: DCS A-10C home cockpit
-
Ponieważ miałem zapytanie jak zrobić z płyty MJ16 matrycę dla DMKeys8 to postanowiłem to opisać. Aby w pełni wykorzystać możliwości DMKeys8 potrzebujemy dwie płyty MJ16. Inf. o tych płytach jest pod linkiem https://sites.google.com/site/mjoy16/plytka . Na płytach montujemy tylko diody oraz złącza 2x20 pin. Dodatkowo lutujemy dwie pojedyncze listwy do druku 8 pin oraz dwie pojedyncze 1 pin. Jest to pokazane na zdjęciu pod linkiem http://il2forum.pl/index.php/topic,13149.315.html # 321 i to wszystko jeśli chodzi o matryce dla DMKeys8.
Teraz kilka słów wyjaśnienia. DMKeys8 jest zaprojektowany do sterowania matrycą 10x16 co daje 160 pozycji na mapie. Natomiast matryca dla MJ16 ma strukturę 12x8 czyli 96 pozycji. Jak widać jest różnica w ilości wierszy oraz kolumn w obu matrycach. W związku z czym trzeba dostosować matrycę z MJ16 do DMKeys8. W płycie MJ16 wykorzystujemy 10 wierszy ( 2 wiersze są niepołączone, na zdjęciu czerwona taśma ) oraz wszystkie kolumny. To nam daje 80 pozycji w mapie matrycy, dlatego potrzebujemy dwie płyty MJ16 aby pokryć całą mapę czyli 160 pozycji.
Z schematu MJ16 wynika, że wiersze są wyprowadzone na nóżkach uP pin 1 do pin 8 (ozn. wierszy ) są ozn. wg MJ16 A, B, C, D, E, F, G oraz H. Na zdjęciu jest to taśma góra lewa strona. Dodatkowe brakujące dwa wiersze są na pin 18 uP (wiersz I) na zdjęciu połączony żółtym przewodem oraz pin 21 uP (wiersz L) połączony przewodem kolor czerwony.
Kolumny ozn. na mapie matrycy MJ16 jako liczby od 1 do 8 są wyprowadzone na nóżkach uP pin 22 do pin 29 (1-8 lub C1-C8 jak kto woli). Na zdjęciu jest to taśma prawa strona uP dół. Teraz wystarczy to połączyć z DMKeys8. Do tego służy tzw. interfejs gdzie jest osadzony kontroler Damosa. Druga płytka MJ16 zrobiona tak samo jak ta na zdjęciu ma swój interfejs, który jest połączony z interfejsem z DMKeys8 dwoma taśmami 10 pin. Widać to na innym zdjęciu # 323.
Jutro przedstawię schematy interfejsów. Mam nadzieję, że jest to zrozumiałe.
-
Na załączonym szkicu są oznaczone wyprowadzenia z matryc do zew. elementów typu enkoder, przycisk, przełącznik oraz organizacja matrycy. Matryca ma 16 kolumn oraz 10 wierszy. Na szkicu są pokazane łączówki na MJ16 i rozmieszczenie na nich mapy matrycy. Np. złącze 2x16 ozn PF0 ozn wiersz PF0 (styki z prawej strony złącza), z lewej są kolejne kolumny, gdzie 0 ozn. PB0 na matrycy MJ16-1 lub PD0 na matrycy MJ16-2. 7 ozn. odpowiednio PB7 lub PD7. Do tych złączy podpinamy przełączniki, przyciski lub enkodery.
Obie matryce ozn. MJ16-1 oraz MJ16-2 są połączone z swoimi interfejsami ozn. na szkicu INT-1 oraz INT-2. Na interfejsie ozn. INT-1 jest osadzony kontroler DMKeys8 z którego jest wyprowadzonych 16 kolumn ozn. PB0-PB7 oraz PD0-PD7 oraz 10 wierszy ozn. PC6.....PF0. Wiersze są połączone taśmą 8 żył z płytą M16-1 oraz 2 pojedynczymi przewodami PF0, PF1. Pierwsze 8 kolumn matrycy PB0-PB7 jest połączone taśmą 8 żyłową także z M16-1. Jest to pokazane na załączonym szkicu.
Drugi interfejs ozn. INT-2 jest w podobny sposób połączony z MJ16-2 jak poprzedni INT-1. Interfejsy są z sobą połączone dwoma taśmami 10 pin, gdzie w jednej są wiersze PC6..PF0 (row) a w drugiej kolumny ozn. PD0-PD7 (col). Matryca MJ16-2 realizuje drugą połowę matrycy DMKeys8.
Reasumując realizacja tego pomysłu jest bardzo łatwa i tania, jednocześnie diody są umieszczone na płytach a nie na np. panelach co powinno redykować możliwość przypadkowych zwarć. Mam nadzieję, że ten opis wystarczy do wykonania tego projektu.
(http://i700.photobucket.com/albums/ww5/vito_zm/matrycaD.jpg) (http://s700.photobucket.com/user/vito_zm/media/matrycaD.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/M16-1D.jpg) (http://s700.photobucket.com/user/vito_zm/media/M16-1D.jpg.html)
(http://i700.photobucket.com/albums/ww5/vito_zm/M16-2D.jpg) (http://s700.photobucket.com/user/vito_zm/media/M16-2D.jpg.html)
-
W związku z problemami Marcin_B z DMKeys8 próbowałem rozeznać problem. Moim zdaniem problem jest związany z enkoderami. Zrobiłem także u siebie testy z 8 enkoderami podłączonymi do mojej testowej matrycy z DMKeys8. Otrzymałem następujące wyniki. Z 4 tanich enkoderów dwa były dobre z pozostałych 4 droższych ED161110 3 były dobre jeden zły. Zła praca enkodera polega na tym, że np. dla obrotu w prawo generuje co jakiś czas przypisanie do obrotu w lewo. Np. jeśli przypiszemy dla obrotu w prawo sekwencję R spacja a dla obrotu w lewo L spacja to możemy otrzymać coś takiego: obrót w prawo R R R R L R R itd i odwrotnie L L L R L L itd. U mnie w tych wadliwych tak to wyglądało. Czasami przeskok następuje tylko dla określonej pozycji kątowej obrotu, czasem dla kilku pozycji. Ponieważ jest to element mechaniczny to jest to możliwe. Te ED161110 mają 24 impulsy na obrót. W tych gorszych może występować zjawisko nakładania się zboczy sygnałów dla obu kanałów. Wg katalogu odstęp pomiędzy zboczami powinien wynosić 1/2 impulsu, ale w praktyce tak nie jest i przy małym jitterze może być problem. Damos przewidział korekcję dla tych gorszych, ale to może nie wystarczyć.
Praktyczny wniosek jest taki, że tam gdzie są potrzebne precyzyjne enkodery np. strojenie radia musimy albo kupić droższe ale kupić większą liczę tanich i zrobić selekcję. Selekcja polegałaby na wykonaniu testu z DMKeys8. Te wadliwe można zastosować w innych miejscach kokpitu np. regulacja jaskrawości wyświetlacza HUD. Jeśli ktoś ma u siebie dobrze działające enkodery to może poda ich typ.
-
Po aktualizacji do Win 10 soft Damosa przestał widzieć płytki. Czy ktoś z Was ma ten sam problem i pomysł jak go rozwiązać? Problem jest chyba sterownikach do USB.
-
Temat na czasie. Zastanawiam się, czy nie edytować nowego wątku. Chcę zrobić modernizację mojego komputera oraz zmienić system operacyjny i przewiduję duże problemy. Ponieważ mój kokpit jest dedykowany pod BMS4 to pytanie podstawowe czy Win 8 (8.1) współpracuje z tym symulatorem. Jeśli tak to jest duża szansa, że będzie z Win 10. Może ktoś już to przerabiał.
-
U mnie BMS działa na laptopie z Win 8.1 bez żadnego problemu :)
-
To jest dobra wiadomość. Rozwinę ten temat w swoim wątku, ponieważ jest on związany z BMS4 oraz hardware i softem z nim związanym w powiązaniu z fizycznym kokpitem. Myślę, że temat może być interesujący dla macieja oraz drejku oraz innych zainteresowanych budową kokpitów.
-
W związku z ostatnimi pracami mam do was kilka pytań.
Na prośbę Marcina_B zająłem się w ten weekend problemem z Windows 10 i sprawa okazuje się nieco bardziej złożona:
1) ludzie od LibUSB mają problem z Win10 i zupełnie odradzają korzystania z "Filtered Mode", jak to było dotychczas
2) brak filtered mode uniemożliwia pod Windows bezpośredni kontakt z urządzeniem, ponieważ takie device'y jak mysz lub klawiatura są otwierane przez System Operacyjny w trybie wyłączności
Z tych powodów niemożliwe jest skomunikowanie się z hardwarem tak, jak to było dotychczas robione - pozostają mi dwie drogi:
a) utrzymać widoczność urządzenia jako klawiatury i dodać do niego drugie "virtualne" urządzenie do komunikacji i programowania (powinno zadziałać pod Windows, ale spożytkuje więcej zasobów więc możliwa, maksymalna konfiguracja urządzenia będzie mniejsza (krótsze sekwencje klawiszy, mniej urządzeń itp))
b) porzucić "udawanie" klawiatury przez urządzenie i stworzyć dedykowany software, który będzie się komunikował z płytką i sam generował sekwencje klawiszy w odpowiedzi na użycia fizycznych urządzeń. Wtedy będzie można definiować długie sekwencje, opóźnienia między przyciskami itp
c) przejść na inny microchip, który łatwiej udźwignie dwa urządzenia w jednym - ale wtedy posiadany aktualnie hardware będzie mniej rozwojowy :(
opcja A):
za:
- utrzymanie uniwersalnego interface'u klawiatury
- utrzymanie tego samego wyglądu aplikacji do konfiguracji
- brak konieczności uruchamiania dedykowanego oprogramowania na PC
przeciw:
- zmniejszy się maksymalna wielkość danych konfigurujących urządzenie (jak bardzo - nie wiadomo)
- każda płytka będzie widziana jako dwa osobne urządzenia: jedno to klawiatura a drugie to urządzenie do jej konfiguracji
- nadal nie można będzie wstawiać opóźnień między klawiszami ani tworzyć sekwencji z jednym klawiszem wciśniętym i kilkoma zwalnianymi i wciskanymi
- bardziej skomplikowany firmware
opcja b)
za:
- można będzie wstawiać opóźnienia między klawiszami, tworzyć sekwencji z jednym klawiszem wciśniętym i kilkoma zwalnianymi i wciskanymi
- ilość zaprogramowanych sekwencji będzie niemal nieograniczona
- uproszczenie firmware
- możliwość software'owego wstępnego ustawiania stanu przycisków/przełączników
przeciw:
- dodatkowy software po stronie PC, który będzie musiał być uruchomiony aby połączyć się z płytką i aby sekwencje klawiszy były generowane
- ryzyko konieczności tworzenia w/w software wraz z kolejnymi wersjami Windows
- zapewne nieco zmieniony software do konfiguracji
opcja c)
za:
- większe możliwości w nowym hardware
- lepsze (?) ADC w nowym hardware (12 bit)
przeciw:
- stary hardware pozostanie z aktualnym software
- stack firmware robiony "na nowo"
- software po stronie PC też pewnie ulegnie zmianie
Rozsądek podpowiada wariant A, ambicja wariant B, ciekawość wariant C.
Nie wiem, jak bardzo istotne są dla Was długie i skomplikowane sekwencje klawiszy?
-
Nie wiem, jak bardzo istotne są dla Was długie i skomplikowane sekwencje klawiszy?
Nie są istotne.
Z mojego punktu widzenia istotne jest czy DMKeys8 pracuje poprawnie pod Win8.2. Na forum BMS4 panuje przekonanie, że Win10 ale za jakiś czas, są z nim w tym symulatorze sterowanym fizycznym kokpitem pewne problemy.
Ci którzy mieli do czynienia z innymi sterownikami oraz softem np. SIOC OpenCockpit czy SimOut wiedzą jaką zaletą jest obecne rozwiązanie Damosa. Jest to nawet prostsze od MJoy z SVMapper.
Zdaję sobie sprawę ile czasu potrzeba na zrobienie wariantu A, B lub C. Jeśli DMKeys8 pracuje pod Win8.2 to można założyć, że obecna wersja DMKeys8 może być jeszcze atrakcyjna przez co najmniej 1 rok lub dłużej.
Jeśli masz czas i możliwości to wybierz takę wersję, która jest dla Ciebie do zrobienia w jakimś realnym terminie. To jest moje zdanie, ale koledzy mogą mieć inne.
-
Z mojego punktu widzenia istotne jest czy DMKeys8 pracuje poprawnie pod Win8.2.
DMKyes8 po skonfigurowaniu pracuje poprawnie pod każdym systemem operacyjnym: od Windows 98 przez MacOS, Unix, Linux po OS/2.
Jedynie zmiana konfiguracji wymaga podłączenia maszyny w WinXP <-> Win7 z zainstalowanym LibUSB
-
W sumie to nie jest to aż taki duży problem, zawsze ktoś z znajomych może mieć jeszcze Win7 (ja mam WinXP). Można tak jak wspomniałem pomyśleć o wersji A, B lub C, ale w jakimś realnym terminie. Tutaj Ty znasz najlepiej swoje możliwości. Faktycznie za 1-2 lata będzie tylko Win8 lub Win10, czyli trzeba coś zrobić.
-
Jeszcze raz przeczytałem to co napisałeś. Jeśli dobrze rozumiem to możemy konfigurować w obecnej chwili w WinXP oraz Win7. Jeśli powstanie opcja A lub B to stare zaprogramowane DMKeys8 można będzie ponownie przeprogramować w nowym soft konfiguracyjnym w Win 8.2 lub Win 10. W opcji C stare DMKeys8 można przeprogramować tylko w WinXP lub Win 7. Z tego wynika, że wygodniejszy jest wariant A lub B dla tych, którzy już mają DMKeys8. Jeśli chodzi o opcje A lub B to wybór zależy od Twoich możliwości czasowych. Z tego co wiem to Maciej z forum chce zakupić DMKeys8 a pracuje na Win 8.2, czyli musiałby konfigurować na innym pc z WinXP lub Win 7. Dobrze, że ta sprawa została zauważona. Pojawiły się także problemy u Macieja z platformą HSC Codeking w Win 8.2.
-
A jak w kwestii wyboru jednej z tych trzech oopcji ma się sprawa DMJoy (w sensie terminu jego wydania)? Bo pewnie oprócz mnie znalazłoby się pewnie kilka osób zainteresowanych tym rozwiązaniem (tutaj 12-bitowa rozdzielczość osi jest szczególnie interesująca).
A tak mi jeszcze przyszło do głowy - czy jest szansa, że oprogramowanie konfiguracyjne ruszy na wine po Linuxem. Bo jeżeli tak, to kilka rozwiązań włącznie z mini dystrybucją na maszynie wirtualnej mogłoby załatwić problem systemu operacyjnego.
-
W sumie to nie jest to aż taki duży problem, zawsze ktoś z znajomych może mieć jeszcze Win7 (ja mam WinXP). Można tak jak wspomniałem pomyśleć o wersji A, B lub C, ale w jakimś realnym terminie. Tutaj Ty znasz najlepiej swoje możliwości. Faktycznie za 1-2 lata będzie tylko Win8 lub Win10, czyli trzeba coś zrobić.
Też się pod tym podpisuję. Płytki DMK8 programuję za pomocą lapka z XP-kiem. Oczywiście byłoby wygodniej móc robic to z poziomu W10 ale tragedii nie ma. Damos - wybierz rozwiązanie najbardziej optymalne wg Swojej wiedzy.
-
A jak w kwestii wyboru jednej z tych trzech oopcji ma się sprawa DMJoy (w sensie terminu jego wydania)?
Tu DMKeys8 powinno być swego rodzaju "rozgrzewką". Po długim czasie, kiedy nie miałem szans na zajęcie się Joyem - chcę wrócić i dokończyć. Dlatego zapewne wybiorę wariant A. Taki sam model rekonfiguracji otrzyma DMJoy. Joy już działa - trzeba tylko dorobić mu oprogramowanie konfigurujące. Chyba, że zdecydujemy, iż nie jest konieczne rekonfigurowanie Joy'a - wtedy temat jest niemal zakończony.
Jeśli chodzi o konfiguracje - były plany dotyczące wbudowanego zerowania, trymerów, mapowania pinów na konkretne przyciski Joy'a itp.
A tak mi jeszcze przyszło do głowy - czy jest szansa, że oprogramowanie konfiguracyjne ruszy na wine po Linuxem.
Planowane jest natywne uruchamianie softu konfiguracyjnego pod Linuxem (Debian/Ubuntu), bez konieczności stosowania Wine'a. Soft korzysta z bibliotek QT a komunikacja posiada warstwę abstrakcji względem USB, więc - żadnych emulatorów.
-
Wariant A przeszedł właśnie fazę "Proof Of Concept" i potwierdził wykonalność tej idei :)
W ciągu około tygodnia powinienem mieć nową wersję Firmware i Software, które będą działać na wszystkich systemach Windows (od XP do 10) bez konieczności instalowania dodatkowych bibliotek. Tu liczę na pomoc kogoś w testowaniu na nowych OS'ach :)
Przejście tej ścieżki otworzyło pewne nowe możliwości przed DMJoy8. Mianowicie:
1) Układ ma 12 osi analogowych a Windows jest w stanie obsłużyć jedynie 8. Pozostałe 4 są "marnotrawione". Początkowo planowałem:
1a: z tamtych 4 osi zrobić wewnętrzne trymery obsługiwane hardware'owo - za pomocą dodatkowych, fizycznych potencjometrów.
Jednak teraz można zrobić coś innego:
1b: Urządzenie będzie pracować (będzie widoczne dla systemu operacyjnego) jak dwa Joysticki: Jeden z 8-ma osiami analogowymi a drugi z 4-ma. Dodatkowo, do tych 4-ch osi analogowych Joysticka2 można dodać emulowane osie analogowe, sterowane np. hatem lub osobnymi przyciskami: wciśnięcie będzie powodowało przesunięcie osi w jedną lub w druga stronę a jeszcze inny przycisk będzie powodował wyzerowanie. Może być to pomocne w sterowaniu kierunkiem omiatania wiązką radarową lub wskazywaniem celu (sterowana klawiszami oś idealnie utrzymuje zadaną wartość bez konieczności trzymania dodatkowego drążka) Który wariant jest bardziej interesujący 1a czy 1b? A może oba?
2) Do DMJoy8 można dodać emulację myszy - wtedy za pomocą HAT'a będzie się dało poruszać wskaźnikiem myszki. Feature wart uwagi?
-
Dla mnie wariant 1b jest interesujący podobnie jak emulacja myszy, chociaż 1a jest też przydatny. Wszystko zależy od Twoich możliwości czasowych realizacji tych pomysłów.
-
Dla mnie również 1b jest bardzo przydatne (u mnie będzie dużo osi). Jeśli chodzi o myszkę, to ja chyba wolę używać tradycyjnej myszy lub trackballa.
-
Mi też opcja 1b bardziej się podoba. :)
-
Czołem,
Jeśli można się dosiąść :) ja bym się pisał na ver 1b. I to w kilku egzemplarzach ;).
-
Ok, w takim razie wersja 1b.
Obecnie pracuję nad wersją A dla DMkeys8.
Zaraz po niej będzie pierwsza wersja DMJoy8 bez myszy.
-
Szukając uszkodzenia w moim drążku oraz aktualizując moje pliki TMJ i TMM które są podstawą profilu dla Cougara przypomniałem sobie jakie robiliśmy założenia dla DMJoy. Ponieważ nie wszystko rozumiem to postanowiłem ten temat tutaj rozwinąć. Nie znam innych symulatorów oraz joysticków oprócz Cougara dlatego rozpocznę od niego. Załóżmy, że chcemy zrobić kontroler dla Cougara dla drążka oraz przepustnicy. Załóżmy, że przepustnica oraz drążek pracują po I2C. Ponieważ kontrolery do Cougara są obecnie nie do zdobycia to powstał pomysł aby zastąpić go DMjoy Damosa. Rozumiem, że DMJoy będzie widziany w Windows jako joystick z swoimi analogowymi osiami oraz przyciskami, hatami i przełącznikami czyli tak jak w CCP Cougara w opcji bez emulacji. Pozostaje problem zaprogramowania DMJoya oraz zrobienia pliku .key w BMS4 dla Cougara lub dowolnego innego joysticku.
Zakładam, że w programie konfiguracyjnym DMjoy można przypisać kombinacje klawiszy dla przycisków, hat oraz przełączników oraz zrobić ustawianie zakresów dla osi analogowych. Wracam do pliku konfiguracyjnego w setup BMS4 tzw pliku . key. W setup BMS4 są różne pliki .key zakładam, że nas interesuje plik blank (bez przypisań klawiszy). W tych plikach .key są tzw. callbacks związane z przepustnicą (24) oraz drążkiem (23). Jeśli dobrze rozumiem to po przypisaniu w konfiguracji DMJoya klawiszy robimy te same przypisania dla callbacks w setup BMS4. Ta procedura może być stosowana dla innych symulatorów oraz joysticków. Jeśli cos pomieszałem to proszę o wyprostowanie.
-
Komunikacja po I2C byłaby świetnym rozwiązaniem- wystarczają tylko 2 przewody do komunikacji plus masa i zasilanie co jest dużym ułatwieniem. Przez I2C skomunikować się z ekspanderem, który można dostać w obudowie takiej jak rejestry ze stick'a Cougara więc wielkość płytki byłaby identyczna z tą oryginalną.
Łatwo powiedzieć- trudniej wykonać, a czasu brak. :(
-
Oryginalnie Cougar nie wykorzystuje I2C. Tam są proste rejestry dostępne szeregowo. Z przepustnicy z potencjometru idzie sygnał analogowy.
Mam już elektronikę do własnego Cougara na bazie DMJoy8, ale działa jak zwykły joystick i nie obsługuje jeszcze wszystkiego w przepustnicy.
Co pada w Cougarze najczęściej? Główna jednostka sterująca, czy rejestry w drążku/przepustnicy?
-
Wiem wiem o rejestrach badałem je za pomocą oscyloskopu ;) U mnie padł główny procek- co dziwne działa wszystko oprócz przełączników w stick'u.
-
Chciałbym wyjaśnić parę spraw. Problem Cougara to jedna sprawa a DMJoy to inna. Co do DMJoy to ma to być uniwersalny kontroler dla różnych zastosowań w tym różnych joysticków. Moja sugestia to zrobienie takiej wersji, które jest realna do wykonania w jakimś sensownym terminie. Biorąc za przykład Cougara to są dwie opcje. Jedna to dwa niezależne DMJoy w przepustnicy oraz w podstawie drążka. Druga to jeden DMJoy obsługujący po I2C przepustnicę oraz drążek. Niezależnie od opcji DMJoy powinien mieć interfejs I2C dotyczy to tego od drążka. Obecnie w drążku są rejestry szeregowe i po 5 przewodach komunikują się z kontrolerem. Wiem, że jest problem z zrobieniem interfejsu I2C w drążku ze względu na małą powierzchnię ale to jest problem na później.
Aby rozpocząć sensowne testy to potrzeba DMJoy z kontrolerem I2C oraz interfejs z nim współpracujący. Ten interfejs powinien mieć kontroler I2C oraz wejścia cyfrowe podobne do tych w drążku Cougara przyciski, haty oraz przełączniki. Po konfiguracji można taki model sprawdzić w symulatorze. Nie potrzeba profili, ponieważ będzie dla Windows joystickiem. Takie rozwiązanie nie ogranicza DMJoy tylko do Cougara.
Wracając do problemów macieja to tak jak napisał rejestry są dobre, ale kontroler nie widzi przełączników co jest trochę dziwne, ponieważ widzi pozostałe elementy np. hats czy przyciski. U mnie nie widzi przycisku S3 pinky, ale bez niego mogę używać drążek. Nie sprawdzałem dokładnie ponieważ zrobię to później, u mnie przycisk jest sprawny. Założyłem, że może wejście rejestru. Maciej chce zastosować u siebie rozwiązanie Hempstick, gdzie autor zrobił kontroler i napisał program pod drążek Cougara i jego oryginalny interfejs. Może maciej wyjaśni dokładniej.
Reasumując wg mojej oceny DMJoy powinien mieć oprócz analogów możliwość programowania przycisków, hats oraz przełączników w ilości podobnej do drążka Cougara po interfejsie I2C. Aby to testować potrzeba DMjoy oraz interfejs I2C z wejściami cyfrowymi.
-
Wersja DMJoy do obsługi Cougara będzie inna niż zwykły DMJoy. Pewnie będzie się nazywać DMCJoy. Planują wykorzystać obecną elektronikę w sticku (bo ona nie pada) i obecne okablowanie do sticka i do przepustnicy. W przepustnicy nie ma żadnej elektroniki po za diodami od matrycy. Mam cougara - więc z tym problemu nie będzie. Inna kwestia jest podłączenie - nie chcę ciąć oryginalnych wiązek więc pewnie zrobię jakąś płytkę przejściową.
Apropos: znacie jakieś źródło przyzwoitej kołyski do Cougara? Mój ma takie luzy, że... :) Chodzi mi o samą kołyskę - bez elektroniki
-
Wersja DMJoy do obsługi Cougara będzie inna niż zwykły DMJoy. Pewnie będzie się nazywać DMCJoy. Planują wykorzystać obecną elektronikę w sticku (bo ona nie pada) i obecne okablowanie do sticka i do przepustnicy. W przepustnicy nie ma żadnej elektroniki po za diodami od matrycy.
To jest bardzo dobra wiadomość. Faktycznie w przepustnicy jest tylko matryca. Ja za jakiś czas rozbiorę mój drążek i zrobię schemat elektryczny płyty oraz połączeń z elementami. Są dostępne diagramy połączeń ale to za mało. Ponieważ nie działa u mnie S3 to będę musiał to zlokalizować. Zrezygnowałem z modu opartego na tensometrach i powróciłem do kołysek. Dlaczego to zrobiłem napisałem w innym wątku. Zapytaj macieja on będzie musiał przerobić drążek pod swój kokpit i kołyski będą u niego niepotrzebne, podobnie u drejku.
-
Kołyska z naszego Cougara nadaje się jedynie na złom. Luz w osi Y jest ogromny- potrzeba by dotoczyć tuleję o grubości co najmniej 2mm żeby się tego pozbyć.
-
Dotarły do mnie informacje o problemach z zainstalowaniem sterowników umożliwiających wgranie nowego Firmware na płytki. Poniżej prezentuję krótki tutorial, jak to zrobić:
1) Należy zacząć od zainstalowania programu FLIP ze strony Atmela:
http://www.atmel.com/tools/FLIP.aspx
(jeśli ktoś się nie orientuje - niech wybierze opcję: "FLIP 3.4.7 for Windows (Java Runtime Environement included)"
Podczas instalacji FLIP na dysku komputera zostaną umieszczone sterowniki. Użyjemy ich później.
2) Przełączyć płytkę w tryb DFU Bootloader poprzez użycie 2 przycisków znajdujących się na płytce lub za pomocą dołączonego programu do konfiguracji
2a) - za pomocą przycisków:
wciśnij i trzymaj przycisk Reset
wciśnij i trzymaj przycisk HWD
zwolnij przycisk Reset
odczekaj przynajmniej sekundę lub dwie
zwolnij przycisk HWD
odczekaj kilka sekund
2b) - za pomocą dołączonego programu: po zaznaczeniu na liście właściwego urządzenia program pozwala na zdalne "bezdotykowe" włączenie trybu DFU za pomocą klawisza "Start DFU"
3) należy wejść do Menagera Urządzeń":
(http://s10.postimg.org/w40or8xyt/image.jpg) (http://postimg.org/image/w40or8xyt/)
4) sprawdzić, czy widać w nim sekcję "Atmel USB Devices" wraz z urządzeniem ATmega32U4:
(http://s10.postimg.org/kmkbzshyt/image.jpg) (http://postimg.org/image/kmkbzshyt/)
5) jesli taka sekcja istnieje i posiada pozycje ATmega32U4 - możemy zakończyć pracę, ponieważ oznacza to, że sterownik został pomyślnie zainstalowany
6) jeśli takiej sekcji nie ma:
(http://s10.postimg.org/53mw2o9o5/image.jpg) (http://postimg.org/image/53mw2o9o5/)
- oznacza to, że musimy zainstalować sterowniki. Należy wtedy znaleźć "Nieznane urządzenie USB" i kliknąć na nim prawym przyciskiem myszy. Ja zamiast "nieznanego urządzenia" mam już Atmega32U4 - i posłużę się nim: czynności sa takie same:
(http://s10.postimg.org/tvmi9wqut/image.jpg) (http://postimg.org/image/tvmi9wqut/)
7) pojawi się menu, w którym należy wybrać opcję aktualizacji sterownika
(http://s10.postimg.org/nn16gbt9x/image.jpg) (http://postimg.org/image/nn16gbt9x/)
8) kolejne okno pozwoli na wybór - czy szukać sterownika lokalnie, czy w Internecie. Wybrać: lokalnie
(http://s10.postimg.org/w2qqxtw51/image.jpg) (http://postimg.org/image/w2qqxtw51/)
9) następne okno pozwoli wskazać lokalizacje sterownika. Zależy ona od tego, gdzie został zainstalowany program FLIP:
(http://s10.postimg.org/majhefvud/image.jpg) (http://postimg.org/image/majhefvud/)
10) trzeba wskazać właściwa lokalizację i kliknąć "dalej"
(http://s10.postimg.org/pwuco78j9/image.jpg) (http://postimg.org/image/pwuco78j9/)
11) nastąpi proces instalacji sterownika a po nim pojawi się informacja:
(http://s10.postimg.org/k7926rw1h/image.jpg) (http://postimg.org/image/k7926rw1h/)
12) można już pracować z programem FLIP - nawet bez odłączania urządzenia od PC. Jeśli FLIP nie widzi - można odpiąć płytke od USB, podłączyć ponownie i włączyć tryb DFU (opisywana już sekwencja z przyciskami Reset i HWD lub Przycisk programowy "Start DFU")
13) Po poprawnym zainstalowaniu sterowników Atmega32U4 i włączeniu trybu - DFU Menager Urządzeń powinien pokazywać sekcję Atmel wraz z wykrytym kontrolerem:
(http://s10.postimg.org/aa33atur9/image.jpg) (http://postimg.org/image/aa33atur9/)
Mam nadzieję, że to rozwiąże problemy z używaniem programatora FLIP.
-
Dzięki Damos, zrobiłem tak jak napisałeś i działa. Zrobiłem to na starym Flip 3.4.1, ale mam nadzieję, że to dla Win7 nie ma znaczenia. Pojawił się komunikat, że brak podpisu, ale to pominąłem najważniejsze, że można programować kości.
-
Apropos: znacie jakieś źródło przyzwoitej kołyski do Cougara? Mój ma takie luzy, że... :) Chodzi mi o samą kołyskę - bez elektroniki
Mógłbym spróbować odtworzyć ale potrzebowałbym do tego kogoś z okolic Śląska/Bydgoszczy żebym mógł zwymiarować i wykonać model w komputerze.
A potem wystarczyłoby na maszynę to wrzucić.
Taki odgrzewany post trochę ale dopiero teraz doczytałem wątek do 25 strony ;)
-
Jak tylko znajdę trochę czasu po obronie mogę postarać się zwymiarować i zrobić model :)
-
Chciałem spróbować zabrać się za schemat połączeń zanim przyjdą mi płytki i elektronika niestety wszystko co znajduje google prowadzi do miniatur niewyświetlanych już na forum obrazów :(
Czy mógłbym prosić o namiar na jakieś źródło którego nie udało mi się znaleźć lub podesłanie na maila?
-
Mam problem z płytką DMKeys8. Teoretycznie sterowniki wgrane, komputer widzi płytkę. Programem Flip wgrywam firmware, reset płytki i niby powinno być OK. Niestety nie jest. Programikiem od Damos-a "DamosUSBCfg" chcę zacząć coś robić ale ten nie widzi płytki , dopiero jak wyłączę pokazywanie tylko kompatybilnych urządzeń w programie, to widzi,. Lecz nie pokazuje wersji, vendor ID, produkt ID itd. Mam system Win 7, zatem powinno wszystko działać.
Ktoś wie co się dzieje ?
(http://images76.fotosik.pl/720/671764cd5f9390a8.jpg)
-
Mogę tylko potwierdzić, że w Win7 u mnie jest ok. Jeśli nie było problemów przy wgraniu Flipem firmware to musi być widziane w "DamosUSBCfg" nie zależnie od on/off kompatybilnych urządzeń. Może jest problem z aktualnym firmware (pliki hex oraz eep) oraz wersją DamosUSBCfg.
-
Uzupełnienie. Mam u siebie DamosUSBCfg oraz DMKeys8 (hex oraz eep) z 2012-05-21. Prawdopodobnie jest jakiś konflikt z wersjami.
-
Jeśli to nie problem, to może kolega podeśle mi swoje hex i eep oraz DamosUSBCfg, podam mail-a na pv.
-
Mam problem z płytką DMKeys8. Teoretycznie sterowniki wgrane, komputer widzi płytkę. Programem Flip wgrywam firmware, reset płytki i niby powinno być OK. Niestety nie jest. Programikiem od Damos-a "DamosUSBCfg" chcę zacząć coś robić ale ten nie widzi płytki , dopiero jak wyłączę pokazywanie tylko kompatybilnych urządzeń w programie, to widzi,. Lecz nie pokazuje wersji, vendor ID, produkt ID itd. Mam system Win 7, zatem powinno wszystko działać.
Ktoś wie co się dzieje ?
(http://images76.fotosik.pl/720/671764cd5f9390a8.jpg)
Wg tej fotki to płytka jest nadal w trybie programowania (DFU) czyli coś się nie załadowało i dlatego konfigurator jej nie widzi.
Jak ją podłaczasz do FLIPa to ją teraz też widzi? U mnie jak są zaprogramowane to FLIP przestaje je widzieć a widzi je konfigurator. Ja w konfiguratorze właczę tryn DFU to jest odwrotnie - FLIp zaczyna ją widzieć a konfigurator nie.
-
No nie, program ją widzi dopiero po wciśnięciu resetu na płytce, Flip teraz nie widzi, dopiero jak za pomocą drugiego przycisku na płytce wejdę do DFU to Flip ją widzi. Flip potwierdza prawidłowe wgranie hex-a ale po resecie programik damis-a nie rozpoznaje płytki.
-
Nie powinno być problemów z programowaniem DMKeys8. Jak programować jest opisane tutaj https://sites.google.com/site/damosmpds/projects/programowanie-ukladow/programming
Na załączonym obrazku widać, że program widzi Atmel. Można nacisnąć dla pewności przycisk DFU i przejść do Flip. Tutaj zgodnie z instrukcją Damosa (link) zaprogramować kość hex, eep. Po zaprogramowaniu uP można sprawdzić innym programem np. USBDeview jak jest widziany uP Damosa. Powinno być Urządzenie wejściowe USB HID oraz inne parametry oraz nazwa Damos.....a nie Atmel. Jeśli tak jest to w programie konfiguracyjnym Damosa taż powinno być to samo co w USBDeview. Jeśli nie to jest konflikt z wersją firmware DMKeys8.hex, DMKeys8.eep oraz DamosUSBCfg. Pliki, które wysłałem powinny być dobre. Daj znać jak poszło.
-
Dokładnie tak robiłem, programem DamosUSBCfg ściągniętym z tej strony (starsza wersja) przełączałem w tryb DFU bez problenu. Nowszą wersją tego programu, ktorą dostałem od Marcina a z której wrzuciłem wcześniej zrzut z ekranu, przejść w tryb DFU się nie da, pewnie z powodu braku kompatybilności. Tak jak pisałem, ten nowszy program widzi płytkę tylko jak wyłączony jest tryb kompatybilności, jak widać włączenie trybu DFU jest nieaktywne. Flipem czyściłem też pamięć płytki, nie zmieniło to zachowania się względem starszej i nowszej wersji DamosUSBCfg.
Vito_zm podeślij mi jeszcze plik eep.
-
Wysłane.
Tak jak pisałem, ten nowszy program widzi płytkę tylko jak wyłączony jest tryb kompatybilności
Co widzi czy Atmel czy Damos...
Po wgraniu Flipem firmware Damosa co widzi np. USBDeview czy Atmel czy Damos...
-
Przed i po widzi Atmel, dlatego zakładam, że to coś z firmware. FLIP pokazuje prawidłowe wgranie.
-
Jest to ciekawe zjawisko. Sugerowałem inny program do sprawdzenia np. USBDeview aby wyeliminować program konfiguracyjny Damosa. Jeśli Flip wgrał firmware DMKeys8 to niezależnie od wersji powinno to być widziane jako Damos a nie Atmel. Może jest coś na płytce (zwarcie) co powoduje, że kontroler nie może przejść do normalnej pracy. Może jest ktoś w W-wa z DMKeys8. Byłoby łatwiej razem poeksperymentować.
-
Ja tak troszkę odbiegnę od tematu za co z góry przepraszam - ale czy zamiast tylu diod do matrycy przycisków nie lepiej byłoby wykorzystać rejestry przesuwne? Z tego co czytałem damos ma opanowane programowanie po różnych interfejsach i2c etc. po spi można podpiąć wiele takich rejestrów.
-
Z tego co wiem, to damos nie miał za bradzo czasu jej testować przed wysłaniem do Wolfa. Wszystko jest możliwe.... No i ponoć był już wgrany hex.
-
ale czy zamiast tylu diod do matrycy przycisków nie lepiej byłoby wykorzystać rejestry przesuwne? Z tego co czytałem damos ma opanowane programowanie po różnych interfejsach i2c etc. po spi można podpiąć wiele takich rejestrów
Otworzę nowy wątek i postaram się zrobić porównanie kontrolerów stosowanych przez nas na tym forum do budowania kokpitów. Temat jest o tyle na czasie, że coraz więcej kolegów stosuje już u siebie Arduino. Ja mam u siebie układy Damosa, codeking oraz OC, ale od jakiegoś czasu poznaję Arduino i próbuję zastosować te kontrolery do BMS.
-
No i niestety lipa, nadal układ jest widoczny tylko jako Atmel. Niby hex wgrany, reset i Guzik... Napisałem do damos-a, może znajdzie tycio czasu ? Kataklizm - tylko piwo złagodzi mój ból :cry: .
-
OK to była długa walka ale udało się, płytka działa. FLip był dobrze zainstalowany, sterowniki USB też, plik hex i eep na płytkę też był dobrze zainstalowany.
Problemem okazał się brak "libusb-win32-devel-filter", u mnie w dodatku po zainstalowaniu go, i włączeniu testu pojawiał się BLUE SCREEN. Problemem było zbyt wiele urządzeń USB a może tylko jakieś jedno. Po wielu próbach udało się to zrobić "libusb-win32-devel-filter-1.2.2.0", ta wersja ma wybór przy instalacji, jakimi urządzeniami ma się zajmować. Wybrana została tylko płytka DMKey8 i wszystko zaczęło działać bez problemu :) Dzięki Damos za poświęcony czas, ważne że problem udało się rozwiązać.
-
Gratulacje, faktycznie był to ciekawy przypadek. Uruchomiłem kilka DMKeys8 i nie było z tym problemu, ale kiedyś musiał być ten wyjątek najważniejsze, że działa.
-
Panowie, możecie pokazać jak łączycie przewody od przycisków, tak by uniknąć pajączków ? Myslę o jakiejś płytce uniwersalnej za panelem, tak by do DMKey8 szłą tylko wiązka ze złączką.Coś takiego jak to http://www.piekarz.pl/pl/?item=1681 lub http://www.piekarz.pl/pl/?item=1663
-
Zobacz w tym samym wątku pod #321. Coś takiego zrobiłem kiedyś dla kolegi na bazie pcb dla MJoy16, ale można to zrobić inaczej robiąc swój rozdzielacz sygnałów.
-
Ja tak troszkę odbiegnę od tematu za co z góry przepraszam - ale czy zamiast tylu diod do matrycy przycisków nie lepiej byłoby wykorzystać rejestry przesuwne?
"zwykłe" rejestry przesuwne same się nie "zatrzasną". W dodatku po "zatrzaśnięciu" trzeba sobie ręcznie przesłać ich stan - bit po bicie. Obecny układ skanuje matryce kilka tysięcy razy na sekundę. Jest to potrzebne szczególnie w przypadku enkoderów, które generują szybkozmienne sygnały z żałośnie małym przesunięciem czasowym miedzy kanałami. W przypadku stosowania rejestrów nie byłoby to możliwe.
Zamiast rejestrów używam innych układów: MCP23S17 (szybsze), ale wtedy nie będzie enkoderów lub będą...ale tylko porządne :)
Jednak najpierw muszę zakończyć proces pozbywania się sterowników LibUSB.
Dzięki Damos za poświęcony czas, ważne że problem udało się rozwiązać.
:) Było to całkiem ciekawe doświadczenie. Słyszałem o problemach LibUSB z trybem "filtered", ale jeszcze nigdy się z tym nie spotkałem "na żywo". Prawdopodobnie jest to kwestia konfliktów z innymi sterownikami. Teraz pamiętaj, że nie możesz zmieniać VID ani PID albo po zmianie musisz "doinstalować" filtr na nową parę identyfikatorów.
-
Jestem nowy na forum, wiec jako ze to mój pierwszy post wszystkich serdecznie.
Witam,
Piszę w wątku ponieważ nie otrzymałem odpowiedzi na PW do od Damosa. Czy można otrzymać kontakt do osoby która pomogła by w związku z DMKey8? Najchętniej jakieś na miary namiary od kogo/gdzie można zakupić urządzenie.
Pozdrawiam
Regulamin forum. Mazak.
-
DMKey8 kupisz tylko u Damosa, robi to na zamówienie i jest to jego projekt. Damos jest strasznie zarobiony, nie ma zbytnio czasu ostatnio tu zaglądać. Jak ma tycio czasu to pracuje nad przystosowaniem oprogramowania do Win10. Czasem spotykam go na Skype, mogę mu przekazać, że się do niego dobijasz. Ale czy znajdzie czas szybko to nie wiem.
-
Dzięki za szybką odpowiedz. Byłoby super!
-
Damos czytał wiadomość i powiedział, że się odezwie . Z góry przeprasza ale jest zawalony robotą. Cytuję " dostałem maila, ale chcę człowiekowi odpisać dłużej niż w 2 słowach
i nie ma kiedy" .
-
No to będę czekał cierpliwe, jeszcze raz dzięki za pomoc.